Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)

Page 88 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Ajay

Lifer
Jan 8, 2001
16,094
8,109
136
OMG Reverse Hyperthreading!
Not really. If in fact AMD is going wider on the front end like Apple, then there should be a greater extraction of ILP (instruction level parallelism). This would make hyperthreading yields lower - and possibly not worth the extra silicon for SMT anymore. JITs could improve ILP on the fly if updated or recompilation with improved compilers for machine coded executables.
 

HurleyBird

Platinum Member
Apr 22, 2003
2,760
1,455
136
Not really. If in fact AMD is going wider on the front end like Apple, then there should be a greater extraction of ILP (instruction level parallelism). This would make hyperthreading yields lower - and possibly not worth the extra silicon for SMT anymore. JITs could improve ILP on the fly if updated or recompilation with improved compilers for machine coded executables.

Well, this is going to depend a lot on implementation details, but you got that generally backwards. Increased ILP will not scale anywhere near 1:1 as you add more resources to the core. Everything else being equal, when you have more resources sitting idle more often, that is beneficial for SMT.
 

uzzi38

Platinum Member
Oct 16, 2019
2,705
6,427
146
@Kepler_L2 You're jumping the gun a little.

Lets just take a look again at what we're talking about here. The document shows us a new feature that lets you poll a core to check how many SMT threads a single individual core supports. Why would you want to ever poll a single core individually? Start from there.
 

Geddagod

Golden Member
Dec 28, 2021
1,296
1,368
106
What project ?
soft machines version of core fusion. IIRC the cores were able to be pretty tightly knit- as in a couple cycles worth of latency, able to act as one giant core or multiple smaller, less wide cores, but it also had to have a software translation layer. There's an anandtech article if you care to read more about it.
Maybe Intel is working on a similar project on the background, who knows, but Cutress said the project was mothballed and the personal from the original acquisition had since dispersed, possibly due to frequency issues of the design. Read somewhere (forgot where, so if it was here, I'm sorry that I'm not quoting whoever lol) that Intel is pathfinding ~1 or 2 'next gen' architectures at the same time, so VISC fusion cores might have been one of those projects at some point.
 

Exist50

Platinum Member
Aug 18, 2016
2,452
3,102
136
Zen6 stuff. Not in any publicly leaked roadmap yet :p
You tease :). Can you at least tell us what "SX" is? Styx, if I had to guess.
Lets just take a look again at what we're talking about here. The document shows us a new feature that lets you poll a core to check how many SMT threads a single individual core supports. Why would you want to ever poll a single core individually? Start from there.
uzzi, are you implying that they are adding a feature to disable SMT on a per core basis? Do they not have that already?
 
Last edited:
  • Like
Reactions: Tlh97 and Kepler_L2

uzzi38

Platinum Member
Oct 16, 2019
2,705
6,427
146
You tease :). Can you at least tell us what "SX" is? Styx, if I had to guess.

uzzi, are you implying that they are adding a feature to disable SMT on a per core basis? Do they not have that already

I don't know the codename so I couldn't tell you anyway, even if I wanted to.

And no, that's not what I'm saying. I'll be honest, I can't think of a way of implying it without saying it outright, so I'm going to shut up now.
 

soresu

Diamond Member
Dec 19, 2014
3,230
2,515
136
Can you at least tell us what "SX" is? Styx, if I had to guess
Did you mean Strix/Strix Point?

Pretty sure I've already seen that listed as STX - seems unlikely that they would name something so close to a previous product codename.

Edit: Missed Kepler's post, just ignore this.
 
  • Like
Reactions: SpudLobby

Tuna-Fish

Golden Member
Mar 4, 2011
1,486
2,023
136
uzzi, are you implying that they are adding a feature to disable SMT on a per core basis? Do they not have that already?
This is not about disabling HT through software, it's about asking if the core is capable of HT in the first place.

And the reason is probably making scheduling easier. Right now, on Intel the small core/big core divide is not as much of a problem as it could be for scheduling because a small core is pretty close in performance to one HT thread of the big core. That is, if all threads on the CPU are loaded, they are all about equally fast. The problem cases where it's difficult for schedulers is when the available parallelism of multithreaded workload is > the amount of big cores, but not unbounded.

When AMD ships c and normal cores as part of a single CPU, this is not true for them. If both cores have SMT2, when every core is loaded, the c cores have significantly lower throughput, assuming they clock significantly lower. If SMT2 is disabled for them, this would be fixed, and in the client world where the windows scheduler determines how good your product is, it might be worthwhile to match what Intel does so that the systems work the same.
 

