[PragmaticPulp]

Server and workstation chips still have AVX-512. It’s only unsupported on CPUs with smaller E(fficeincy) cores.

AVX-512 was never really supported in newer consumer CPUs with heterogeneous architecture. These CPUs have a mix of powerful cores and efficiency cores. The AVX-512 instructions were never added to the efficiency cores because it would use way too much die space and defeat the purpose of efficiency cores.

There was previously a hidden option to disable the efficiency cores and enable AVX-512 on the remaining power cores, but the number of workloads that would warrant turning off a lot of your cores to speed up AVX-512 calculations is virtually non-existent in the consumer world (where these cheap CPUs are targeted).

The whole journalism controversy around AVX-512 has been a bit of a joke because many of the same journalists tried to generate controversy when AVX-512 was first introduced and they realized that AVX-512 code would reduce the CPU clock speed. There were numerous articles about turning off AVX-512 on previous generation CPUs to avoid this downclocking and to make overclocks more stable.

[pantalaimon]

Catching the bad instruction fault on the E-cores and only scheduling the thread on the P-cores would be something that could be added to Linux (there were already third party patches towards that goal) if Intel had not disable the feature entirely.

[jeffbee]

But it's not really compatible with the GCC IFUNC scheme ... PTL entries will be permanently remapped to the most appropriate code on the CPU where the function is first called, and never thereafter remapped. So you end up with a coin toss whether you get the optimized function or not.

Personally I don't find the e-cores on my alder lake CPU to be of any value. They're more of a hazard than a benefit.

[janwas]

Fair point about ifunc, but we're using our own table of function pointers, which can be invalidated/re-initialized. Someone also mentioned that the OS could catch SIGILL.. indeed seems doable to then reset thread affinity to the P cores?

[saagarjha]

Presumably the AVX-512 code is something on your hot path, so I’m not sure waiting for a signal to reschedule the work is something you would want.

[heavenlyblue]

You reschedule it only once so it doesn’t matter

[saagarjha]

I don’t see how? Once your quantum is up the thread gets put back into the scheduling pool and you have to do this all over again…

[boardwaalk]

Couldn’t there be some flag on the thread that marks it as “P-core only”? Doesn’t seem hard. I don’t known Linux scheduler internals though.

[pantalaimon]

Threads already have an affinity bit mask where you can select which cores they can be scheduled on.

https://man7.org/linux/man-pages/man2/sched_setaffinity.2.ht...

[saagarjha]

Right but then you’d just have all processes with that flag all the time.

[heavenlyblue]

You don’t have to schedule your thread on another core at all

[zozbot234]

> The AVX-512 instructions were never added to the efficiency cores because it would use way too much die space and defeat the purpose of efficiency cores.

And this is why scalable vector ISA's like the RISC-V vector extensions are superior to fixed-size SIMD. You can support both kinds of microarchitecture while running the exact same code.

[willis936]

>The AVX-512 instructions were never added to the efficiency cores because it would use way too much die space and defeat the purpose of efficiency cores.

Isn't the purpose of efficiency cores to be more power efficient? It's more power efficient to vectorize instructions and minimize pipeline re-ordering.

[mastax]

Power and area efficient. You can fit 4 E cores in the area of 1 P core. Adding AVX-512 to the E cores would significantly hamper that, though I don't know by how much.

[willis936]

I've been thinking about this. I think the idea of heterogeneous extensions is nuts. Intel is right to either have it on all cores or none. I think the die space would be worth it to actually have more high performance, efficient vector extensions available. Considering how many E cores are being crammed into raptor lake, I hope Intel will decide to add AVX-512 into E cores in time.

[R0b0t1]

That's not a valid reason why I can't use them on the P cores. Some motherboards can enable them on the i9-12900k, it works fine, but you need to pin to a P core.

[PragmaticPulp]

The reason is that it was never validated or tested with AVX-512 and Intel and motherboard vendors couldn’t commit to shipping everything with AVX-512 support in future steppings/revisions.

If you disable E cores you could enable AVX-512 on certain motherboards, but like I said that’s not really a net win 99.99% of the time when you’re giving up entire cores.

It was also at your own risk because presumably the power/clock speed profiles were never tuned for a feature that wasn’t actually supported. I can see exactly why they turned it off on newer CPUs only after an announcement.

[R0b0t1]

Still smells like bullshit. Let the customer decide. Who cares if it was validated? Why was it even included? Just put it behind a yes-I-really-mean-it-switch so nobody uses it by accident.

[kadoban]

There's not many great places for such a switch, and even then, then you have to validate _that_ behavior. It's mostly just not worth it.

[pantalaimon]

Several motherboard vendors added that very switch in UEFI (some even with the option to force an older microcode version AFAIK) before it was disabled in hardware by Intel

[Dylan16807]

> it was never validated or tested with AVX-512 and Intel and motherboard vendors couldn’t commit

Only because they screwed it up on purpose! That's not an acceptable reason for removing the feature; in part because it would apply to any feature they decided to cut.