Phase 12 Delivers: The Split GPU Proving API and the Memory Wall

Introduction

In the relentless pursuit of faster Groth16 proof generation for Filecoin's Proof-of-Replication (PoRep), every millisecond counts. The opencode session captured in message [msg 3054] represents a critical inflection point: the successful completion of Phase 12's split GPU proving API, delivering a tangible 2.4% throughput improvement, but also revealing a hard memory ceiling that would define the project's next frontier. This message, written by the AI assistant after committing the Phase 12 code at 99c31c2c, is simultaneously a victory lap and a sobering reality check. It announces a working architectural refactor, documents a critical concurrency bug fix, presents benchmark numbers, and delivers a clear-eyed assessment of the memory capacity constraints that now limit further scaling.

The Message in Context

To understand what [msg 3054] accomplishes, one must understand the problem it solves. The Groth16 proving pipeline in the supraseal-c2 CUDA backend had a structural bottleneck: the generate_groth16_proofs_c function was a monolithic, synchronous operation. A GPU worker thread would enter this function, acquire the GPU lock, perform the GPU kernel work (NTT, MSM), release the lock, and then—still inside the same function—run the CPU-bound b_g2_msm (the G2 MSM computation for the b proof element). This CPU post-processing step took approximately 1.7 seconds, during which the GPU worker was blocked from picking up the next synthesized partition. In a pipeline where every partition's GPU work is precious and the GPU itself is the most expensive resource, having a worker idle for 1.7 seconds while the GPU sat idle (or was used by another worker) represented pure waste.

Phase 12's core insight was simple: decouple the CPU post-processing from the GPU worker's critical path. By splitting the monolithic function into generate_groth16_proofs_start_c (which handles the GPU work and returns a pending handle) and finalize_groth16_proof_c (which completes the CPU computation), the GPU worker could immediately loop back to pick up the next partition, spawning a separate tokio task to finalize the proof in the background. This is the classic split-phase or "deferred execution" pattern, applied to GPU proving.

What the Message Reports

The message is structured as a concise engineering report with three sections: what was done, benchmark results, and memory analysis. Let us examine each in detail.

The Implementation

The assistant reports three key technical achievements. First, the C++ generate_groth16_proofs_c was refactored into start + finalize functions. This required creating a new groth16_pending_proof heap-allocated struct to hold all shared state between the two calls. Second, the GPU worker loop in the Rust engine was restructured to spawn a finalizer tokio task, allowing the worker to immediately loop back for the next job. Third—and critically—a use-after-free bug was discovered and fixed during this refactoring.

The use-after-free bug is particularly instructive. The prep_msm_thread (a background thread that runs b_g2_msm) was capturing a reference to the provers parameter, which was a stack-allocated array of Assignment<fr_t> structs passed into the C function. Because prep_msm_thread was launched as a std::thread that could outlive the function call, the thread would read from dangling stack memory after the function returned. The fix was to copy the provers array into the heap-allocated groth16_pending_proof struct as provers_owned, ensuring the background thread always accesses stable memory. This is a classic C++ concurrency pitfall: capturing stack references in background threads without ensuring the referenced objects outlive the thread.

The Benchmark Results

The message presents a clean three-row table:

| Config | Throughput | vs Phase 11 baseline | |--------|-----------|---------------------| | pw=10 gw=2 gt=32 | 37.1s/proof | 2.4% faster than 38.0s | | pw=12 | OOM (~668 GiB peak) | Too much memory | | pw=15 | OOM (immediate) | Way too much memory |

The headline number is 37.1 seconds per proof with the optimal configuration of partition_workers=10, gpu_workers=2, gpu_threads=32. This represents a 2.4% improvement over the Phase 11 baseline of 38.0 seconds. While 2.4% may seem modest, it is pure throughput gain from architectural optimization—no additional hardware, no algorithmic changes to the core proving math. The 1.7 seconds of b_g2_msm that was previously blocking the GPU worker has been successfully offloaded to a background task.

