Chunk 17.0

In this chunk, Phase 5 (Pre-Compiled Constraint Evaluator) was implemented, debugged, and benchmarked. The initial test revealed two critical issues: a correctness bug causing ~53% of constraint evaluations to mismatch, and a performance problem where the PCE path was actually slower than the old path (61.1s vs 50.4s). The correctness bug was traced to `RecordingCS::enforce()` using the current `num_inputs` as the aux column offset during recording — but since `alloc_input()` and `enforce()` are interleaved during PoRep circuit synthesis, early constraints used a smaller offset than late ones, producing inconsistent column indices. This was fixed with a tagged encoding scheme (bit 31 flags aux vs input) with deferred remapping in `into_precompiled()`. The performance issue was that the CSR MatVec was running 10 circuits sequentially (34s total); switching to parallel execution via `rayon::par_iter` dropped MatVec to 8.8s. After fixes, all 10 circuits × 130M constraints validated bit-for-bit correct. PCE synthesis achieved 35.5s (26.5s witness + 8.8s MatVec) vs 50.4s baseline — a 1.42× speedup, below the 3-5× target because witness generation (not enforce overhead) is now the dominant cost. The 46.9s PCE extraction is a one-time cost amortized across all future proofs. The user then raised a memory scaling question about multi-GPU deployments, noting the 375 GB peak RAM usage. The assistant analyzed that PCE adds 25.7 GiB of static CSR matrix data (shared via `OnceLock`, paid once regardless of GPU count) while per-pipeline working set remains ~21 GiB — essentially unchanged from the old path. For an 8-GPU system with 2 pipelines per GPU, PCE adds only ~3.6% total memory overhead (~738 GiB vs ~712 GiB). The user's pointed question about whether the 375 GB peak came from per-partition PCE copying rather than deduplication remains open and warrants investigation.

From Correctness to Deployment: The Full Arc of Phase 5's Pre-Compiled Constraint Evaluator 2243 words

Message Articles

Subagent Sessions