Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel completely disables AVX-512 on Alder Lake after all

igorslab.de

Post reply on HN
Print view View original

131–140 of 317 posts

Re: Intel completely disables AVX-512 on Alder Lake after all

#131

Post by adgjlsfhk1 »

PragmaticPulp wrote: post #91
formerly_proven wrote: post #73

Earlier quoted context omitted.

I've voiced this before but I think AVX-512 is completely irrelevant in the consumer space (which imho makes titles like "Intel artificially slows 12th gen down" incredulous). Even for commercial applications - sure there are some things that benefit from it. On the other hand, I work in HPC and even in (commercial, not nuke simulations or whatever the nuke powers do with their supercomputers) HPC applications AVX-51…

> I've voiced this before but I think AVX-512 is completely irrelevant in the consumer spac Don’t forget that reviewers made a huge deal out of the fact that CPUs downclock themselves when running AVX instructions. Several reviewers tried to make this into some sort of scandal at the time, which I’d guess contributed to Intel wanting to remove the feature from consumer CPUs. Of course, many of those same reviewers ar…

To me, it does seem really weird that they opted to downclock the entire CPU rather than increase the latency of the instructions that caused overheating. That feels like it would have been a much less disruptive solution that would work strictly better.

Re: Intel completely disables AVX-512 on Alder Lake after all

#132

Post by im3w1l »

PragmaticPulp wrote: post #86
codeflo wrote: post #11

If all of this was planned (and I’m not saying it is), that would have been very clever. It would work like this: 1. You “accidentally forget” to disable the feature in hardware. Given how competitive the market is, motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed. 2. You “tolerate” this practice just long enough to win the critical initial wave of rev…

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come. That’s not what happened here. The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unle…

Comparing the facts to all the suspicious people here, it made me realize something. Our zeitgeist sure is a cynical one.

Re: Intel completely disables AVX-512 on Alder Lake after all

#133

Post by timpattinson »

marcan_42 wrote: post #26
pantalaimon wrote: post #16

Since Linux loads the microcode on it's own, can this be used to apply an old microcode or is there a prevention against downgrading the version?

I'm pretty sure downgrades are blocked. You need to hack the BIOS so the (volatile) upgrade never happens on boot.

I think for the subset of people that care about having AVX512 on their 12900K, and bother to disable the E-cores to achieve it, they will be using enthusiast motherboards that don't block bios upgrades in this way.

Re: Intel completely disables AVX-512 on Alder Lake after all

#134

Post by pantalaimon »

PragmaticPulp wrote: post #126
hajile wrote: post #118

Earlier quoted context omitted.

> The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unless disabling those extra cores was offset by the AVX-512 instructions on the remaining cores. If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Sixteen…

> If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Maybe if you have a poorly parallelized problem where the bulk of the code is spent in AVX-512 instructions and you don’t ever do anything else on the computer, but that’s going to be rare for any consumer. > The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and…

There have been reports that it was possible to enable AVX512 on the big cores with the little ones enabled [0] by toggling some bits in the MSR.

For a first step it would have been enough to manually pin threads to the big cores for adventurous users, but Linux already tacks which threads use AVX (since it comes with a clock penalty, so you want to isolate them if possible), it's not unreasonable to think that auto-setting CPU mask based on that should be possible too.

[0] https://lkml.org/lkml/2021/12/2/1059

Re: Intel completely disables AVX-512 on Alder Lake after all

#135

Post by amluto »

hajile wrote: post #118
PragmaticPulp wrote: post #86

Earlier quoted context omitted.

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come. That’s not what happened here. The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unle…

> The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unless disabling those extra cores was offset by the AVX-512 instructions on the remaining cores. If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Sixteen…

> The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores. It wouldn't be hard either, just catch the unknown instruction exception and see if it is AVX-512 then move the thread.

