Question Raptor Lake - Official Thread

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

TheELF

Diamond Member
Dec 22, 2012
3,623
528
126
CPUs are better at resource sharing than that, especially if it's a background task.
Yes! IF!
Meaning that it has a low priority but most if not all compute heavy apps are normal priority or even higher.
And even if it has a low priority it's not the same as having an "empty" core to work with, power consumption and turbos are going to reduce the clocks all the cores, if nothing else.

I understand where you come from and it can seem like it's not worth it, but as you can see from HULK some people do appreciate it, and if it's enough people intel will keep at it.
 

DrMrLordX

Lifer
Apr 27, 2000
19,626
8,452
136
Which it is if the editor is in the foreground. Worst case he edits process priority, rather than fiddling with process lasso or what have you. That shouldn't be necessary regardless, assuming sufficient P-cores (such as on a Sapphire Rapids-based HEDT CPU, or a hypothetical 16c Raptor Cove).

It is at best an accidental benefit of Alder Lake (or presumably Raptor Lake) that it shunts backround applications to the e-cores exclusively whether or not you actually want that behavior.

If he really wants a Raptor Lake then he'll get one. It's just a shame that only foreground applications can use e-cores plus p-cores, so far as we know.
 

cortexa99

Senior member
Jul 2, 2018
221
296
136
The problem of big-little or big-middle-little is manufacturers make the processors too specific.
I heard so many reports that complaining their Alder Lake rendering/computing with Ecores only while leave their Pcores alone idle, and some users thought it's good to have some Pcores unused and could deal with other tasks.
That looks like users have to adapt these big-little characteristic to gain highest efficiency, but OTOH our benchmark tools always loads all your cores no matter big or little. That said the bench result is distorted and cannot reflect to the realworld/in real life.

For me. I would rather render with pure big core or GPU. Ecore is out of question. I even won't put any hope that software side would be optimized enough to solve these problem.

Maybe I would looking forward to AMD's Zen5-Zen4c hybrid solution if the rumor turn out to be right, looks like relieve the problem a bit.
 
Last edited:

igor_kavinski

Diamond Member
Jul 27, 2020
3,735
2,201
106
I still think Thread Director was a dumb idea. They just needed one application built into Windows that would specify the default affinity for applications/system processes. Most users wouldn't need to mess with the defaults and power users could customize the settings to their heart's content.

Shifting applications between P-cores and E-cores on laptops is fine but on desktop, it's not needed and should have been selectable with a toggle. Set the toggle to OFF and then you can have P-cores with AVX-512 doing their thing and E-cores doing their own dedicated thing with processes never leaving the core cluster they were started on. They wasted their time on all this hardware engineering complexity when it could have been software/OS controlled.
 
  • Like
Reactions: Timmah! and Hulk

Hulk

Diamond Member
Oct 9, 1999
3,379
877
136
I still think Thread Director was a dumb idea. They just needed one application built into Windows that would specify the default affinity for applications/system processes. Most users wouldn't need to mess with the defaults and power users could customize the settings to their heart's content.

Shifting applications between P-cores and E-cores on laptops is fine but on desktop, it's not needed and should have been selectable with a toggle. Set the toggle to OFF and then you can have P-cores with AVX-512 doing their thing and E-cores doing their own dedicated thing with processes never leaving the core cluster they were started on. They wasted their time on all this hardware engineering complexity when it could have been software/OS controlled.
I like this. Perhaps there should be an "Advanced Setting" tab for the TD for users with the skill/need customize behavior to their workflow.
 

DrMrLordX

Lifer
Apr 27, 2000
19,626
8,452
136

Det0x

Senior member
Sep 11, 2014
665
1,187
136
50% faster than alder lake at 3.7ghz still has a 55% clocks headroom.. raptor lake will cruise to victory ✅😊
The graphs:
1655107344389.png
1655107352362.png

Somewhat strange they only used the 5900x and not a 5950x for the AMD comparison (?)
 
  • Like
Reactions: lightmanek

Hulk

Diamond Member
Oct 9, 1999
3,379
877
136
I suppose Intel 4 isn't ready but it might have been good for Intel to build Raptor Lake on Intel 4 so that there wasn't an architecture and node change all at once moving to Intel 4. A new architecture and node for Meteor seems like a lot of new tech at once.
 

DrMrLordX

Lifer
Apr 27, 2000
19,626
8,452
136
I suppose Intel 4 isn't ready but it might have been good for Intel to build Raptor Lake on Intel 4 so that there wasn't an architecture and node change all at once moving to Intel 4. A new architecture and node for Meteor seems like a lot of new tech at once.
Raptor Lake only exists due to delays with Intel 4. That would be like Intel producing Rocket Lake on 10nm.
 
  • Like
Reactions: Hulk

nicalandia

