Question Zen 6 Speculation Thread

[OneEng2]

People on this forum are generally not children, so it does not have to have kindergarten rules.

Any reputable forum has rules prohibiting personal attacks to prevent the discourse from getting ugly. It is too easy for cowardly people to get personal over a forum not to have and enforce these rules.



You can not call out moderating of the forum into a post.
If you have concerns. Make a Reported Post.
Please read the forum rules.

AnandTech Forum Guidelines

AnandTech Forum Guidelines Introduction In an effort to make our management of the forums as transparent as possible, we have refined our member and posting guidelines and we have created a set of moderator guidelines. It is our hope that we can better satisfy members by being upfront and...

forums.anandtech.com

Specifically rules 1, 12 and 13.


esquared
Anandtech Forum Director

 

[Shmee]

Hello everyone, this is a reminder to avoid personal attacks and maintain decorum, we don't need ugly fighting here. Also, this is not the place to debate our rules, if you have questions or concerns about them, please post in moderator discussions. If someone is misbehaving or posting questionable content, do not feed them and simply use the report function if applicable. -AT Moderator Shmee

 

[Josh128]

the biggest improvements are at lower power levels at higher power levels the gains are less.

TR and EPYC had the largest gains, those are at the highest power levels, not the lowest. SKU power levels have nothing to do with it. Cores clocked at optimum points in the v/f curve do. That is, in practical scenarios, achieved with higher core count SKUs.

 

[Josh128]

LOL. I was literally already considering a very similar remark.

@adroc_thurston,

The lack of any intelligent response from you is a testament to your maturity level. Instead of tossing adolescent personal insults at your betters, go find your binkie and suck on it until the urge to be a baby dissipates.

@ the mods. Before you criticize me for breaking forum rules, note: I wouldn't need to had you dispelled this infantile behavior yourselves.

This forum has been a model of decorum for the most part and I honestly don't wish it to decay into personal insults as it is a great source of intelligent discussion and a resource for lots of people across the web.

As someone who is fairly infamous at WCCFTECH for engaging with trolls and trading insults with them, I agree. I come here for an escape back to sanity and a bit of respectful dialogue while I let things simmer over there.

 

[LightningZ71]

TR and EPYC had the largest gains, those are at the highest power levels, not the lowest. SKU power levels have nothing to do with it. Cores clocked at optimum points in the v/f curve do. That is, in practical scenarios, achieved with higher core count SKUs.

There's also a point where you get too many cores. Each core requires a baseline level of power to even be ready for use. In addition, increasingly large numbers of cores require a supporting network of connections. Those connections aren't free and do not scale literally (edit: should be linearly). Depending on how you divide them into coherency domains, coherency traffic will eventually overtake actual work as well, both in data volume and in power draw.

There's a balance, and it is slightly to drastically different for EVERY application. You will always be able to find a benchmark that shows either solution is superior. It remains to be seen which path will be able to show the most.

 

[511]

TR and EPYC had the largest gains, those are at the highest power levels, not the lowest. SKU power levels have nothing to do with it. Cores clocked at optimum points in the v/f curve do. That is, in practical scenarios, achieved with higher core count SKUs.

EPYC Usually run at lower frequency compared to desktop outside the F SKU they are well within the efficiency window for the most part

 

[marees]

There's also a point where you get too many cores. Each core requires a baseline level of power to even be ready for use. In addition, increasingly large numbers of cores require a supporting network of connections. Those connections aren't free and do not scale literally. Depending on how you divide them into coherency domains, coherency traffic will eventually overtake actual work as well, both in data volume and in power draw.

There's a balance, and it is slightly to drastically different for EVERY application. You will always be able to find a benchmark that shows either solution is superior. It remains to be seen which path will be able to show the most.

Too many unbalanced cores is also a problem for designing

I believe this caused some issues for Intel GPUs during shader compilation for Nvidia GPUs

 

[Josh128]

There's also a point where you get too many cores. Each core requires a baseline level of power to even be ready for use. In addition, increasingly large numbers of cores require a supporting network of connections. Those connections aren't free and do not scale literally (edit: should be linearly). Depending on how you divide them into coherency domains, coherency traffic will eventually overtake actual work as well, both in data volume and in power draw.

There's a balance, and it is slightly to drastically different for EVERY application. You will always be able to find a benchmark that shows either solution is superior. It remains to be seen which path will be able to show the most.

Of course. Theres also a point where you have too little power. Trying to go to 45W TDP from 65W TDP on a 7950X shows a drastic decrease in perf/w.

That why I said the answer is always to clock to cores in the most efficent point on the v/f curve, regardless of the number of cores.

 

[StefanR5R]

the answer is always to clock to cores in the most efficent point on the v/f curve, regardless of the number of cores.

v/f considers just the cores (plus associated uncore). But the cores are part of a SoC (this ties into what @LightningZ71 wrote), and the SoC is part of a computer. There are lots of config items which determine computer performance per power, and core v/f is just one of them. There are scenarios in which it is efficient to configure the cores outside their own sweet zone.

 

[StefanR5R]

