August 1, 2026
Register cage match
Register deprivation: spills and runtime under forced register scarcity
Most tests got slower when registers vanished, but commenters are fighting over whether the proof is real
TLDR: A benchmark found that squeezing available CPU registers made 8 of 9 test programs slower, but one oddball barely changed at all. Commenters immediately turned it into a credibility brawl, demanding deeper proof and questioning whether the old test chip hides the real story.
A delightfully nerdy benchmark just dropped, and the big headline is simple: take away the CPU’s tiny stash of fast-access storage spots, and most programs get slower — sometimes a lot. In this spillbench repo, eight of nine mini-programs slowed down by 14% to 76% when the squeeze got tight. But then came the plot twist the comments latched onto: SipHash basically shrugged. More spills, no real slowdown, same output every time. For performance nerds, that’s the kind of result that starts arguments before the page even finishes loading.
And oh, the community did not disappoint. One camp was instantly suspicious, basically saying, “Cool chart, but where’s the juicy machine-code proof?” The loudest hot take was that the whole thing feels half-finished without assembly listings showing what the inner loops actually looked like. Another commenter side-eyed the test machine itself, calling it an “ancient CPU” and wondering whether fancy behind-the-scenes chip tricks like register remapping muddy the whole story. In plain English: readers are debating whether this is a clean lesson about code getting cramped, or a messy real-world demo with too many hidden variables.
The funniest part? The benchmark’s most dramatic finding — that extra spill instructions only sort of predict slowdown — has commenters acting like they’ve caught performance folklore in 4K. The vibe is equal parts science fair, courtroom cross-examination, and “show us the receipts.”
Key Points
- •The study used gcc -ffixed-<reg> to progressively reserve registers and measured spill counts and runtime across nine small kernels on one Intel Xeon E-2236 system.
- •At the tightest register budget, 8 of 9 kernels slowed by 14% to 76%, while SipHash showed no runtime change despite 23 additional spills.
- •Static spill counts were only a weak predictor of slowdown, with a reported Pearson correlation of 0.55 across 105 measured points.
- •Performance effects depended on the register file in use: SHA-256 was more affected by GP-register removal than XMM removal, while double-precision matrix multiplication was affected by XMM removal but not GP removal.
- •All builds passed known-answer tests and produced identical checksums at every budget, indicating register reservation changed generated code but not program results.