- Mar 3, 2017
- 1,777
- 6,789
- 136
Eh, people I trust tell me that hyperthreading is for sure disabled on LNC.
As you said they may have initially intended to support it but decided against it once they saw the cost / benefit analysis.
remember intel has been sucking at validation , so decreasing validation complexity could be a big help for them.
Eh, depends what you mean.
If you mean their validation process takes forever and is extremely expensive.. then yes.
If you mean processors that pass their validation still have a lot of bugs.. then no.
This makes more sense. Shorter time to market. And disabling HT would improve power efficiency and provide maximum 1T performance. Cinebench fans will be sad though.
Takes a long time, costs a lot of money, comparable or less performance. Where I come from that is considered a failure.
15% is 15% - for those who run high thread count applications, it matters. A fair number of people who use something like a 7900XT or 7950XT as a workstation for pro apps, this will matter.
how many stepping's did SPR need ?
Adroc claims Zen 5 dense only gets like 10% extra perf with SMT. LNC is likely even wider than Zen 5, meaning it's pretty likely to gain even less perf from enabling SMT...
Having SMT or not doesn't really matter if total MT perf is the same. If anything, I would wager a guess that not having SMT and having the same MT perf than an arch that does have SMT is better.
Besides, I thought what most people who really need that extra cores drool over is memory bandwidth, not as much thread count lol.
That's not the question you want to ask, since he said that chips that pass validation don't have a lot of bugs. There's a much better response to @H433x0n 's claim. And that's just looking at the SPR MCC die, which had shipments paused due to the discovery of a new bug that Intel thought might require a new hard silicon stepping to fix. I'm pretty sure they managed to fix it with a firmware mitigation, but it is still extremely embarrassing. So yes, Intel's post si verification is so bad that even after their incredibly troubled and long "validation" is finished, certain dies still remained buggy and unreliable, to the extent that shipments had to be paused for months. That's incredibly embarrassing.
But perhaps if we want to continue this discussion, it should be elsewhere. This is a zen5 thread after all.
If Zen5 dense gains only 10% by enabling SMT, then I would expect the same for Zen5.
If the core is wider, then I would expect more unused resources, which would mean bigger gain by enabling SMT not the exact opposite.
If enabling SMT doesn't provide any performance gain, then of course It's useless and you don't need It.
Personally, even If they disabled SMT It wouldn't hurt most people, because first you would need to use that many threads to gain that extra performance.
In the case of Strix Point, you would need to use >12 threads.
In case of Strix Halo It's >16 threads.
Last edited:
I am also confused by notion set in the last pages, that wider core means less benefit from SMT. As that, without additional changes in different areas, goes against logic. Most of the software cannot utilize the execution width these cores offer simply because they cannot reach IPC that execution units offer. I am not talking about not using specific uArch targeted software compilation. Just any enterprise software.
Other problem where SMT should help in hiding latency are stalls caused by memory fetch/store - Problem / algorithm that fits into cache with its data is anomaly not something that is valid "by default".
Once you leave CPU cache and head for memory (playing chess with a friend over mail - not email!) or god-forbid in NUMA other's node memory controller or even talk over wire to another Node (playing chess with a friend stationed on a Moon/Mars) - how come you don't see "throughput increase" by playing 10 games at once?
Other problem where SMT should help in hiding latency are stalls caused by memory fetch/store - Problem / algorithm that fits into cache with its data is anomaly not something that is valid "by default".
Once you leave CPU cache and head for memory (playing chess with a friend over mail - not email!) or god-forbid in NUMA other's node memory controller or even talk over wire to another Node (playing chess with a friend stationed on a Moon/Mars) - how come you don't see "throughput increase" by playing 10 games at once?
It's cuz people keep forgetting it's spec int rate nt which will put massive stress on the fabric and memory sub system. So it could simply be because ifop links are saturated in Zen 5 dense etc.
DrMrLordX
Lifer
- Apr 27, 2000
- 22,816
- 12,860
- 136
And what exactly makes you say that? Most of the users here are rather hostile towards MLID.
Embarrassing if true.
Most users on the forum are hostile towards a certain boisterous former POTUS too, yet there are multiple active threads about him
MLID must feel honored to be discussed way more than Jim Keller or Lisa Su.
XT chips used N7 DUV. 7+ was an EUV node and was not design compatible, and that was the point I was trying (and failing to) make.AMD specifically called out process refinements for increased boost clocks on the XT chips. When Zen 3 launched, they specifically called out they were using the same optimized process as the XT chips versus the original Zen 2 release.
View attachment 86642
I admit not having any internal knowledge to back this up, but I will make an educated guess: Likely this was the beginning of the point where AMD began working with TSMC to customize the process in order to eke out more performance from the chip. Zen 3 customized the process further and further was a rebuild/optimization for those customizations. Zen 4 is said to use a custom version of N5.
I suspect that all of the customizations were centered around hitting higher clocks without increasing power consumption by much. Until Zen 3, AMD chips were great, but held back by low frequencies. The IPC was there, they just couldn’t compete with Intel’s absurd clocks.
The fact that the 7950X handily beats a 5950X with an 88W PPT provides some evidence to support this. Sure there were IPC gains, but Zen 4 hits obscene clocks, even at a 65W TDP. No other chip that I know of (at 65W or less) made at TSMC can hit 5+ ghz clocks at low power limits. Sure, the chip architecture has a lot to do with it as well.
This may also explain the RDNA3 missteps (if there were any, I have seen no real evidence of this other than folks saying it) as well. I again speculate AMD customized the process there, but things didn’t go as expected. RDNA3 is much more dense than Ryzen, so that is likely part of it. The reason we won’t see fixed parts is likely due to how intertwined the process and chip design are: fixing one means changing both. Normally fixes in hardware could be made relatively easily: Intel and AMD have both pushed out new steppings in the past to fix bugs, improve efficiency, etc so why hasn’t AMD done that with RDNA3? See above.
Again, speculation above (except the fact AMD customizes the process, they have stated that). However, I suspect it is somewhere close to the truth.
I do wish AMD were more public about this type of thing. Even if it is simple having a blog where select engineers can post vetted articles and such. It would go a long way towards keeping the nerds happy without crossing the line and revealing proprietary info.
At any rate, I have owned a lot of Intel and AMD chips in my lifetime, and there were a few that stand out. AMD’s moment to me was Zen 3. It remains the x86 perf/watt champion to this day. Even Zen 4 doesn’t have as good of perf/watt (without dialing back power limits, then it becomes champion)
For those curious, for me the Athlon, Athlon x2, Intel Core 2 Quad, and the Intel Core i7 2600k were a few of the others that stood out to me. Ryzen actually reminded me of the Athlon days where AMD couldn’t hit the clocks Intel was hitting, but higher IPC meant they were competitive anyway. Threadripper 1xxx reminded me of when the first dual/quad core chips came out. Anyone want to guess why? 🤣
Panino Manino
Golden Member
- Jan 28, 2017
- 1,122
- 1,371
- 136
Everyone hates MLID, almost no one is carrying water for him. It's the most reluctant acknowledgement for the entire HW community if he's got something directionally accurate.
What's possibly telling about the recent Zen 5 IPC leak/rumor for those who saw (10-15% IPC increase) is that various big names have been real quiet since the announcement and, in other forums, they suspect it's an accurate and legitimate leak.
It's pretty funny if true, because even at 25% they'd technically still be short of Firestorm by a smidge on perf/GHz in some stuff, but similar enough - but now you'd be looking at a much more obvious failure to close a gap there with Firestorm or even an X4.
But it's also quite possible there's a detail missing e.g. it's for servers under some constraint.
Last edited:
How about a possibility that 1-thread and n-thread "IPC" increase (or, for something more tangible: "SPECint Rate iso-clock performance" increase) might not be exactly the same? (And in different segments, such as client, HPC server, dense cloud server.) Such a possibility has been claimed by one or more other poster(s) earlier in this thread, if I understood correctly.
I wouldn't go that far.
It takes a lot of energy to hate and I'm far too lazy to waste it on him 😂
Yeah as I alluded to I think that's quite possible/likely too. Would make total sense.
I wouldn't go as far as saying it makes total sense, but ig it is a possibility.
Looking back at the leaked image - I agree that's a massive overstatement and recant that.
The slide basically has 4nm/3nm which is client and DC both, lists off a low power core option too which isn't for servers - the dense option is already known with Zen 4C, this is different.
The 19% from Zen 3 and 14% from Zen 4 is interesting. If they're listing those, then any scenarios where Zen 3 and 4 fell short (see: servers under load) aren't the bar here - the IPC they list and try to achieve is using the averaged upper bounds for these IPC figures which is relevant especially for client. It would be odd and.... convenient if for Zen 5, the number is some secret lower bound in a server scenario while they list their more general IPC figures in Zen 3, 4.
I think it's possible though given how central Zen 5c servers are this generation, but it's doing some gymnastics.
Attachments
DrMrLordX
Lifer
- Apr 27, 2000
- 22,816
- 12,860
- 136
That or it's getting too close to launch for people to be chatty. People have seeded false info to MLID before . . .
I tried to say this earlier but I got nowhere with it. It doesn't make sense to sandbag Zen 5 and change how it's measured without any note of it on the document. I can't see the logic for why they wouldn't keep the IPC measurement consistent.
Didn't know there was any other notable forums similar to Anandtech.. I'll have to check those out.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)
- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter