- Mar 3, 2017
- 1,747
- 6,598
- 136
Remember when Intel bought SoftMachines?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.OMG Reverse Hyperthreading!
SMT costs barely any area, the tax is in validation time really.and possibly not worth the extra silicon for SMT anymore
Yes. They are still working out the kinks (rumors).Remember when Intel bought SoftMachines?
Ian Cutress claimed the project is dead at IntelYes. They are still working out the kinks (rumors).
That's what Intel would like us to believe. Calm before the stormIan Cutress claimed the project is dead at Intel
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.
Zen6 stuff. Not in any publicly leaked roadmap yetI miss an AMD codename?
What project ?Ian Cutress claimed the project is dead at Intel
SoftMachines/Reverse HT (presumably)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.What project ?
You teaseZen6 stuff. Not in any publicly leaked roadmap yet![]()
uzzi, are you implying that they are adding a feature to disable SMT on a per core basis? Do they not have that already?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.
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
Did you mean Strix/Strix Point?Can you at least tell us what "SX" is? Styx, if I had to guess
This is not about disabling HT through software, it's about asking if the core is capable of HT in the first place.uzzi, are you implying that they are adding a feature to disable SMT on a per core basis? Do they not have that already?
its SMT-16 right ...... right ?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.
"Just like other 2016 chips from AMD, “Styx” will be made using 14nm fabrication process at GlobalFoundries."Yup it's Styx.
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.
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."Just like other 2016 chips from AMD, “Styx” will be made using 14nm fabrication process at GlobalFoundries."
Wait... wut? Codenames are confusing...
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.
Briefly apparently...Was that ever released?
https://www.theregister.com/2022/06/20/jim_keller_arm_cpu/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.
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?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.
