Hacker News

Agreed, this is likely going to change the landscape for people ekeing everything out of an AMD-based HEDT.

To take full advantage of it, folks likely will want A) a new motherboard with likely a new chipset to support the higher frequencies and B) <GULP> higher frequency DDR5.

I’d love more memory bandwidth with the limited 2-channels I have, but the 2x48GB (96GB) of “tuner memory” I bought in February 2025 I’m not even sure is manufactured anymore. I paid $440 back then, and my understanding is it’s not produced now, and commands $2500 - $3000 on the second-hand market.

(AM4 was 3600 MT/s; AM5 is 6000 MT/s.)

The "compute" part of the CPU is almost negligible, most of it is SRAM, reordering and branch prediction

IIRC, PDEP/PEXT are generalizations of shifter networks.

They are unlikely to share circuits with the multipliers, but the 2 of the 6 execution units that include multipliers must be identical, to simplify layout, and the PDEP/PEXT circuits are allocated to these 2 units, like the multipliers.

From what I've seen there is no intermediate unit. IMO this is good because it allows larger VMs that don't have to straddle L3s.

32 cores is only on the Zen 6c CCDs. There are 12 cores on the Zen 6 CCDs. Also not all 6c parts have the full 32 cores per CCD

This is amusing since Intel seems to be sort of going in the other direction lately: their efficiency cores are becoming more like their performance cores with each new generation (at least in so far as they are getting wider and more capable of higher clock speeds), and there even seem to be some rumors that the two design trains may get "merged" in the future.

I think it's less there because of differences in the memory subsystem, but more because clock targets are lower so they can afford more. The structures they grew cost basically nothing in die area, but make timing tighter. It's possible they'd like them to be bigger for the non-c core too, but can't fit them in their timing constraints.

The unified L3 per CCD really helps on some key desktop loads (especially games). Most server throughput loads partition nicely into smaller partitions, but most games are hurt so bad by the latency penalty of crossing into a different partition that AMD's game drivers park the second CCD on their 2-CCD CPUs when they detect a game running. So long as games are an important target for them, I suspect they will not partition the CCD again. (It, of course, used to be parititioned for Zen 1 and 2.)

Rumor mill says they are going to use costlier interconnect to drive down CCD -> CCD latency in Zen 7+.

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.

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).

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.

That doesn't help memory latency and most of the time a cpu is waiting it's because of latency, not bandwidth.

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...

Nine women cannot make a baby in one month.

128 cores x 288 pins per DIMM = 36864 pins on your socket, and all the motherboard traces. Good luck with that...

The single-threaded results of the Apple cores are excellent, but the multi-threaded results per socket of a Zen 6 absolutely wipe out any Apple CPU.

The Apple CPUs may be great for a personal computer, but they are not competitive with a server CPU.

Moreover, the SPEC floating-point results are not really representative for the floating-point performance of Zen 5 and Zen 6 that can be reached with optimized AVX-512 programs, which is much greater.

if you're interested in a fair comparison here's one https://openbenchmarking.org/test/pts/stockfish

1. Different market

2. What flags & compiler?

3. Can't run Linux on that M5/M6 can we?

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.