scoreboard: acpu vs Apple Accelerate

baseline: M1 Pro (8P+2E), 2026-04-03

M4 Max — SME / SME2 / SSVE (2026-05-22)

new M4-only paths: streaming::Stream, sme::matmul_f32_sme, lut::permute_u8, streaming::kern::axpy_f32.

sme matmul (single-thread, vs AMX path)

SME baseline is correct but loses to AMX at every measured size. The gap closes as N grows; the path to WIN is 4-way ZA tile interleave (hide FMOPA's 4-cycle latency) + persistent SME worker pool. Tracked as Phase 2.5 in .claude/plans/m4_upgrade.md.

lut permute u8 (LUTI4 → SVE TBL in streaming, vs NEON vqtbl1q_u8)

Hits the ≥2× target. Implementation note: uses SVE TBL inside SME streaming mode rather than LUTI4 — LUTI4's multi-vector register-tuple semantics is friction for the single-16-byte-table case.

ssve axpy

4 unit tests pass at n=16, 64, 1024, 73. Standalone benchmark currently hangs; root-cause investigation tracked as Phase 4.5.

tip5 (scalar, vs twenty-first 1.1.0 reference)

Throughput on M4 Max single-thread:

• 3.24 M permutations / s
• 3.43 M Merkle inner-node hashes / s

5 bit-identity tests (acpu/tests/tip5_compat.rs) pass against twenty-first 1.1.0 — 1000 random permutations, 1000 random hash_pair calls, hash_varlen across padding boundaries 0,1,9,10, 11,30,100,1000 plus random length sweep, and 5 edge-case states.

Honest summary: acpu's scalar Tip5 is at performance parity with twenty-first and exposes a cleaner u64 API (no BFieldElement / Digest construction at the call site). Real perf gain for nika's heapify_mary bottleneck (~448ms / proof) requires either P-core parallelism (embarrassingly parallel Merkle layers) or batched SIMD across multiple Tip5 states — neither is necessary for the correctness goal of swapping twenty-first out of the prover hot path.

tip5 ILP batching experiment (negative result)

The 4-way interleaved variant runs four independent Tip5 permutations simultaneously in scalar code, exposing more parallel work to the CPU's OOO engine. The 1.02× speedup confirms the OOO engine already extracts most ILP from a single Tip5 permutation; adding more independent work doesn't help.

implications for M4-feature optimization

Memory bandwidth check: ~1 KB per permutation × 3 M permutes/s = 3 GB/s. M4 Max has ~200 GB/s — Tip5 is two orders of magnitude below saturating memory. The bottleneck is compute throughput.

To beat twenty-first on M4 we need genuine SIMD instruction-set parallelism, not just ILP:

SSVE empirical results — Tip5 cannot be sped up by SME on M4

Wrote the load-bearing primitive simd::raw_mul_batch8 (8-way SVE Goldilocks Montgomery multiply) and the fused simd::sbox_x7_8way (4 chained multiplies, register-to-register, no LD/ST between). Both pass bit-identity tests against scalar.

Scalar wins by ~3.8× even in the fused-kernel best case where SSVE has zero LD/ST overhead between chained multiplies. M4's scalar OOO engine is unusually well-matched to Goldilocks Montgomery multiply (carry/borrow flag idioms, wide instruction issue, MUL+UMULH pair). SVE's per-instruction overhead and constrained issue rate on M4 do not amortize.

This rules out SSVE as a path to beat twenty-first on Tip5. The remaining win is P-core multi-threading (8–10× via std::thread::scope on independent Merkle layers) — not M4-specific, but the only demonstrably-positive optimization direction left.

where M4 features DO help honeycrisp

Reaffirmed positive results from earlier phases:

• LUTI lookup: 2.0–3.2× over NEON vqtbl1q_u8 on byte permute (sizes ≥ 4 KB) — useful for Tip5's split-and-lookup S-box if a fused-permute kernel were built around it, but the kernel cost swamps any S-box savings.
• SME GEMM: baseline single-thread; loses to AMX path for now. 4-tile interleave (Phase 2.5) is the path to WIN here.
• SSVE axpy: correctness ✓, perf bench pending root-cause on bench hang (Phase 4.5).

Strategic takeaway: M4 SME/SSVE shine for genuine vector workloads with no scalar fast path (sparse matmul, large LUT permute, dense fp32 GEMM at sizes where Apple Accelerate has overhead). They do not help Goldilocks-flavour ZK arithmetic where ARM64 scalar is already at the architectural sweet spot.

tip5 multi-threaded Merkle layer — the actual win

After confirming SSVE doesn't help, switched to the only direction with empirical headroom: P-core multi-threading.

acpu::field::tip5::tip5_hash_pair_n_par(pairs, out, 0) — std::thread::scope partitioning across P-cores with acpu::sync::affinity::pin_p_core pinning. Correctness gated by assert_eq! in the bench.

Throughput on M4 Max (12 P-cores, sequential ~3.03 M hashes/s):

Falls below the 12× P-core ceiling because (a) macOS QoS is a soft pin not hard affinity, (b) shared LOOKUP_TABLE / ROUND_CONSTANTS create cross-core memory contention, (c) thermal throttling on sustained loads.

Net for nika: heapify_mary at 448 ms (= 1.54 M hashes / proof at 3.43 M/s scalar) drops to roughly 105 ms with the parallel path at 13 M/s. About 70% reduction in the dominant bottleneck.

elementwise f32 (4096 elements)

reductions f32 (4096 elements)

compound

sgemm (GFLOPS)

crypto (vs CommonCrypto/OpenSSL)

ZK (vs nebu pure Rust)

summary

• losses: 1 (exp)
• ties: 6 (log, sum, dot, max, min, sgemm×2 — at hardware ceiling)
• wins: 12

how to update

cargo run --release -p acpu --example bench_summary