241–250 of 317 posts
I absolutely destest FP benchmarks, and I realize other people care deeply. I just think AVX512 is exactly the wrong thing to do. It’s a pet peeve of mine. It’s a prime example of something Intel has done wrong, partly by just increasing the fragmentation of the market." Linus T
Earlier quoted context omitted.
DDR5 is a form of ECC and DDR5 is only supported on Intel so far.
The DDR5 memory bus used by Intel's latest consumer processors does not have ECC enabled. The memory dies themselves have some internal ECC that is not exposed to the host system and is not related to the fact that they use a DDR5 interface; all state of the art DRAM now needs on-die ECC due to the high density.
Earlier quoted context omitted.
There's significant downclocking only on on Skylake-X (aka: 1st generation teething problems). On more recent cores, there's only ~100 MHz of downclocking, which is so small you can pretty much ignore it.
It's amazing how sticky the myth has become, though. On Ice Lake Xeon there is basically no penalty for using the AVX-512 unit.
If Intel was able to get Icelake out on time, it may have reduced the "stickiness" of the myth.
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…
- Let's thread this thing.
- OMG things are working N times faster (where N=cpus)
- 1 year later, shit... In 0.1% of the cases there is race condition and we can't figure it out, random garbage to our data...
- 1 week later rolled back to single thread and now everyone is complaing why things are slow...
- This actually happened... (just not the same time frames)Earlier quoted context omitted.
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 hassl…
They don't support CPUs that were overclocked, yet advertise that feature, so support isn't the reason.
An therein lies the difference. They advertise the feature, which is something they never did for AVX-512 on Alder Lake desktop. If they advertise a feature, they cannot disable it without getting into legal trouble.
If you get K-SKU, you get an unlocked multiplier. That's guaranteed by Intel and that's were their support begins and ends.
They cannot do the same for AVX-512, though, because that's not possible in their heterogeneous architecture. There's currently no desktop OS that supports different CPU cores (as in capabilities) on the same socket (or even board).
Such feature would require kernel drivers, thread schedulers, and possibly compiler toolchains to be modified for at least Linux and Windows and that's the kind of support Intel would need to provide. They did provide a thread scheduler, but to my knowledge that didn't include any AVX-512 related logic.
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…
> 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…
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’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…
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…
> 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…
Wouldn't it be entirely up to the OS to decide on what core(s) a thread will run?
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…