The Surgical Revert: Learning from a 19% Regression in Groth16 Proof Optimization

Message Overview

The subject message ([msg 866]) is deceptively brief — a single sentence from the assistant followed by a successful file edit:

"Let me revert to using synthesize_circuits_batch (no hint) at all call sites and keep the _with_hint API available but unused."

This three-line message is the culmination of a sophisticated diagnostic chain spanning five preceding messages ([msg 862] through [msg 865]), representing a critical turning point in the Phase 4 optimization campaign for the cuzk pipelined SNARK proving engine. What makes this message significant is not what it says, but what it implies: a carefully reasoned retreat from a well-intentioned optimization that backfired spectacularly.

The Context: Phase 4 Compute-Level Optimizations

To understand why this revert was necessary, we must reconstruct the context. The cuzk project had just completed Phase 3 — cross-sector batching — achieving a 1.42× throughput improvement by batching two sectors' circuits together, amortizing synthesis cost while scaling GPU time linearly. Phase 4 was intended to deliver "compute quick wins" from a detailed optimization proposal document (c2-optimization-proposal-4.md).

The assistant had implemented five optimizations in the preceding messages:

  1. A1 — SmallVec for LC Indexer: Replaced Vec<(usize, Scalar)> with SmallVec<[(usize, Scalar); 4]> in the bellpepper-core fork, eliminating ~780 million heap allocations per partition. This is a stack-first optimization that avoids the heap entirely for small linear combination entries.
  2. A2 — Pre-sizing for ProvingAssignment: Added a new_with_capacity constructor to ProvingAssignment in the bellperson fork, allowing upfront allocation of the ~131M-element vectors (a, b, c) rather than relying on incremental doubling reallocation.
  3. A4 — Parallelize B_G2 CPU MSMs: Changed a sequential loop to use groth16_pool.par_map, parallelizing the B_G2 multi-scalar multiplications across CPU threads.
  4. B1 — Pin a,b,c vectors with cudaHostRegister: Added cudaHostRegister/cudaHostUnregister around the Rust-provided arrays to enable faster GPU DMA transfers by pinning host memory.
  5. D4 — Per-MSM window tuning: Split the single msm_t object into three instances tuned for the distinct popcount characteristics of L, A, and B_G1 MSMs. These changes were implemented across three separate codebases: the bellpepper-core fork, the bellperson fork, and the supraseal-c2 fork — all patched into the workspace via [patch.crates-io]. The release build compiled successfully, and the assistant launched an E2E benchmark with real 32 GiB PoRep data on an RTX 5070 Ti.

The Regression Discovery

The benchmark result ([msg 862]) was alarming:

| Metric | Baseline (Phase 3) | Phase 4 | Change | |--------|-------------------|---------|--------| | Total time | 88.9s | 106.0s | +19.2% | | Synthesis | 54.7s | 61.6s | +12.6% | | GPU (wrapper) | 34.0s | 44.2s | +30.0% | | GPU (bellperson) | ~34s | 35.6s | ~comparable |

The assistant's immediate reaction — "This is unexpected and concerning" ([msg 863]) — is telling. The optimizations were supposed to reduce time, not increase it. The discrepancy between the bellperson GPU timer (35.6s, comparable to baseline) and the wrapper timer (44.2s, +10.2s) was a crucial clue: the extra 8.6s was coming from overhead outside the core GPU proving logic, specifically the cudaHostRegister/cudaHostUnregister calls added by B1.

The Diagnostic Reasoning

The assistant's analysis in [msg 864] demonstrates a methodical approach to performance regression diagnosis. Two root causes were identified:

Synthesis regression (A2 pre-sizing): The new_with_capacity constructor allocated ~4.1 GiB per vector × 8 vectors = ~32.8 GiB per circuit. With 10 circuits running in parallel via rayon, this meant 328 GiB of upfront allocation all at once. The previous incremental doubling strategy spread memory pressure over the synthesis duration, allowing the OS to fault in pages gradually. The upfront allocation caused a page-fault storm — 328 GiB of virtual memory pages all faulting simultaneously — combined with TLB pressure and potential NUMA effects. This is a classic case of an optimization that looks good in isolation (avoiding reallocation copies) but fails in practice when the scale of allocation overwhelms the memory subsystem.

GPU regression (B1 pinning): For 10 circuits × 3 arrays (a, b, c) × ~4 GiB each = 30 cudaHostRegister calls pinning ~120 GiB total. The assistant had earlier noted ([msg 843]) that cudaHostRegister is slow — approximately 50-100ms per 4 GiB. At that rate, 30 calls would add 1.5-3.0 seconds of overhead. The actual 8.6s discrepancy suggests even worse performance, possibly due to the kernel's DMA mapping table pressure or contention when registering such large regions concurrently.

The Surgical Revert

Message [msg 866] executes the first corrective action: reverting the usage of A2 pre-sizing while keeping the API infrastructure in place. This is a deliberate architectural decision, not a panicked rollback. The assistant writes:

