from Hacker News

Intel's “Cripple AMD” Function (2019)

by phab on 4/6/22, 5:27 PM with 109 comments

• by phkahler on 4/6/22, 7:30 PM

  Worth noting that Intel has dropped their "old" compiler and the newer "Intel" compilers are LLVM based. IMHO they will likely be pulling similar anti-AMD tricks with it and they are keeping their paid version closed source - which is allowed by LLVMs license.

  RMS was right that compilers should be GPL licensed to prevent exactly this kind of thing (and worse things which are haven't happened yet).

  On another compiler related note, I find it insane that GCC had not turned on vectorization at optimization -O2 for the x68-64 targets. The baseline for that arch has SSE2, so vectorization has always made sense there. The upcoming GCC 12 will have it enabled at -O2. I'd bet the Intel compiler always did vectorization at -O2 for their 64bit builds.

• by JoshTriplett on 4/6/22, 8:12 PM

  If Intel had shipped a library/compiler that did just use feature flags and didn't check the CPU vendor, and the resulting code used features that on AMD ran much more slowly than the equivalent unoptimized code, would people blame AMD for the slow instructions, or blame Intel for releasing a library/compiler that they didn't optimize for their competitor's processor?

  This isn't a hypothetical; quoting https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... :

  > AMD processors before Zen 3[11] that implement PDEP and PEXT do so in microcode, with a latency of 18 cycles rather than a single cycle. As a result it is often faster to use other instructions on these processors.

  There's no feature flag for "technically supported, but slow, don't use it"; you have to check the CPU model for that.

  All that said, the right fix here would have been to release this as Open Source, and then people could contribute optimizations for many different processors. But that would have required a decision to rely on winning in hardware quality, rather than sometimes squeezing out a "win" via software even in generations where the hardware quality isn't as good as the competition.

• by dang on 4/6/22, 9:14 PM

  Related:

  Intel's “cripple AMD” function (2019) - https://news.ycombinator.com/item?id=24307596 - Aug 2020 (104 comments)

  Intel's “Cripple AMD” Function - https://news.ycombinator.com/item?id=21709884 - Dec 2019 (10 comments)

  Intel's "cripple AMD" function (2009) - https://news.ycombinator.com/item?id=7091064 - Jan 2014 (124 comments)

  Intel's "cripple AMD" function - https://news.ycombinator.com/item?id=1028795 - Jan 2010 (80 comments)

• by Certified on 4/6/22, 6:23 PM

  Last time this came up on Hacker News I discovered SolidWorks 2021 was using an older MKL library that supports the MKL_DEBUG_CPU_TYPE=5 environment variable. I'm on an AMD cpu and measured a small solidworks fps and rebuild time improvement with the flag enabled

• by mhh__ on 4/6/22, 6:56 PM

  This could arguably dated 2009 as that is when it was originally discovered (approx.). https://www.agner.org/optimize/blog/read.php?i=49

• by holdenk on 4/6/22, 5:49 PM

  Huh I had wondered why I saw so many Python packages blacklist MKL now I know why.

• by midjji on 4/6/22, 7:29 PM

  So blacklist intel compiler in favor or GCC and CLANG, seems entirely reasonable!

• by bee_rider on 4/6/22, 7:44 PM

  Has anyone tried a recent version of MKL on AMD? I assume they were shunting AMD off into an AVX codepath because pre-Zen AMD lacked AVX2 (well, Excavator had I guess...).

  If they are sending Zen down the generic AVX2 codepaths by default and those are competitive with, say, openBLAS, that seems reasonable, right?

  Hopefully BLIS will save us all from this kind of confusion eventually.

• by penguin_booze on 4/6/22, 8:09 PM

  This sounds to me very much like VW cheat devices: detect the current situation, and "act accordingly".

• by Kon-Peki on 4/6/22, 6:08 PM

  This has been discussed on HN before.

  I don't condone Intel behavior, but let's be honest here: AMD underinvests in software and expects others to pick up the slack. That isn't acceptable.

• by mechanical_bear on 4/6/22, 6:18 PM

  So it appears not only is this posting from 2019, but the most recent information they reference is 2010. This seems to be no longer relevant? I’d love it if submissions on HN had a small blurb from the author explaining why their submission is interesting/relevant.

• by marginalia_nu on 4/6/22, 7:39 PM

  I'm getting flashbacks to the AARD code and Microsoft's attempts to sabotage DR-DOS.

• by snvzz on 4/6/22, 10:15 PM

  RISC is less amenable to this category of BS.

  Looking forward to RISC-V pushing x86 into retrocomputing territory.

• by DSingularity on 4/7/22, 2:41 AM

  > After Intel had flatly denied to change their CPU dispatcher, I decided that the most efficient way to make them change their minds was to create publicity about the problem. I contacted several IT magazines, but nobody wanted to write about it. Sad, but not very surprising, considering that they all depend on advertising money from Intel.

  Sorry to go on this tangent: but is capitalism so rotten that everything eventually corrupts? Here even outlets for discussion on topics of science and technology self-censure to maximize profit. So much for freedom of speech.

  Where is truth these days?