Intel i9-12900K Alder Lake Linux Performance In Different P/E Core Configurations

[Sonadow]

Yes but GPU's have a very different workload, they are much more specific than general purpose CPU's. Also Optimus is incredibly crude, it just sees how much load you have on the GPU and if the load is very high then it moves it to the discrete GPU.

What we are dealing with big-little is an entirely different problem and its already been shown numerous times that the scheduler does close to jack shit when it comes to optimising anything. Steve from Gamers Nexus did extensive performance testing on Windows 10 (which has no scheduler) vs Windows 11 and the difference is almost completely negligible (talking about <1% if anything)

This is what I meant what I said earlier about a "completely magical scheduler" not really existing, at least not one that makes enough of a difference.

And yet Alder Lake performs much better on Windows than it does in Linux.

There is definitely something going on in the Windows scheduler, that much is for sure. Microsoft is no stranger to BIG.little; they dealt with it before in Windows RT on the Tegra 3 and they recently worked with it again on the SQ1 and SQ2 for the Surface Pro X. It will be hardly a surprise if the lack of performance difference for Alder Lake in Windows 10 and Windows 11 simply comes down to the fact that Microsoft has already worked on the scheduler to the point where the version in Windows 10 is punting jobs between the P cores and the E cores properly.

[mdedetrich]

Optimus is supposed to know which applications should run on the powerful Nvidia GPU cores while lesser applications get punted off to the iGPU. Sounds magical but really isn't. What Nvidia implemented was a dictionary of applications with static declarations of what should run where. Worked well enough that it did not get in the way of users who knew nothing about Optimus, while the more savvy ones went around editing said dictionary for their individual preferences.

Yes but GPU's have a very different workload, they are much more specific than general purpose CPU's. Also Optimus is incredibly crude, it just sees how much load you have on the GPU and if the load is very high then it moves it to the discrete GPU.

What we are dealing with big-little is an entirely different problem and its already been shown numerous times that the scheduler does close to jack shit when it comes to optimising anything. Steve from Gamers Nexus did extensive performance testing on Windows 10 (which has no scheduler) vs Windows 11 and the difference is almost completely negligible (talking about <1% if anything)

This is what I meant what I said earlier about a "completely magical scheduler" not really existing, at least not one that makes enough of a difference.

[Sonadow]

I am getting the impression that the biggest issue appears to be Intel trying to provide a solution for something that from at least my OS studies back at uni is not really solvable, i.e. automagic scheduling on big little design that generally works better than the alternative. Big little designs work best when developers specifically code into their applications how to use cores, i.e. if you are virus scanner you would pretty much always want to use an E core, or for background tasks like checking for emails or index'ing for fuzzy file search.

This is because knowing what should run on an e-core and what should run on a p-core is primarily a subjective thing, its when making something deliberately slower but to save power is acceptable which depends on the context of the application.

Processor architectures are created by humans, as are operating system kernels and schedulers. Even an NP-complete problem is solvable with crude techniques.

Optimus is supposed to know which applications should run on the powerful Nvidia GPU cores while lesser applications get punted off to the iGPU. Sounds magical but really isn't. What Nvidia implemented was a dictionary of applications with static declarations of what should run where. Worked well enough that it did not get in the way of users who knew nothing about Optimus, while the more savvy ones went around editing said dictionary for their individual preferences.

[Sonadow]

Back in to your rat hole

Right, because you have nothing to argue?

Fact remains that for all the benchmarks Michael has done about Linux having better performance over Windows, they simply don't carry forward to real-world computing. Till now nobody can provide a reasonable explanation as to why Windows boots, launches programs and generally respond to application inputs faster than Linux on the same hardware, especially on low-power hardware like Atoms.

[mdedetrich]

AMD's Zen CPUs are not as uniform as people think. Only AMD hides the details and presents a uniform multi-core CPU. One can certainly find cases where AMD's design shows weaknesses, but I have not yet seen anything as worrying as was shown here with Alder Lake.

The idea of hybrid designs is certainly not bad. What is bad is not to have the software ready on release to benefit from it as there is evidently much to gain from it.

I am getting the impression that the biggest issue appears to be Intel trying to provide a solution for something that from at least my OS studies back at uni is not really solvable, i.e. automagic scheduling on big little design that generally works better than the alternative. Big little designs work best when developers specifically code into their applications how to use cores, i.e. if you are virus scanner you would pretty much always want to use an E core, or for background tasks like checking for emails or index'ing for fuzzy file search.

This is because knowing what should run on an e-core and what should run on a p-core is primarily a subjective thing, its when making something deliberately slower but to save power is acceptable which depends on the context of the application.

[Sonadow]

ARM as well as Apple have been using BIG-little designs for many years now. AMD has been rumored to migrate to a BIG-little uArch as well somewhere in the future. Maybe what Intel has implemented is not that bad after all. Maybe if the Linux kernel properly supported ADL CPUs we wouldn't have such a salty conversation.

Brings back memories of the old Surface and its Windows RT* operating system which ran rather fast despite being Microsoft's first real attempt on having a desktop WIndows implementation on ARM, and the Tegra 3 also had BIG.little. Considering that Windows 10 also has an ARM64 version the only feasible explanation is that Microsoft merged what they learned from Windows RT into mainline Windows' kernel and scheduler.

*Windows RT 8.0 release only. RT 8.1 was badly broken.

[sdack]

ARM as well as Apple have been using BIG-little designs for many years now. AMD has been rumored to migrate to a BIG-little uArch as well somewhere in the future. Maybe what Intel has implemented is not that bad after all. Maybe if the Linux kernel properly supported ADL CPUs we wouldn't have such a salty conversation.

AMD's Zen CPUs are not as uniform as people think. Only AMD hides the details and presents a uniform multi-core CPU. One can certainly find cases where AMD's design shows weaknesses, but I have not yet seen anything as worrying as was shown here with Alder Lake.

The idea of hybrid designs is certainly not bad. What is bad is not to have the software ready on release to benefit from it as there is evidently much to gain from it.

[mdedetrich]

Just putting it out there, SAM is not the same thing as re-sizable bar. Resizable bar is just the optional part of the PCI'e spec that allows you specify whatever sized chunks from PCI'e, things like "smart access memory" from AMD is resizable bar + specific optimizations for CPU + tweaks for games.

The last bit is quite important because in quite a few games, enabling resizable bar actually slows the game down (and in some cases this slow down is non negligible, i.e. > 10%). The reason why AMD is ahead than Intel here is because they have done the necessary tweaking

[Sonadow]

Looks like your final line of "reasoning" here is insults and I prefer to talk to civil and rational people instead.

Now why would you waste your precious time arguing civilly with a self-proclaimed Linux power-luser who doesn't even know how to compile a web browser and its dependencies?

[MadCatX]

I wonder this as well. The scheduler issues are significant though. Look at the average power consumption for the two scenarios. P only was 50% more power. That’s significant enough to make me hesitant to compare the performance. Also keep in mind intel said that one P core has the same size as 4(!) E cores

I guess that most of the P-core die size is taken up by the effectivelly useless AVX-512 block. Performance of a 10 P-core chip with AVX-512 enabled would be interesting to see. Since AVX-512 will probably remain restricted to specific workloads that most people don't run, maybe a consumer variant of Golden Cove without the -512 block would allow for 12 P-cores to fit on a die. Considering that the performance difference between 12700K and 12900K is quite negligible despite the 12700K being 4 E-cores and a few MHz short, such a chip could've been ideal for gamers ect.