pcs: batch sparse-PD round-0 recompute — O(n_pd·2^L) → O(Σ support + 2^L)#7
Open
SipengXie2024 wants to merge 1 commit into
Open
pcs: batch sparse-PD round-0 recompute — O(n_pd·2^L) → O(Σ support + 2^L)#7SipengXie2024 wants to merge 1 commit into
SipengXie2024 wants to merge 1 commit into
Conversation
… + 2^L) compute_combined_basis_and_target re-swept the full 2^L b_combined to recompute the round-0 correction after EACH sparse PackedDirectClaim was scattered. The per-claim assignment overwrites round0_u0/u2 (it does not accumulate), so every sweep except the last was dead work: with n_pd sparse claims the loop cost O(n_pd * 2^L) while only the final sweep's result survived. Scatter all sparse claims first, then reduce once. Output is bit-identical (F128 addition is commutative; the overwritten intermediate results were never observable). On a workload with many per-block sparse PD claims (~9k claims, L=23, batched SHA-256 Merkle-path openings), this cut the PCS open from 29.5s to 0.43s (68x) and end-to-end prove 34.8s -> 2.0s. Workloads with zero or few sparse PD claims are unaffected (identical bytes out). All flock-core tests pass (255).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
compute_combined_basis_and_targetre-swept the full2^Lb_combinedarray to recompute the round-0 correction after each sparsePackedDirectClaimwas scattered. The per-claim assignment overwritesround0_u0/round0_u2rather than accumulating, so every sweep except the last one was dead work — withn_pdsparse claims the loop costO(n_pd · 2^L)while only the final sweep's result survived.This PR scatters all sparse claims first, then does the round-0 reduction once.
Why it is safe
Bit-identical output: F128 addition is commutative (the scatter order doesn't matter), and the overwritten intermediate
round0_*values were never observable. Workloads with zero or one sparse PD claim produce identical bytes and identical work.Measured
Found while profiling a batched SHA-256 Merkle-path workload (MHOT multiproof on our fork) that opens ~9k per-block sparse PD claims at L=23:
Proof bytes identical before/after.
Tests
All flock-core tests pass (255). No behavior change, so no new tests added.