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

31–40 of 317 posts

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

#31

Post by pantalaimon »

zinekeller wrote: post #19
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…

I'll be honest, this looks to be a simple mistake. Cutting AVX-512 literally (meaning in hardware) requires actual staff doing that cut plus it'll increase turnaround times, plus the efficiency cores don't have it. Unlike "let's bin perfectly functional processors into a lower-cored product", this is economically not logical for Intel, which often is the closest from the truth.

Then why not leave it as an option for people who want to experiment with the feature?

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

#33

Post by flatiron »

Fnoord wrote: post #20
SkeuomorphicBee wrote: post #10

Stuff like this is why I plan to never buy Intel ever again. I always disliked Intel's strategy for market segmentation by disabling specific instructions, I much prefer AMD's strategy of segmenting just by speed and number of cores. It is really annoying that with Intel you can't run the same program on the server and on your desktop, it makes development and testing a huge pain.

Nvidia do the same with disabling passthrough on consumer GPUs (gotta upsell Quatro). However I would say avoiding Intel completely is unnecessary. They're a good FOSS citizen when it boils to things like WLAN and GPU. Its just that with AMD, you can hardly go wrong on CPU and GPU side. Especially on Linux.

I’m waiting for amd to do TB4 so I can get a ryzen framework laptop.

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

#34

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.

The BIOS doesn't upgrade microcode - the OS does.

During boot there's usually no network connectivity, so how would the BIOS even know of an update, let alone acquire it?

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

#35

Post by adrian_b »

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…

Intel very specifically said that AVX-512 instructions will not be available only a few weeks before the Alder Lake launch.

While it cannot be said that Intel advertised AVX-512 for Alder Lake, at all previous disclosures it was said that the Golden Cove cores have AVX-512 and the Gracemont cores do not have it.

It was clearly said that in hybrid configurations AVX-512 will be disabled, because for Microsoft it is a too difficult task to implement scheduling on a system with heterogeneous cores.

Whether AVX-512 can be enabled by disabling the Gracemont cores was not said, but everybody interpreted that saying nothing about this means that it will be possible to enable AVX-512, because Alder Lake is a replacement for Rocket Lake and Tiger Lake, both of which have AVX-512.

This is one of a very few cases, if not the only case, when Intel replaced a CPU product without preserving backward software compatibility.

If this was their intention from the beginning, then they certainly should have said it much earlier, not just immediately prior to launch.

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

#36

Post by gambiting »

jacquesm wrote: post #27
gambiting wrote: post #17

Earlier quoted context omitted.

Bringing a product in line with specification is very much fixing it. Even if the fix happens to be disabling something.

Yes, but once it has shipped and people may have come to depend on it it will break stuff, not fix stuff. Besides the obvious benefit of first having benchmarks out there claiming these chips are better than they really are. So this change just benefits Intel, and nobody else. If it would be a fix then it would be that something that was advertised did not work, and now it does.

>>Yes, but once it has shipped and people may have come to depend on it it will break stuff, not fix stuff.

If people depend on functionality that is explicitly unsupported then I don't know what to say other than that I don't see how that's Intel's responsibility. If you buy a CPU that doesn't support AVX-512 instructions in order to use AVX-512 instructions then ...I think you're the one who is wrong here.

To go back to my car analogy - if you buy a car that isn't type approved for towing, and yet you install a tow bar anyway, you can't complain to the manufacturer if stuff breaks.

>>Besides the obvious benefit of first having benchmarks out there claiming these chips are better than they really are

Are any of the published benchmarks using AVX-512 instructions that were used by Intel in advertising, and were those in fact available at the time when the benchmarks were ran?

>>If it would be a fix then it would be that something that was advertised did not work, and now it does

Those CPUs were not compliant with their own published spec, now they are - it is absolutely a fix.

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

#37

Post by zinekeller »

pantalaimon wrote: post #31
zinekeller wrote: post #19

Earlier quoted context omitted.

I'll be honest, this looks to be a simple mistake. Cutting AVX-512 literally (meaning in hardware) requires actual staff doing that cut plus it'll increase turnaround times, plus the efficiency cores don't have it. Unlike "let's bin perfectly functional processors into a lower-cored product", this is economically not logical for Intel, which often is the closest from the truth.

Then why not leave it as an option for people who want to experiment with the feature?

Fair point, but again most Windows programs aren't designed with heterogeneous CPUs in mind, so probably they don't want to deal with the headaches, plus the space used for AVX-512 (note that it's now in microcode) can be repurposed for more important tasks.

Of course, this could be evil Intel playing its tricks again but financially speaking removing AVX-512 do have tangible benefits to them in the form of increased microcode for the rest of the instructions (I want to see the detailed Alder Lake errata, maybe there's indeed a bug in another instruction that requires more microcode to implement - AVX-512 is an easy sacrifice for that).

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

#38

Post by marcan_42 »

SkeuomorphicBee wrote: post #10

Stuff like this is why I plan to never buy Intel ever again. I always disliked Intel's strategy for market segmentation by disabling specific instructions, I much prefer AMD's strategy of segmenting just by speed and number of cores. It is really annoying that with Intel you can't run the same program on the server and on your desktop, it makes development and testing a huge pain.

Don't forget it's not just instruction sets; Intel is the reason we don't have ECC RAM on desktops. Every other high density storage technology has used error correction for a decade or two, but we're still sitting here pretending we can have 512 billion bits of perfect memory sitting around that will never go wrong, because Intel fuse it off on desktop chips. I guess only servers need to be reliable.

AMD supports ECC on their consumer chips, but without Intel support it's never taken off and some motherboards don't support it, or if they do it's not clear in the documentation. I do use ECC RAM on my Threadripper machine and it does work, but I had to look for third party info on whether it would and dig around DMI and EDAC info to convince myself it was really on. It also makes it safer to overclock RAM since you get warnings when you're pushing things too far, before outright failures. And it helps with Rowhammer mitigation.

Apple M1s don't do ECC in the memory controller as far as I can tell, but at least they have a good excuse: you can't sensibly do ECC with 16-bit LPDDR RAM channels. There's no such excuse for 64/72-bit DIMM modules. I do hope we work out a way to make ECC available on mobile/LPDDR architectures in the future, though. Probably with something like in-RAM-die ECC (which for all I know might already be a thing on M1s; we don't have all the details).

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

#39

Post by qayxc »

pantalaimon wrote: post #31
zinekeller wrote: post #19

Earlier quoted context omitted.

I'll be honest, this looks to be a simple mistake. Cutting AVX-512 literally (meaning in hardware) requires actual staff doing that cut plus it'll increase turnaround times, plus the efficiency cores don't have it. Unlike "let's bin perfectly functional processors into a lower-cored product", this is economically not logical for Intel, which often is the closest from the truth.

Then why not leave it as an option for people who want to experiment with the feature?

One word: support.

Once you advertise a feature, you have to support it. It'd be pretty damn hard for Intel to explain why lower tier i5 and i3 CPUs have a feature that higher tier i7 and i9 SKUs are missing unless you jump through hoops via hardware (e.g. disable E-cores) or software (e.g. making sure to only run your process on P-cores).

If you want to experiment with AVX-512, just get an older CPU. Much less hassle for both Intel and their customers in this particular case.

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

#40

Post by Croftengea »

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…

> just long enough to win the critical initial wave of reviews and benchmarks.

Is the average set of tests by, say, LTT or THG influenced by presence of these instructions? (not being snarky, I really don't know).

Post reply on HN