Skip to content

docs(bench): ledger §40 — the shared-pack negative result, and softmax by phase - #1423

Merged
justinchuby merged 2 commits into
mainfrom
squad/leon-p29-ledger-40
Aug 19, 2026
Merged

justinchuby merged 2 commits into
mainfrom
squad/leon-p29-ledger-40

Conversation

@justinchuby

@justinchuby justinchuby commented Aug 19, 2026 •

Copy link
Copy Markdown
Owner

Ledger write-up for #1402 and #1416. No code.

Records, in order:

  • §40.1 The experiment §39.4 left open — one immutable pack shared across row blocks — built, measured, and lost, at every panel width and worse the wider the pool (geomean 0.20–1.04 vs the unpacked driver). Full grid included so it is not rediscovered. Two causes: a fork-join per panel, and a pack that is a partly serial Amdahl term (at phi35's k=6400 a 512 KB panel is a single micro-panel, so splitting the pack by micro-panel leaves it on one thread).
  • §40.2 The win one level up: distribute whole panels, which gets the "pack each panel exactly once" property §39.4 wanted, without a barrier and with the panel resident in the owning core's L2.
  • §40.3 The gate, including the k >= 1024 variant that scored better on grid geomean and was rejected for regressing a production shape.
  • §40.4 Softmax profiled by phase: pass 2 is 73% of the row and throughput-bound, pass 1 is 11% and latency-bound, so the same fix helps one and hurts the other. Includes the magic-number round fusion that was measured, costed at 3%, and declined.
  • §40.5 Two method lessons: exhaustive verification over all 2^32 f32 inputs (0.6s, and the control that proves it can fail), and the invariance-hidden test hole that let a deleted accumulator chain pass every existing test.

Also records the mixtral cell where the §39 control arm moved +66% and the ratio metric had to be abandoned for native-time-vs-control.


Update: adds §42 as well

main claimed ## 40 while this branch was open, so my original section was
renumbered to §41 on rebase. This PR now also carries §42, recording the
softmax fan-out gate finding from #1484.

§42 is deliberately a continuation of upstream's §40 rather than a new theme.
§40 closes by asking that "the fourth instance is recognised rather than
re-derived"; §42 is that fourth instance, and it reports the way it differs
from the three §40 collected: the constant was not calibrated in the wrong
regime, it was expressed in the wrong unit. A row is not a unit of work — n
prices work only if d is held fixed, and d is the key length. §40.3's remedy
— record the regime beside the constant — would not have caught it.

§42.3 records the more transferable half: softmax rows are independent, so the
output is bit-identical whether or not the fan-out happens, which makes every
correctness test in the file blind to the gate by construction. Inverting the
caller's use of the predicate undoes the entire optimisation and left all 1448
tests green. A performance gate has no numerical signature and has to be
asserted directly.

§42.4 is a reporting note: the host was heavily contended for that run (A/A nulls
up to 61%), and the honest read came from structure rather than the grid — only
four of seven fixtures change gate decision at all, so the other three cannot
have moved and their scatter calibrates the host.

#1484's doc comment cites §42, so the two are written to land consistently in
either order.

@justinchuby

Copy link
Copy Markdown
Owner Author

Status: validated locally, held on required CI — not merging.

Per instruction, this waits for the required checks (Fast (Linux x86_64) and Rust quality) rather than using an admin/ruleset bypass. Those checks have not reported, and the reason is repository-wide rather than anything about this PR:

  • Across the last 200 workflow runs on this repo, none has concluded success or failure — 161 are still queued/pending and 39 were cancelled (superseded by their concurrency group while still queued).
  • The oldest queued run started at 2026-08-19T05:25Z and is still queued; CI on main itself is queued too. This is runner capacity, not this branch.

So the required checks are currently unreachable, and this PR stays open until they run. It is not blocked on review or on any known defect.

Local validation on this branch (not a substitute for CI, recorded for whoever merges):

  • cargo test -p onnx-runtime-ep-cpu --lib — all green
  • cargo clippy -p onnx-runtime-ep-cpu --lib --all-targets — 0 warnings
  • cargo fmt --check — clean
  • cargo check -p onnx-runtime-ep-cpu --features mlas — clean
  • Opus review completed; the actionable nits it raised are fixed in follow-up commits on this branch.

@justinchuby
justinchuby enabled auto-merge (squash) August 19, 2026 06:41
@justinchuby

Copy link
Copy Markdown
Owner Author

Status: auto-merge armed, waiting on required CI. Not merging by hand.

GitHub Actions has not concluded a run on this repo for some time (last 200 runs: 0
success, 0 failure; the rest queued or cancelled-while-queued). mergeStateStatus here
means checks pending, not a permissions problem. --auto --squash is set, so this lands
by itself the moment the required checks report.

#1429 has to land before this one can go green. While replicating the CI lanes locally I
found that Rust quality is red on main itself: its cross-arch step fails with three
never used errors on aarch64, introduced by bf722725a (#1363). Because PR checks run
against the merge result, every open PR inherits that failure. #1429 fixes it.

Independent replication of both required checks on main @ f8f3878ba:

lane result
Fast (Linux x86_64) full offline test set (--locked, -D warnings) 3942 tests / 188 targets, exit 0
MLAS-only lanes (feature config, kernels::moe::, kernels::qlinear_matmul::) 1 + 19 + 30 passed
cargo clippy --locked --all-targets over the 30 offline crates exit 0
cargo fmt --all --check clean
all 9 Rust quality python gates pass
shipped onnx-runtime-ep-cpu-plugin cdylib with mlas exit 0
Miri, all four onnx-runtime-ep-cpu lanes 28 + 8 + 16 + 12 passed
weight-cache guard + per-thread-buffer guard vs this PR 0 hits
bash scripts/check_cross_compile.sh FAIL — see #1429

@justinchuby
justinchuby force-pushed the squad/leon-p29-ledger-40 branch from 57a4c4b to 3c32d65 Compare August 19, 2026 14:15
justinchuby and others added 2 commits August 19, 2026 17:16
… by phase

Two results that are only useful written down.

The experiment 39.4 left open (share one packed panel across row blocks) was
run and lost, at every panel width and worse the wider the pool. The grid is
recorded so it is not rediscovered. The win was one level up: distribute whole
panels, which gets the same 'pack each panel once' property without a barrier.

And softmax, profiled by phase rather than as a whole: pass 2 is 73% of the
row and is throughput-bound, so the 4-accumulator fix that gives pass 1 a 1.8x
makes pass 2 slower. Removing ops, not reordering them, is what worked.

Closes the loop on 39.4.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… unit

40 was written so the fourth instance of "a threshold calibrated in one regime
makes the wrong call in another" would be recognised rather than re-derived.
1484 is that instance, and it arrived with a variant 40 does not cover: the
softmax fan-out's row floor was not calibrated in the wrong regime, it was
expressed in the wrong unit. A row prices work only if d is held fixed, and d is
the key length. The predicate already contained the honest form of the question
one line below as an element floor, so the fix was to delete the proxy rather
than retune it.

Also records the testing lesson, which generalises further than the perf win:
softmax rows are independent, so output is bit-identical whether or not the
fan-out happens, and every correctness test in the file is blind to the gate by
construction. Inverting the caller's use of the predicate undoes the whole
optimisation and left 1448 tests green. A performance gate has no numerical
signature and must be asserted directly.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@justinchuby
justinchuby force-pushed the squad/leon-p29-ledger-40 branch from 15b2bdd to 88f5d33 Compare August 19, 2026 17:17
@justinchuby
justinchuby merged commit d08b190 into main Aug 19, 2026
2 checks passed
@justinchuby
justinchuby deleted the squad/leon-p29-ledger-40 branch August 19, 2026 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant