Question Zen 6 Speculation Thread

[itsmydamnation]

If they are not morons, they would say yes for the gratitude AMD would receive from existing customers, making them even more loyal.

no one will care. your fabric limited. if you really want stupid expensive memory use it to run lower latency/ timings not bandwidth.

 

[StefanR5R]

your fabric limited.

My understanding was that @igor_kavinski had processor upgrades in existing boards in mind.

 

[MS_AT]

had processor upgrades in existing boards in mind.

That requires new iOD imo for many reasons that were already stated in this thread. What I am afraid does not make much sense for them if Zen5 is supposed to move to be the lower cost platform next to Zen6. Especially if somebody will buy CUDIMM memory, he will probably also go for Zen6.

 

[StefanR5R]

@MS_AT, yep, this part of the discussion was about upgrades to Zen 6 based desktop CPUs in existing AM5 boards.

 

[OneEng2]

Apart from the fact that APU_Fusion was obviously joking:
If it's done by sacrificing IPC like Netburst and Bulldozer did, then sure, but that's not what AMD will be doing.

Increasing clocks runs exponentially into higher thermals past a certain point (and super linearly before that even). Especially in a MT cpu design, thermal density and power consumption are more the limiting factor than the pipeline stalling out due to sync issues.

That's harder to get right than clockspeed increases, though.

Yes, it certainly is.... and it isn't without trade-offs.

Not in every workload, and even there it usually loses against the 9800X3D.

I believe that the reason it performs poorly compared to 9800X3D is mostly due to the overall latency difference .... greatly reduced in X3D by keeping much of the information in L3 which is much lower latency than main memory.

It's a neat trick, but as I was saying, it isn't impossible to believe NVL will improve by much more than people are giving voice to at this time simply by big improvements in that God Awful latent ring bus.

Zen4->5 was on a barely improved node, with a ~30% fatter core due to full-rate AXV512/512bit FP pipes and 50% more INT ALUs.
It was a very server-focused design, so hitting 6+ GHz was secondary, as server CPUs don't clock in that range anyway.
With Zen6 on the other hand, the only server-focused aspect is the design of the 32c dense CCD, otherwise it seems to be more about clocks and core count.

... and it will be server focused again for Zen 6. Nothing has changed in that respect. AMD makes the best margins in DC. It makes sense for them to focus on that market.

I suspect the clocks have much more (everything) to do with the greatly improved process node (N4P->N2) than any minor tweaks we will see in architecture between Z5 and Z6.

 

[adroc_thurston]

Increasing clocks runs exponentially into higher thermals past a certain point (and super linearly before that even

Theyre not jacking up the voltage because they can't.
Already at Vmax.

 

[LightningZ71]

Nova Lake L3 and off die latency should improve if for no other reason than the reduced number of ring compute stops and a very likely increase in d2d comms frequency.

 

[OneEng2]

Theyre not jacking up the voltage because they can't.
Already at Vmax.

Even without changing voltage, raising frequency when already at or near the frequency ability of a node, is much more than linear.

Linear heat production occurs only at low powers. In the middle it isn't quite a square of the frequency, but it's still a power of 1.3 to 1.5.

Once you get toward the top of the ability of the process, its pretty much a power of 2.

My point being, frequency scaling as a method of increasing ST performance is a terrible strategy if that is what your architectural strategy is betting on.

 

[OneEng2]

Nova Lake L3 and off die latency should improve if for no other reason than the reduced number of ring compute stops and a very likely increase in d2d comms frequency.

Completely agree.

 

[Thibsie]

Even without changing voltage, raising frequency when already at or near the frequency ability of a node, is much more than linear.

Linear heat production occurs only at low powers. In the middle it isn't quite a square of the frequency, but it's still a power of 1.3 to 1.5.

Once you get toward the top of the ability of the process, its pretty much a power of 2.

My point being, frequency scaling as a method of increasing ST performance is a terrible strategy if that is what your architectural strategy is betting on.

For a given architecture.

 

[OneEng2]

For a given architecture.

Not sure about that. I think that the power the transistor library uses at a given frequency is independent of the CPU design and relies on the library and process node.

Now, depending on the library used on a process for a give transistor, you can make a design that can clock higher by giving up space and or power .... but I think that the general rule of engineering still applies. "You don't get something for nothing".

 

[Hitman928]

Not sure about that. I think that the power the transistor library uses at a given frequency is independent of the CPU design and relies on the library and process node.

Now, depending on the library used on a process for a give transistor, you can make a design that can clock higher by giving up space and or power .... but I think that the general rule of engineering still applies. "You don't get something for nothing".

One easy way to see that CPU design affects power is that different architectures use different numbers of transistors and power is directly related to the number of transistors in your design (static portion of total power unless power gated) and the number of transistors switching at any given time (dynamic portion of total power).

 

[Joe NYC]

x86 Advisory group agrees on new instruction extension standards:
- AVX10
- ACE/AMX

I am wondering what could be the earliest AMD CPU to have AMX. Probably not Zen 6. Likely Zen 7.

Edit, it says "from laptop to datacenter"

https://www.amd.com/en/blogs/2025/amd-and-intel-celebrate-first-anniversary-of-x86-ecosys.html

 

[Josh128]

Not sure about that. I think that the power the transistor library uses at a given frequency is independent of the CPU design and relies on the library and process node.

Now, depending on the library used on a process for a give transistor, you can make a design that can clock higher by giving up space and or power .... but I think that the general rule of engineering still applies. "You don't get something for nothing".

Not just space and power, but current leakage as well. Transistors that never fully shut off can open and close(ish) faster.

 

[Josh128]

My point being, frequency scaling as a method of increasing ST performance is a terrible strategy if that is what your architectural strategy is betting on.

Stop dogging Intel bruh, I thought you were rooting for them.

 

[Markfw]

Stop dogging Intel bruh, I thought you were rooting for them.

Dude, this is an AMD thread duhhhhhh

 

[poke01]

Is SPEC irrelevant now? Does AMD agree?

 

[regen1]

View attachment 132003

Is SPEC irrelevant now? Does AMD agree?

Well SPEC 2017 has a lot of outdated tests, some tests ranging back to two decades even which kinda needs to be updated for modern day relevance.

There should be a new SPEC version coming in some time. AFAIK AMD, Intel and others already to some level of internal tests on that(SPEC CPU V8).

All that being said SPEC CPU 2017 and many parts of it are still somewhat or lot better than what recent Geekbench versions are doing(SME boosting ST that largely? is it even that relevant so soon in everyday applications) for providing overall score.

SPEC CPU cadence:



SPEC CPU V8 has some very interesting new things coming.

 

[Nothingness]

All that being said SPEC CPU 2017 and many parts of it are still somewhat or lot better than what recent Geekbench versions are doing(SME boosting ST that largely? is it even that relevant so soon in everyday applications) for providing overall score.

OTOH SPEC has one issue that Geekbench doesn't have: compiler cheating; the only vendor compiler used for GB compilation is Apple clang, but as far as I know they don't play games with it. In both cases, one should not look only at overall score.

 

[Nothingness]

View attachment 132003

Is SPEC irrelevant now? Does AMD agree?

Given the efforts they spent to "tune" AOCC for SPEC, I'd say they disagree And given ICX "tuning", Intel also disagrees.
Anyway it's well known that SPEC is too light on front-end, and no CPU design team relies exclusively on it.

 

[regen1]

In both cases, one should not look only at overall score.

Yeah, a major issue is that many reviewers simply portray overall scores esp. when comparing different ISA SKUs.

 

[MS_AT]

Given the efforts they spent to "tune" AOCC for SPEC, I'd say they disagree And given ICX "tuning", Intel also disagrees.

Do they give higher uplift in SPEC specifically compared to other codebases? I remember Phoronix was doing AOCC against vanilla clang, but since Phoronix is not doing SPEC I was not able to find a place that would compare the two (aocc vs vanilla clang) on the same hw/os in SPEC.

 

[Doug S]

OTOH SPEC has one issue that Geekbench doesn't have: compiler cheating; the only vendor compiler used for GB compilation is Apple clang, but as far as I know they don't play games with it. In both cases, one should not look only at overall score.

They are different tests. SPEC is a system test, and sees the compiler as part of the system. That was universally true when SPEC originated in 1989, every workstation vendor shipped their own compiler. You could use gcc, but its performance back then was abysmal compared to the vendor compilers. Since SPEC has diminished in importance for driving sales versus the 90s and early 00s it is probably no longer worth it for vendors to invest in making their compiler cheat at SPEC.

Even without cheating SPEC gives vendors a lot of leeway to choose the best compiler and flags to produce the best result with that provided source code. You can improve results for your CPU by making a better CPU, or by making a better compiler. Geekbench aims to take the compiler out of the mix by having the compilation done in a black box and you run the resulting binary. For any given version of Geekbench (e.g. 6.5) you can only improve results for your CPU by making a better CPU.

Yes support for stuff like SME and AVX512 tilts the playing field depending on whether John can be bothered to insert assembly code to take full advantage of those features, and everyone is sort of at his mercy for whether and how well that is done. If for example he wrote AVX512 assembly assuming CPUs can issue a maximum of two AVX512 instructions per cycle and you have a new CPU that issues four per cycle it will not see benefit of that in its Geekbench results for the existing releases of Geekbench, and won't see it in the future unless/until he rewrites that code. Of course in SPEC you probably won't see it at all, since compilers generate AVX512 instructions only in limited cases.

 

[MS_AT]

black box and you run the resulting binary. For any given version of Geekbench (e.g. 6.5) you can only improve results for your CPU by making a better CPU.

The performance is not OS independent (differences between MacOS, Linux, Windows, iOS, Android exist) so it is a leaky sandbox. So it's still a system benchmark, just with fewer knobs. Benefit is that it's harder to misconfigure the compiler, intentionally or not and the results are almost directly comparable on the same OS.

Yes support for stuff like SME and AVX512 tilts the playing field depending on whether John can be bothered to insert assembly code to take full advantage of those features, and everyone is sort of at his mercy for whether and how well that is done.

You don't need to go to assembly unless compiler is doing something stupid (or you are writing microbenchmarks that are checking architecture specific things, but then it's easier from assembly). You have intrinsics. You have 3rd party libs. Some language have support built-in into the standard library of the language. And most of all, if you write the high level code using well known idioms for a language the compiler will be able to pick this up. Problem is compilers are capricious so the libs are better fit if you want control. But we are well past: "want to use SIMD? you have to roll your hand optimized assembly every time".

Of course in SPEC you probably won't see it at all, since compilers generate AVX512 instructions only in limited cases.

I guess that's the part of the tuning they do for the compilers, to make limited cases less limited?

 

[Geddagod]

View attachment 132003

Is SPEC irrelevant now? Does AMD agree?

This is an old chart. A few years ago IIRC.