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.
Intel completely disables AVX-512 on Alder Lake after all
261–270 of 317 posts
Re: Intel completely disables AVX-512 on Alder Lake after all
#262The 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)
(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
#263Earlier 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?
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
#264Earlier 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.
Re: Intel completely disables AVX-512 on Alder Lake after all
#265Earlier 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.
Re: Intel completely disables AVX-512 on Alder Lake after all
#266Earlier 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…
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
#267Earlier 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/ >
Re: Intel completely disables AVX-512 on Alder Lake after all
#268Earlier 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…
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
#269Re: Intel completely disables AVX-512 on Alder Lake after all
#270I’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…
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.