Intel Core i5 12600K / Core i9 12900K "Alder Lake" Linux Performance

[numacross]

Good showing and in desperate need of a "tock" (bring back the "tock")

Tock was a new microarchitecture, so with ADL there's two Tocks - Golden Cove (P-cores) and Gracemont (E-cores). You can argue that it's a Tock-Tock-Tick as well, at least for the desktop vs. Rocket Lake, since it's the first desktop processor on the Intel 7 (previously known as 10ESF) manufacturing process

While Alder Lake seems to be a great step forward for Intel, from a consumer perspective, Raptor Lake should be even more appealing. At least I expect them to solve the AVX-512 dilemma with their new Thread Scheduler with that iteration, maybe they fine tune their 10 nm process a bit further and fix a couple of other architecture bugs. By then I also expect DDR5-pricing to be more sane.

I'm not sure that the AVX-512 problem can be solved in any other way than by introducing it to E-cores, at least without breaking backwards compatibility along the way.

[Spacefish]

While Alder Lake seems to be a great step forward for Intel, from a consumer perspective, Raptor Lake should be even more appealing. At least I expect them to solve the AVX-512 dilemma with their new Thread Scheduler with that iteration, maybe they fine tune their 10 nm process a bit further and fix a couple of other architecture bugs. By then I also expect DDR5-pricing to be more sane.

Guess the "AVC512 dilemma" is not caused by the Thread-Scheduler but more by the E-Cores not supporting it.
Having cores with different ISAs / extensions isn´t supported by most platforms at least not if you want to move threads between these cores.

[birdie]

I'm not sure that the AVX-512 problem can be solved in any other way than by introducing it to E-cores, at least without breaking backwards compatibility along the way.

But ... can't the OS simply never let AVX-512 tasks run on e-cores? It's trivial to detect AVX-512 instructions and then pin the application to the appropriate cores. If I've said something stupid, please let me know.

[andreano]

Maybe this is where vector instructions (instead of SIMD, i.e. not hardcoding the instruction width) would have paid off. They are supposedly easier to support on big and small cores alike. Not to mention that we wouldn't have needed AVX512 for the purpose of moving to 512 bit.

[numacross]

But ... can't the OS simply never let AVX-512 tasks run on e-cores? It's trivial to detect AVX-512 instructions and then pin the application to the appropriate cores. If I've said something stupid, please let me know.

It's not stupid, your idea is correct, but what about all the previous OSes? As I wrote, the problem here is backwards compatibility. You can still run MS-DOS (provided your motherboard has CSM, which was made not mandatory in 2020 on Intel boards) on modern computers.

Maybe this is where vector instructions (instead of SIMD, i.e. not hardcoding the instruction width) would have paid off. They are supposedly easier to support on big and small cores alike. Not to mention that we wouldn't have needed AVX512 for the purpose of moving to 512 bit.

AVX-512 is not only about enabling the use of 512-bit registers. It's also about operand masking and memory capabilities.
Yeah, something like SVE2 would be great, but Intel is hamstrung by its legacy (Larrabee, Xeon Phi, AVX/2).

[sdack]