Golden Member
Jan 10, 2019
1,598
1,861
106
Raptor Lake only exists due to delays with Intel 4. That would be like Intel producing Rocket Lake on 10nm.
And due to Delays/Issue with Intel 4, Sapphire Rapids/Emerald Rapids that are built in Intel 7 will have to hang in there until Intel 3 Granite Rapids shows up.
 

eek2121

Golden Member
Aug 2, 2005
1,912
2,226
136
I still think Thread Director was a dumb idea. They just needed one application built into Windows that would specify the default affinity for applications/system processes. Most users wouldn't need to mess with the defaults and power users could customize the settings to their heart's content.

Shifting applications between P-cores and E-cores on laptops is fine but on desktop, it's not needed and should have been selectable with a toggle. Set the toggle to OFF and then you can have P-cores with AVX-512 doing their thing and E-cores doing their own dedicated thing with processes never leaving the core cluster they were started on. They wasted their time on all this hardware engineering complexity when it could have been software/OS controlled.
The issue is that Intel (or Microsoft) can’t possibly know every application/driver/service out there, which would be needed to make such a determination.

Microsoft could absolutely both do a better job at scheduling as well as provide more tools for managing thread scheduling.
 
  • Like
Reactions: igor_kavinski

dullard

Elite Member
May 21, 2001
24,031
2,247
126
The issue is that Intel (or Microsoft) can’t possibly know every application/driver/service out there, which would be needed to make such a determination.

Microsoft could absolutely both do a better job at scheduling as well as provide more tools for managing thread scheduling.
The end goal is to have EVERY application specify how to be scheduled. Windows can't possibly do it all perfectly. That requires recoding. The code changes are minimal, but it does require time and effort to do so.

When a programmer creates a thread, there are several things that are assigned. You must give the thread a name, you must assign the thread to be background or foreground, you must assign a rough priority level (note a programmer can ignore setting these but they just are assigned to default values). The priority level wasn't very specific or granular as there were only 5 priority levels: https://docs.microsoft.com/en-us/dotnet/api/system.threading.threadpriority?view=net-6.0

But now there are a whole lot more options when you create a thread. For example, the programmer can specify what cores to strongly prefer (such as use the P-cores and not E-cores, use all cores, use only E-cores, use a mixture of P and E cores, etc): https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask Or, the programmer can weakly suggest what cores to use (such as use a P core if available otherwise use an E core): https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadidealprocessor The programmer must still specify priority, but now there are many more levels to choose from instead of just 5: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadpriority

The problem is that it takes years for new software to come out with these changes. Ultimately in the future when there are dozens of E cores, the choice is obvious. But right now when there could be just a few E cores the choice is quite difficult for Windows to make. @igor_kavinski was incorrect, Windows always can choose the priority--that functionality that igor wanted is already present. The thread director is simply there to give Windows hints for the really terrible processors with only a few E cores (especially the i7 series with just 4 E cores).
 

igor_kavinski

Diamond Member
Jul 27, 2020
3,735
2,201
106
The thread director is simply there to give Windows hints for the really terrible processors with only a few E cores (especially the i7 series with just 4 E cores).
So Windows needs to do a better job ingesting the hints from the Thread Director? I don't think Microsoft will take this seriously until AMD also has E-cores of their own. But who knows? This might be a thing of the past with Raptor Lake. Windows 11 was clearly a very rushed release.
 

dullard

Elite Member
May 21, 2001
24,031
2,247
126
So Windows needs to do a better job ingesting the hints from the Thread Director? I don't think Microsoft will take this seriously until AMD also has E-cores of their own. But who knows? This might be a thing of the past with Raptor Lake. Windows 11 was clearly a very rushed release.
Rushed: probably. Impossible task: definitely. I think Windows 11 did an okay job and will likely improve over time. Maybe listening more to the thread director is part of that (I really don't know).

Ultimately this job will get easier when software tells Windows 11 how each program is best handled. Outlook should only use E cores if available to send/receive mail. Virus scanners too should only use E-cores for background file scans but maybe only P-cores when opening a specific file. User interfaces (which are required to be single threaded since two threads can't display on the same pixel at the same time) should only use P-cores. Multi-threaded applications should initially be programmed for all cores but over the years switch to using all E-cores.
 
  • Like
Reactions: igor_kavinski

FangBLade

Member
Apr 13, 2022
72
114
66
We can conclude that current big/little implementation is bad, and it requires also that each application is optimized with big/little in mind, and it will take years to get that. In theory big/little should be excellent in mobile devices, but Intel design is also bad at that because ryzen 6000 beat it in efficiency, so what's the real benefit of that big/little? It only supplements MT workloads like cinebench, while creating so much complication/complexity in software optimizations. Big/little was created because Intel currently can't create more than 8 big cores at reasonable power consumption, that's why they created this partial solution, but once they migrate to 3d MCM stacking cores, those little cores won't be needed.
 

ASK THE COMMUNITY