Segment 28

In this sub-session, the assistant abandoned the Phase 10 two-lock GPU interlock design after discovering fundamental flaws: 16 GB VRAM cannot accommodate pre-staged buffers from multiple workers simultaneously, and CUDA memory management APIs (cudaDeviceSynchronize, cudaMemPoolTrimTo) are device-global, defeating the lock split's purpose. The code was reverted to Phase 9's proven single-lock approach. Comprehensive benchmarks were then run across concurrency levels (c=5 j=5 through c=20 j=15), and a detailed waterfall timing analysis was performed by extracting TIMELINE events from the daemon logs. This revealed 90.8% GPU utilization at high concurrency, with throughput plateauing at ~38s/proof due to DDR5 memory bandwidth contention—synthesis and prep_msm both inflating under load as they compete for the same memory channels. Building on this analysis, the assistant designed Phase 11 with three interventions to reduce contention: bounding async_deallocation to a single thread to eliminate TLB shootdown storms, reducing the groth16_pool thread count (via gpu_threads = 32) to shrink b_g2_msm's memory footprint and L3 cache pressure, and adding a lightweight atomic throttle flag to briefly pause synthesis workers during the b_g2_msm window. The plan was documented in c2-optimization-proposal-11.md, and cuzk-project.md was updated with the Phase 10 post-mortem and Phase 11 roadmap, with all documentation changes committed.

Abandon Phase 10 two-lock design and revert code to Phase 9 single-lockRun comprehensive benchmarks across concurrency levels (c=5..c=20)Perform waterfall timing analysis from daemon logs to identify bottleneckDesign Phase 11 with three interventions to reduce DDR5 memory bandwidth contentionWrite c2-optimization-proposal-11.md design spec and update cuzk-project.md with Phase 10 post-mortem and Phase 11 roadmap

From Two Locks to Bandwidth Wars: The Phase 10 Post-Mortem and Phase 11 Memory-Bandwidth Optimization Plan 3733 words

Chunks