"Let me revert to using synthesize_circuits_batch (no hint) at all call sites and keep the _with_hint API available but unused."

This phrasing reveals several layers of strategic thinking:

  1. Surgical precision: Only the call sites are changed, not the API itself. The synthesize_circuits_batch_with_hint function and the SynthesisCapacityHint struct remain in the codebase, available for future use.
  2. Preserving option value: The pre-sizing infrastructure might be valuable in a different context — perhaps with a single circuit, or with NUMA-aware allocation, or with a different memory allocator (e.g., jemalloc with MALLOC_CONF=background_thread:true).
  3. Isolating variables: By reverting only A2's usage, the assistant can now run benchmarks to measure the remaining optimizations (A1 SmallVec, A4 parallel B_G2, D4 per-MSM window tuning) in isolation, without the confounding effect of the A2 regression.
  4. Keeping A1: The SmallVec optimization is explicitly retained because it's "pure stack, no memory issues" — a stack-based optimization cannot cause page-fault storms.

Assumptions Made and Validated

Several assumptions underlay the original Phase 4 implementation, and the regression exposed which ones were incorrect:

Faulty assumption: "Pre-allocating large vectors upfront will reduce time by avoiding reallocation copies." This assumption failed because it ignored the concurrency multiplier — 10 circuits running in parallel × 32 GiB each = 328 GiB of simultaneous allocation. The incremental approach, while theoretically less efficient, spreads allocation over time and avoids pathological memory subsystem behavior.

Faulty assumption: "cudaHostRegister overhead is negligible for a few large arrays." The assumption was that 30 calls × ~100ms = ~3s would be acceptable. The actual overhead was 8.6s, suggesting either slower per-call performance or additional hidden costs (e.g., TLB shootdowns, DMA remapping).

Validated assumption: "SmallVec is safe because it uses stack allocation." The A1 optimization was retained because stack allocation cannot cause page faults at this scale — each SmallVec is a fixed-size inline array on the stack, not a heap allocation.

Validated assumption: "The API abstraction is worth the complexity." By keeping _with_hint available but unused, the assistant preserved the ability to re-enable pre-sizing later with different parameters (e.g., smaller initial capacity, sequential allocation, or a custom allocator).

Knowledge Required and Created

To understand this message, the reader needs knowledge of:

The Thinking Process

The assistant's reasoning chain from [msg 862] to [msg 866] reveals a disciplined diagnostic methodology:

  1. Measure first: Run the benchmark before analyzing code. The 106s result is data, not speculation.
  2. Disaggregate timings: Separate synthesis (61.6s) from GPU (44.2s wrapper, 35.6s bellperson). The discrepancy between the two GPU timings is the key clue.
  3. Quantify the scale: Calculate exact allocation sizes — 131M elements × 32B = 4.1 GiB per vector × 8 vectors = 32.8 GiB per circuit × 10 circuits = 328 GiB.
  4. Identify the mechanism: Page-fault storm, TLB pressure, NUMA effects — not just "slower code" but a specific memory subsystem pathology.
  5. Isolate variables: Revert A2 first (most likely culprit for synthesis), then measure again. If GPU time remains high, revert B1 next.
  6. Preserve infrastructure: Don't delete the API — it may be useful with different parameters or a different allocator. This is textbook performance debugging: form a hypothesis, isolate variables, measure, and iterate. The assistant's willingness to revert its own work — to admit that an optimization was counterproductive — is a hallmark of rigorous engineering.

Broader Implications

The Phase 4 regression and subsequent revert have implications beyond this single optimization wave. They demonstrate that:

  1. Optimizations interact nonlinearly: A2 pre-sizing and B1 pinning, each reasonable in isolation, combined to produce a 19% regression. The concurrency multiplier (10 circuits in parallel) transformed a local optimization into a global pathology.
  2. Memory subsystem effects dominate at scale: At 200+ GiB working sets, allocation strategy, page fault handling, and TLB behavior matter more than algorithmic efficiency. The incremental doubling strategy, while theoretically less efficient, was empirically superior because it respected the memory hierarchy.
  3. GPU pinning overhead is real: cudaHostRegister is not free. For workloads with large host arrays and frequent register/unregister cycles, the overhead can exceed the DMA speedup.
  4. The value of measurement infrastructure: The assistant had detailed phase-level timing from both bellperson and the wrapper. Without this disaggregation, the root cause would have remained hidden behind the aggregate 106s number.

Conclusion

Message [msg 866] is a masterclass in disciplined optimization engineering. In three lines of text and one file edit, the assistant executed a surgical revert that preserved architectural investment while removing a counterproductive optimization. The message is the visible tip of a deep reasoning chain — five messages of diagnosis, quantification, and hypothesis testing — that transformed a 19% regression into actionable knowledge. The _with_hint API remains in the codebase as a monument to this learning, ready to be deployed when the right conditions arise. The revert is not a failure; it is the most productive outcome possible: a wrong hypothesis eliminated, a correct diagnosis confirmed, and the path cleared for the next iteration.