cherullo

Member
May 19, 2019
51
119
106
Ok, here goes nothing: the workload where SMT is not very helpful is gaming.
So you can have, say 4 SMT-less, normal-sized cores able to reach 5Ghz running the game's main thread and other high priority stuff for that sweet 120hz goodness, and 8 dense, SMT-capable cores for throughput, running around 3Ghz.
Now, you'll want some more cores for OS background tasks, let's say 4 dense cores for this. You organize this in two 2+6 CCXs which also works well for low-end mobile, and there you go.
 

naukkis

Senior member
Jun 5, 2002
903
786
136
When AMD ships c and normal cores as part of a single CPU, this is not true for them. If both cores have SMT2, when every core is loaded, the c cores have significantly lower throughput, assuming they clock significantly lower. If SMT2 is disabled for them, this would be fixed, and in the client world where the windows scheduler determines how good your product is, it might be worthwhile to match what Intel does so that the systems work the same.

What they want to do is to disable SMT from fast cores. So 1-thread preferred loads can always get best performing cores. Slow cores can have SMT enabled as they are utilized only for high-throughput cases when all slow cores are already in use and SMT can bring additional throughput. SMT enabled fast cores would do exactly opposite, non smt slow core would then be faster than fast core with SMT complicating finding fastest core for high-priority threads.
 

Kepler_L2

Senior member
Sep 6, 2020
537
2,198
136
"Just like other 2016 chips from AMD, “Styx” will be made using 14nm fabrication process at GlobalFoundries."

Wait... wut? Codenames are confusing...
Was that ever released? Maybe they just felt like reusing the codename. Anyway this info is from a old-ish roadmap, about 1/3 of the Zen4/Zen5 products there have been canned, so I wouldn't put too much faith into it being the final codename.
 

Abwx

Lifer
Apr 2, 2011
11,557
4,349
136
This is not about disabling HT through software, it's about asking if the core is capable of HT in the first place.

And the reason is probably making scheduling easier. Right now, on Intel the small core/big core divide is not as much of a problem as it could be for scheduling because a small core is pretty close in performance to one HT thread of the big core. That is, if all threads on the CPU are loaded, they are all about equally fast. The problem cases where it's difficult for schedulers is when the available parallelism of multithreaded workload is > the amount of big cores, but not unbounded.

When AMD ships c and normal cores as part of a single CPU, this is not true for them. If both cores have SMT2, when every core is loaded, the c cores have significantly lower throughput, assuming they clock significantly lower. If SMT2 is disabled for them, this would be fixed, and in the client world where the windows scheduler determines how good your product is, it might be worthwhile to match what Intel does so that the systems work the same.

SMT is used only when the CPU run out of cores for the thread amount, with Bergamo 128 cores will be used for the 128 first threads and SMT is used for threads 129 to 256, this way up to 128T there s an optimal ST perf and quite higher than what is provided by a small core, it s not like such a CPU is always working at full 256T loading.
 

RnR_au

Platinum Member
Jun 6, 2021
2,062
5,007
106
Was that ever released?
Briefly apparently...

Amid the renewed interest in Arm-based servers, it is easy to forget that one company with experience in building server platforms actually brought to market its own Arm-based processor before apparently losing interest: AMD.

Now it has emerged that Jim Keller, a key architect who worked on Arm development at AMD, reckons the chipmaker was wrong to halt the project after he left the company in 2016.
https://www.theregister.com/2022/06/20/jim_keller_arm_cpu/
 
  • Like
Reactions: Tlh97 and Kepler_L2

Exist50

Platinum Member
Aug 18, 2016
2,452
3,102
136
And the reason is probably making scheduling easier. Right now, on Intel the small core/big core divide is not as much of a problem as it could be for scheduling because a small core is pretty close in performance to one HT thread of the big core. That is, if all threads on the CPU are loaded, they are all about equally fast. The problem cases where it's difficult for schedulers is when the available parallelism of multithreaded workload is > the amount of big cores, but not unbounded.
Even if the per-thread performance ends up similar, "Thread Director" definitely prioritizes SMT threads last. But in this case, I'm interested in what exactly is making the scheduling decisions. Sounds like they're making this threading info OS visible to assist that side of the scheduling algorithm?