The Semaphore Trade-Off: Diagnosing Throughput Regression in a GPU Proving Pipeline

Introduction

In the high-stakes world of Filecoin proof generation, every second counts. A Groth16 proving pipeline that processes 32 GiB sectors must balance two competing constraints: memory capacity and throughput. Push synthesis parallelism too hard, and the system runs out of memory. Throttle it too aggressively, and proof times suffer. Message 3126 captures a pivotal moment in this balancing act — a benchmark run that would reveal whether a critical memory fix had inadvertently destroyed the performance gains of an entire optimization phase.

The message is deceptively simple: a bash command launching a batch benchmark, followed by its first five completion lines. But behind this routine output lies a story of careful diagnosis, a discovered bottleneck, a structural fix, and the sobering realization that every engineering decision carries hidden costs.

The Context: Phase 12 and the Memory Wall

To understand message 3126, we must first understand what led to it. The assistant had been implementing Phase 12 of a multi-phase optimization effort for the cuzk SNARK proving engine — a CUDA-accelerated Groth16 prover used in Filecoin's proof-of-replication (PoRep) pipeline. Phase 12 introduced a "split GPU proving API" that decoupled the GPU worker's critical path from CPU post-processing by offloading the b_g2_msm operation into a background thread. This architectural change promised to hide latency and improve throughput.

Initial benchmarking of Phase 12 had been promising. With the optimal configuration of gw=2 (GPU workers), pw=10 (partition workers), gt=32 (GPU threads), and j=15 (concurrent jobs), the system achieved 37.1 seconds per proof — a ~2.4% improvement over the Phase 11 baseline of 38.0 seconds. The split API was working.

But then the assistant pushed further. Increasing pw from 10 to 12 (more parallel CPU synthesis workers) triggered OOM (Out of Memory) failures, with RSS (Resident Set Size) peaking at 668 GiB on a 755 GiB system. The memory wall had been hit.

Tracing the Memory Buildup

The assistant's response to the OOM was methodical. Rather than simply reducing parallelism, they built instrumentation — a global buffer tracker with atomic counters (buf_synth_start, buf_abc_freed, buf_dealloc_done) that provided real-time visibility into every large buffer class in flight. This instrumentation revealed the root cause with stark clarity.

