One have to be reasonable. That performance improvement would have been insane (think Zen 5 40% IPC) to be compelling for that premium.
As already mentioned, the competition was there - Intel's Raptor was fresh from owen and pretty good vs Zen 4.
One have to be reasonable. That performance improvement would have been insane (think Zen 5 40% IPC) to be compelling for that premium.Which also says that performance of Zen 4 without V-Cache was not compelling enough to pay the premium.
It also forced AMD to offer deep discounts.
GPU production is inherently serial because you need to get chip first, then get shipped to be placed into boards, add memory etc - all extra steps required, per GPU.X3D production is inherently serial between the bit that makes the chip and the bit that puts the cache on the chip.
You don't need to make 80s or 90s for the other one to be available
Hmm, isn't 5 twice that of 2.5? The graphs which you are linked are informative. But even more informative would be simulations of a choice of different workloads, with different cache hit rates and different cache latencies.Shared L2 (Apple and Qualcomm have shown you can do this with a manageable latency penalty: ~5ns vs ~2.5ns for 16x the size, original source)
Bad for server CPUs, such as Zen ones.
This paints a too simplistic picture of what they actually did. First, they still have L2 and L3 (and L4 even), just that L3 and L4 are now "virtual" by way of sharing SRAM with L2 dynamically. Still, L3 (let alone L4) latency is higher than L2 latency — typically much higher. Second, and this is what your argument neglects, there is a bunch of QoS not-so-secret sauce in place, to keep the extent of sharing in check, IOW to maintain a prioritized rest of low-latency L2 cache for each active core. If a core is not completely idle, it does have L2 cache which other cores can't displace. So in this regard, these mainframe CPUs don't really differ from what @Win2012R2 claimed about server CPUs.Shared L2 caches in server provessors is so bad that IBM went ahead and designed a whole Power processor generation that shared all the L2 caches among the cores in one dynamic virtual L3 pool.
Are you trying to make sure everybody gets thinking you indeed make bad faith arguments?GPU production is inherently serial because you need to get chip first, then get shipped to be placed into boards, add memory etc - all extra steps required, per GPU.
I never said that it was perfect, but they have a VERY effective strategy for sharing it that hides a lot of the problems and also gives some big advantages for things that have high locality in a smaller footprint.Hmm, isn't 5 twice that of 2.5? The graphs which you are linked are informative. But even more informative would be simulations of a choice of different workloads, with different cache hit rates and different cache latencies.
[Shared L2…]
This paints a too simplistic picture of what they actually did. First, they still have L2 and L3 (and L4 even), just that L3 and L4 are now "virtual" by way of sharing SRAM with L2 dynamically. Still, L3 (let alone L4) latency is higher than L2 latency — typically much higher. Second, and this is what your argument neglects, there is a bunch of QoS not-so-secret sauce in place, to keep the extent of sharing in check, IOW to maintain a prioritized rest of low-latency L2 cache for each active core. If a core is not completely idle, it does have L2 cache which other cores can't displace. So in this regard, these mainframe CPUs don't really differ from what @Win2012R2 claimed about server CPUs.
Meanwhile, Xeon's shared L3 cache has become so unwieldy, i.e. cache latency has become so nonuniform across the entirety of the L3 cache, that they now offer the option of dividing the SoC into NUMA domains (clustering modes), such that groups of cores preferrably access nearest subsets of the overall L3 cache. Oh and this option is on by default. Turns out, making shared caches bigger gets tricky if you also want to keep them fast.
If it costs 15-20 bucks (as claimed here and retail pricing suggest it can't be far off) per X3D packing then it is comparable (cost wise) with what is done got GPUs.The GPU production is bog standard stuff any ODM can and will do. V-cache package on the other hand is seriously bottlenecked by being a high end proprietary packaging technique only few companies can do at select packaging factories.
True. Sharing of SRAM is so important for them that they do it even across package, across sockets, and across drawers. Evidently they can stomach the huge amount of metadata broadcasting and data movements across their entire system which this caching regime entails. It is a four-level cache hierarchy, applied in a quite special field of computing.I never said that it was perfect, but they have a VERY effective strategy for sharing it that hides a lot of the problems and also gives some big advantages for things that have high locality in a smaller footprint.
Yes it did. I wonder if AMD will make a bridge platform to DDR6 in the future as a result of that experience?Which also says that performance of Zen 4 without V-Cache was not compelling enough to pay the premium.
It also forced AMD to offer deep discounts.
It was better at some things, but at the same time, AMD took a devastating lead in DC. Hard to fault the strategy IMO.Raptor Lake was better at that time as well and people on LGA1700 had a good upgrade path
No doubt with Zen 4 but now the lead is way less with GNR in DC but the client took a hit.It was better at some things, but at the same time, AMD took a devastating lead in DC. Hard to fault the strategy IMO.
Does this have any relevance to the thread topic (zen 6 speculation) ?No doubt with Zen 4 but now the lead is way less with GNR in DC but the client took a hit.
recalling history to analyze future 🤣Does this have any relevance to the thread topic (zen 6 speculation) ?
Or will x86 or ARM CPU makers take a page out of IBM's book, or in Dr. Ian Cutress' words, did IBM preview the future of CPU caches? Well, there are the costs which I mentioned, but maybe they eventually become affordable for server or client even, if limited to on-chip or on-package dynamic sharing (costs in terms of transistors, routing, and operating power). Plus monetary costs of R&D, both if licensing the technology or if working around IBM's patented IP.
Dr Ian Cutress said:In the Q&A following the session, Dr. Christian Jacobi (Chief Architect of Z) said that the system is designed to keep track of data on a cache miss, uses broadcasts, and memory state bits are tracked for broadcasts to external chips. These go across the whole system, and when data arrives it makes sure it can be used and confirms that all other copies are invalidated before working on the data. In the slack channel as part of the event, he also stated that lots of cycle counting goes on!
GNR is still significantly behind Turin. It just isn't hilariously behind any more. It is not accurate to say that a 20-40% lead is not "significant". It is just that Intel was behind by >100% for quite some time so suddenly "20-40%" seems like they have "caught up".No doubt with Zen 4 but now the lead is way less with GNR in DC but the client took a hit.
Certainly. We are all speculating on what features and capabilities will be in Zen 6 and how well these features and capabilities will meet market demand compared to Intel's features and capabilities.Does this have any relevance to the thread topic (zen 6 speculation) ?
It was 20% in Phoronix suit in SpecInt they are pretty even not counting Turin D ofc not to mention phoronix forgot to review the HW accelerator in GNR.GNR is still significantly behind Turin. It just isn't hilariously behind any more. It is not accurate to say that a 20-40% lead is not "significant". It is just that Intel was behind by >100% for quite some time so suddenly "20-40%" seems like they have "caught up".
Phoronix never rebenched those CPUs after the initial review did he?Additionally, I heard the argument that muli-socket in GNR had a bug and therefore those benchmarks were not valid. We are closing in on a year since the GNR release and those benchmarks still appear valid. Just like Intel said ARL just needed an update and performance would be greatly improved.
It is not going to happen CWF is not going to beat Zen 6 but Zen6 is close to DMR launch than it is to Clearwater Forest best guess is DMR/Zen 6 will launch Q3 26 like last year.No, I still believe that while GNR was a big step up for Intel, they are still way behind the curve in DC. Intel desperately needs CWF to best not just Turin, but AMD's Zen 6 based EYPC as well or it will continue to devastate Intel's bottom line.
Clearwater Forest is supposedly the last product of its kind, and it also won't be a direct competitor to anything EPYC except for dense processsors (currently Turin-d). Prediction: it'll probably match Turin-d in performance at slightly lower power. It will not challenge anything Zen6.Intel desperately needs CWF to best not just Turin, but AMD's Zen 6 based EYPC as well or it will continue to devastate Intel's bottom line.
Agree on all points. If you are expecting EPYC Zen6c to be 256c/512t, what are you expecting CWF to be?It was 20% in Phoronix suit in SpecInt they are pretty even not counting Turin D ofc not to mention phoronix forgot to review the HW accelerator in GNR.
I am expecting Zen 6 to be 192C/384T and Zen6C to be 256C/512T for the servers we have a new socket as well.
Not that I am aware. In fact, I can't find any more recent reviews for GNR or Turin.Phoronix never rebenched those CPUs after the initial review did he?
Yea, well they are saying H1 2026 for CWF .... which generally means end of May 2026 in my book. Best info I can find on EPYC Venice is "2026" which I am guessing means end of Q4. Also, based on the fact that the first wafers seem to be EPYC and not desktop, either desktop is later, or desktop is N3P. I have heard little to no info on Diamond Rapids.It is not going to happen CWF is not going to beat Zen 6 but Zen6 is close to DMR launch than it is to Clearwater Forest best guess is DMR/Zen 6 will launch Q3 26 like last year.
Possibly. How many cores do you figure CWF will have?Clearwater Forest is supposedly the last product of its kind, and it also won't be a direct competitor to anything EPYC except for dense processsors (currently Turin-d). Prediction: it'll probably match Turin-d in performance at slightly lower power. It will not challenge anything Zen6.
Possibly. How many cores do you figure CWF will have?
It's supposed to be 18a. Whether or not Intel can release it on 18a in an acceptable state remains to be seen (it may need to wait for 18ap).Also, is Diamond Rapids N3B/N3E/18A? Intel 3?
Venice is N2 AMD made a PR with it for Desktop I tYea, well they are saying H1 2026 for CWF .... which generally means end of May 2026 in my book. Best info I can find on EPYC Venice is "2026" which I am guessing means end of Q4. Also, based on the fact that the first wafers seem to be EPYC and not desktop, either desktop is later, or desktop is N3P. I have heard little to no info on Diamond Rapids.
288C/TPossibly. How many cores do you figure CWF will have?
DMR is 18APAlso, is Diamond Rapids N3B/N3E/18A? Intel 3?
No? no 288C/T SKU is not dead the Sierra Forest SKU became hyperscaler and niche customer only as for Clear water forest the 288C/T SKU is going to happen.that's the dead one
yeah.
They're all dead lol.no 288C/T SKU is not dead the Sierra Forest SKU became hyperscaler and niche customer only as for Clear water forest the 288C/T SKU is going to happen.
Really another SRF-AP situation?yeah.
They're all dead lol.
Only the 192 CWF-SP survived.
Well they have no customers for any of the server Atoms.Really another SRF-AP situation?
Who told you that ?yeah.
They're all dead lol.
Only the 192 CWF-SP survived.
This is true from what I heard recently they are making a bigger P core variant instead of RRF.Well they have no customers for any of the server Atoms.
RRF is entirely dead too.