perf(bus): decide flat guest accesses inline when no foreign address space is attached - #1420
Conversation
…space is attached MacMemoryBus::route runs on every bus read and write. Since the unified runtime it was an out-of-line call that recomputed the address translation and consulted the foreign address space before reaching the flat-RAM answer that the 68k-only configuration always takes. Keep the same decision order but answer the common case inline from the translated address and RAM size; only an attached foreign space pays the router.
|
Per-step CPU time, re-measured with the machine idle (3 in Three headless replay, 200 M guest instructions, 3 pairs each, identical ticks and framebuffer hash on every pair; each step against the previous one in the order the fixes were built):
All four together vs rebased #1220 (5 pairs, both workloads): 3 in Three −60.7% instructions / −53.0% CPU time; SimCity 2000 −39.1% / −30.8%. Note on the first row: removing the per-dispatch clone alone lowers the instruction count but costs CPU time (the borrowed check still walks the whole range list, now without the copy that had just pulled it into cache). The sorted-ranges commit removes that walk, so #1419 is measured as the pair; a run of #1419's two commits on their own is queued and will be posted here. |
2 participants
Summary
MacMemoryBus::routeruns on every bus read and write. Since #1364 it has been an out-of-line call that recomputes the address translation and consults the foreign address space before reaching the flat-RAM answer that the 68k-only configuration always takes; it carried#[inline]but LLVM declined it. This keeps the same decision order but splits the function: a small inline wrapper answers the common case from the translated address and the RAM size, and only an attached foreign space pays the out-of-line router.Why
Part of the host-work regression found while re-baselining against
master(see #1364 comment):routewas 6.5% of self time on a 3 in Three replay.Measurements
Measured together with the themed-chrome cache PR (the two were built as one step), paired hardware counters on the headless replay against a tree carrying rebased #1220 and the trap-table fix, identical ticks and framebuffer hash on every pair:
All four regression fixes together vs rebased #1220: −60.7% instructions, −53.0% CPU time (35.4 s → 16.6 s), 5/5 on 3 in Three, −39.1% instructions, −30.8% CPU time (18.6 s → 12.9 s), 5/5 on SimCity 2000.
Measured on builds based on c40588f, the
masterof the day; the branch is rebased onto d30234c, whose seven commits do not touch these paths.The per-step instruction counts above were measured while the machine was loaded (cycles and CPU time were noise); the combined row was re-measured with the machine idle, and per-step CPU times from the same idle rerun follow in a comment.
Related fixes for the same regression: #1419 (trap-table lookup), #1420 (routing fast path), #1421 (themed chrome cache); #1220 removes the single-step mode they were measured on top of.
Tests
cargo test; see the trap-table PR for the one pre-existing failure.🤖 Generated with Claude Code
https://claude.ai/code/session_01UqCuD9vsGeeij5DdYt3vcK