News Intel'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

Status
Not open for further replies.
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.
That sounds exactly like what Soft Machines was working on.

Intel bought them, so presumably they are still working away on the technology.


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.
Depends on whether you believe this leak:

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.

XmVXeRM.jpg
 
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.

Intel bought them, so presumably they are still working away on the technology.

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".
 
Last edited:
Depends on whether you believe this leak:

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 agree, but I don't think it would be happening with ARL unless the IPC increase is truly massive, and as you say not without 32 E-cores.
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.
 
  • Like
Reactions: NinoPino
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.
 
  • Like
Reactions: bit_user
MLiD already leaked what Intel is going to try to replace Hyper-Threading with.
Here's the vid, from July 21, 2023:

View: https://www.youtube.com/watch?v=ZuriVO-s26k


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.
They might wait until Arrow Lake Refresh to do 32 E-cores.
 
so instead of moving the technology further by allowing 3 threads per core they are cancelling all together ?
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.
 
Last edited:
  • Like
Reactions: usertests
"At least 30% more IPC over Golden Cove (Used in AlderLake & Sapphire Rapids)" in the Lunar Lake leak according to MLiD,
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.
 
  • Like
Reactions: artk2219
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.
 
Last edited:
so instead of moving the technology further by allowing 3 threads per core they are cancelling all together ?
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?
 
  • Like
Reactions: artk2219
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.
You do realize that Golden Cove was the P-Cores used in AlderLake & Sapphire Rapids, right?

We're not even talking about the E-cores at all, that's a seperate kettle of fish.
The important question here is why would this be an either or???
Ask Intel, they decided to abandon HyperThreading and go for Rentable Units on their P-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.
That's not what I was thinking was going to happen.
I was thinking that it would be closer to the VISC design.

But who knows what Intel is doing with this Rentable Units idea?
 
Last edited:
  • Like
Reactions: artk2219
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?
That's Intel's problem to figure out!

Good Luck with that!

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?
I was thinking of all the various hardware units allocated into Pairs like a GPU.

2 Integer Pipelines Units, 2 FP Pipeline units, 2x OOE units, etc.

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.
 

"This issue will be fixed in a future CPU stepping. "
What exactly this applies to is open ended,
Here's the full text, above the table:

"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?).

but given the wording and being Pre-Alpha, trying to draw a conclusion from this is a fool's errand IMO.
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.
 
Last edited:
With all the issues they, and AMD, have had in regards to speculative computing exploits perhaps it is best if HT went away in servers as well.
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.
 
Status
Not open for further replies.