NewsIntel's next-gen Arrow Lake CPUs might come without hyperthreaded cores — leak points to 24 CPU cores, DDR5-6400 support, and a new 800-series chipset
In mainstream CPUs, I could see ditching hyperthreading. However, they'd probably want to boost E-core count, at the same time. Long ago, there were rumors of them going to 32 E-cores. It's hard to see why you'd need hyperthreading on the P-cores, when you have so many E-cores that are each faster than a second thread on a P-core.
In server CPUs, they lose enough margin by disabling hyperthreading that I think they probably wouldn't want to cede that ground to AMD or ARM. We'll see.
There have long been rumors that Intel will move to a new approach with its P-Cores that discards hyperthreading, which allows two threads to run on a single CPU core, for a new approach that it has outlined in a patent.
Chipzilla's silicon acquisition spree continues with a $250m deal
www.theregister.com
I think there's pretty much no chance of that tech making it into Arrow Lake, however. It has big software implications, and Intel would have publicized that info further in advance of such products launching. Even if they kept it under NDA, I think rumors would've been swirling by now.
This fabrication node introduces RibbonFET gate-all-around transistors and the PowerVia backside power delivery network. Both innovations can enable Intel to optimize power consumption, increase performance, and boost transistor density. How this will affect the performance of socketed Intel's Arrow Lake processors remains to be seen.
The bomshell from that leak is just 3-4% faster single-threaded integer performance and 1-2% faster single-threaded floating point performance, in the same power envelope as 13th gen (Raptor Lake). Multithreaded improves by a lot more, but that could be just due to E-core improvements (I'd guess P-core efficiency improvements also play a role).
It's best to take this with a grain of salt; the documents point to the P-Cores being disabled in the BIOS due to initialization issues, so anything is possible.
So what exactly was the rumor or the leak that showed no hyperthreading?
If this one pic is all the info we have then that's not even worth to be called a rumor.
I'd be fine with not having HT. I turn it off sometimes anyways. 32 threads is overkill for most anyways. I'd have them off all of the time but I think I have a hoarding problem or something. I just like to see all of those threads I don't need in monitoring software.
The important thing is when I turn off HT I only lose some MT performance and at least hold even on ST performance with lower power use and P-core temps. If it makes the ST performance better for the client market that is a good thing. 24 threads is still plenty.
In mainstream CPUs, I could see ditching hyperthreading. However, they'd probably want to boost E-core count, at the same time. Long ago, there were rumors of them going to 32 E-cores. It's hard to see why you'd need hyperthreading on the P-cores, when you have so many E-cores that are each faster than a second thread on a P-core.
In server CPUs, they lose enough margin by disabling hyperthreading that I think they probably wouldn't want to cede that ground to AMD or ARM. We'll see.
That sounds exactly like what Soft Machines was working on.
Chipzilla's silicon acquisition spree continues with a $250m deal
www.theregister.com
I think there's pretty much no chance of that tech making it into Arrow Lake, however. It has big software implications, and Intel would have publicized that info further in advance of such products launching. Even if they kept it under NDA, I think rumors would've been swirling by now.
MLiD already leaked what Intel is going to try to replace Hyper-Threading with.
It's part of Jim Keller's Royal Core Family of CPU's that he helped architect for his short stint in Intel.
They call it "Rentable Units" which is the virtualization of CPU cores and allocating CPU hardware components in sets to a Virtual CPU to do "More Efficient" processing of threads.
All the major building blocks of a CPU will be in Dual Unit pairs to allow easy bundling of a Virtual CPU with "Enough Hardware Resources" to solve the thread processing issue at hand.
How well this will work in practice, they claim the simulations talk about a +30-40% Single Core Performance uplift.
We'll see how reality pans out.
But they fully intend to throw Hyper-Threading out the window & replace it with "Rentable Units".
But the "Rentable Units" sounds very much like the VISC architecture in design, but the allocation of CPU Hardware Resources works in Pairs and how many Virtual CPU Resources will be available is still TBD (To Be Determined) since we don't know that much about how they want to execute on "Rentable Units".
The bomshell from that leak is just 3-4% faster single-threaded integer performance and 1-2% faster single-threaded floating point performance, in the same power envelope as 13th gen (Raptor Lake). Multithreaded improves by a lot more, but that could be just due to E-core improvements (I'd guess P-core efficiency improvements also play a role).
probably true. geekbench benches the igpu as well as the cpu. so any performance boost on the igpu will show up pretty big in geekbench even if there is almost no gain elsewhere.
In mainstream CPUs, I could see ditching hyperthreading. However, they'd probably want to boost E-core count, at the same time. Long ago, there were rumors of them going to 32 E-cores. It's hard to see why you'd need hyperthreading on the P-cores, when you have so many E-cores that are each faster than a second thread on a P-core.
I think there's pretty much no chance of that tech making it into Arrow Lake, however. It has big software implications, and Intel would have publicized that info further in advance of such products launching. Even if they kept it under NDA, I think rumors would've been swirling by now.
It would make sense that it would be implemented in whatever came from Jim Keller's time which would likely be the core arch after Lion Cove at the earliest. Not to mention the patent cited in the article has a 2023 date so that certainly wouldn't be tech in ARL.
I really like the soc tile e-core idea. Probably 95% of the time I'd rather have the fan off and less than 1% of the time I might care if hyper-threading is available.
In mainstream CPUs, I could see ditching hyperthreading. However, they'd probably want to boost E-core count, at the same time. Long ago, there were rumors of them going to 32 E-cores. It's hard to see why you'd need hyperthreading on the P-cores, when you have so many E-cores that are each faster than a second thread on a P-core.
Yup, but substituting it with "Rentable Units" that allow dynamic allocation of CPU hardware resources to create "Virtual CPU cores" of varying hardware capabilities to solve the current software threads problem.
How well that works "In Practice" remains to be seen, their prediction through simulations for Single-Threaded IPC was "At least 30% more IPC over Golden Cove (Used in AlderLake & Sapphire Rapids)" in the Lunar Lake leak according to MLiD, but changing the CPU core at such a fundamental level could be "Really Good" or a "Disaster waiting to happen" depending on how it's implemented.
Yeah, it might increase the golden cove IPC by 30% bringing it on the level of the P-cores since they will be using them for the heavy parts instead of running them on the e-cores.
The important question here is why would this be an either or???
According to this explanation they will break threads up and send the complex parts to the p-cores and the simpler parts to the e-cores.
Unless they can guarantee that the complex part, of the partial one single thread, will always be using 100% of the p-core HTT will still be useful and still be adding a lot of performance for very cheap.
Intel’s adoption of the hybrid core architecture has significantly changed the roadmap of the PC chipmaking industry. More and more applications are now taking advantage of the “secondary” low-power E-cores to boost performance and efficiency. This approach has its shortcomings, which Intel...
They call it "Rentable Units" which is the virtualization of CPU cores and allocating CPU hardware components in sets to a Virtual CPU to do "More Efficient" processing of threads.
This sounds a tiny bit like the deconstructed CPU core I've been thinking about, ever since I started reading about modern GPUs. My vision was to have giant pools of ALUs and registers, sort of like having a super wide core with many-ways SMT. I get why that would be bad (you want to minimize the distance data has to travel and also keep muxes as small as possible), but it's kinda fun to think about.
Usually, you'd go to 4 or 8-way SMT. IBM's recent POWER 9 has gone up to 8-way.
The last time I heard of an odd number of SMT threads, it was the 7 threads per EU in Intel's Gen 9 iGPUs. I have no idea how many threads their current GPUs support, as they've gotten more tight-lipped about such details.
MLiD already leaked what Intel is going to try to replace Hyper-Threading with.
It's part of Jim Keller's Royal Core Family of CPU's that he helped architect for his short stint in Intel.
They call it "Rentable Units" which is the virtualization of CPU cores and allocating CPU hardware components in sets to a Virtual CPU to do "More Efficient" processing of threads.
All the major building blocks of a CPU will be in Dual Unit pairs to allow easy bundling of a Virtual CPU with "Enough Hardware Resources" to solve the thread processing issue at hand.
How well this will work in practice, they claim the simulations talk about a +30-40% Single Core Performance uplift.
We'll see how reality pans out.
But they fully intend to throw Hyper-Threading out the window & replace it with "Rentable Units".
But the "Rentable Units" sounds very much like the VISC architecture in design, but the allocation of CPU Hardware Resources works in Pairs and how many Virtual CPU Resources will be available is still TBD (To Be Determined) since we don't know that much about how they want to execute on "Rentable Units".
Forgive me if I am wrong here as I’ve yet to dive into info relating to “rentable units”, but your description of the “dual unit pairs” sounds like AMD’s core module architecture from bulldozer (2 integer pipelines per module, however the caveat is that floating point was shared between the 2 supported threads). I wonder if the integer part of the bulldozer module could be compatible with the “rentable unit” concept given the appropriate software, microcode, and scheduling was devised? Or is the physical hardware more than just redundant resources fitted into each core?
Wouldn't this also need to be fully supported by the OS? Since Win11 already craps the bed with hybrid architecture, is this just going to make it worse?
Yeah, it might increase the golden cove IPC by 30% bringing it on the level of the P-cores since they will be using them for the heavy parts instead of running them on the e-cores.
According to this explanation they will break threads up and send the complex parts to the p-cores and the simpler parts to the e-cores.
Unless they can guarantee that the complex part, of the partial one single thread, will always be using 100% of the p-core HTT will still be useful and still be adding a lot of performance for very cheap.
Intel’s adoption of the hybrid core architecture has significantly changed the roadmap of the PC chipmaking industry. More and more applications are now taking advantage of the “secondary” low-power E-cores to boost performance and efficiency. This approach has its shortcomings, which Intel...
Wouldn't this also need to be fully supported by the OS? Since Win11 already craps the bed with hybrid architecture, is this just going to make it worse?
Forgive me if I am wrong here as I’ve yet to dive into info relating to “rentable units”, but your description of the “dual unit pairs” sounds like AMD’s core module architecture from bulldozer (2 integer pipelines per module, however the caveat is that floating point was shared between the 2 supported threads). I wonder if the integer part of the bulldozer module could be compatible with the “rentable unit” concept given the appropriate software, microcode, and scheduling was devised? Or is the physical hardware more than just redundant resources fitted into each core?
Somehow, they'll slap them all together in real time, re-order the hardware to be as big/small as needed for a virtual CPU, then run the thread through it.
How they plan on doing that consistently will be interesting.
Also, can they pull this off w/o causing all sorts of security or stability issues.
In server CPUs, they lose enough margin by disabling hyperthreading that I think they probably wouldn't want to cede that ground to AMD or ARM. We'll see.
"pre-released Intel Desktop Board code named MTL-S DDR5
featuring the 15th Generation Intel Processor code named Arrow Lake S
Intel Platform Controller Hub (PCH) code named Metor Lake PCH-S
Note: The pre-Alpha ARL-S CPU that is configured in BIOS to turn of the performance cores due to a hw issue. Enabling the performance cores will cause system instability and cause some board functions to not work
(such as detecting M.2 SSD's). This issue will be fixed in a future CPU stepping."
So, probably justthe fact that you have to disable the P-cores. Weirdly, I thought you couldn't do that in Gen 12-14 desktop CPUs. So, it's interesting that Gen 15 can (or maybe just a special feature of pre-release BIOS?).
Yeah, I guess. Now that I've had a closer look at the doc, the English is pretty rough and the spacing is kinda weird. I wonder how it matches up against previous such docs we've seen, because maybe it's just a forgery.
There's actually a very effective mitigation for SMT-related security issues: don't schedule threads from different VMs or processes on the same core! That still lets you attain most of the benefits of SMT without the associated risks. In Linux, this feature is known as "Core Scheduling", and has been in the main kernel for a while.