A bold statement considering the many times Intel lost in court over anti-competitive practices (and had to pay billions to AMD). They seem to only allow competition from AMD up to a certain point, basically allowing them to be a deterrent for antitrust investigations from governments. The situation has changed a bit lately with the advent of ARM in more markets and the general lack of antitrust action from governments (when compared for example to the 90's).

Not bold at all. Intel had competition not only by AMD, but also by IBM, Cyrix and Via. All while x86 is Intel's creation. Others copied from Intel to get a piece of their success and for no other reason. Companies like Sun, DEC, HP, SGI, Motorola, MIPS, ARM and others at least had the decency not to copy, but to create their own CPU designs and to use these to compete. This says enough about the copying companies and also explains why any other reasonable company would have tried to fight off copying competitors like Intel did. It still is Intel's success and their creation. Others are just hitching a ride on it to this day. And let us not pretend as if x86 was the world's best CPU design. It is being kept alive thanks to the copying competition like AMD and why we still use x86 CPUs today. We could have let it all die a long time ago, and gone with ARM or other RISC designs. Instead, did we buy what was cheap and affordable, no matter who stole what from whom. Your objection then fails to address why Intel was somehow like Monsanto.

[numacross]

Not bold at all. Intel had competition not only by AMD, but also by IBM, Cyrix and Via. All while x86 is Intel's creation. Others copied from Intel to get a piece of their success and for no other reason. Companies like Sun, DEC, HP, SGI, Motorola, MIPS, ARM and others at least had the decency not to copy, but to create their own CPU designs and to use these to compete. This says enough about the copying companies and also explains why any other reasonable company would have tried to fight off copying competitors like Intel did. It still is Intel's success and their creation. Others are just hitching a ride on it to this day. And let us not pretend as if x86 was the world's best CPU design. It is being kept alive thanks to the copying competition like AMD and why we still use x86 CPUs today. We could have let it all die a long time ago, and gone with ARM or other RISC designs. Instead, did we buy what was cheap and affordable, no matter who stole what from whom. Your objection then fails to address why Intel was somehow like Monsanto.

You are aware that Intel was forced by IBM to "allow" the competition in the first place? They didn't want to let Intel have the upper hand as the sole vendor of x86.

What is more Intel actually tried to break from x86 a few times (i960, ARM, Itanium), but in the end they decided to scrap all that and, here will come a shock, copy AMD's amd64

[Archestratus]

Greetings!

I am a relatively non-technical forum member with a request for guidance. If I am in the wrong place, please direct me toward the right direction. Thank you.

My situation: I am looking at the purchase of a new computer upon which I plan to run a Linux home Desktop. My habit has been to run the latest Ubuntu LTS for close to five years at a time, then upgrade as the older version loses support. My computer usage is relatively non-demanding: web browsing (Firefox with ~20-30 tabs open, max), email and the occasional printed page. Quiet is the major priority. I like to go with an upgradeable desktop computer with a GPU integrated into the processor - I tend to keep a computer for a while, with upgrades of used parts as the sands of time pass by. Unfortunately, I do not feel very comfortable in the command line.

A generous relative has offered to provide me with a moderate new Dell computer of my choosing.

People are basically good.

I have been looking at 10th and 11th (hotter/noisier?) generation Intel offerings, when, today - November 4 - with the announcement of the 12th generation chips - imagine my surprise - the world has changed.

Hence this post.

I regret that Mr. Larabel's meticulous Alder Lake review is a bit beyond my ken, but from what I can gather, Linux does not seem to be quite ready for Intel Generation 12 at this time. And I am not sure that the integrated CPU/GPU chips have hit the market at this point. My questions:

(1) Should I go now with a generation 10 or 11 chip, or will I be well-served to wait just a little bit? No hurry, here - no time pressure. If I do choose to wait - any guesses as to a likely timeline?

(2) I think that a 12th generation i5 with integrated graphics may suit my purposes well. Yea or nay?

(3) My kind benefactor seems to think that my current computer is a tad slow. I have tried to explain to him that it proceeds at a perfectly normal computer pace, but you know how these young 70 year-old whippersnappers are. Always in such a hurry!

The current computer is largely of 2008 vintage - cobbled together post capacitor plague (another story). E8600 Intel Core 2 Duo, 4 GB of DDR 800 RAM, a blazingly silent (fanless) nVidia GeForce GT 520 video card, a conventional spinning hard drive, Ubuntu 16.04 or so.

My question: do you really think that upgrading by 10 or 12 Intel CPU generations will make much of a difference?

Thank you for your kind patience -

Archestratus

[Kraut]

But ... can't the OS simply never let AVX-512 tasks run on e-cores? It's trivial to detect AVX-512 instructions and then pin the application to the appropriate cores. If I've said something stupid, please let me know.

Then you get other issues, like for example with task based libraries. (HPX)
Where you will "dirty" up all threads in no time if you happen to use any AVX512 instructions.

Way to many programs will have this issue of "dirty" threads, that can never be migrated to the E-cores again. Maybe the thread director could detect if threads don't use AVX512 for some time and mark them as "clean" again. But every time they use it again, it triggers an expensive IRQ and a thread eviction from the E-core.

[blackshard]

It's not stupid, your idea is correct, but what about all the previous OSes?

It is not stupid, but it just not feasible.
How does the operating system could know in advance if an AVX-512 instruction would be executed or not?
You could say that the operating system would scan the whole .text segment (the code), do something like disassemble it, and then flag the process to run on P-core if an AVX-512 instruction is found. Yet you don't know if that instruction will ever be executed, so the OS allocates the process to P-cores wasting the E-cores presence, not counting the fact that the OS should do something which is not expected it to do (disassemble the executable to change affinity mask ...)

The only way to do that is catching the IRQ fault during runtime in case of illegal instruction and then moving the process to a more capable core. This is similar to what Windows 95 did as a compatibility layer with MS-DOS when in/out x86 instructions were issued during runtime.