Live data from Hacker News

Intel completely disables AVX-512 on Alder Lake after all

igorslab.de

261–270 of 317 posts

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

#261

Earlier quoted context omitted.

ECC memory on the other hand is always going to be more expensive.

Indeed, which is why it should be an option. OTOH, it shouldn't be significantly more expensive. It should be ~9/8 the cost of regular memory. It's just one extra chip for every 8. Nothing more.

Actually less, because you only need the additional memory chip and associated trace layouting, not any additional PCB manufacturing cost (beyond miniscule yield impact of the additional traces) and no significant added distribution cost (packaging, shipping weight, etc.).

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

#262
post #250

The AVX-512 rollout has been a complete disaster. Look at how quickly AVX-2 became widespread and targetable. My all metrics, AVX-512 adoption has been abysmal and most of the blame lies squarely on Intel's shoulders. And even now that platforms are beginning to support it, developers just aren't interested because AVX-2 + optimizations got them most of the way there. Then there's the heavy performance hit that regul…

That performance hit doesn't necessarily exist on a given workload, because the hysteria over downclocking was mainly with the very early desktop implementations of AVX-512. You'd have to measure it and see nowadays (and consider that the downclocking may be simply due to yourself actually using all the execution units at once)

Whether the hit is there or not is besides the point so long as it's perceived to be there by a not insignificant portion of the developers that might otherwise chase after an AVX-512 implementation.

(Citation needed for my initial claim that the perception of the performance hit exists within that population.)

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

#263
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…

> 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. Wouldn't it be entirely up to the OS to decide on what core(s) a thread will run?

Theoretically, the E core can raise a #UD (undefined instruction) exception that the OS would trap (which already happens if the CPU doesn’t have AVX-512). The OS could then detect that the offending instruction is from the AVX-512 set, and move it to a P core. It could even set a flag on the thread to force it to use P cores.

Intel even touted the work they did with Microsoft about the scheduler to deal with selecting which E or P core to use.

I’m not sure why they chose to disable AVX-512 instead of doing that. Maybe that is their end goal, but it’s too much effort to have it done by release.

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

#264
post #224

Earlier quoted context omitted.

I could absolutely make a good use of AVX-512 for a lot of applications, including consumer space. It's even better than AVX2 when it comes to flexibility, and of course, it's double width. Of course because of lower clock speed and the associated penalties limit it a bit. But you can work around those limitations, for example perhaps by dynamically switching between AVX2 and AVX-512 paths depending on workload.

Thing is, you probably wouldn't use most of the AVX-512 instructions even provided. Some of them are ridiculously niche to the point I'd be really curious how anyone has actually used them.

Like which?

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

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

Don't forget the Intel Payola scheme: https://www.theatlantic.com/technology/archive/2010/07/dells...

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

#266

Earlier quoted context omitted.

> You’re blaming Intel’s CPU lineup for people not using ECC RAM on their AMD builds? I'm blaming the decade+ of Intel dominance for killing any chance of ECC becoming popular in non-server environments, just as RAM density was reaching the point where it is absolutely essential for reliability. > The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC require…

> I'm blaming the decade+ of Intel dominance for killing any chance of ECC becoming popular in non-server environments I disagree. AMD has offered ECC support for a while and it’s not catching on. It doesn’t make sense to blame this on Intel. > Motherboard traces are ~free and the feature is in the die already, so it requires zero expense to offer it to consumers. Yet it’s missing from a substantial number of AMD boa…

> I disagree. AMD has offered ECC support for a while and it’s not catching on. It doesn’t make sense to blame this on Intel.

It does make sense. Imagine if only 50% of web browsers supported a feature, would you implement it in your website?

Point being, the low market share of ECC-compatible setups means that the market demand for ECC is low, which means that the selection is low, which means the prices are higher than they could be. So yes, absolutely Intel has contributed massively to the issue.

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

#267

Earlier quoted context omitted.

> Traces aren’t entirely free. Modern boards are densely packed and manufacturers aren’t interested in spending extra time on routing for a feature that consumers aren’t interested in anyway. Or they just don't care because it's not already popular and unbuffered ECC RAM isn't even particularly widely available. The delta design cost of routing another 8 data lines per DIMM channel is tiny. Especially on ATX boards a…

> ...unbuffered ECC RAM isn't even particularly widely available. Every time I've gone looking for unbuffered ECC RAM over the past three or five years, I've had no trouble finding it. In my experience, the trick is to shop for "server" RAM, rather than "desktop" RAM. Are there speeds or capacities here that you'd particularly like to see that aren't present? https://nemixram.com/server-memory/ecc-udimm/ >

It's available, but not nearly as widely, and even less so at reasonable prices. Last time I had to buy ECC RAM over here in Japan, I had to go to a niche webshop to get a decent price on the capacity I was interested in. For every other PC part I'd just use Amazon and get it delivered next day, usually at the market lowest price or almost.

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

#268
post #217

Earlier quoted context omitted.

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…

It's worth saying that in my life as and academic, the only program I've ever used that has commonly benefited from avx-512 in my work is Gromacs. Gromacs is a molecular dynamics program that creates beautifully graphical simulations and often appears as-is in benchmarks (the so-called ns-per-day metric). Although almost indescribably complex it's also fundamentally strangely straightforward in what it does, and avx-512 does indeed make it significantly faster.

The overwhelming bulk of my research does not use Gromacs, however. Mkl, matrix algebra and similar hybrid MPI tasks, yes, but oddly there the extensions really don't seem to do much, and frankly the inferior memory architecture of the Xeon platinum nodes we use makes itself apparent. I frequently get annoyed that Intel charge you a fortune for CPUs into which you can put a ton of ram, and then marketing makes the CPU's exclusive feature an instruction that doesn't seem to help that much in my actual workloads.

They really should just shunt it to some specialised product and use the die space for something else. I'm with Linus here.

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

#270
post #29
post #22

I’m not surprised. A lot of people were burned last year when their entire CPU downclocked as soon as one application started using AVX-512. That killed all interest even before Alder Lake. Also see Linus’s rants in this thread: https://www.realworldtech.com/forum/?threadid=193189&curpost... And the discussion: https://news.ycombinator.com/item?id=23809335 Today only benchmarks and HPC workloads use AVX-512. I’m sure…

> Today, only benchmarks and HPC workloads make use of it. From what I've heard, there's also a PS3 emulator that benefits greatly from it and its users are quite annoyed by this [0]. According to the sources, users would need to disable E-cores and preferably HT as well to get the best results, though. Pretty niche and not helpful in general (since disabling up to 50% of the cores/threads doesn't seem great for othe…

> According to the sources, users would need to disable E-cores

I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow heterogeneous CPU features within a single machine.

For example, let's assume two CPU feature sets, E and P. E is a proper subset of P. Further, an E core will issue an "illegal instruction" exception when it encounters an instruction that is undefined on E and _may be_ defined on P.

Now the OS becomes free to do what it needs to do: Run a program on whatever core, E or P; but if it gets an "illegal instruction" on an E core, check the instruction; if it would be valid on the P core, mark the program (or thread or whatever) as runnable on P-cores only.

It wouldn't all work optimally on day one, but it's hardly clear that it's impossible to make it workable. There are other 'niceties' you'd want, such as the ability for applications to query the 'biggest set' and 'smallest set' of CPU feature flags.

Would it be worth the work? I'd have to classify that an open question.

Post reply on HN