5 ms·

I'd like to commend the authors for embarking on this. Complex ISA's are an unfortunate reality for performance as advances in cycles-per-second on a single cor

I'd like to commend the authors for embarking on this. Complex ISA's are an unfortunate reality for performance as advances in cycles-per-second on a single core are negligible. The divergence of these increasingly complex ISA's among platforms weigh heavily on competitive application developers. As someone who is interested in writing cross-platform SIMD code the most valuable asset to me is a library or compiler that can generate the instructions dynamically from otherwise normal'ish looking C/C++. This is the most powerful mode of development in my experience. Clang already does this remarkably. I can write with standard C++ syntax (albeit awkwardly) and maybe using a few custom types with `__attribute__((vector_size(x)))` and not have to involve explicit intrinsics except perhaps for a very small number of leaf operations that cannot be expressed. At this time Clang has the upper-hand on GCC: the latter cannot generate code which scales between platforms utilizing different vector sizes. For example, if you try to perform an operation on a 256-bit vector using a 128-bit target: Clang will seamlessly generate two 128-bit operations; GCC will fall back entirely to scalar. My assumption is that developments in Clang for ARM's SVE have carried over to generating scalable code for other platforms, but nevertheless it is remarkable. I don't believe that writing functions comprised of hand-crafted lists of intrinsics is the best way forward. Undoubtedly it's worked for projects, even quite well to ship stable software -- but it scales and adapts poorly in a fast-developing and diverse market of hardware. For example, years ago I wrote a simple `tolower(string)` implementation using an assemblage of 128-bit standard-Intel SSE2 statements and today the instructions it produces are exactly the same as the day that I wrote it. All I can hope for is that 256-bit capable architectures can execute two of my operations at once. That's not ideal.

throwaway189262 6y ago
If you just need "big" numbers, Rust supports 128 bit int on all platforms using Clangs code generation
- moonchild 6y ago
  No need to reach for rust; just use __(u)int128_t. Works with gcc, too.
nemequ1729 6y ago
> I'd like to commend the authors for embarking on this. As the crazy bastard who started SIMDe, thanks! I'm very concerned about portability, so unfortunately just using clang isn't really an option. Most of my code has to work not only on GCC and clang, but also on MSVC (/me cries) and ICC, and I generally try to make it work on other compilers (PGI, IAR, etc.). In my experience you're right, clang does do much better with vectors that don't match the hardware by default, but in SIMDe we actually have explicit fallbacks which call shorter functions twice and the result is pretty good on both compilers. For example, here is what `_mm256_add_ps` looks like on GCC and clang when targeting SSE2: <https://godbolt.org/z/n68Ecn> https://godbolt.org/z/n68Ecn>. Length-agnostic instruction sets like SVE are definitely very interesting, but honestly I'd rather see them de-emphasize non-portable APIs like SVE and instead work on improving the compiler's ability to recognize the relevant code patterns to work with things like OpenMP SIMD (which, to be clear, does not require the OpenMP runtime). I'd also be happy to see more builtins which work cross-platform… for example, I'd love to see builtins for saturated operations which could easily be auto-vectorized by the compiler when used in an OpenMP SIMD loop. Currently for new SIMD code, I start with an OpenMP SIMD implementation, then profile. If I see any spots which perform particularly poorly and/or are particularly hot, I'll work on some optimized implementations for those spots using intrinsics. In the future I hope to need to hand-optimize less code, but for now I think this offers a pretty good trade-off between portability, performance, and development time.

throwaway189262 6y ago

If you just need "big" numbers, Rust supports 128 bit int on all platforms using Clangs code generation

moonchild 6y ago
No need to reach for rust; just use __(u)int128_t. Works with gcc, too.

nemequ1729 6y ago

> I'd like to commend the authors for embarking on this. As the crazy bastard who started SIMDe, thanks! I'm very concerned about portability, so unfortunately just using clang isn't really an option. Most of my code has to work not only on GCC and clang, but also on MSVC (/me cries) and ICC, and I generally try to make it work on other compilers (PGI, IAR, etc.). In my experience you're right, clang does do much better with vectors that don't match the hardware by default, but in SIMDe we actually have explicit fallbacks which call shorter functions twice and the result is pretty good on both compilers. For example, here is what `_mm256_add_ps` looks like on GCC and clang when targeting SSE2: <https://godbolt.org/z/n68Ecn> https://godbolt.org/z/n68Ecn>. Length-agnostic instruction sets like SVE are definitely very interesting, but honestly I'd rather see them de-emphasize non-portable APIs like SVE and instead work on improving the compiler's ability to recognize the relevant code patterns to work with things like OpenMP SIMD (which, to be clear, does not require the OpenMP runtime). I'd also be happy to see more builtins which work cross-platform… for example, I'd love to see builtins for saturated operations which could easily be auto-vectorized by the compiler when used in an OpenMP SIMD loop. Currently for new SIMD code, I start with an OpenMP SIMD implementation, then profile. If I see any spots which perform particularly poorly and/or are particularly hot, I'll work on some optimized implementations for those spots using intrinsics. In the future I hope to need to hand-optimize less code, but for now I think this offers a pretty good trade-off between portability, performance, and development time.