What looks like a lot of small balanced improvements to the core itself. Four vector loads per cycle at 256b of less, I wonder if the gather performance is finally acceptable? Another balance example, they actually reduced the number of integer multipliers down to two. I wonder if that was to make diespace for the vnni pipes?
The real star looks like the c cores though. 32 C cores per chiplet with increased l3 cache is impressive
The instruction level parallelism in the 2-ahead branch prediction is super cool stuff, I know zen5 had this feature but it's kind of crazy that memory is so slow relative to the cores that this complexity is beneficial and worthwhile.
> AMD has reduced the number of integer multiply units from three to two, with PDEP and PEXT throughput also falling from three instructions per cycle to two.
Are PDEP and PEXT using the same (parts of) circuits as multiply (they are very different operations...), or are this just two independent drops of circuitry and the wording is just a bit unclear?
It is hilarious that the SPEC2026 graph does not include apple's P-cores. And no, not because they are ARM and not x86, since Graviton is included. It is because their integer & FP scores of 9.8 & 13 respectively absolutely wipe out everything else on this chart.
I was going to be sad than Zen 6c was divergent, but they increased a bunch of OoO structures on Zen 6c? To absorb more potential latency, since the memory is going to be heavier loaded? Ok, that I can appreciate!
It's absolutely wild that adjusting some l3 and using a smaller node goes from 12 to 32 cores for basically the same chip.
I wonder if the CCD will remain as monolithic as it does, for how long? The l3 latency being signficantly higher for 6c (10.3ns zen5 -> 10.7ns z6 -> 16.4ns z6c) feels like a symptom of a broader scaling challenge as the CCD hosts more and more. I can imagine dividing zen 7 or zen8 CCD into partitions, perhaps?
One thing I wonder about is that these CPUs are just so much faster than their memory controllers. So why not add more? Why don't they have a memory controller per core, for example?
Cost, and especially now, cost of memory! But you can buy AMD chips with 2 controllers (consumer), 4 (threadripper), 6 (8005), 12 (EPYC) memory channels, so in effect you can. Next generation Zen 6 Epyc has 16 channels. Roughly you get about 1 channel per chiplet, but you csn adjust if you need more memory bandwidth by buying fewer chiplets, eg there is an 8 core EPYC if you want to optimisise for bandwidth. But many applications are not bandwidth bound so this isn't the right choice, eg they are IO bound, rarely compute bound.
More memory controllers would add more bandwidth. That can help, but few workloads are bottlenecked by memory bandwidth. (Dual memory channels have been a thing in desktops and laptops since the early 2000s single-core era at least, but newer generations of DDR have increased bandwidth to keep up with increased core counts.) What's really needed is less memory latency (less latency = faster), which has not improved as much as bandwidth.
I think it mostly is for more controllers to be useful that means more PHYs and more actual pins on the package and more traces on the board and more sockets for the memory and... The space and cost of all of that is substantial (to a point, and then it just physically can't be manufactured).
It's not always trivial to saturate available memory bandwidth. You may need to use more than one core, or you need to carefully consider the topology of the chip you're working with (see lstopo). For example, what if the L3 cache is actually split in two [0]? In such cases, adding more bandwidth doesn't do much for you.
What looks like a lot of small balanced improvements to the core itself. Four vector loads per cycle at 256b of less, I wonder if the gather performance is finally acceptable? Another balance example, they actually reduced the number of integer multipliers down to two. I wonder if that was to make diespace for the vnni pipes?
The real star looks like the c cores though. 32 C cores per chiplet with increased l3 cache is impressive
The instruction level parallelism in the 2-ahead branch prediction is super cool stuff, I know zen5 had this feature but it's kind of crazy that memory is so slow relative to the cores that this complexity is beneficial and worthwhile.
> AMD has reduced the number of integer multiply units from three to two, with PDEP and PEXT throughput also falling from three instructions per cycle to two.
Are PDEP and PEXT using the same (parts of) circuits as multiply (they are very different operations...), or are this just two independent drops of circuitry and the wording is just a bit unclear?
It is hilarious that the SPEC2026 graph does not include apple's P-cores. And no, not because they are ARM and not x86, since Graviton is included. It is because their integer & FP scores of 9.8 & 13 respectively absolutely wipe out everything else on this chart.
I mean, this is a review of the server grade parts. Apple is not exactly selling m chips to hyperscalers right?
Different story when you're talking about the context of a desktop or mobile.
I was going to be sad than Zen 6c was divergent, but they increased a bunch of OoO structures on Zen 6c? To absorb more potential latency, since the memory is going to be heavier loaded? Ok, that I can appreciate!
It's absolutely wild that adjusting some l3 and using a smaller node goes from 12 to 32 cores for basically the same chip.
I wonder if the CCD will remain as monolithic as it does, for how long? The l3 latency being signficantly higher for 6c (10.3ns zen5 -> 10.7ns z6 -> 16.4ns z6c) feels like a symptom of a broader scaling challenge as the CCD hosts more and more. I can imagine dividing zen 7 or zen8 CCD into partitions, perhaps?
Rumor mill says they are going to use costlier interconnect to drive down CCD -> CCD latency in Zen 7+.
One thing I wonder about is that these CPUs are just so much faster than their memory controllers. So why not add more? Why don't they have a memory controller per core, for example?
Cost, and especially now, cost of memory! But you can buy AMD chips with 2 controllers (consumer), 4 (threadripper), 6 (8005), 12 (EPYC) memory channels, so in effect you can. Next generation Zen 6 Epyc has 16 channels. Roughly you get about 1 channel per chiplet, but you csn adjust if you need more memory bandwidth by buying fewer chiplets, eg there is an 8 core EPYC if you want to optimisise for bandwidth. But many applications are not bandwidth bound so this isn't the right choice, eg they are IO bound, rarely compute bound.
More memory controllers would add more bandwidth. That can help, but few workloads are bottlenecked by memory bandwidth. (Dual memory channels have been a thing in desktops and laptops since the early 2000s single-core era at least, but newer generations of DDR have increased bandwidth to keep up with increased core counts.) What's really needed is less memory latency (less latency = faster), which has not improved as much as bandwidth.
I think it mostly is for more controllers to be useful that means more PHYs and more actual pins on the package and more traces on the board and more sockets for the memory and... The space and cost of all of that is substantial (to a point, and then it just physically can't be manufactured).
It's not always trivial to saturate available memory bandwidth. You may need to use more than one core, or you need to carefully consider the topology of the chip you're working with (see lstopo). For example, what if the L3 cache is actually split in two [0]? In such cases, adding more bandwidth doesn't do much for you.
[0] https://en.algorithmica.org/hpc/cpu-cache/sharing/#saturatin...
That doesn't help memory latency and most of the time a cpu is waiting it's because of latency, not bandwidth.
Nine women cannot make a baby in one month.
Well, in Venice they now have 16 memory controllers, 4 more than last generation.