Re server core counts:
*If* AMD moves xGMI to advanced packaging tech on their server platforms (besides MI300, I mean), and *if* they make different sIODs for SP7 and SP8, then it would simplify the affair for them if the SP7 sIOD was only compatible with the 32c CCDs, and if the SP8 sIOD was only compatible with the 12c CCDs.
Though maybe the possible gains from simplifications would not be enough to justify the loss of flexibility, and they rather stick with their modus operandi of being able to mix and match in LEGO® style.

 

[adroc_thurston]

then it would simplify the affair for them if the SP7 sIOD was only compatible with the 32c CCDs, and if the SP8 sIOD was only co mpatible with the 12c CCDs.

Nope, SP8 has dense variants just the same.

Though maybe the possible gains from simplifications would not be enough to justify the loss of flexibility, and they rather stick with their modus operandi of being able to mix and match in LEGO® style.

Oh it's much more flexible since the stateless interface lets you scale the d2d shoreline for 1/2/4/whatever the # of 32B SDPs you want.

 

[Joe NYC]

Re server core counts:
*If* AMD moves xGMI to advanced packaging tech on their server platforms (besides MI300, I mean), and *if* they make different sIODs for SP7 and SP8, then it would simplify the affair for them if the SP7 sIOD was only compatible with the 32c CCDs, and if the SP8 sIOD was only compatible with the 12c CCDs.
Though maybe the possible gains from simplifications would not be enough to justify the loss of flexibility, and they rather stick with their modus operandi of being able to mix and match in LEGO® style.

You mean incompatible because of different physical size of the CCDs? I think they are going to figure it out, where perhaps one side of rectangle is the same and the other is different.

 

[marees]

I suspect that desktop zen6 will be on N3 rather than N2

Prices for TSMC’s latest manufacturing process, N3P of the 3nm family, are about 20% higher than the prior generation, and 2nm will be over-50% higher than N3P as price inflation continues to hit semiconductors, media report, citing unnamed supply chain sources.

TSMC is not allowing any 2nm (N2) discounts due to its huge production line equipment spend.

https://twitter.com/x/status/1969964842980458863

 

[adroc_thurston]

I suspect that desktop zen6 will be on N3 rather than N2

can you stop?
It TO'd eons ago.
They're all N2p besides mainstream mobile peanuts.

 

[511]

Everything is already decided it's too late to make roadmap changes.

 

[Josh128]

I suspect that desktop zen6 will be on N3 rather than N2

Ive said this time and again, but Kepler, Adroc, and others insisted otherwise. I hope they are right. Maybe Pat and Lip Bu can save us all with 18A.

 

[511]

Ive said this time and again, but Kepler, Adroc, and others insisted otherwise. I hope they are right. Maybe Pat and Lip Bu can save us all with 18A.

View attachment 130749

AMD is not the one suffering from success rn they shoud have revenue pop up but they don't

 

[MoistOintment]

If you say so.

Have you ever tried to scale applications beyond 64C? Or even 128C? It is quite hard. You can look at Phoronix benchmark suites, where high core count SKU performance scaling is deep in the sub-linear range.
Frequency will always scale, no matter what amount of cores you throw at your problem. It is just the reality of many applications.

The other reason for 96C is simply the limitation to max. 8 CCDs as BorisTheBlade82 pointed out. And another point could be that you hit a power wall before you exceed Zen 6c clock rates at 128C. Then it would not make sense to use "P" cores unless you expect low usage rates of your CPU (what you do not want as a server host / provider due to economic reasons).

In my experience, the vast majority of high core count usecases in DC come not from a single application scaling across all those cores, but more cores enabling more instances of a smaller application being run simultaneously. Like, more cores = more VMs. More VDIs. More simultaneous users accessing and spinning off their own smaller instance of the application.
So I think there's always more value in core count scaling in DC - but less so in workstation.

 

[Josh128]

AMD is not the one suffering from success rn they shoud have revenue pop up but they don't

Are you new here? AMD just had record quarterly revenue. They were on the verge of bankruptcy around 7 years ago.

 

[511]

Are you new here? AMD just had record quarterly revenue. They were on the verge of bankruptcy around 7 years ago.

View attachment 130755

TSMC for reference

 

[Antey]

Why are you comparing TSMC with AMD in terms of revenue... ?

 

[511]

Why are you comparing TSMC with AMD in terms of revenue... ?

Not revenue In terms of growth aka success. AMD has grown but nothing to write home about unlike TSMC who has Monopoly not over Fables but their Equipment provider as well.

 

[gdansk]

Not revenue In terms of growth aka success. AMD has grown but nothing to write home about unlike TSMC who has Monopoly not over Fables but their Equipment provider as well.

2.5x for TSMC is better than AMD's 2.0x in the same time period. But that's successful for both.

 

[Thibsie]

Not revenue In terms of growth aka success. AMD has grown but nothing to write home about unlike TSMC who has Monopoly not over Fables but their Equipment provider as well.

What about Intel's growth ?

 

[511]

What about Intel's growth ?

It's downard xDd with record losses