5 ms·

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for y

> 2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come. That’s not what happened here. 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. None of the benchmarks you saw in reviews or marketing material would have used these instructions unless specifically called out by the reviewers as having made all of these changes. Benchmarks like the multi-core Geekbench would actually go down, not up, with this enabled because you’re giving up cores. Thermal performance would be worse because the efficiency cores were disabled. Intel never marketed the part with AVX-512. It was discovered by a reviewer poking around in the BIOS of a review board. > motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed. Nope. You had to disable cores to enable AVX-512 and I doubt it would show up in any gaming or consumer benchmarks as a positive. The conspiracy theory about Intel doing this to mislead consumers not only doesn’t make sense, it’s completely wrong given how this worked and how it was discovered.

hajile 5y ago
> 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 256-bit AVX channels are the same as eight 512-bit channels in theoretical throughput. Because there are fewer load/store commands and fewer bunches of setup code to run, overall theoretical efficiency should be higher. Power efficiency was a killer at 14nm. The cores would downclock into oblivion when AVX-512 executed. Given the node shrink and shutting off half the cores, I don't see why this would happen here. Doing the same calculations with less power means a lot for the kinds of workloads that actually use AVX-512. Sure, idle performance may go down a bit, but once again, if you're running the kind of application that benefits from this, that's also probably not a top consideration either. 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.
- PragmaticPulp 5y ago
  > If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Maybe if you have a poorly parallelized problem where the bulk of the code is spent in AVX-512 instructions and you don’t ever do anything else on the computer, but that’s going to be rare for any consumer. > 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. “It wouldn’t be hard” is a huge understatement. This is OS-level support, not something Intel can just do inside the CPU. And operating system vendors and developers are still catching up to basic Alder Like scheduler support without AVX-512 handing, so it’s not reasonable to suggest this would be easy.
  - pantalaimon 5y ago
    There have been reports that it was possible to enable AVX512 on the big cores with the little ones enabled [0] by toggling some bits in the MSR. For a first step it would have been enough to manually pin threads to the big cores for adventurous users, but Linux already tacks which threads use AVX (since it comes with a clock penalty, so you want to isolate them if possible), it's not unreasonable to think that auto-setting CPU mask based on that should be possible too. [0] https://lkml.org/lkml/2021/12/2/1059 https://lkml.org/lkml/2021/12/2/1059
  - gnufx 5y ago
    I don't see how "poorly parallelized" is relevant compared with, say, a decent OpenMP BLAS which is likely to benefit from any reduced power consumption that allows a faster clock. In general on compute nodes it's worth turning off cores dynamically which aren't being used by jobs, like on a half-full node.
- amluto 5y ago
  > 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 decision that all cores would expose the same feature set, and now this is baked into Linux and probably other OSes at the ABI level, and changing it would be a mess. A correct heterogeneous ABI (and frankly a good AVX512 ABI at all) would require explicit opt-in, per process, for AVX512. Opting in would change the signal frame format, the available features, and the set of allowed cores.
im3w1l 5y ago
Comparing the facts to all the suspicious people here, it made me realize something. Our zeitgeist sure is a cynical one.
- duxup 5y ago
  Humans seem prone to find meaning and conspiracy amidst chaos and confusing circumstances.
  - steveBK123 5y ago
    There's a saying I like - Humans are deterministic machines in a probabilistic world.
- yjftsjthsd-h 5y ago
  Intel has spent decades accumulating its reputation. Sometimes cynicism is appropriate.
- jacquesm 5y ago
  Let's see: Intel - ME https://news.ycombinator.com/item?id=21534199 https://news.ycombinator.com/item?id=21534199 - Anti Trust: https://www.networkworld.com/article/2239461/intel-and-antitrust--a-brief-history.html 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 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.
  - slibhb 5y ago
    > 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.
  - mhh__ 5y ago
    All companies deserve skepticism, to be clear. AMD have their management engine too. As far as I'm concerned the only reason why AMD's ME isn't as developed as Intel's is because their products have been such a joke leading up to Zen that no one with men in suits bothered asking them for the capabilites, or something like that.

hajile 5y ago

> 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 256-bit AVX channels are the same as eight 512-bit channels in theoretical throughput. Because there are fewer load/store commands and fewer bunches of setup code to run, overall theoretical efficiency should be higher. Power efficiency was a killer at 14nm. The cores would downclock into oblivion when AVX-512 executed. Given the node shrink and shutting off half the cores, I don't see why this would happen here. Doing the same calculations with less power means a lot for the kinds of workloads that actually use AVX-512. Sure, idle performance may go down a bit, but once again, if you're running the kind of application that benefits from this, that's also probably not a top consideration either. 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.

PragmaticPulp 5y ago
> If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Maybe if you have a poorly parallelized problem where the bulk of the code is spent in AVX-512 instructions and you don’t ever do anything else on the computer, but that’s going to be rare for any consumer. > 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. “It wouldn’t be hard” is a huge understatement. This is OS-level support, not something Intel can just do inside the CPU. And operating system vendors and developers are still catching up to basic Alder Like scheduler support without AVX-512 handing, so it’s not reasonable to suggest this would be easy.
- pantalaimon 5y ago
  There have been reports that it was possible to enable AVX512 on the big cores with the little ones enabled [0] by toggling some bits in the MSR. For a first step it would have been enough to manually pin threads to the big cores for adventurous users, but Linux already tacks which threads use AVX (since it comes with a clock penalty, so you want to isolate them if possible), it's not unreasonable to think that auto-setting CPU mask based on that should be possible too. [0] https://lkml.org/lkml/2021/12/2/1059 https://lkml.org/lkml/2021/12/2/1059
- gnufx 5y ago
  I don't see how "poorly parallelized" is relevant compared with, say, a decent OpenMP BLAS which is likely to benefit from any reduced power consumption that allows a faster clock. In general on compute nodes it's worth turning off cores dynamically which aren't being used by jobs, like on a half-full node.
amluto 5y ago
> 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 decision that all cores would expose the same feature set, and now this is baked into Linux and probably other OSes at the ABI level, and changing it would be a mess. A correct heterogeneous ABI (and frankly a good AVX512 ABI at all) would require explicit opt-in, per process, for AVX512. Opting in would change the signal frame format, the available features, and the set of allowed cores.

im3w1l 5y ago

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

duxup 5y ago
Humans seem prone to find meaning and conspiracy amidst chaos and confusing circumstances.
- steveBK123 5y ago
  There's a saying I like - Humans are deterministic machines in a probabilistic world.
yjftsjthsd-h 5y ago
Intel has spent decades accumulating its reputation. Sometimes cynicism is appropriate.
jacquesm 5y ago
Let's see: Intel - ME https://news.ycombinator.com/item?id=21534199 https://news.ycombinator.com/item?id=21534199 - Anti Trust: https://www.networkworld.com/article/2239461/intel-and-antitrust--a-brief-history.html 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 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.
- slibhb 5y ago
  > 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.
- mhh__ 5y ago
  All companies deserve skepticism, to be clear. AMD have their management engine too. As far as I'm concerned the only reason why AMD's ME isn't as developed as Intel's is because their products have been such a joke leading up to Zen that no one with men in suits bothered asking them for the capabilites, or something like that.