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

[birdie]

No, look again. The benchmarks show the opposite. Several of these show clearly that one gains performance by disabling the 8 E cores.

The Linux kernel doesn't understand the ADL CPUs topology. Even the newly released Windows 11 which was supposed to support ADL perfectly struggles with some applications and Windows 10, despite not knowing or understanding ADL CPUs, sometimes works better:

[perpetually high]

At the end of the day, Alder Lake is a new platform and you're paying the early adopter penalty and tax in every way. For what? To set some benchmarks? F***ing lol.

Yeah, let me buy this super fast CPU, and then undervolt it right away, tinker with this and that BIOS settings, disable this E core, do this, do that.

Or, buy an established Zen 3. Enable XMP, PBO Auto. Done. No problems.

[birdie]

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.

[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.

[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?

[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

[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.

[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.

[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]

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.