Repository navigation
docs: stop attributing the supernodal allocation and the whole-suite failures - #339
Conversation
…failures (#337 review)
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
…gure as reported, not re-measured
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
… counter, helper vs analysis request)
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
…y helper is not the whole analysis request
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changes
Unverified claims
Checked and fine
Reviewed head: |
GPT-6.1-sol adversarial reviewCRITICAL: none Critical (must not merge)none Needs changesnone Unverified claims
Checked and fine
Reviewed head: |
What this changes
Two sentences that
#337left onmain, narrowed to what was measured.1. The 468080 B supernodal allocation.
CHANGELOG.mdandPATCHSET.mdsaid it is the supernodal symbolic workspace andnot the COLAMD one. The supernodal helper for that arm requests four n-element index arrays
(
lu.rs:567-573,qr.rs:433-439,cholesky.rs:2373-2376) — 64000 B at m = n = 2000 with 8-byte indices — but that helper isonly one component of the top-level analysis request, which also carries the transpose storage and the largest temporary. The
helper alone cannot account for 468080 B, so it has to come from somewhere else inside symbolic analysis. The simplicial QR
helper, by contrast, requests three arrays (
qr.rs:1698-1703), so the request is not one shared four-array shape either.The number was measured; the attribution was inferred from it. It now says the allocation did not change and that its call site was
not traced.
2. The whole-suite failures.
PATCHSET.mdsaid the process-wide allocation counters inno_step_allocandtriangular_solve::aliased_rhs::staged_solve_is_bitwise_the_in_place_one"pass standalone and flake only inside the whole-suiteparallel run".
no_step_allocis its own test binary, so another test binary cannot perturb its counter directly — the obviousexplanation is not available. The latter test also asserts the opposite of what the ledger sentence said:
triangular_solve.rs:1131-1135requires
ran_kib == 0, i.e. that a 1 KiB stride is not staged. It now says both pass standalone, both were seen to fail in thewhole-suite run, and what makes them fail there was not identified.
Neither change touches code, and neither weakens a guarantee: the fix in
#337is unaffected, and the tests that pin the twodirections of the COLAMD request are untouched.
Verification
No code changed, so nothing in the repository's per-PR checks exercises these edits:
cargo test --docruns Rust doctests andscripts/check-migration-examples.pycompares the migration guides with examples, and neither readsCHANGELOG.mdorPATCHSET.md. What was actually checked by hand is the diff above plus a line-by-line read of the two changed paragraphs againsttriangular_solve.rs:1131-1135(ran_kib == 0),qr.rs:1698-1703(StackReq::new::<I>(ncols).array(3)), andlu.rs:567-573/qr.rs:433-439/cholesky.rs:2373-2376(the four-array supernodal helper).The allocation-tracing experiment the review asked for (run issue #322's counting program against
e756f13andb989876, force thesupernodal arm on both, and trace the 468080 B allocation to its call site) is deliberately not part of this PR: it belongs in
an issue where its result can be read on its own, not in a sentence that guesses at it now.