4 ms·

My understanding is that that flag is gone, as of couple of months ago. Intel “fixed” it.

danieldk 6y ago
Yes, starting with MKL 2020.01 release. The Wikipedia page has more information and references: https://en.wikipedia.org/wiki/Math_Kernel_Library#Performance https://en.wikipedia.org/wiki/Math_Kernel_Library#Performanc... This is quite bad, since a lot of software relies on Intel MKL as the default BLAS implementation (e.g. PyTorch binaries).
rasz 6y ago
Why not patch out the CPUID check as a post compilation step?
- iforgotpassword 6y ago
  Exactly what I was thinking. For libs like MKL it should even be feasible to have a database of known binary releases with a patch offset so you can speed up your scientific application using a little patch tool. But even for executables my guess is that it should be relatively easy to programmatically find the relevant check and patch it, unless Intel starts to deliberately obfuscate it, like copy protection checks in games.
- danieldk 6y ago
  That's definitely possible (it probably checks that the manufacturer ID is GenuineIntel), but nobody wants to distribute patched MKL versions, because it most likely violates the MKL license. It may even be easier to replace the function altogether with LD_PRELOAD.
  - danieldk 6y ago
    Indeed works. A simple trace reveals that the function is called mkl_serv_intel_cpu_true(). Make a file with the following content: int mkl_serv_intel_cpu_true() { return 1; } Compile gcc -shared -o libfake.so fake.c Run LD_PRELOAD=libfake.so yourprogram And it uses the optimized AVX codepaths. Disclaimer: may not be legal in your country. I take no responsibility.
    - ashleyn 6y ago
      Wow. I wasn't quite expecting something as simple as "if CPU is not intel, make everything worse."
      - colejohnson66 6y ago
        I’m sure their justification is that (1) they have no obligation to help AMD, and (2) how could you guarantee AMD implements CPUID the same as Intel (as in: what if AMD implements a feature bit differently?) Of course, the second one makes no sense as x86 programs run just as fine on AMD as Intel with the same feature set (albeit at different speeds)
    - danieldk 6y ago
      By the way, if you want make this permanent in a binary, there is no need to set LD_PRELOAD all the time. You could just add a DT_NEEDED entry to the dynamic section. E.g. something like: patchelf --add-needed libfakeintel.so yourbinary
  - krageon 6y ago
    You distribute a binary patch for a given MKL release, have your package download the official MKL release and then patch it using the binary patch. Nobody suffers, everyone wins.
    - rasz 6y ago
      No need to patch MKL, just your own binaries post compile.

Yes, starting with MKL 2020.01 release. The Wikipedia page has more information and references: https://en.wikipedia.org/wiki/Math_Kernel_Library#Performance https://en.wikipedia.org/wiki/Math_Kernel_Library#Performanc... This is quite bad, since a lot of software relies on Intel MKL as the default BLAS implementation (e.g. PyTorch binaries).

rasz 6y ago

Why not patch out the CPUID check as a post compilation step?

iforgotpassword 6y ago
Exactly what I was thinking. For libs like MKL it should even be feasible to have a database of known binary releases with a patch offset so you can speed up your scientific application using a little patch tool. But even for executables my guess is that it should be relatively easy to programmatically find the relevant check and patch it, unless Intel starts to deliberately obfuscate it, like copy protection checks in games.
danieldk 6y ago
That's definitely possible (it probably checks that the manufacturer ID is GenuineIntel), but nobody wants to distribute patched MKL versions, because it most likely violates the MKL license. It may even be easier to replace the function altogether with LD_PRELOAD.
- danieldk 6y ago
  Indeed works. A simple trace reveals that the function is called mkl_serv_intel_cpu_true(). Make a file with the following content: int mkl_serv_intel_cpu_true() { return 1; } Compile gcc -shared -o libfake.so fake.c Run LD_PRELOAD=libfake.so yourprogram And it uses the optimized AVX codepaths. Disclaimer: may not be legal in your country. I take no responsibility.
  - ashleyn 6y ago
    Wow. I wasn't quite expecting something as simple as "if CPU is not intel, make everything worse."
    - colejohnson66 6y ago
      I’m sure their justification is that (1) they have no obligation to help AMD, and (2) how could you guarantee AMD implements CPUID the same as Intel (as in: what if AMD implements a feature bit differently?) Of course, the second one makes no sense as x86 programs run just as fine on AMD as Intel with the same feature set (albeit at different speeds)
  - danieldk 6y ago
    By the way, if you want make this permanent in a binary, there is no need to set LD_PRELOAD all the time. You could just add a DT_NEEDED entry to the dynamic section. E.g. something like: patchelf --add-needed libfakeintel.so yourbinary
- krageon 6y ago
  You distribute a binary patch for a given MKL release, have your package download the official MKL release and then patch it using the binary patch. Nobody suffers, everyone wins.
  - rasz 6y ago
    No need to patch MKL, just your own binaries post compile.