Having actually worked on this, it’s quite a bit more complicated, although it is possible. For better or for worse, though, Intel made a decision that all cores would expose the same feature set, and now this is baked into Linux and probably other OSes at the ABI level, and changing it would be a mess.

A correct heterogeneous ABI (and frankly a good AVX512 ABI at all) would require explicit opt-in, per process, for AVX512. Opting in would change the signal frame format, the available features, and the set of allowed cores.

Re: Intel completely disables AVX-512 on Alder Lake after all

#136

Post by josephcsible »

qayxc wrote: post #18

Much ado about nothing, IMHO. AVX-512 isn't advertised by Intel as a 12th gen desktop CPU feature and doesn't provide any advantages for most desktop users anyway. Sure, there's niche applications like some particular PS3 emulator, but I don't share the author's opinion w.r.t. to performance and efficiency in desktop use.

I wouldn't say that Intel taking away a working, if niche, feature from their hardware retroactively after users bought it is "nothing".

Re: Intel completely disables AVX-512 on Alder Lake after all

#137

Post by salawat »

Fnoord wrote: post #111
fsflover wrote: post #69

Earlier quoted context omitted.

> AMD Ryzen Framework laptop would be amazing Except you cannot disable AMD PSP.

Lets compare it to all the other options, shall we? Perfect is the enemy of good, and your uncompromising way of doing things (including not loading microcode 'because it is closed source') is, to put it simple: harmful. And unusual, as well (its not a dealbreaker for many people). The laptop is modular and repairable, just like a Fairphone is modular and repairable. Its a great step forward and, while not perfect an…

...I'm more curious why firmware is even closed source. Seems to me, just releasing the assembler, documentation and a datasheet should be basic courtesy.

Then again everything I think that way about is apparently a mortal sin in the business world.

Re: Intel completely disables AVX-512 on Alder Lake after all

#138

Post by josephcsible »

gambiting wrote: post #7
christkv wrote: post #2

Is this not the definition of bait and switch? How can this not end up in a lawsuit and investigation from regulatory bodies ?

It was never advertised, and Intel very specifically said AVX-512 instructions will not be available. Some motherboard manufacturers made them available anyway, now Intel is fixing that. It's like buying a car with an advertised speed limiter of 155mph, then finding that actually it can go 170mph, and then the manufacturer fixes the speed limiter with a software update. Yes we know the car could go faster, but the sp…

This has nothing to do with advertisement. You should not be able to retroactively make products that you've already sold to people be less useful, whether or not the feature you're clawing back was advertised.

Re: Intel completely disables AVX-512 on Alder Lake after all

#139

Post by avx512 »

alkonaut wrote: post #60

Do both E and P cores handle avx instructions or are some instructions specific to p-cores? In that case, how does a processor with heterogeneous cores deal with processes (or, how does the OS/driver do it in automatic mode when affinity isn’t guided)?

The elephant in the room is the classic CPU architecture mistake where you use two different instruction sets on your performance and efficiency cores. There is no way to prevent code with AVX-512 instructions from being executed on an unsupported core. This exact same problem that plagued early ARM big.LITTLE designs that used ARMv8.2 on the performance core but ARM8.0 on the efficiency core, forcing all code to use the more restrictive instruction set and cripple the performance benefits of the “big” cores.

Re: Intel completely disables AVX-512 on Alder Lake after all

#140

Post by qayxc »

marcan_42 wrote: post #28
qayxc wrote: post #23

Earlier quoted context omitted.

Depending on the OS, microcode updates are under full user control. You can apply them or don't at your own discretion. The problem is knowing which particular update includes the change.

You can only upgrade microcode on any given boot, not downgrade it. Therefore, if the BIOS has already upgraded your microcode for you on boot, you can't undo that from the OS.

I misread that there, so disregard the first reply.

Point still stands: no one forces you to upgrade your BIOS (unless there's problems) and even then, patching the BIOS upgrade itself is still an option.

So it remains under user control.

Post reply on HN