4 ms·

Strong disagree. When writing optimized code you typically check for CPU feature before CPUID, and profile to verify that it actually is faster. In Intel's ca

Strong disagree. When writing optimized code you typically check for CPU feature before CPUID, and profile to verify that it actually is faster. In Intel's case, libraries like MKL/IPP don't decide which implementation to use based on available features but CPUID, and fall back to slow versions even if the CPU supports all features required for the optimization. There's nothing stopping Intel from providing fast libs that are optimized for their hardware, profiled on their systems, and utilize all the secret sauce they want while still being more or less "fast" on AMD. But all that said those libs aren't especially compelling when there are alternatives that may be a bit slower on Intel but kick ass on AMD, when a non-zero segment of users are transitioning to the better value processors today.

toast0 7y ago
> In Intel's case, libraries like MKL/IPP don't decide which implementation to use based on available features but CPUID, and fall back to slow versions even if the CPU supports all features required for the optimization. The CPU features indicates if a feature is available, but doesn't indicate if it's advisable or fast -- that's why Intel built a table for their hardware, and they'd need a table for AMD hardware too, except they don't care, because it's not their hardware. AMD or someone could build that table and patch it in, or try to convince Intel to include it, but expecting Intel to build it themselves is wishful thinking at best.
- endorphone 7y ago
  "and they'd need a table for AMD hardware too, except they don't care" They very much do care, and that is amply evident. Every other compiler uses feature detection or developer intention (e.g. if I say use AVX, use it or crash). Intel actively and intentionally -- with intent -- sabotages performance on AMD devices. This is where the market decides, however, and it's why the intel compilers and libraries are fringe products, and their software division is effectively a disaster. If you have a specific HPC setup with Intel processors maybe you'll cross compile with them, but most simply steer far clear of them. For a while Intel sold them as a software vendor -- not as some sort of coupled processor support -- and many learned they aren't trustworthy.
  - Const-me 7y ago
    > Every other compiler uses feature detection or developer intention ICC has tons of built-in functions like _mm_div_epi32, _mm256_log10_ps, _mm_sin_ps and many others. These are not hardware intrinsics. These are library functions. Other compilers don’t need to feature detect because unlike Intel’s they don’t have these functions in their standard libraries: no exponents/logarithms, no trigonometry, no integer divides, nothing at all on top of the hardware instructions. I mostly use VC++ and I had to implement these functions more than once. Funny enough, AMD’s SSEPlus helped even on Intel, despite AMD abandoned the library a decade ago.
- MertsA 7y ago
  >that's why Intel built a table for their hardware Err... Correct me if I'm wrong, but wasn't the check literally just a string match on "GenuineIntel"?
- sliken 7y ago
  Dunno, just about every compiler on the planet has different settings for different CPUs and often let you hard code what you prefer. I can see MKL not automatically picking the fastest path, but they should allow you to manually pick. In fact they do, this flag lets you pick the AVX2 libs and speed increases up to 6.6x in my tests with matlab. export MKL_DEBUG_CPU_TYPE=5
deleted 7y ago
[deleted]

toast0 7y ago

> In Intel's case, libraries like MKL/IPP don't decide which implementation to use based on available features but CPUID, and fall back to slow versions even if the CPU supports all features required for the optimization. The CPU features indicates if a feature is available, but doesn't indicate if it's advisable or fast -- that's why Intel built a table for their hardware, and they'd need a table for AMD hardware too, except they don't care, because it's not their hardware. AMD or someone could build that table and patch it in, or try to convince Intel to include it, but expecting Intel to build it themselves is wishful thinking at best.

endorphone 7y ago
"and they'd need a table for AMD hardware too, except they don't care" They very much do care, and that is amply evident. Every other compiler uses feature detection or developer intention (e.g. if I say use AVX, use it or crash). Intel actively and intentionally -- with intent -- sabotages performance on AMD devices. This is where the market decides, however, and it's why the intel compilers and libraries are fringe products, and their software division is effectively a disaster. If you have a specific HPC setup with Intel processors maybe you'll cross compile with them, but most simply steer far clear of them. For a while Intel sold them as a software vendor -- not as some sort of coupled processor support -- and many learned they aren't trustworthy.
- Const-me 7y ago
  > Every other compiler uses feature detection or developer intention ICC has tons of built-in functions like _mm_div_epi32, _mm256_log10_ps, _mm_sin_ps and many others. These are not hardware intrinsics. These are library functions. Other compilers don’t need to feature detect because unlike Intel’s they don’t have these functions in their standard libraries: no exponents/logarithms, no trigonometry, no integer divides, nothing at all on top of the hardware instructions. I mostly use VC++ and I had to implement these functions more than once. Funny enough, AMD’s SSEPlus helped even on Intel, despite AMD abandoned the library a decade ago.
MertsA 7y ago
>that's why Intel built a table for their hardware Err... Correct me if I'm wrong, but wasn't the check literally just a string match on "GenuineIntel"?
sliken 7y ago
Dunno, just about every compiler on the planet has different settings for different CPUs and often let you hard code what you prefer. I can see MKL not automatically picking the fastest path, but they should allow you to manually pick. In fact they do, this flag lets you pick the AVX2 libs and speed increases up to 6.6x in my tests with matlab. export MKL_DEBUG_CPU_TYPE=5

deleted 7y ago

[deleted]