• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Zen 6 Speculation Thread

Page 89 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
It seems that people don't learn from history.

If you take the best case for every possible outcome and then add them cumulatively for Zen 6 to form expectations for Zen 6 performance vs Zen 5, I give you guys a 100% chance of being bitterly disappointed with the Zen 6 release.

First, I am not convinced AMD will use N2X for anything other than server chips where the margins will be big and they will need the density improvement in order to get improvements over the N3E Zen 5 Turin D currently shipping. I think it much more likely that desktop Zen 6 will use N3P. I might even bet a coke on it 😉.

Second, since transistor density is not going up greatly between shrinks any longer, the transistor budget between generations isn't either. this means that IPC increases will be smaller. I would guess that desktop Zen 6 is only 15-20% higher IPC than Zen 5 ..... and most of that will likely come in the form of a higher bandwidth, lower latency IOD.

In MT, I expect that Zen 6 will easily improve over Zen 5 by 50% simply due to having 50% more cores. The issue that AMD is going to run into with Zen 6 MT is that Intel will have even MORE cores (54 if the rumors are correct). Those "mont" cores are not nearly the computational power houses that Zen c cores rather on full Zen cores are, but they do crunch through low computational throughput stuff (like Cinebench) very effectively. I suspect on more computationally challenging MT tasks, Zen 6 will rule.... but lots of people seem to take those Cinebench scores pretty seriously.
 
The 54 core monster is likely to run into memory throughput issues in the only cases where that many cores would truly make a difference, unless they have significant improvements coming in that area.
 
I would guess that desktop Zen 6 is only 15-20% higher IPC than Zen 5 ...
That would be rather high for "leveraged cores".
... and most of that will likely come in the form of a higher bandwidth, lower latency IOD.
Higher bandwidth, lower latency IOD is one thing. There will also be higher bandwidth main memory — but not appreciably lower latency main memory.
In MT, I expect that Zen 6 will easily improve over Zen 5 by 50% simply due to having 50% more cores.
Only in an iso-clock comparison at moderate core clock (relative to memory clock). Not e.g. in an iso-power comparison, obviously.
Edit, and only in embarrassingly parallel workloads of course, not in a plethora of less-than-embarassingly parallel workloads.
 
Last edited:
The 54 core monster is likely to run into memory throughput issues in the only cases where that many cores would truly make a difference, unless they have significant improvements coming in that area.

It is of course possible to have tasks that are massively parallel which are *not* that bandwidth sensitive.

I wonder what the LLC looks like for the ostensible 52-core monster? There's more than one way to skin a cat, and something like v-cache, or Crystal Well, or just something large and shared (144MB rumored... but that might be split), could go a long way.

Everything else being equal, more cores are never wasted. To the extent a 52-core monster is bandwidth constrained on some embarrassingly parallel task so that it cannot stretch its legs, it can at least downclock to get much better perf/w.

It's probably more appropriately thought of as a 48-core monster though. The rumored 4 LP E-cores most likely lack an L3 (but maybe there's a shared L4?), and would just be there for background tasks and keeping near-idle power consumption in check, not for throughput.
 
Last edited:
unless they have significant improvements coming in that area.
One way could be segregating the P and E cores into their own NUMA domains, each with its own dedicated dual channel slots and using their Thread Director to give the necessary hints to Windows Scheduler. It will be more complicated and will need all RAM slots to be filled but if it's the only way, they could go with it.

With so many cores available, it may be possible to even assign the required P or E cores to the separate NUMA domains. So for example, in BIOS, one could set:

P and E on separate domains
Some P and some E on one domain and the rest on the other
 
lmao dawg that ain't flying in client.
NUMA is a pain. NUMA is extra pain in client.
Do you have a better idea on how to increase the RAM bandwidth to all the cores without going quad channel and without a large L4 cache (which Intel has so far scrapped due to unknown problems, probably cost and yield)?
 
Back
Top