5 ms·

> but I agree with the author that the solution for most software should be to ship separate AVX-enabled and non-AVX-enabled binaries I don't think this scales

> but I agree with the author that the solution for most software should be to ship separate AVX-enabled and non-AVX-enabled binaries I don't think this scales. I work on text search, and there are distinct algorithms that use at most SSSE3, some use at most SSE 4.2 and some use at most AVX2. Should I then ship 4 different versions for every platform I support? What are my instructions to users on the download page?

Arnavion 10y ago
>Should I then ship 4 different versions for every platform I support? It's worse than what you have now, of course, but the situation is not new with AVX. >What are my instructions to users on the download page? If the differentiation is at the DLL level (SSE3 implementations in their own DLL, SSE4 implementations in their own DLL, all providing a common interface), your application would load the corresponding one at runtime based on feature detection and your user never notices. If the entire binary / program package needs to be differentiated (say ripgrep where there's only one statically linked binary to speak of), your Windows installer picks the right binary to install, and you have multiple Linux packages and a metadata package that depends on them and picks the one with the matching architecture. The former is definitely done, and I believe I've seen instances of the latter in my package manager's listings.
- burntsushi 10y ago
  But I don't think you actually need to do that. You can compile individual functions with different target specific optimizations using (e.g.) LLVM's target_feature attribute. Both gcc and clang expose this type of functionality. As DannyBee mentions in the sibling, this issue is compounded in AVX512. You really need to support runtime detection, and doing that means including multiple versions of the same function in the same binary. It looks like one is at the mercy of your compiler for how well this works, but it seems like gcc/clang do this just fine?
  - Arnavion 10y ago
    >Both gcc and clang expose this type of functionality. Sure, I didn't say that it was impossible in general. The context of my comments was that MSVC doesn't appear to support automatic target-architecture-based dispatch and thus requires such workarounds.
    - burntsushi 10y ago
      Ah! Gotya. Understood. Sorry for the mixup!
DannyBee 10y ago
It's infinitely worse with AVX512, where there are cpu's that support bits and pieces.
mcbain 10y ago
FWIW, frustratingly MSVC has no compiler options for generating SSE3/SSSE3 or SSE4.x code - you can get them from intrinsics, but the compiler flags are SSE/SSE2 (on ia32) and AVX/AVX2 only. https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

Arnavion 10y ago

>Should I then ship 4 different versions for every platform I support? It's worse than what you have now, of course, but the situation is not new with AVX. >What are my instructions to users on the download page? If the differentiation is at the DLL level (SSE3 implementations in their own DLL, SSE4 implementations in their own DLL, all providing a common interface), your application would load the corresponding one at runtime based on feature detection and your user never notices. If the entire binary / program package needs to be differentiated (say ripgrep where there's only one statically linked binary to speak of), your Windows installer picks the right binary to install, and you have multiple Linux packages and a metadata package that depends on them and picks the one with the matching architecture. The former is definitely done, and I believe I've seen instances of the latter in my package manager's listings.

burntsushi 10y ago
But I don't think you actually need to do that. You can compile individual functions with different target specific optimizations using (e.g.) LLVM's target_feature attribute. Both gcc and clang expose this type of functionality. As DannyBee mentions in the sibling, this issue is compounded in AVX512. You really need to support runtime detection, and doing that means including multiple versions of the same function in the same binary. It looks like one is at the mercy of your compiler for how well this works, but it seems like gcc/clang do this just fine?
- Arnavion 10y ago
  >Both gcc and clang expose this type of functionality. Sure, I didn't say that it was impossible in general. The context of my comments was that MSVC doesn't appear to support automatic target-architecture-based dispatch and thus requires such workarounds.
  - burntsushi 10y ago
    Ah! Gotya. Understood. Sorry for the mixup!

DannyBee 10y ago

It's infinitely worse with AVX512, where there are cpu's that support bits and pieces.

mcbain 10y ago

FWIW, frustratingly MSVC has no compiler options for generating SSE3/SSSE3 or SSE4.x code - you can get them from intrinsics, but the compiler flags are SSE/SSE2 (on ia32) and AVX/AVX2 only. https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx