AMD's Two-Year, 58% Ryzen Gain Didn't Come From Clock Speed

The claim making the rounds on Hacker News this week is that AMD's Ryzen desktop chips got 50% faster in two years. The precise numbers, from a Sept. 18 benchmark comparison published on Daniel Lemire's blog, are a 47% gain on a single core and a 58% gain across all cores, and almost none of it came from clock speed.

Lemire compared three chips: the Ryzen 7 5800X3D (Zen 3, released 2022), the 7800X3D (Zen 4, 2023) and the 9800X3D (Zen 5, 2024). On Geekbench 6, single-core scores rose from 2,016 to 2,969 points; multi-core scores rose from 11,832 to 18,751. Max boost clock climbed from 4.5 GHz to 5.2 GHz over the same span, a 15% increase, which accounts for a fraction of a 47% single-core gain.

The number that matters is not clock speed but width

The rest of the gain, Lemire's post argues, came from AMD spending a transistor budget that grew from roughly 11 billion (Zen 3) to roughly 16 billion (Zen 5), about a 50% increase, on widening the core rather than pushing frequency. Dispatch width, the number of instructions the front end can hand to the execution units each cycle, went from 6 to 8 by Lemire's count. Integer ALUs grew from 4 to 6, and the reorder buffer, which tracks in-flight instructions waiting to retire, grew from 256 to 448 entries.

Resource	5800X3D (2022)	7800X3D (2023)	9800X3D (2024)
Dispatch width	6	6	8
Integer ALUs	4	4	6
Reorder buffer	256 entries	320 entries	448 entries
L2 cache per core	512 KB	1 MB	1 MB
L1 data cache	32 KB	32 KB	48 KB

1. 5800X3D single-core2016 points
2. 9800X3D single-core2969 points
3. 5800X3D multi-core12K points
4. 9800X3D multi-core19K points

Source: Daniel Lemire's blog, Sept. 18, 2026, accessed 2026-09-23

Why AMD chose width over frequency

Mike Clark, AMD's chief architect of Zen, told Chips and Cheese in July 2024 that Zen 5 required resetting the core's foundation rather than iterating on Zen 4: the team "needed a new foundation for more compute to drive future workloads," and that meant a wider execution engine, "more ALUs," ahead of software that could fully use it. That is a bet running the other direction from clock speed, which has diminishing returns past a point set by power and heat, toward a wager that games and applications will eventually issue enough parallel instructions per cycle to fill the extra ALUs.

Where the two independent accounts disagree

A separate teardown of the non-3D Ryzen 9950X, published by Chips and Cheese in August 2024, complicates the dispatch-width figure. That piece describes Zen 5's dispatch and rename stage as staying 5 to 6 wide, unchanged from Zen 4, with the 8-wide expansion confined to the decoder, which is arranged in two 4-wide clusters rather than one. Single-thread decode is still capped at four instructions per cycle in that account. The two pieces are measuring different pipeline stages under similar-sounding names, decode versus dispatch, and neither is the vendor's own published microarchitecture manual, so the exact width of the bottleneck AMD widened is not settled by either post alone.

What both accounts agree on is the store queue and cache growth: L1 data cache capacity rose 50% and the store queue grew from 64 to 104 entries, matching gains the same teardown measured directly: 27.6% faster libx264 video encoding and 25% to 27% faster Linux kernel compiles on the non-3D Zen 5 part, gains driven by instructions-per-cycle rather than clock.

What would change this read

AMD's own architecture disclosures, and gaming benchmarks that isolate the 3D V-Cache variants specifically rather than the plain Zen 5 desktop part Chips and Cheese tested, would settle the dispatch-width question directly. A repeat of Lemire's test on the non-3D 9800X, run against its own Zen 4 and Zen 3 equivalents, would also show whether the extra 64 MB of stacked cache on the X3D parts is doing more of the work than the wider core Clark described, since cache and width improved together in every generation Lemire measured and neither post isolates one from the other.

Until then, the safest claim is the one both Lemire's numbers and the teardown support without contradiction: AMD's two-year Ryzen gain is real, it is concentrated in multi-core work more than single-core, and it tracks a wider, cache-heavier core rather than a faster one. The same logic AMD applied to Ryzen now faces its EPYC server line, where the tradeoff between core width and power draw carries a different denominator, watts per rack rather than frames per second, and a customer, cloud operators such as those running AMD-powered supercomputing deals, who cares far more about the former.

The same widening also raises the stakes for software that competes with AMD's own driver stack. A CUDA-on-AMD compatibility project depends on AMD's hardware behaving predictably at the instruction level, and a core whose dispatch and decode widths are still being worked out in public by independent researchers is a harder target to reverse-engineer against than one AMD has fully documented itself.