Skip to content

update(perf): record the wrapped-window Gemma 3 decode measurement - #2275

Merged
inureyes merged 2 commits into
mainfrom
perf/issue-2239-gemma3-b1-decode
Oct 12, 2026
Merged

inureyes merged 2 commits into
mainfrom
perf/issue-2239-gemma3-b1-decode

Conversation

@inureyes

Copy link
Copy Markdown
Member

Summary

Docs-only measurement record for issue #2239: the reported pipelined B=1 decode regression on Gemma 3 (gfx1151, pp2048/tg128) does not reproduce on the current tree, so no code change ships. docs/benchmark_results/wrapped-ring-lookahead-gfx1151-2026-10-12.md records the paired measurements, with session scripts and raw CSV under docs/benchmark_results/data/.

Measurements

Four-arm interleaved session (pre-epic 4c44e317 base, branch pipelined, MLXCEL_FORCE_SYNC=1, base noise floor), 12 runs, all CLEAN under the GPU guard: base median 62.61 tok/s, pipelined branch 62.63 (paired median -0.13 percent), sync 61.10 (-2.41 percent), noise floor +0.00 percent (range -0.18 to +0.14). A follow-up arm on origin/main at e24fb7b2 without the branch's changes measures 62.79 (+0.29 percent), so the Oct 8 -1.3 percent gap was already recovered by #2271 and #2272 before this branch existed. The pp512 cell stays within the 1.0 percent threshold (+0.78 percent). A wrapped-window synchronous handover prototype carried during measurement was dropped: it never routes this bench path and its destination measures below the pipeline today.

Test plan

  • Full ROCm gate (make verify-rocm-held): 12264 passed, 0 failed, 404 ignored
  • engine-parity: 14 pairs, 13 identical, 1 n/a
  • CUDA (GB10) three-arm measurement: not run, the spark-102 host's gpu-lock tooling is not reachable from this host; that criterion stays open

Closes #2239

The decode profile script hardcoded the 512-token prompt shape, so profiling a wrapped sliding window meant editing the script. --prompt-tokens and --max-tokens take the issue-2192 isolation shape (pp2048/tg128) without an edit.
Repeating the issue-2239 three-arm measurement on the current tree does not reproduce the pp2048 regression: the pipelined arm is -0.13 percent against the pre-epic loop, inside the null arm's spread, and a build of origin/main at e24fb7b is at parity too (+0.29 percent), so the commits merged since the Oct 8 session (#2271, #2272) recovered the gap. MLXCEL_FORCE_SYNC on the same binary now measures below the pipelined arm where Oct 8 measured it above, so the synchronous step is no longer the faster choice in this bench. The page and the session scripts record the four-arm run, the pre-fix comparison and the pp512 spot check.
@inureyes
inureyes merged commit 190b83c into main Oct 12, 2026
27 checks passed
@inureyes
inureyes deleted the perf/issue-2239-gemma3-b1-decode branch October 12, 2026 02:40
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.

perf(rocm): pipelined B=1 decode on Gemma 3 is 1.3 percent below the pre-epic loop at 2048 tokens on gfx1151

1 participant