But the real story is in the OOM rows. Attempting to increase partition parallelism to pw=12 caused the process to be killed by the kernel's OOM killer at approximately 668 GiB RSS. With the system having 755 GiB of total RAM, this leaves only 87 GiB of headroom—and the kernel itself consumes memory for page tables, buffers, and other purposes. The OOM at pw=15 was even more immediate, suggesting a nonlinear scaling of memory pressure.

The Memory Analysis

The assistant's memory analysis is the most revealing part of the message. It makes several important observations:

  1. The memory is not leaked. RSS returns to approximately 71 GiB after completion, indicating that all allocations are properly freed. The problem is peak memory pressure, not a leak.
  2. Phase 12 adds memory pressure. The PendingProofHandle (the heap-allocated state that survives from start to finalize) holds the synthesis data approximately 1.7 seconds longer than before—the duration of the background b_g2_msm computation. When many partitions are in-flight simultaneously, this extra retention amplifies peak memory.
  3. Higher pw values cause more proofs to be queued. The partition worker semaphore gates how many partitions can be synthesized concurrently. When synthesis is faster (more workers), the scheduler can parse and queue more proofs from the input, increasing the total number of in-flight partitions. This creates a feedback loop: more partition workers → faster drain of the input queue → more proofs loaded → more memory.
  4. The scaling is nonlinear. Going from pw=10 to pw=12 (a 20% increase in partition workers) caused RSS to jump from ~367 GiB to ~668 GiB—an 82% increase. This strongly suggests that the memory consumption is not simply proportional to the number of partition workers, but is amplified by the scheduler's ability to load more proofs into the pipeline.

The Thinking Process Behind the Message

The message [msg 3054] is the culmination of a long chain of reasoning visible in the preceding messages. Looking at the context messages (3025–3053), we can reconstruct the assistant's thought process:

The assistant began by investigating the use-after-free bug. In [msg 3025], it used grep to find all references to provers[] in the CUDA source. In [msg 3026], it carefully analyzed which references were safe (those inside the GPU thread, which runs within a locked section and is joined before the function returns) and which were dangerous (those inside prep_msm_thread, which runs in the background and may outlive the function). This analysis shows a sophisticated understanding of C++ threading semantics and stack lifetime.

The fix was implemented incrementally. In [msg 3028], the assistant considered multiple approaches—changing the lambda capture to capture pp by value, or adding a new alias—and chose the alias approach for minimal invasiveness. In [msg 3029]–[msg 3031], it applied the edits, changing provers[c] to provers_safe[c] (which aliases pp->provers_owned). In [msg 3032]–[msg 3033], it verified that no other provers references remained in the prep_msm_thread lambda.

After the fix compiled successfully ([msg 3034]), the assistant turned to benchmarking. It killed the old daemon, started a fresh one with pw=12, and monitored RSS ([msg 3039]–[msg 3041]). The benchmark ran and OOM'd ([msg 3042]). The assistant then analyzed the RSS trace ([msg 3043]–[msg 3045]), finding a peak of 668 GiB. It compared this with the pw=10 peak of 367 GiB and recognized the nonlinear scaling.

The assistant's conclusion in [msg 3046] is telling: "This is a systemic memory capacity issue, not a leak. pw=10 with j=15 is the sweet spot for 755 GiB." This is a mature engineering judgment—accepting the constraint and optimizing within it, rather than chasing a futile battle against physics.

Assumptions and Their Validity

The message makes several implicit assumptions that are worth examining:

Assumption: The 2.4% improvement is real and not noise. The benchmark methodology (20 proofs at concurrency 15) provides reasonable statistical confidence, but the message does not report variance or run-to-run stability. A single benchmark run could be influenced by system noise (NUMA effects, thermal throttling, background processes). However, given the consistent improvement across multiple phases of optimization, the 2.4% figure is likely genuine.

Assumption: The OOM at pw=12 is purely a memory capacity problem. The assistant rules out a memory leak because RSS returns to baseline after completion. This is a valid inference, but it does not rule out memory fragmentation or inefficient allocation patterns that could be improved. The nonlinear scaling from pw=10 to pw=12 (367 GiB → 668 GiB) suggests that the memory model has a threshold effect that could potentially be addressed.

Assumption: The use-after-free bug was the only concurrency issue. The assistant fixed the provers reference in prep_msm_thread, but did not exhaustively audit all other captured references in the thread. The split_vectors_l, split_vectors_a, split_vectors_b references are aliases to pp-> fields (heap-allocated), which the assistant correctly identified as safe. But other captures in the lambda (caught_exception, barrier, results) are references to pp-> fields and should be safe for the same reason.

Input Knowledge Required

To fully understand this message, the reader needs:

  1. Groth16 proof structure: Understanding that a Groth16 proof consists of elements A, B, C (in G1/G2 groups), and that the b_g2_msm computes the G2 multi-scalar multiplication for element B.
  2. CUDA GPU programming model: Understanding that GPU operations are asynchronous, that host-side computation can overlap with GPU kernel execution, and that the GPU lock serializes access to the device.
  3. C++ memory model: Understanding stack vs heap allocation, reference lifetime, and the dangers of capturing stack references in background threads.
  4. Rust async/tokio: Understanding that the engine uses tokio tasks for asynchronous work, and that spawning a finalizer task allows the worker to continue without blocking.
  5. The project's architecture: The cuzk system with its pipeline of synthesis → GPU proving → finalization, the partition worker semaphore (pw), GPU workers (gw), and GPU threads (gt).
  6. The memory model: Each partition's synthesis produces ~13 GiB of data (the a, b, c NTT evaluation vectors), and the system has 755 GiB of total RAM.

Output Knowledge Created

This message creates several important pieces of knowledge:

  1. A validated architectural pattern: The split API for GPU proving is proven to work correctly and deliver measurable improvement. Future phases can build on this pattern.
  2. A benchmark baseline: 37.1s/proof at pw=10, gw=2, gt=32 becomes the new reference point for all subsequent optimization.
  3. A memory capacity boundary: The system cannot support pw > 10 with j=15 on 755 GiB RAM. This is a hard constraint that future work must either accept or circumvent.
  4. A nonlinear memory scaling model: The relationship between partition workers and peak RSS is not linear, suggesting interactions with the scheduler and proof queue that merit further investigation.
  5. A fixed concurrency bug: The use-after-free in prep_msm_thread is documented and corrected, preventing potential data corruption or crashes in production.
  6. A documented trade-off: Phase 12 improves throughput at the cost of increased memory pressure (due to longer data retention in PendingProofHandle). This trade-off is acceptable at pw=10 but becomes fatal at pw=12.

Broader Significance

The message [msg 3054] represents a mature engineering milestone. It is not the flashy "10x improvement" that captures headlines, but rather the steady, methodical optimization that characterizes serious systems engineering. A 2.4% improvement from architectural refactoring, a critical bug fix, and a clear-eyed assessment of fundamental constraints—these are the building blocks of production-quality systems.

The memory wall identified here is particularly significant. The system is approaching the physical limits of its hardware. With 755 GiB of RAM and each proof requiring substantial memory for synthesis, the only way to scale further is to reduce per-proof memory footprint (through techniques like the Sequential Partition Synthesis proposed in earlier phases) or to increase hardware capacity. The assistant's decision to accept pw=10 as the optimal configuration and commit the Phase 12 code is the right call—it delivers the best possible performance within the available resources, and documents the constraint clearly for future work.

The message also demonstrates a commendable engineering discipline: the assistant did not chase the OOM issue beyond what was productive. It recognized that pw=12 OOM was a capacity problem, not a bug, and chose to commit the working improvement rather than spin wheels on an intractable memory problem. This judgment—knowing when to stop optimizing and ship—is one of the hardest skills in engineering.

Conclusion

Message [msg 3054] is a compact but dense engineering report that captures the completion of Phase 12's split GPU proving API. It delivers a working implementation, a benchmark result, a bug fix, and a memory analysis—all in a few paragraphs. The 37.1s/proof throughput represents real progress, the use-after-free fix prevents a latent crash, and the memory analysis provides crucial guidance for future optimization work. For anyone following the optimization of Groth16 proof generation at scale, this message is a milestone worth studying: it shows what a disciplined, measurement-driven approach to systems optimization looks like in practice.