The buffer counters showed provers=28 at peak — meaning 28 synthesized partitions were alive simultaneously, each holding approximately 16 GiB of data (12 GiB for the a, b, c NTT evaluation vectors plus 4 GiB for auxiliary assignments). That alone accounted for roughly 336 GiB of the 668 GiB peak. The auxiliary buffer counter (aux) hit 99-100, though this was later identified as a counter bug (bellperson's deallocation path never decremented the counter) rather than actual memory leakage.

The root cause was a subtle timing issue in the pipeline architecture. The partition semaphore (which limited concurrent synthesis to pw=12) released its permit immediately after synthesis completed, before the synthesized job was delivered to the GPU channel. This meant that while one partition sat in the channel queue holding 16 GiB of data, the semaphore had already allowed another synthesis task to start. With the GPU consuming partitions at roughly 3.5 seconds each and synthesis completing in about 5 seconds, the backlog grew at a rate of approximately 9 partitions per cycle.

The Semaphore Fix

The fix was elegant and surgical: hold the semaphore permit until after synth_tx.send() completes, so that the semaphore enforces not just "max N synthesizing" but "max N between start-of-synthesis and channel-accept." The assistant modified the code in engine.rs to move the permit variable out of the spawn_blocking closure and into the outer async block, ensuring it was only dropped after the synthesized job was successfully enqueued for GPU processing.

The result was dramatic. Peak RSS dropped from 668 GiB to 294.7 GiB — a 56% reduction. The provers counter peaked at exactly 12, matching the pw limit. The OOM was solved.

But there was a catch. The fix introduced a throughput regression: with pw=12, proof time increased from the expected ~37 seconds to 39.9 seconds per proof. By holding the semaphore through the channel send, synthesis was now throttled by GPU throughput. The pipeline had gone from memory-bound to throughput-limited, and the balance had shifted too far.

Message 3126: The Diagnostic Benchmark

This is where message 3126 enters the story. The assistant had a hypothesis: perhaps the regression was specific to pw=12, where the semaphore was overly restrictive. Maybe pw=10 — the original optimal configuration — would show different behavior with the semaphore fix applied.

The message reads:

[assistant] [bash] /home/theuser/curio/extern/cuzk/target/release/cuzk-bench batch --type porep --c1 /data/32gbench/c1.json --count 20 --concurrency 15 2>&1
[2026-02-20T11:24:32.612808Z  INFO cuzk_bench] loading C1 output path=/data/32gbench/c1.json
=== Batch Benchmark ===
proof type:  porep
count:       20
concurrency: 15

  [1/20] COMPLETED — 66.6s (prove=65672 ms, queue=291 ms)
  [2/20] COMPLETED — 103.9s (prove=71200 ms, queue=726 ms)
  [3/20] COMPLETED — 139.8s (prove=72279 ms, queue=1140 ms)
  [4/20] COMPLETED — 176.1s (prove=72192 ms, queue=1592 ms)
  [5/20] COMPLETED — 213.0s (prove=7...

The configuration is pw=10 (partition workers), with concurrency=15 (maximum concurrent proofs in flight). The benchmark runs 20 proofs against the same C1 input file. The output shows cumulative wall-clock time and per-proof breakdowns.

The first proof completes in 66.6 seconds total (65.7 seconds of actual proving plus 0.3 seconds of queue wait). Subsequent proofs show a pattern: each takes roughly 36-40 seconds of prove time, with queue times growing as the system reaches steady-state. By the fifth proof, the cumulative wall time is 213.0 seconds, meaning the fifth proof alone took about 36.9 seconds (213.0 - 176.1 = 36.9s).

This is critical data. The per-proof prove times in the 65-72 second range shown here are cumulative — they include the time the proof spent in the queue waiting for previous proofs to complete. The actual GPU processing time per proof (visible in the per-proof breakdown) is what matters for throughput analysis.

What the Results Reveal

The assistant truncated the output after the fifth completion, but the pattern is already visible. The queue times grow steadily (291ms, 726ms, 1140ms, 1592ms...), indicating that the system is saturated at concurrency=15. The prove times per individual proof (subtracting queue time from wall time) suggest the system is operating in the 36-40 second range per proof.

Comparing to the Phase 11 baseline of 38.0s and the Phase 12 optimal of 37.1s, this pw=10 run with the semaphore fix appears to be competitive. The assistant would need to see the full 20-proof run to calculate the steady-state throughput, but the early indications are that pw=10 with the semaphore fix may restore performance close to the original 37.1s/proof, while pw=12 with the fix regressed to 39.9s/proof.

This makes physical sense. With pw=10, the semaphore limits synthesis to 10 concurrent workers. The GPU processes a partition in ~3.5 seconds, and synthesis takes ~5 seconds. With 10 workers, the pipeline can sustain roughly 2 partitions completing per GPU cycle (10 workers × 5s synthesis / 3.5s GPU = ~14 partitions in flight, but capped at 10 by the semaphore). The system is balanced. With pw=12, the extra 2 workers create a slight oversupply that, when throttled by the semaphore-through-channel-send, manifests as idle synthesis capacity and longer overall proof times.

The Deeper Engineering Insight

Message 3126 represents more than just a benchmark run. It embodies a fundamental tension in pipeline design: the coupling between memory pressure and throughput is nonlinear and configuration-dependent. The semaphore fix that solved the OOM problem did so by serializing two previously decoupled operations — synthesis completion and channel delivery. This serialization converted a memory problem into a throughput problem, but only at certain configuration points.

The assistant's approach — testing multiple configurations (pw=10, pw=12) with the same fix — demonstrates a systematic methodology. Rather than accepting the regression at face value and reverting the fix, they are probing the design space to understand where the trade-off is acceptable and where it isn't. This is the mark of mature engineering: not just fixing bugs, but characterizing the behavior of the fix across the operating envelope.

Conclusion

Message 3126 captures a single benchmark invocation, but it sits at the intersection of several critical threads in the proving pipeline optimization effort: memory instrumentation, concurrency control, pipeline backpressure, and the ever-present tension between throughput and resource consumption. The assistant's systematic approach — diagnose, fix, measure, iterate — transformed an OOM crisis into a deeper understanding of the synthesis-to-GPU coupling.

The story doesn't end here. The assistant would go on to revert the semaphore change and instead increase the channel capacity from 1 to partition_workers, allowing a natural buffer of completed jobs without blocking the semaphore. But message 3126 remains a crucial data point — the moment when the cost of the memory fix was quantified, and the search for a better balance began.