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.
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.
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?
[0] https://en.algorithmica.org/hpc/cpu-cache/sharing/#saturatin...