Question Raptor Lake - Official Thread

[DrMrLordX]

You mean 16 zen4 cores?

Or Golden Cove/Raptor Cove, same basic idea.

Read again what the HULK workflow is, any rendering task on a 16 core system would use all 16 cores lowering the response for the other more real-time task he needs to do.

CPUs are better at resource sharing than that, especially if it's a background task.

 

[TheELF]

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]

Yes! IF!

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]

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.

 

[biostud]

Or Golden Cove/Raptor Cove, same basic idea.

I know, but of these options only zen4 is actually happening.

 

[Hulk]

Wouldn't 16P cores fit your workloads better?

Yes, and 24P cores better yet. And 32P even better.
My point was that given the die area available to Intel and other cost constraints Raptor Lake 8/16 is a good fit for me.

 

[igor_kavinski]

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.

 

[Hulk]

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.

 

[igor_kavinski]

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.

Hopefully Intel comes to their senses regarding this with Raptor Lake.

 

[Henry swagger]

Intel Core i9-13900 'Raptor Lake' Early CPU Sample Tested, Up To 50% Faster Than Core i9-12900 'Alder Lake' at Just 3.7 GHz Clock Speeds

Intel's 13th Gen Raptor Lake Core i9-13900 CPU benchmarks have leaked and show a 50% performance improvement over Alder Lake in ES state.

wccftech.com

50% faster than alder lake at 3.7ghz still has a 55% clocks headroom.. raptor lake will cruise to victory ✅😊

 

[DrMrLordX]

Intel Core i9-13900 'Raptor Lake' Early CPU Sample Tested, Up To 50% Faster Than Core i9-12900 'Alder Lake' at Just 3.7 GHz Clock Speeds

Intel's 13th Gen Raptor Lake Core i9-13900 CPU benchmarks have leaked and show a 50% performance improvement over Alder Lake in ES state.

wccftech.com

50% faster than alder lake at 3.7ghz still has a 55% clocks headroom.. raptor lake will cruise to victory ✅😊

Somehow that seems unlikely.

 

[Det0x]

Intel Core i9-13900 'Raptor Lake' Early CPU Sample Tested, Up To 50% Faster Than Core i9-12900 'Alder Lake' at Just 3.7 GHz Clock Speeds

Intel's 13th Gen Raptor Lake Core i9-13900 CPU benchmarks have leaked and show a 50% performance improvement over Alder Lake in ES state.

wccftech.com

50% faster than alder lake at 3.7ghz still has a 55% clocks headroom.. raptor lake will cruise to victory ✅😊

The graphs:



Somewhat strange they only used the 5900x and not a 5950x for the AMD comparison (?)

 

[coercitiv]

Somewhat strange they only used the 5900x and not a 5950x for the AMD comparison (?)

Using 5950x would confuse prospective buyers.

 

[Hulk]

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.

 

[Markfw]

Using 5950x would confuse prospective buyers.

Between that and having detailed benchmarks out this early, I don't even believe these are real.

 

[nicalandia]

Between that and having detailed benchmarks out this early, I don't even believe these are real.

It's nothing to brag about when the 5900X and the 11900K is beating your 12900K....

 

[DrMrLordX]

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.

 

[nicalandia]

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.

 

[psolord]

Hello everyone.

Will raptor lake work on z690?

thanks

 

[igor_kavinski]

Will raptor lake work on z690?

They say it's compatible. Will it work? It should.

 

[eek2121]

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.

 

[dullard]

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]

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]

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.

 

[FangBLade]

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.