Rendered at 06:07:07 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
bmenrigh 4 days ago [-]
The worst thing about consumer (AM5) Zen4 and Zen5 is the I/O die chiplet and memory controller on it. I've heard they're finally going to ship a new I/O chiplet in Zen6 on a much smaller node. Their existing AM5 Zen4/5 memory controller when using both memory channels is terrible. Extremely hard or impossible to get above 3600 MT/s.
Of all the things I'm looking forward to on Zen6, an improved memory controller is at the top of the list.
Edit: and yes, others may say the paltry few PCIE 5.0 lanes is the worst thing about AM5, but that doesn't affect my usage much, and unfortunately I think that's a limitation of AM5 itself rather than the I/O chiplet.
eyegor 4 days ago [-]
It's not too hard to get above 3600 MT/s (I assume what you actually want is to get the uclk above 1800) if you bump the soc voltage, but at default voltages there's no chance. Most people overclocking don't touch the soc rail. I've done it on a few zen4 parts and supposedly there are golden samples that go above 1800 without major soc voltage increases but I've never seen evidence of one. And even with major voltage increases the highest you can really achieve is like 2000 on the uclk which is almost a pointless change in memory bandwidth when ddr5 is like +60% without any shenanigans.
bmenrigh 4 days ago [-]
I'm talking about with 4 sticks, not 2.
I've never gotten 4 sticks to pass training, no matter what I change. This is a well-known limitation. Some people, with newer AGESA on certain motherboards, have been able to get 4 sticks above 3600 MT/s but it's not possible for most people, and questionably stable even for those that have succeeded.
papascrubs 4 days ago [-]
I've had no issues on my ASRock X870E Taichi from the very beginning. I'm running four 24 gig sticks at 6000 MT/s (Corsair, all bought before the crazy). I didn't realize people were having this many issues. These are on the certified lists from the manufacturer of the motherboard. Never had a problem. They've been working through multiple AGESA updates / multiple BIOS updates without a hitch.
eyegor 4 days ago [-]
X870e is not am4 though. That's ddr5 and a different memory controller.
happymellon 4 days ago [-]
The initial comment wasn't about AM4.
> Their existing AM5 Zen4/5 memory controller when using both memory channels is terrible. Extremely hard or impossible to get above 3600 MT/s.
bmenrigh 4 days ago [-]
I’m on an MSI x670e with 4x32 sticks, also Corsair. Never gotten training beyond 3600. I’ve recently seen people posting success stories on my same motherboard at 6000 MT thanks to newer bios AGESA. But none of that has worked for me.
disiplus 4 days ago [-]
how ? i have ASRock X870 Steel Legend WiFi and VENGEANCE 6400MT/s CL3 4x32gb and the best i got is 5800 and that was unstable so i run it back at 5000 and even that with slight overclock.
eyegor 4 days ago [-]
Not sure how deep into it you went, but I found with 4 sticks I had to bump soc voltage, memory voltage, and loosen all my timings, especially tRFC. I can only pass training at marginally higher mem clocks with tRFC around 350ns with 4 sticks whereas 2 sticks was down near 200ns. Is it perfectly stable though... I think it's crashed once in the past month? So not perfect but it passed 12-24h of every stress test I could think of, and the one crash was near idle which probably just means my voltages need another bump.
For reference I'm using vsoc 1.08v, vddp 0.98v, vddg 1.0v, vdimm 1.38v and couldn't get above 1900 uclk / 3800 MT/s without uncomfortable vsoc. I've seen lots of people claim 2000/4000 at 1.1-1.15v vsoc but I don't want to run that high daily.
Oh and don't push vsoc to 1.2v+ as per AMD.
SomeHacker44 4 days ago [-]
I have a 9950X with 4x48G sticks. It is so hard to get it to boot even at 3600. But I persevere to run my local LLMs. I would love to get a new reliable chip for this same motherboard and RAM.
alfiedotwtf 4 days ago [-]
4 sticks from 2 different serial numbers, and it’s pretty stable at 5200 until it hits the high memory range.. that’s without pushing voltages up (Intel though)
GoofGarage 4 days ago [-]
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.
wmf 4 days ago [-]
(AM4 was 3600 MT/s; AM5 is 6000 MT/s.)
codebje 4 days ago [-]
AM5 is 3600MT/s for 4 sticks; check the specification of a CPU of interest to you, expand the Connectivity section. For 2 sticks it's 5600MT/s. The Ryzen 9 9950x3d officially only supports 5600 or 3600.
Obviously, you can run memory faster than the officially supported speed, including 4 DIMMS, but the Zen 5 architecture has a reputation for being finicky trying to run 4 DIMMs at higher speeds and you need a bit of care in what you pick and how you tune it.
Covzire 4 days ago [-]
Reported even on AM5, you can only get 6000 Mt/s with 2 sticks, attempting to run all 4 slots on most boards won't work unless you slow them down to base JEDEC speeds.
mldbk 4 days ago [-]
4 x 32GB G.Skill Flare 6000CL30 are running on Asus TUF B650E with 6000CL34
semi-extrinsic 4 days ago [-]
Can confirm, had this issue on an ASRock DeskMeet X600.
papascrubs 4 days ago [-]
Really? I'm running 4x 24GB sticks at 6000 with no issues. These were on the certified list for the motherboard.
I'm running 8000 in 2:1 on my 9800x3D. Slightly better than 6200 1:1 on here, and basically the same as 6400 1:1, but easier to dial in at 8000.
Side note: At 2ghz IF, a single Zen4/5 CCD can saturate 7200 MT DDR5, but the io die is not restricted to that, so x16 and IGPU DMA can still saturate it at 8000.
sylware 4 days ago [-]
Crazy to think we are really pushing that hard the ASICs.
Well, we also have to get rid of x86_64 ISA... Shouldn't those "µops" be the ISA?
Personnally I try to code as much as I can in RISC-V assembly, or in the worst case scenario simple and plain C compiling with NOT gcc | clang/llvm.
peterfirefly 2 days ago [-]
> Shouldn't those "µops" be the ISA?
of course not.
This allows Intel and AMD (and VIA) to have different µops. It also allows the µops to change from Pentium Pro to Pentium II to Pentium III, and from Zen 1 to 6.
It also allows the µops to be a lot bigger than the fairly lame 32 bits of normal RISC instructions, while also allowing for extra internal registers.
All modern CPUs that try to go for performance use out of order execution and decoders and µops of some sort, no matter what their external instruction set looks like. That's true for IBM's PowerPC, for ARM's ARM CPUs, for Apple's ARM CPUs, for everybody's RISC-V, etc.
Your experience (and everybody's) would be worse in every way if people started coding in µops.
By keeping them internal and hidden, you get compatibility, higher code density, compatibility, higher performance, compatibility, reuse of test vectors, compatibility, reuse of formal proofs of various parts of the processor (very important because you can't fully test something as complicated as a modern CPU), compatibility plus compatibility. And compatibility, of course.
sylware 2 days ago [-]
But nowdays, we have something we did not have back then: decades of experience, namely we "know now", and we could expect those µops to be very stable. Their difference among vendor is probably more cosmetic (and vendor lock-in) more than anything else. The "distance" between them is probably rarely significant.
That said, the real sweet spot is probably not in an ISA based on pure µops, but something in between, but closer to those µops, like RISC.
peterfirefly 2 days ago [-]
"Physics and archaeology have disproved everything about Christianity but I still think Christianity is right."
They would be stable enough to make it fairly easy to port validation software/tests/proofs over within a single company. They would not be stable enough to base software upon them. Obviously. Not even for CPUs from a single company. They would also be grossly inefficient because they are bigger than the current external instructions.
sylware 19 hours ago [-]
I understand that, and I think I said it a bit "below": I am aware that those µops are intimate to one µarchitecture, but their "operations" should tell us something about what would be required for "performance", and an ISA should be related to that to some extend (and not have too "alien" legacy or it will cost, seriously, in implementation complexity). And we are often hearing (even here on HN) from the CPU design people: 'this is "RISC"'.
(It is a bit like GPU hardware binary "descriptors")
phire 4 days ago [-]
> Shouldn't those "µops" be the ISA?
Well... that is the pure RISC philosophy from the 80s.
But there are advantages to having a disconnect between the encoded instructions and μops. So much that most "RISC" ISAs have instructions that are explicitly intended to decode to multiple μops. ARMv8 takes this approach pretty far, with quite a few instructions that are explicitly intended to be split into multiple μops.
Hell... Even RISC-V has begrudgingly expermented with the idea: See the Zcmp/Zcmt extensions which are explicitly defined to decoded to multiple 32-bit instructions; Or arguably the Zaamo Atomic instructions, which are part of RVA23.
sylware 3 days ago [-]
This disconnect is really light compared to x86_64 mess (status register on out-of-order CPU).
The transition is going, if any, will be tough: basically you would need a "x86_64" hardware 'slow' mode, on the side of the 'clean' and light RISC one.
peterfirefly 2 days ago [-]
Condition codes are not hard to do on an OOO machine. I know that there are RISC books that say there, but they are not.
z/Arch, x86, ARM, PowerPC, and SPARC all have condition codes. They all have OOO implementations and all but SPARC have really, really fast implementations.
---
µops are not at all like RISC instructions. They tend to be quite big, for example, or have really strange encodings (that vary from place to place inside the CPU). A group of 2-4 µops may share a single wide literal field (or bigger literals will be encoded with a number of µops or something else crazy).
Pentium Pro (P6) had a µops length (at some point inside the CPU) of around 115 bits, for example.
µops also typically expose the pipeline(s) to some extent which is just ugly and very, very for from being clean.
phire 2 days ago [-]
> know that there are RISC books that say there, but they are not.
You don't have to look far, the RISC-V spec makes this incorrect claim.
> µops are not at all like RISC instructions
Yeah. Zen μops are actually documented to be variable length (at least when stored in the μop cache, but presumably elsewhere). And μops hold both a memory load and an ALU operation... very CISC.
It's only the full read-modify-write instructions that still get split into two μops. And I doubt it's actually two fully independent μops, because seems a waste to send the instruction through the AGU twice.
sylware 2 days ago [-]
Much content on HN says the opposite: "a status register on OOO is disgusting". Should not have been there in the first place, but x86_64 has too much toxic legacy. Namely, you have to pay with serious implementation complexity that legacy for high performance.
And RISC-V as its sweet spot roughly set for implementation simplicity, namely some core design choices show a strong difference here.
Obviously µops are encoded specific to some µarchitecture, but their "operations" may tell us what would be a "good" ISA for performance, and many seem to agree that this ISA would be "RISC" based. This what I intended to say.
phire 1 days ago [-]
> Much content on HN says the opposite
Doesn't mean they are right. It's mostly just RISC-V fans blindly repeating the RISC-V justification for not having flags without understanding the situation.
And it's only RISC-V (and MIPS before it) which sticks to this position. Most other high-performance RISC arches have flags. Including ARMv8, a complete departure from 32-bit ARM, and one which was explicitly designed with high-performance OoO cores in mind. ARMv8 dropped many fun RISC features from Arm32, but they kept flags.
Really, the cost for flags on OoO cores isn't that high. You have already implemented everything you need to rename regular registers, which you can reuse to implement flag renaming too. It costs a tiny bit of area and maybe a little routing complexity, but doesn't have any impact on fmax.
> but their "operations" may tell us what would be a "good" ISA for performance, and many seem to agree that this ISA would be "RISC" based.
Well... given that the current μops of x86 cores aren't RISC-like, (because they are variable length, and aren't load-store), your suggested philosophy would not result in a RISC-like replacement ISA for x86.
Like, the weaker form of your argument is probably correct. If we were designing a replacement x86 ISA, then the current μops of various x86 implementations would be a good inspiration for informing what that ISA could look like.
It's only the strong form that I disagree with: There is no good reason for any ISA to be a 1:1 mapping of the μops it decodes into. And there are many good arguments for not doing that. μops can be arbitrarily wide, as they are only used for internal purposes. Instructions need to be dense and compressed, as code density can have a large impact on performance. There is no good reason why a single instruction shouldn't decode to two or even hundreds of μops... that's just good compression.
camel-cdr 14 hours ago [-]
> Really, the cost for flags on OoO cores isn't that high. You have already implemented everything you need to rename regular registers, which you can reuse to implement flag renaming too. It costs a tiny bit of area and maybe a little routing complexity, but doesn't have any impact on fmax.
I generally agree, but want to point out that they aren't "free" either.
Look at contemporary wide OoO Arm cores, most (Apple Silicon, C1-Ultra, ...) have half the throughput on flag reading/writing instructions than the equivalent instruction without the flag write (ADD vs ADC vs ADDS).
So clearly the cost is high enough to drive towards such tradeoffs being made.
phire 4 hours ago [-]
Yeah, not free.
I'm only really arguing that handling flags in OoO designs doesn't require massive amounts of extra "complexity", which is the common argument.
They don't argue that flags add area, or power consumption. Just an unreasonable amount of extra design complexity (and maybe a FMAX limitation) to the extent that OoO μarches would be far better with flags not existing.
Of course flags uses more area (though IMO, probably not much that area). And if it uses area (even a tiny bit), then engineers are probably going to spend time optimising it. Even tiny savings can be put to use elsewhere.
peterfirefly 21 hours ago [-]
> You have already implemented everything you need to rename regular registers, which you can reuse to implement flag renaming too. It costs a tiny bit of area and maybe a little routing complexity, but doesn't have any impact on fmax.
Renaming the condition codes separately from the registers seems to be the current fashion but it is not the only way.
The Intel P6 kept the condition code outputs together with the register outputs from the ALU -- so it would rename the condition codes and registers together.
However the renaming is done, it is abundantly clear that it can be done. We have 30 years of CPUs in the hands of customers that do it, and they do it fast and using very little area.
sylware 18 hours ago [-]
> Doesn't mean they are right. It's mostly just RISC-V fans blindly repeating the RISC-V justification for not having flags without understanding the situation.
It seems it comes from some CPU designers which have that understanding: for performant implementations, not having a status flag would remove some significant complexity from the way. Having a status flag is said to make classic performant implementation more complicated, and newer ISAs removes that (RISC-V is one of them). And this is only one design choices, I guess they made many others which were done in a similar fashion.
Yeah, I actually meant the distance between µops and the "operation" should be reduced in order to avoid implementation complexity. This statement was not to be taken as verbatim, my bad. The thing is how much of the bad from some ISA legacy did infuse in those µops.
phire 4 hours ago [-]
> It seems it comes from some CPU designers
It comes from CPU designers who don't have a history of making OoO designs. Designers who love making high-performance area-optimised in-order RISC cores. CPU designers who created RISC-V.
I mean, I design CPUs too, (as a hobby) so why not take my word?
RISC-V is not a modern ISA. It might be a new ISA, but it's very much a design stuck in the late-80s. It's basically just "MIPS, but with the benefit of hindsight". They didn't get rid of flags because that was the modern approach, they just blindly copied what MIPS already did in 1984 and tried to come up with a post-hoc rationalisation for it.
Don't get me wrong, RISC-V is not the worst ISA. It does a good job in its intended use-case (of being a great university ISA, easy for students and hobbyists to implement themselves. Or a starting point for weird cores with lots of custom vector instructions). It's just not a modern ISA.
If you want to see an actual modern ISA, take a look at ARMv8.
ARMv8 was designed around the same time as RISC-V, but by professional CPU designers. It was a joint project between ARM Inc and Apple. Those Apple engineers were working on what later became the M1, and the ARMv8 ISA shows very clear signs of being optimised for modern very-wide OoO cores.
peterfirefly 2 days ago [-]
RMW memory instructions are actually pretty nice (and totally counter to the RISC philosophy).
Not only are they compact, they also make it crystal clear that the cache line in question should be marked exclusive as soon as it gets read.
The x86 does not have that much implementation complexity. There's the complexity you always get from high-performance implementations, but Apple, ARM, and IBM pay for that, too. The main issue is that there's just a lot to implement and verify.
sylware 18 hours ago [-]
And if I am not too mistaken, many RISC-V design choices were made to remove that complexity (to bring saner high-performance silicon... and that without IP lock).
adgjlsfhk1 2 days ago [-]
No one does this. Every cpu at this point decodes into uops (the downside of x86 is that the expansion is fairly expensive so it needs caching)
sylware 2 days ago [-]
This is some complexity which seems to be significantly downsized with RISC ISAs.
christkv 4 days ago [-]
This is why I love the Ryzen 395 as it has so much more bandwidth than the typical consumer CPU has. Now I would have loved some PCIE 5.0 lanes.
hxorr 4 days ago [-]
I heard they had issues with the new consumer zen5 I/O die, so unfortunately had to revert to zen4 I/O die for the consumer zen5 CPUs
lowbloodsugar 4 days ago [-]
The 9996 in this article has 16 channels for 1.6TB/s and 256 cores/512 threads. Don't know if this will translate to consumer parts.
prima-facie 4 days ago [-]
I wonder if this also applies to APUs like the Strix Halo?
wtallis 4 days ago [-]
Strix Halo has a newer IO die with twice as many memory controllers, and a better interconnect to the CPU dies. I'm not sure if the individual memory controllers are much better than on the Zen4/5 desktop IO die; I don't think I've seen a Strix Halo system built to use desktop DIMMs so testing how it handles two DIMMs per channel isn't practical.
sliken 5 hours ago [-]
Indeed. All strix halos have soldering on memory. There's some hope that the next generation (medusa halo) might have some systems available with CUDimms.
At least in exchange for soldering on memory you get a decently fast memory clocks and it's 256 bits wide. Much like the macbook pro.
joebonrichie 5 days ago [-]
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.
stingraycharles 4 days ago [-]
It has always been like this, and it’s amazing how branch prediction and speculative execution work. CPUs are so much more complex than the simple mental model you first learn.
magicalhippo 4 days ago [-]
> It has always been like this
Nah. I recall putting multiplication tables in RAM because it was faster to read the tables than doing the multiplication.
RAM used to be relatively fast. These days it's dog slow unless you're streaming.
peterfirefly 2 days ago [-]
It's now been true for longer than we have had VLSI memory.
RAM chips won out over core memory in the early 70's. We've had caches to compensate for the relative slowness of memory since around 1990. That's for mainstream computers (486, Pentium). Mainframe computers have had caches for longer.
WithinReason 4 days ago [-]
The "compute" part of the CPU is almost negligible, most of it is SRAM, reordering and branch prediction
InsidiousWombat 4 days ago [-]
SIMD stuff is also generally pretty big part of the chip, tho of course dwarfed by cache
jauntywundrkind 5 days ago [-]
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?
Tuna-Fish 4 days ago [-]
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+.
spwa4 5 days ago [-]
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?
justincormack 5 days ago [-]
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.
p_l 4 days ago [-]
Memory controllers are pretty much limited by external pinout.
Zen 4 and newer consumer chips have 4 memory controllers (for legacy reasons shown as 2) which handle 32bit wide LPDDR5 or DDR5 interfaces (2x per dimm for DDR5)
The AM5 (desktop) socket has in addition to the 4x 32bit memory lanes, 28 PCI-E lanes (generally 16x for GPU, two 4x general purpose, one 4x to chipset), 4x combined DP/HDMI outputs, USB 2.0 port, 4 USB 3.2 Gen 2 ports. And that's just the major buses, there's ton of other components exposed (simpler IO, sound, power)
All of that counts to staggering 1718 pins - anyone remember when moving dual-channel K8 from 940 pin to 939 allowed removal of whole layer from motherboard PCB, making them way cheaper?
The high-end performance server socket from AMD has 6096 pins, significant chunk of it being the 24x 32bit DDR5 interfaces.
So unfortunately it's very much not easy to add more memory, and that's before considering issues with routing it on motherboard even if you accept changing shapes
servo_sausage 4 days ago [-]
I have no real idea of how much a "pin" costs though; it seems There was a brief period of affordable threadripper, but then product segmentation made that not great for amd...
Perhaps it's better to stick on am5 for a while, but it's not clear if this number of pins is somehow cost effective, or if it's just enough to beat Intel.
AnthonyMouse 4 days ago [-]
> There was a brief period of affordable threadripper, but then product segmentation made that not great for amd...
The thing they're doing which is completely insane is using different sockets for Threadripper and Epyc.
The primary difference between them isn't the price -- they're both expensive -- it's that Epyc uses the power budget to reach higher core counts and Threadripper uses it to hit higher clock speeds. So for example, Zen5 Threadripper 9975WX has 32 cores with a 4 GHz base clock and 5.4 GHz boost clock. There is no equivalent Zen5 Epyc, the most similar is 9375F which is 3.8GHz/4.8GHz. Conversely, Epyc 9755 has 128 Zen5 cores and Epyc 9965 has 192 Zen5c cores and there is no Threadripper with that many cores.
The reason this matters is that the system boards themselves are pricey, not just the CPUs, but as the platform starts to age you start to get a lot of old servers on the used market that originally had a bottom-end Epyc in them. Which you'd then like to pull and replace with a Threadripper -- i.e. pay them more money to buy a new Threadripper -- except that they inexplicably decided to screw you and themselves by using a different socket.
And the same thing the other way around. It also means you can't find an older workstation with the bottom-end Threadripper and pay them money for a high core count Epyc with better performance per watt to use it as a server.
Whoever did it this way doesn't seem to understand that market segmentation is intended to separate price segments rather than just creating arbitrary compatibility impairment between things that have similar prices.
p_l 4 days ago [-]
Apparently it is nearly possible electrically for some EPYC/Threadripper combinations, but requires considerable investment on the motherboard side - muxing different firmware types, analog and digital logic to detect CPU type and modify some of the connections (including different VRM configuration)
So, possible to do by motherboard vendor, not necessarily enforced by AMD, expensive
AnthonyMouse 3 days ago [-]
Anything is possible if you want to hire an entire team of professionals and fabricate your own parts, but that's not the issue.
Consider that they could have had the opposite of that. Companies design a single board that can be used for either chip instead of two separate boards, and thereby have lower design costs, which allows them to sell the boards for less while making more money, which in turn makes customers happy and causes them to buy more of your chips.
p_l 4 days ago [-]
The real issue is that the cost is not really on AMD - the cost is on motherboard vendors - more complex routing, thicker PCBs, etc. - all adds up.
A pin on underside of CPU is reasonably cheaper especially with how they've got a sea of wires working for the humongous models replacing previous serdes-based approach
adrian_b 3 days ago [-]
The new Zen 6 Venice server CPUs have 32 x 32-bit DDR5 interfaces, which also work up to 12800 MT/s, double in comparison with the DDR5-6400 supported by the Zen 5 server CPUs.
So the socket is even bigger, but they no longer support 2 DIMMs per channel, so a CPU socket connects to only 16 DIMM sockets.
p_l 3 days ago [-]
The reason we had the saga of "registered" aka "buffered" memory, and the various serial-link based memories, is just how it is to run wide parallel buses at high clock speeds.
At the newest speeds, it becomes impractical even with buffered drivers and self-clocking
adrian_b 3 days ago [-]
That's true.
However, besides the big SP7 socket with 16 DIMMs and 1 DIMM per channel, Zen 6 Venice will be available also with the somewhat smaller SP8 socket, which uses the same 16 DIMM sockets, but here there are 2 DIMMs per channel at a halved number of channels, so the maximum memory throughput is halved, from 1.6 TByte/s to 0.8 TByte/s, while the maximum amount of memory stays the same, at 2 TB.
It is interesting that Zen 6 has 2 I/O dies, each with 8 memory controllers, but in the smaller SP8 socket the same 2 memory controllers are used, with only 4 memory controllers enabled in each I/O die, instead of using only 1 I/O die.
Presumably that was done in order to not reduce the number of PCIe lanes in the SP8 socket, which actually has more PCIe lanes than the SP7 socket.
p_l 3 days ago [-]
It's possible also that most beneficial routing/partitioning for IOD made an impact, including actual Infinity Fabric topology and port counts
hedgehog 5 days ago [-]
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).
theandrewbailey 5 days ago [-]
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.
yread 4 days ago [-]
Strata is!
Dylan16807 4 days ago [-]
"few workloads are bottlenecked by memory bandwidth" becomes a self-fulfilling prophecy at a certain point. Especially when companies are marketing AI stuff but still sticking with 128 bit memory busses for their mainstream models. Except for Apple, the only company competing on this metric.
spwa4 4 days ago [-]
This is probably why open weight models run so well on "old" Epyc hardware.
adgjlsfhk1 4 days ago [-]
That doesn't help memory latency and most of the time a cpu is waiting it's because of latency, not bandwidth.
O3marchnative 4 days ago [-]
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.
This is something AI is really good at. Plus, you don't need AI for this. In my time at <FANG> I made a "runtime compiler" that did this for parallelizable calculations (applying kernels on images, this was a long time ago). It didn't even need information on the machine it was running on, it just spent 5-6 seconds during startup trying some 50 different memory access patterns, figuring out the size of the cache from when it slows down, ... and then you had a simple language you could specify operations to execute on large images and it would do them. Fast. Very fast.
And yes, this was only worth doing for things that were memory bound. But anything relating to images is, pretty much.
I wrote something similar for regexes too. Get all matches from a massive file, or check massive numbers of lines of text and figure out which ones match a given regex. That too is still running. Even the AI models are now using it, although I'm told they at least also improved that one. I wonder how, actually.
A team took over the image compiler and it's still running, I'm told. I got 12k'd, of course. At this point there's literally ONE person left in the team that created the core tools, and he's the one known for going into management first chance he got.
I should write an open source version of this focusing on ML. I wonder how hard that actually is ...
O3marchnative 4 days ago [-]
> It didn't even need information on the machine it was running on, it just spent 5-6 seconds during startup trying some 50 different memory access patterns, figuring out the size of the cache from when it slows down, ... and then you had a simple language you could specify operations to execute on large images and it would do them. Fast. Very fast.
This is pretty cool. It sounds very similar to how FFTW works. You create a plan, and you give it as much time as you're willing to spend on planning. It will then use that time to find the fastest set of underlying kernels for your hardware and input size.
5 days ago [-]
Sharlin 4 days ago [-]
Nine women cannot make a baby in one month.
edelbitter 4 days ago [-]
I wonder how much more cores I need to start meaningfully predicting keyboard input and have all the babies will all applicable bathwater ready before the clock starts.
CyberDildonics 4 days ago [-]
CPUs are just so much faster than their memory controllers
This assumption isn't true. It takes solid optimization to end up limited by memory bandwidth. The problem is memory latency and that is not something that can be solved by adding more bandwidth from another memory controller.
matja 4 days ago [-]
128 cores x 288 pins per DIMM = 36864 pins on your socket, and all the motherboard traces. Good luck with that...
Rohansi 4 days ago [-]
Why would each core need a direct connection to the DIMMs?
matja 4 days ago [-]
That'd give you the best memory bandwidth. A single core is more than capable of saturating a single memory channel in certain streams of instructions.
Early AMD x86-64 chips were exactly that, and EPYC Naples (gen 1) was similar - each CCD had 2 memory channels. Later EPYCs ran the memory controllers from a separate IOD, in part because the strong NUMA topology was a bit too much for some OS's (Windows) to handle.
But these days with the very high core counts, it is infeasible for a memory channel per core.
imtringued 3 days ago [-]
because 64GB/s is 256 bits per cycle at 2 GHz.
If you want to have an NoC, then you will need an ultra wide multi channel interface on the order of 4096 bits for 16 parallel 256 bit channels per row.
spwa4 1 days ago [-]
Ah I see. But those pins have to exist inside the package, right? Even if it all gets merged into one memory controller, the cores (or some unit that's repeated) would still need to have a memory-like protocol with something that aggregates them ... So why not stick the memory inside (or close enough) to the package?
Is that why M1-6 chips have the memory glued on top?
Remnant44 4 days ago [-]
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
4 days ago [-]
Aardwolf 4 days ago [-]
> 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?
adrian_b 4 days ago [-]
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.
jandrewrogers 4 days ago [-]
IIRC, PDEP/PEXT are generalizations of shifter networks.
seastarer 4 days ago [-]
A multiplier also contains a generalized shifter network.
Multiplying by 2^n = shift by n.
bee_rider 4 days ago [-]
32 cores is a lot of cores in a CCD. Is there a there any smaller logical unit between a CCD and a core, or are you expected to wrangle 32 cores in your lowest NUMA level?
wmf 4 days ago [-]
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.
deaton 4 days ago [-]
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
lp92 4 days ago [-]
Seems like they are starting to optimize the C core architecture already. Wonder how long it'll be before it becomes its own line up and branding.
ls65536 4 days ago [-]
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.
Numerlor 3 days ago [-]
P cores will eventually move to the same uArch as E cores so they'll get even more similar, I expect it'll be similar to amd's, as you're either pushing frequency at the cost of power, or going for general efficiency which you must do to even consider stuffing so many cores into a cpu
ahartmetz 4 days ago [-]
It's interesting to hear indeed. The 6c's improved latency hiding might be intended for use in extremely high core count Epycs, which have lots of memory channels, but not many at all per core.
sylware 4 days ago [-]
When you look at all this prediction, it is so much important for a 'core/smt' to 'learn' some code behaviour, hence thread CPU/SMT affinity is beyond paramount for applications which are pushing a bit our CPUs.
dmitrygr 4 days ago [-]
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.
adrian_b 4 days ago [-]
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.
hajile 4 days ago [-]
Apple could absolutely make a server CPU using their E-cores that would wipe the floor with Zen6 in both perf and perf/watt. Apple isn't in the server hardware business though which would make it a pointless piece of engineering.
LtdJorge 4 days ago [-]
Sure
hajile 4 days ago [-]
Apples E-cores have higher IPC, are much smaller, and use way less power.
What about beating your competition in perf/watt/area means you couldn’t make a better chip? Has that ever happened before?
LtdJorge 2 days ago [-]
You need scaling, you can make a 4 core that beats a 128 core when running on 4 threads. That doesn't mean scaling the design of the 4 core to 128 will beat the 128 core design.
I have absolutely no idea what this is benchmarking or how, but is there any reason not to just read this as the "consumer/low core ryzen" is twice as fast as the m5 pro?
Sopel 4 days ago [-]
> I have absolutely no idea what this is benchmarking or how
It's the best chess engine used by millions of people and part of SPEC2026, natively compiled
Tuna-Fish 4 days ago [-]
Stockfish parallelizes well and makes heavy use of vector operations, and the Zen5 core has AVX-512 with 4x 512bit° EU per core and 16 cores, while the Apple still only uses 128-bit wide SIMD, with the 6 M5 "Super" cores having 4x128 EUs and the 12 "Performance" cores only having 2x128 EUs.
The M5 Pro is doing shockingly well given the massive disparity in execution resources. But still, it's optimized for web/desktop-like loads, you shouldn't really run heavy number crunching on that CPU.
0: 2x FMA/MUL + 2X ADD
hajile 4 days ago [-]
They also mention using SSE/AVX on x86 and NEON on ARM, but there's zero mention of SVE, SME, or AMX which makes me wonder if they aren't compiling with those options (if so, it would be a serious disadvantage).
Tuna-Fish 4 days ago [-]
Apple cores do not implement SVE, SME is not suitable for Stockfish (it is optimized for matrix-matric with large batch size, stockfish is all matrix-vector with batch size of 1), and AMX has the same problem.
You don't get good performance out of this kind of code by just compiling with different options, the compute kernels must be tuned to fit the architecture, and nothing on the M-series but NEON fits the bill.
Sopel 4 days ago [-]
we've tested x86 AMX when the first Intel CPUs with AMX came out and it was worse. The conclusion was that AMX is not suitable for matrix-vector multiplication, only for matrix-matrix multiplication.
apple's SME/AMX is useless because it's not directly programmable
wredcoll 4 days ago [-]
Is there any sane way to generalize these results?
Narishma 4 days ago [-]
I don't think so. The workloads are simply too different to generalize.
4 days ago [-]
Sopel 4 days ago [-]
it's not year 2006 anymore
dmitrygr 4 days ago [-]
I’m sorry, I wasn’t aware that Amdahl's law has been cancelled. I will brush up on my computing theory.
AnthonyMouse 4 days ago [-]
Workloads with legitimate serialization dependencies rather than just bad code are pretty rare. Of course, there is still a lot of bad code out there, but it's not Amdahl's law stopping them from doing better.
adrian_b 3 days ago [-]
Amdahl's law prevents great improvements through parallelism only in small problems, e.g. those that can be completed in seconds or minutes.
In big problems, e.g. those whose solution requires hours or days of computation, it is almost always possible to decompose them in enough quasi-independent subproblems that can be executed in parallel, so that you can get an acceleration from parallel execution not much less than the number of available processor cores.
trynumber9 4 days ago [-]
1. Different market
2. What flags & compiler?
3. Can't run Linux on that M5/M6 can we?
wmf 4 days ago [-]
Linux is now (barely) working on M5/M6.
dmitrygr 4 days ago [-]
1. so is Ryzen 9 9950X
crote 4 days ago [-]
Regular Ryzen parts are still reasonably relevant for server use! They support ECC, so there's nothing immediately disqualifying them - see the rebranded "EPYC" 4005 series, for example.
A company like Hetzner isn't going to care an awful lot whether they deploy one big SP5 server or four small AM5 ones for the VM instances they rent out: the only thing that matters is TCO per performance.
Want to stick four NVMe SSDs, a 25Gbit NIC, 256GB of ECC RAM, and some OOB module on a Ryzen board? No problem whatsoever. Want to do the same with an Apple CPU? Ehhh, that's going to be slightly more challenging...
trynumber9 4 days ago [-]
1. 9950X isn't on the chart.
The 9950X3D2 was already tested. And was included as comparison point with the fastest possible version of its predecessor (Zen 5).
Some evidence that contextless numbers are meaningless is that your source, David Huang, does include the 9950X but in his results it scores much higher than everything on C&C's chart too (7.25/11.4)
Remnant44 4 days ago [-]
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.
jeffbee 4 days ago [-]
The same graph has a bar for the Ryzen 9 9950X, though.
toast0 4 days ago [-]
Ryzen 9950X is basically the same as an Epyc 4565P, except you can buy the Ryzen in a retail box.
troyvit 4 days ago [-]
Waxes nostalgic over the G5 Xserve
alfiedotwtf 4 days ago [-]
I was excited about the headline, but then disappointed with the article.
It’s 2026, and although everything looks good, I think they’re barking up the wrong bush is they don’t do anything for their memory speeds.
Imagine if AMD opened up consumer CPUs to 8 or even 12 channel memory lanes. You could combine all different size sticks and create a monster that would sell like hot cakes in today’s ramageddon
3 days ago [-]
nukanse 4 days ago [-]
The brach predictor it's the bane of programmers. It forces to waste effort to write unreadable branchless code.
X86 should support no-branch-predict-if and dont-predict-goto
josephg 4 days ago [-]
You've got it the wrong way around. If the branch predictor was 100% accurate, branchless code would have no performance benefit compared to branching code.
> X86 should support no-branch-predict-if
It almost does. You can use __builtin_expect to hint if the branch is predictable - like assertions. Don't annotate conditionals if they're truly unpredictable. The branch predictor will run, but it's not expensive.
Sesse__ 4 days ago [-]
I'm not sure if you mean to imply so, but the __builtin_expect() hint is not embedded in the instruction stream in any way. It mostly affects basic block layout (and not always in a good way).
colejohnson66 3 days ago [-]
Newer Intel CPUs (Raptor Lake?) are "adding back" the "branch hint" prefixes. On the Pentium P4, the segment prefixes were repurposed on conditional branches to be branch hints, but then ditched because branch prediction got good. I guess as cores have gotten deeper and deeper it makes sense to bring them back?
kevin_thibedeau 4 days ago [-]
You should prefer using the standardized likely/unlikely attributes instead.
nukanse 4 days ago [-]
Branchless programming is a thing because those don't work, and branch prediction hurts performance on many cases
peterfirefly 2 days ago [-]
I think -- I know -- that you have misunderstood what branch prediction is.
Maybe you are asking for way to do static branch prediction for selected conditional branches instead of dynamic branch prediction (or as a supplement)? That's the most charitable way I can interpret your comments.
That is already part of the x86 architecture. Intel introduced it back in the Pentium 4 days. It takes the form of an extra prefix byte that hints the branch as "taken" or "not taken". The trick to doing it in a backwards compatible way is that they reuse the segment override prefixes (CS and DS). These hints are ignored on modern CPUs -- except maybe on some very new Intel CPUs? They are ignored because the dynamic branch predictor works better.
frankchn 4 days ago [-]
Won't that just stall the pipeline on a modern superscalar core and cause even worse performance?
simonask 4 days ago [-]
Yes. I don’t think this person (presumed) knows what a branch predictor does.
nukanse 4 days ago [-]
Select my post, right click, press search, and Google ai will explain to you basic stuff about branchless programming that you should know already.
simonask 4 days ago [-]
I write branchless SIMD code every day. The branch predictor is my friend, not my enemy.
nukanse 4 days ago [-]
Liar
nukanse 4 days ago [-]
There are use cases where branch prediction performs better and others where it performs worse. Ask an AI about branchless programming and when it can improve performance. We need both types of CPU instructions to achieve optimal performance.
bajard 4 days ago [-]
A misprediction may be much worse than a small stall.
Your error is to assume that it has to be only one or the other, instead of giving the programmer the choice, since the programmer is the only one benchmarking his code and knowing the answer.
Of all the things I'm looking forward to on Zen6, an improved memory controller is at the top of the list.
Edit: and yes, others may say the paltry few PCIE 5.0 lanes is the worst thing about AM5, but that doesn't affect my usage much, and unfortunately I think that's a limitation of AM5 itself rather than the I/O chiplet.
I've never gotten 4 sticks to pass training, no matter what I change. This is a well-known limitation. Some people, with newer AGESA on certain motherboards, have been able to get 4 sticks above 3600 MT/s but it's not possible for most people, and questionably stable even for those that have succeeded.
> Their existing AM5 Zen4/5 memory controller when using both memory channels is terrible. Extremely hard or impossible to get above 3600 MT/s.
For reference I'm using vsoc 1.08v, vddp 0.98v, vddg 1.0v, vdimm 1.38v and couldn't get above 1900 uclk / 3800 MT/s without uncomfortable vsoc. I've seen lots of people claim 2000/4000 at 1.1-1.15v vsoc but I don't want to run that high daily.
Oh and don't push vsoc to 1.2v+ as per AMD.
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.
https://www.amd.com/en/products/processors/desktops/ryzen/90...
Obviously, you can run memory faster than the officially supported speed, including 4 DIMMS, but the Zen 5 architecture has a reputation for being finicky trying to run 4 DIMMs at higher speeds and you need a bit of care in what you pick and how you tune it.
https://valid.cpuid.com/sdyce7k2
Side note: At 2ghz IF, a single Zen4/5 CCD can saturate 7200 MT DDR5, but the io die is not restricted to that, so x16 and IGPU DMA can still saturate it at 8000.
Well, we also have to get rid of x86_64 ISA... Shouldn't those "µops" be the ISA?
Personnally I try to code as much as I can in RISC-V assembly, or in the worst case scenario simple and plain C compiling with NOT gcc | clang/llvm.
of course not.
This allows Intel and AMD (and VIA) to have different µops. It also allows the µops to change from Pentium Pro to Pentium II to Pentium III, and from Zen 1 to 6.
It also allows the µops to be a lot bigger than the fairly lame 32 bits of normal RISC instructions, while also allowing for extra internal registers.
All modern CPUs that try to go for performance use out of order execution and decoders and µops of some sort, no matter what their external instruction set looks like. That's true for IBM's PowerPC, for ARM's ARM CPUs, for Apple's ARM CPUs, for everybody's RISC-V, etc.
Your experience (and everybody's) would be worse in every way if people started coding in µops.
By keeping them internal and hidden, you get compatibility, higher code density, compatibility, higher performance, compatibility, reuse of test vectors, compatibility, reuse of formal proofs of various parts of the processor (very important because you can't fully test something as complicated as a modern CPU), compatibility plus compatibility. And compatibility, of course.
That said, the real sweet spot is probably not in an ISA based on pure µops, but something in between, but closer to those µops, like RISC.
They would be stable enough to make it fairly easy to port validation software/tests/proofs over within a single company. They would not be stable enough to base software upon them. Obviously. Not even for CPUs from a single company. They would also be grossly inefficient because they are bigger than the current external instructions.
(It is a bit like GPU hardware binary "descriptors")
Well... that is the pure RISC philosophy from the 80s.
But there are advantages to having a disconnect between the encoded instructions and μops. So much that most "RISC" ISAs have instructions that are explicitly intended to decode to multiple μops. ARMv8 takes this approach pretty far, with quite a few instructions that are explicitly intended to be split into multiple μops.
Hell... Even RISC-V has begrudgingly expermented with the idea: See the Zcmp/Zcmt extensions which are explicitly defined to decoded to multiple 32-bit instructions; Or arguably the Zaamo Atomic instructions, which are part of RVA23.
The transition is going, if any, will be tough: basically you would need a "x86_64" hardware 'slow' mode, on the side of the 'clean' and light RISC one.
z/Arch, x86, ARM, PowerPC, and SPARC all have condition codes. They all have OOO implementations and all but SPARC have really, really fast implementations.
---
µops are not at all like RISC instructions. They tend to be quite big, for example, or have really strange encodings (that vary from place to place inside the CPU). A group of 2-4 µops may share a single wide literal field (or bigger literals will be encoded with a number of µops or something else crazy).
Pentium Pro (P6) had a µops length (at some point inside the CPU) of around 115 bits, for example.
µops also typically expose the pipeline(s) to some extent which is just ugly and very, very for from being clean.
You don't have to look far, the RISC-V spec makes this incorrect claim.
> µops are not at all like RISC instructions
Yeah. Zen μops are actually documented to be variable length (at least when stored in the μop cache, but presumably elsewhere). And μops hold both a memory load and an ALU operation... very CISC.
It's only the full read-modify-write instructions that still get split into two μops. And I doubt it's actually two fully independent μops, because seems a waste to send the instruction through the AGU twice.
And RISC-V as its sweet spot roughly set for implementation simplicity, namely some core design choices show a strong difference here.
Obviously µops are encoded specific to some µarchitecture, but their "operations" may tell us what would be a "good" ISA for performance, and many seem to agree that this ISA would be "RISC" based. This what I intended to say.
Doesn't mean they are right. It's mostly just RISC-V fans blindly repeating the RISC-V justification for not having flags without understanding the situation.
And it's only RISC-V (and MIPS before it) which sticks to this position. Most other high-performance RISC arches have flags. Including ARMv8, a complete departure from 32-bit ARM, and one which was explicitly designed with high-performance OoO cores in mind. ARMv8 dropped many fun RISC features from Arm32, but they kept flags.
Really, the cost for flags on OoO cores isn't that high. You have already implemented everything you need to rename regular registers, which you can reuse to implement flag renaming too. It costs a tiny bit of area and maybe a little routing complexity, but doesn't have any impact on fmax.
> but their "operations" may tell us what would be a "good" ISA for performance, and many seem to agree that this ISA would be "RISC" based.
Well... given that the current μops of x86 cores aren't RISC-like, (because they are variable length, and aren't load-store), your suggested philosophy would not result in a RISC-like replacement ISA for x86.
Like, the weaker form of your argument is probably correct. If we were designing a replacement x86 ISA, then the current μops of various x86 implementations would be a good inspiration for informing what that ISA could look like.
It's only the strong form that I disagree with: There is no good reason for any ISA to be a 1:1 mapping of the μops it decodes into. And there are many good arguments for not doing that. μops can be arbitrarily wide, as they are only used for internal purposes. Instructions need to be dense and compressed, as code density can have a large impact on performance. There is no good reason why a single instruction shouldn't decode to two or even hundreds of μops... that's just good compression.
I generally agree, but want to point out that they aren't "free" either. Look at contemporary wide OoO Arm cores, most (Apple Silicon, C1-Ultra, ...) have half the throughput on flag reading/writing instructions than the equivalent instruction without the flag write (ADD vs ADC vs ADDS). So clearly the cost is high enough to drive towards such tradeoffs being made.
I'm only really arguing that handling flags in OoO designs doesn't require massive amounts of extra "complexity", which is the common argument.
They don't argue that flags add area, or power consumption. Just an unreasonable amount of extra design complexity (and maybe a FMAX limitation) to the extent that OoO μarches would be far better with flags not existing.
Of course flags uses more area (though IMO, probably not much that area). And if it uses area (even a tiny bit), then engineers are probably going to spend time optimising it. Even tiny savings can be put to use elsewhere.
Renaming the condition codes separately from the registers seems to be the current fashion but it is not the only way.
The Intel P6 kept the condition code outputs together with the register outputs from the ALU -- so it would rename the condition codes and registers together.
However the renaming is done, it is abundantly clear that it can be done. We have 30 years of CPUs in the hands of customers that do it, and they do it fast and using very little area.
It seems it comes from some CPU designers which have that understanding: for performant implementations, not having a status flag would remove some significant complexity from the way. Having a status flag is said to make classic performant implementation more complicated, and newer ISAs removes that (RISC-V is one of them). And this is only one design choices, I guess they made many others which were done in a similar fashion.
Yeah, I actually meant the distance between µops and the "operation" should be reduced in order to avoid implementation complexity. This statement was not to be taken as verbatim, my bad. The thing is how much of the bad from some ISA legacy did infuse in those µops.
It comes from CPU designers who don't have a history of making OoO designs. Designers who love making high-performance area-optimised in-order RISC cores. CPU designers who created RISC-V.
I mean, I design CPUs too, (as a hobby) so why not take my word?
RISC-V is not a modern ISA. It might be a new ISA, but it's very much a design stuck in the late-80s. It's basically just "MIPS, but with the benefit of hindsight". They didn't get rid of flags because that was the modern approach, they just blindly copied what MIPS already did in 1984 and tried to come up with a post-hoc rationalisation for it.
Don't get me wrong, RISC-V is not the worst ISA. It does a good job in its intended use-case (of being a great university ISA, easy for students and hobbyists to implement themselves. Or a starting point for weird cores with lots of custom vector instructions). It's just not a modern ISA.
If you want to see an actual modern ISA, take a look at ARMv8.
ARMv8 was designed around the same time as RISC-V, but by professional CPU designers. It was a joint project between ARM Inc and Apple. Those Apple engineers were working on what later became the M1, and the ARMv8 ISA shows very clear signs of being optimised for modern very-wide OoO cores.
Not only are they compact, they also make it crystal clear that the cache line in question should be marked exclusive as soon as it gets read.
The x86 does not have that much implementation complexity. There's the complexity you always get from high-performance implementations, but Apple, ARM, and IBM pay for that, too. The main issue is that there's just a lot to implement and verify.
At least in exchange for soldering on memory you get a decently fast memory clocks and it's 256 bits wide. Much like the macbook pro.
Nah. I recall putting multiplication tables in RAM because it was faster to read the tables than doing the multiplication.
RAM used to be relatively fast. These days it's dog slow unless you're streaming.
RAM chips won out over core memory in the early 70's. We've had caches to compensate for the relative slowness of memory since around 1990. That's for mainstream computers (486, Pentium). Mainframe computers have had caches for longer.
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?
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.)
Zen 4 and newer consumer chips have 4 memory controllers (for legacy reasons shown as 2) which handle 32bit wide LPDDR5 or DDR5 interfaces (2x per dimm for DDR5)
The AM5 (desktop) socket has in addition to the 4x 32bit memory lanes, 28 PCI-E lanes (generally 16x for GPU, two 4x general purpose, one 4x to chipset), 4x combined DP/HDMI outputs, USB 2.0 port, 4 USB 3.2 Gen 2 ports. And that's just the major buses, there's ton of other components exposed (simpler IO, sound, power)
All of that counts to staggering 1718 pins - anyone remember when moving dual-channel K8 from 940 pin to 939 allowed removal of whole layer from motherboard PCB, making them way cheaper?
The high-end performance server socket from AMD has 6096 pins, significant chunk of it being the 24x 32bit DDR5 interfaces.
So unfortunately it's very much not easy to add more memory, and that's before considering issues with routing it on motherboard even if you accept changing shapes
Perhaps it's better to stick on am5 for a while, but it's not clear if this number of pins is somehow cost effective, or if it's just enough to beat Intel.
The thing they're doing which is completely insane is using different sockets for Threadripper and Epyc.
The primary difference between them isn't the price -- they're both expensive -- it's that Epyc uses the power budget to reach higher core counts and Threadripper uses it to hit higher clock speeds. So for example, Zen5 Threadripper 9975WX has 32 cores with a 4 GHz base clock and 5.4 GHz boost clock. There is no equivalent Zen5 Epyc, the most similar is 9375F which is 3.8GHz/4.8GHz. Conversely, Epyc 9755 has 128 Zen5 cores and Epyc 9965 has 192 Zen5c cores and there is no Threadripper with that many cores.
The reason this matters is that the system boards themselves are pricey, not just the CPUs, but as the platform starts to age you start to get a lot of old servers on the used market that originally had a bottom-end Epyc in them. Which you'd then like to pull and replace with a Threadripper -- i.e. pay them more money to buy a new Threadripper -- except that they inexplicably decided to screw you and themselves by using a different socket.
And the same thing the other way around. It also means you can't find an older workstation with the bottom-end Threadripper and pay them money for a high core count Epyc with better performance per watt to use it as a server.
Whoever did it this way doesn't seem to understand that market segmentation is intended to separate price segments rather than just creating arbitrary compatibility impairment between things that have similar prices.
So, possible to do by motherboard vendor, not necessarily enforced by AMD, expensive
Consider that they could have had the opposite of that. Companies design a single board that can be used for either chip instead of two separate boards, and thereby have lower design costs, which allows them to sell the boards for less while making more money, which in turn makes customers happy and causes them to buy more of your chips.
A pin on underside of CPU is reasonably cheaper especially with how they've got a sea of wires working for the humongous models replacing previous serdes-based approach
So the socket is even bigger, but they no longer support 2 DIMMs per channel, so a CPU socket connects to only 16 DIMM sockets.
At the newest speeds, it becomes impractical even with buffered drivers and self-clocking
However, besides the big SP7 socket with 16 DIMMs and 1 DIMM per channel, Zen 6 Venice will be available also with the somewhat smaller SP8 socket, which uses the same 16 DIMM sockets, but here there are 2 DIMMs per channel at a halved number of channels, so the maximum memory throughput is halved, from 1.6 TByte/s to 0.8 TByte/s, while the maximum amount of memory stays the same, at 2 TB.
It is interesting that Zen 6 has 2 I/O dies, each with 8 memory controllers, but in the smaller SP8 socket the same 2 memory controllers are used, with only 4 memory controllers enabled in each I/O die, instead of using only 1 I/O die.
Presumably that was done in order to not reduce the number of PCIe lanes in the SP8 socket, which actually has more PCIe lanes than the SP7 socket.
[0] https://en.algorithmica.org/hpc/cpu-cache/sharing/#saturatin...
And yes, this was only worth doing for things that were memory bound. But anything relating to images is, pretty much.
I wrote something similar for regexes too. Get all matches from a massive file, or check massive numbers of lines of text and figure out which ones match a given regex. That too is still running. Even the AI models are now using it, although I'm told they at least also improved that one. I wonder how, actually.
A team took over the image compiler and it's still running, I'm told. I got 12k'd, of course. At this point there's literally ONE person left in the team that created the core tools, and he's the one known for going into management first chance he got.
I should write an open source version of this focusing on ML. I wonder how hard that actually is ...
This is pretty cool. It sounds very similar to how FFTW works. You create a plan, and you give it as much time as you're willing to spend on planning. It will then use that time to find the fastest set of underlying kernels for your hardware and input size.
This assumption isn't true. It takes solid optimization to end up limited by memory bandwidth. The problem is memory latency and that is not something that can be solved by adding more bandwidth from another memory controller.
Early AMD x86-64 chips were exactly that, and EPYC Naples (gen 1) was similar - each CCD had 2 memory channels. Later EPYCs ran the memory controllers from a separate IOD, in part because the strong NUMA topology was a bit too much for some OS's (Windows) to handle.
But these days with the very high core counts, it is infeasible for a memory channel per core.
If you want to have an NoC, then you will need an ultra wide multi channel interface on the order of 4096 bits for 16 parallel 256 bit channels per row.
Is that why M1-6 chips have the memory glued on top?
The real star looks like the c cores though. 32 C cores per chiplet with increased l3 cache is impressive
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?
Multiplying by 2^n = shift by n.
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.
What about beating your competition in perf/watt/area means you couldn’t make a better chip? Has that ever happened before?
> AMD Ryzen 9 9950X 16-Core 63rd 4 40132379 +/- 2530724
> Apple M5 Pro 52nd 5 22108587 +/- 260160
I have absolutely no idea what this is benchmarking or how, but is there any reason not to just read this as the "consumer/low core ryzen" is twice as fast as the m5 pro?
It's the best chess engine used by millions of people and part of SPEC2026, natively compiled
The M5 Pro is doing shockingly well given the massive disparity in execution resources. But still, it's optimized for web/desktop-like loads, you shouldn't really run heavy number crunching on that CPU.
0: 2x FMA/MUL + 2X ADD
You don't get good performance out of this kind of code by just compiling with different options, the compute kernels must be tuned to fit the architecture, and nothing on the M-series but NEON fits the bill.
apple's SME/AMX is useless because it's not directly programmable
In big problems, e.g. those whose solution requires hours or days of computation, it is almost always possible to decompose them in enough quasi-independent subproblems that can be executed in parallel, so that you can get an acceleration from parallel execution not much less than the number of available processor cores.
2. What flags & compiler?
3. Can't run Linux on that M5/M6 can we?
A company like Hetzner isn't going to care an awful lot whether they deploy one big SP5 server or four small AM5 ones for the VM instances they rent out: the only thing that matters is TCO per performance.
Want to stick four NVMe SSDs, a 25Gbit NIC, 256GB of ECC RAM, and some OOB module on a Ryzen board? No problem whatsoever. Want to do the same with an Apple CPU? Ehhh, that's going to be slightly more challenging...
The 9950X3D2 was already tested. And was included as comparison point with the fastest possible version of its predecessor (Zen 5).
Some evidence that contextless numbers are meaningless is that your source, David Huang, does include the 9950X but in his results it scores much higher than everything on C&C's chart too (7.25/11.4)
Different story when you're talking about the context of a desktop or mobile.
It’s 2026, and although everything looks good, I think they’re barking up the wrong bush is they don’t do anything for their memory speeds.
Imagine if AMD opened up consumer CPUs to 8 or even 12 channel memory lanes. You could combine all different size sticks and create a monster that would sell like hot cakes in today’s ramageddon
X86 should support no-branch-predict-if and dont-predict-goto
> X86 should support no-branch-predict-if
It almost does. You can use __builtin_expect to hint if the branch is predictable - like assertions. Don't annotate conditionals if they're truly unpredictable. The branch predictor will run, but it's not expensive.
Maybe you are asking for way to do static branch prediction for selected conditional branches instead of dynamic branch prediction (or as a supplement)? That's the most charitable way I can interpret your comments.
That is already part of the x86 architecture. Intel introduced it back in the Pentium 4 days. It takes the form of an extra prefix byte that hints the branch as "taken" or "not taken". The trick to doing it in a backwards compatible way is that they reuse the segment override prefixes (CS and DS). These hints are ignored on modern CPUs -- except maybe on some very new Intel CPUs? They are ignored because the dynamic branch predictor works better.
Your error is to assume that it has to be only one or the other, instead of giving the programmer the choice, since the programmer is the only one benchmarking his code and knowing the answer.