Apple M5 Max R1CS-over-GF(2) hashing throughput, measured

§ 01 · native hashing baseline

Per-core scalar hashing: M5 Max vs M4 Max

Single-threaded software hashing (no crypto-extension instructions), the reference for Flock's single-threaded prover. Per-core, the two chips are a wash — the M5 Max's advantage for this prover is core count and bandwidth, not single-core speed.

§ 02 · keccak-f[1600] throughput

Thread scaling at the 2¹⁴ keccak point

Flock's keccak MT optimum is 2¹⁴ (KECCAK3_KS=24576). The auto-default pins to 6 = perflevel0 and leaves the chip under-used; throughput peaks at 12–18 threads. 12 is the reproducible sweet spot — 18 only edges ahead on best-case runs.

§ 03 / 04 · throughput vs batch size

Per-hash proving throughput (12 threads)

Throughput climbs with batch size for every hash. The proving-cost order is BLAKE3 (cheapest) → SHA-256 → keccak (heaviest), matching their R1CS weight. BLAKE3 is still rising at 2¹⁸; keccak shown at its single 2¹⁴ profile point.

§ 06 · per-phase prover breakdown

Where prove time goes (2¹⁴, 12 threads)

zerocheck dominates every hash, with the recursive pcs::open the next-largest. Open is also the phase that scales worst with threads — it regresses past 12, which is exactly why 12 threads beats 18 in typical runs.

§ 07 · parallel scaling (BLAKE3)

Single-thread vs multi-thread, and the speedup

One core saturates at ~94–97 K/s from 2¹⁴ up. 18 threads only overtake 12 from 2¹⁶ onward — below that, too little work to feed all cores. Peak is 815.8 K/s at 2²⁰ (9.0× single-core); note the consistent dip at 2¹⁹ (both thread counts), a tiling/load-imbalance artifact.

Why 2¹⁹ dips. At both 12t and 18t, 2¹⁹ falls below 2¹⁸ and 2²⁰ — a reproducible kink, not noise. 2¹⁹ = 524,288 work units doesn't divide evenly across 12 (43,690.67) or 18 (29,127.1) cores, so the parallel phases end with a lopsided tail where a few cores finish late and the rest idle (load imbalance). The even powers 2¹⁸/2²⁰ land on clean boundaries the prover splits evenly, so they skip the remainder tax. Cache/TLB stride effects at ~15 GB likely compound it. Same root cause as §08's under-utilization, sharper here.

§ 05 · keccak 2¹⁴ profile — fast vs slim

The rate-1/4 proof-size tradeoff

At matched 12 threads, the slim prover costs ~31% more prove time (130 vs 99 ms) to cut the proof ~48% smaller (200 vs 386 KiB). Verify (~5 ms) and the 128 MB committed size are unchanged. Bars show prove time; proof size labeled on each.

A third variant, Flock-secure (~120-bit), proves at essentially the same speed as fast (249 vs 246 K/s) for a larger proof (558 KiB) — see the cross-prover section below for how all three stack up against other systems.

§ 02–05 · cross-prover comparison

Flock vs Binius64 vs Hashcaster vs Plonky3 (12 threads, 2¹⁴)

At matched threads and comparable security, Flock proves keccak ~5.9× faster than Binius64, ~6.2× faster than Hashcaster, and ~42× faster than Plonky3, and ~11–12× faster than the others on BLAKE3 (Hashcaster has no SHA-256/BLAKE3 circuit).

Throughput isn't the only gap — Flock's verification is far cheaper too (keccak 2¹⁴, log scale):

Caveats: security bits differ slightly (Binius64 ~96, Plonky3 ~101, Flock & Hashcaster ~100); throughput = hashes / prove, end-to-end incl. trace/witness gen; these are independent compressions, not a chain. Hashcaster is the lightest on memory (367 MB) but has the largest non-Plonky3 proof (664 KiB). Plonky3's proofs are far larger (3.35 MiB keccak, 9.48 MiB BLAKE3) and it peaks at 10.6 GB on keccak.

§ 08 · why it caps at 816K — and the path to 1M

The bottleneck, and what would break past it

§07 shows BLAKE3 peaking at 816K compressions/sec (2²⁰, 18 threads) and declining beyond. This section is the diagnosis: why it caps there, and whether 1M is reachable. The headline — it's not memory bandwidth. The witness at 2²⁰ is 2 GB; commit and zerocheck move only ~10 GB/s against the M5 Max's 614 GB/s ceiling, roughly 2% of available bandwidth, so the bus is nearly idle. The real limit is idle cores: across the full prove, user/real time holds at ~12.5× (three runs), so only ~12 of 18 cores are busy. Zerocheck and commit — 77% of prove time — are under-parallelized and leave ~6 cores unused.

Recursion / partitioning does not help. Four independent 2¹⁸ proofs run concurrently (4 threads each) finished in 7.7 s wall — ~136K/s effective, ~6× slower than the single 2²⁰ run. Splitting adds contention without filling the idle cores, since the cores sit idle inside each proof's serial sections, not for lack of work. (Memory verified clean: swap never engaged, the prover got the full 128 GB.) Conclusion — 1M is reachable on this chip, in software. It's neither bandwidth- nor compute-bound but parallelism-bound: better parallelization of the commit (NTT/Merkle) and zerocheck (sumcheck) phases to keep all 18 cores busy clears the 816K→1M gap — no recursion, bigger batches, or new hardware needed. The fix belongs in the Flock prover's inner loops, made and correctness-tested in-tree. Footnotes: isolated single-phase benches show even lower utilization (commit ~4.8×, zerocheck ~2.3×) but include serial setup, so the trustworthy figure is the in-context ~12.5×; and 18 cores beat 12 here (~18% at 2²⁰), unlike small keccak where the PCS open over-threads past 12 — scaling is size-dependent.