Intel completely disables AVX-512 on Alder Lake after all • Hacker News Board

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

#211

Post by salawat » Fri, Jan 07, 2022, 5:56 PM UTC

loup-vaillant wrote: post #151

salawat wrote: post #137

Earlier quoted context omitted.

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

I hear hardware vendors are scared shitless of running awful of other hardware vendor's patents. If they released their firmware, this would give other folks ammunitions to attack them in court. Personally, I don't care much about firmware being proprietary, if it cannot be used to meaningfully change the functionality of the chip . But I do care about the chip ultimately following a public specification. I want an I…

Unfortunately, from my understanding, hardware innovation seems to be on a trajectory whereby it is exactly going toward the case that most functionality is "soft" and thereby fundamental changes can be wrought through microcode. Just look at Nvidia's use of FALCON's. Hardware manufacturers seemingly WANT to be able to use the same piece of hardware for different jobs, and having blobs tooled to reconfigure it is the way to go.

My biggest problem is that figuring this state of affairs out is like pulling teeth.

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

#212

Post by mhh__ » Fri, Jan 07, 2022, 6:08 PM UTC

xondono wrote: post #153

mhh__ wrote: post #125

Earlier quoted context omitted.

Pretty crap reasoning then. Intel never ever marketed these as having AVX-512 and unless you are running a Xeon from 2012 like the paper you've linked a modern CPU (note, any desktop class CPU) will only be vulnerable to some bits of Spectre and not meltdow

My 7700K (2017) got a similar downgrade in performance from the mitigations. Switched to AMD for the first time in my life, no regrets so far.

Meltdown hadn't been (publicly) found until 2018 so the same applies. Intel's current offerings are extremely competitive with AMD on many workloads.

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

#213

Post by seba_dos1 » Fri, Jan 07, 2022, 6:09 PM UTC

marcan_42 wrote: post #209

fsflover wrote: post #205

Earlier quoted context omitted.

You are of course right that technically it has the access to the RAM. > Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs. I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise. > even though the blob ends up running on the same CPU with the same p…

> I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise. It absolutely wasn't. Look into it. In every case, the blob ends up running on the RAM controller CPU and supposedly finishes running and is done. The whole point of the exercise was obfuscating the process which is used to get to that point such that it avoided the main CPU physically moving the bits of t…

> great, now they either don't know how their own phone

Who's "they"? This is an unofficial community wiki.

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

#214

Post by protastus » Fri, Jan 07, 2022, 6:09 PM UTC

jacquesm wrote: post #13

gambiting wrote: post #7

Earlier quoted context omitted.

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…

> now Intel is fixing that That's not a fix. That's a disabling. A fix repairs something.

If AVX-512 was not in scope yet left turned on, parts may operate outside design limits, there's system-level validation that may not have been run, and specs that are at risk. Think about the scale of all PC OEMs that use these CPUs, rather than a specific product.

For example, it's known that AVX-512 is power hungry and significantly increases TDP (heat). Do all Alder Lake based products have the thermal headroom? If CPUs operate outside of the envelope communicated by Intel, they may not be entirely stable, and parts could fail earlier than expected.

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

#215

Post by temac » Fri, Jan 07, 2022, 6:14 PM UTC

PragmaticPulp wrote: post #67

marcan_42 wrote: post #38

Earlier quoted context omitted.

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 EC…

> Intel is the reason we don't have ECC RAM on desktops. Intel has offered ECC support in a lot of their low-end i3 parts for a long time. They’re popular for budget server builds for this reason. The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC requires more chips, more traces, and more expense. Consumers can’t tell if there’s a benefit, so they skip i…

They did support ECC on some i3 simply because they did not bother to double the sku, however IIRC you need the server / WS S chipset to enable it. At which point just put an entry level Xeon on that.

In the absolute the cost of ECC everywhere would not be substantially greater than the prices we have now without. The current ECC prices are high because it is not broadly used, and not really the inverse. Consumer skip it because it is fucking hard to get ECC enable parts for S SKUs (or H / U) in the current situation, while there are plenty of non-ECC vendors and resellers, and something like at least 3 times the number of SKUs. And consumers have not been informed they are buying unreliable shit.

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

#216

Post by slibhb » Fri, Jan 07, 2022, 6:23 PM UTC

jacquesm wrote: post #182

im3w1l wrote: post #132

Earlier quoted context omitted.

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

Let's see: Intel - ME https://news.ycombinator.com/item?id=21534199 - Anti Trust: https://www.networkworld.com/article/2239461/intel-and-antit... - The cripple AMD function in their compiler: https://www.agner.org/optimize/blog/read.php?i=49 I could keep this up quite a bit longer if you want. Intel well deserves any skepticism and cynicism it is targeted with.

> I could keep this up quite a bit longer if you want. Intel well deserves any skepticism and cynicism it is targeted with.

Intel deserves skepticism and cynicism based on what is true.

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

#217

Post by amluto » Fri, Jan 07, 2022, 6:24 PM UTC

tmccrary55 wrote: post #149

amluto wrote: post #135

Earlier quoted context omitted.

> 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 deci…

Boost your benchmarks with AVX-512 by subscribing to Intel+

What benchmarks? Not a lot of real programs actually use AVX512, and a lot of the ones that did discovered that it made performance worse, so they stopped.

(The issue is that AVX512 (the actual 512-bit parts, not the associated EVEX and masking extensions) may well be excellent for long-running vector-math-heavy usage, but the cost of switching AVX512 on and off is extreme, and using it for things like memcpy() and strcmp() is pretty much always a loss except in silly microbenchmarks.)

To be clear, I don't like the type of product line differentiation that Intel does, and I think Intel should have supported proper heterogenous ISA systems so that AVX512 and related technologies on client systems would make sense, but I don't think any of this is nefarious.

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

#218

Post by temac » Fri, Jan 07, 2022, 6:24 PM UTC

jeffbee wrote: post #175

formerly_proven wrote: post #98

Earlier quoted context omitted.

> Intel has offered ECC support in a lot of their low-end i3 parts for a long time. They’re popular for budget server builds for this reason. Intel removed ECC support in the 10th gen so you have to go for Xeon nowadays.

With DDR5 you can have (a form of) ECC on all current 12th-generation Core CPUs. That is, if you were able to find DDR5 DIMMs on the market, which you currently cannot.

Not really: internal ECC in DDR5 is an implementation detail that is neither exposed on the bus nor giving you the real reliability and monitoring capability that real ECC terminated in the memory controller did. It is only there because the error rate would be absolutely horrific without, so you need internal ECC to get to basically the same point you were without ECC on DDR4.

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

#219

Post by csdvrx » Fri, Jan 07, 2022, 6:32 PM UTC

marcan_42 wrote: post #107

nullify88 wrote: post #59

Earlier quoted context omitted.

I wouldnt call it hacking. If you can find or backup the bios image for your motherboard, you can replace the microcode in it and reflash. Bios images are modular and the microcode is a replacable component.

Hacking BIOS images isn't always that easy. Often they are signed (EFI Capsules) and the standard update utility in the BIOS menu will reject modified versions. I had to use a convoluted flashing process to make a trivial patch to a BIOS a few years back for this reason.

You mean, SOIC clip + flashrom?

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

#220

Post by kergonath » Fri, Jan 07, 2022, 6:48 PM UTC

formerly_proven wrote: post #73

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'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…

> 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-512 is rarely used.

Even in the nuke simulations it is rarely used. More recent cores might be better, but the frequency drop and the associated latency kill performances on the clusters I know. And the new generation ones are AMD anyway.