docs(prover): state the allocator's memory saving, not a time cost we have not established - #965
Merged
Merged
Conversation
… have not established Four cells of the allocator flag read -1.6%, +1.4%, -0.1% and +2.8% on prove time, one run each. That is no consistent sign and three of them sit inside what a single run resolves, so the flag's time cost is not established and the doc no longer implies one. The paired q=20 order comparison IS supported (two runs per arm, consistent sign, ~2.5%) and is kept as such, with the explicit note that it does not carry to the flag. The memory saving is what to quote: it is large, reproducible and has a control. Also names where the durable fix is going — jemalloc in the test harness, lane S — rather than leaving the reader to infer it. Comments only; no code changed.
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
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.
The allocator's saving is memory; the time cost is not established
Doc-only follow-up to #964, which merged at
f1aff94fa few minutes before thiscorrection was ready. One paragraph in
table_walk_weight. No code changes —git diff -U0againstper-table-gpuyields zero non-///lines.Why
#964's doc landed saying the low-retention state "costs ~2.5% prove time", framed as
a property of the allocator flag. The four cells we actually measured do not support
that, and treating it as settled would have put an unearned number where the next
person will read it as one:
7c311c28b92d8358(#956's parent)7c311c28a6359906One run per cell, no consistent sign, and three of the four sit inside what a single
run resolves. Only the last exceeds the noise floor, and one point is not a trade.
What the paragraph says now
≈13 GiB at q=41 from a high-retention start, ≈1.2 GiB from a low-retention one.
is a different measurement: two runs per arm, consistent sign, ~2.5%
(135.8/136.2 s against 139.1/140.3 s). The doc now says explicitly that it does
not carry to the flag — the q=41 tip moved into the low-retention state and got
faster, which is exactly the generalisation that fails.
than leaving a reader to infer it. Phrased as in flight: ✓ VERIFIED it is not in the
tree yet, and
origin/pt/device-fitcarries no allocator change, so this does notpoint at something that does not exist.
Everything else from #964 is untouched: the table, the correlate-not-cause reading,
and the "any change needs a wrap measurement, not an argument about bytes" instruction.
Gates
make lintexit 0 across all three feature sets,make fmtclean,cargo test -p stark --lib -- walk_tests:: device_set::13 passed. Signed.