5 ms·

Counter question: why shouldn't it be portable? It's definitely a 80% solution where you occasionally need to drop down to intrinsics (at zero runtime perf cos

by exDM69 1mo ago

Counter question: why shouldn't it be portable? It's definitely a 80% solution where you occasionally need to drop down to intrinsics (at zero runtime perf cost) for CPU specific instructions. But just having vector types, arithmetic, swizzling, loads and stores will go a long way for basic tasks. And with generics you can write code that is type and width agnostic. No need to rewrite your code of you want to go from SSE to AVX512, just change from f32x4 to f32x16 (or use generics) and you are done.

MomsAVoxell 1mo ago
>Counter question: why shouldn't it be portable? Because there are platform vendors. And SIMD performance very much depends on the use-case, which is a balance of practicalities and specifications and intended deployment targets .. I also think this is a deployment problem, not a build problem, but okay ..
- exDM69 1mo ago
  > also think this is a deployment problem, not a build problem ... This I agree with, deploying and running code for the correct cpu is a problem with no established solution. As for actually writing the code, portable_simd is great. You need to adjust simd width and compiler config for the cpu you deploy to and fill in the blanks with intrinsics. Which is much less work per target than writing it all with raw intrinsics if you are deploying to more than one target.
  - MomsAVoxell 1mo ago
    I wrote a multi-target SIMD-using synthesizer, and I don't think I would've had as much success if I were just using someone else's library - its been especially important to have the SIMD instructions for both architectures I'm supporting (ARM and x86) directly available in the code, since a synthesizer necessarily involves a working pipeline from one stage to the other. I wonder how much easier/better the code would have been to write with portable_simd .. https://github.com/seclorum/SIMDSynth https://github.com/seclorum/SIMDSynth (uses SIMD for optimizing voice allocation and filter calculations on both ARM and x86, same codebase ..)
    - exDM69 1mo ago
      > I wonder how much easier/better the code would have been to write with portable_simd .. I had a quick glance of the code and it seems to use mostly basic arithmetic instructions on fixed width simd vectors using some helper macros like SIMD_MUL(x, y) for _mm_mul_ps, etc. Some explicit simd intrinsics code for stuff like sin. That would've been pretty easy to write with portable_simd in Rust or the equivalent C/C++ language extensions (or maybe C++26 std::simd). You'd just use f32x4 (or add a typedef with attribute in C++) and then use x*y instead of SIMD_MUL. For basic stuff like this, you should get the exact same generated code. https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...

by exDM69 1mo ago

MomsAVoxell 1mo ago

>Counter question: why shouldn't it be portable? Because there are platform vendors. And SIMD performance very much depends on the use-case, which is a balance of practicalities and specifications and intended deployment targets .. I also think this is a deployment problem, not a build problem, but okay ..

exDM69 1mo ago
> also think this is a deployment problem, not a build problem ... This I agree with, deploying and running code for the correct cpu is a problem with no established solution. As for actually writing the code, portable_simd is great. You need to adjust simd width and compiler config for the cpu you deploy to and fill in the blanks with intrinsics. Which is much less work per target than writing it all with raw intrinsics if you are deploying to more than one target.
- MomsAVoxell 1mo ago
  I wrote a multi-target SIMD-using synthesizer, and I don't think I would've had as much success if I were just using someone else's library - its been especially important to have the SIMD instructions for both architectures I'm supporting (ARM and x86) directly available in the code, since a synthesizer necessarily involves a working pipeline from one stage to the other. I wonder how much easier/better the code would have been to write with portable_simd .. https://github.com/seclorum/SIMDSynth https://github.com/seclorum/SIMDSynth (uses SIMD for optimizing voice allocation and filter calculations on both ARM and x86, same codebase ..)
  - exDM69 1mo ago
    > I wonder how much easier/better the code would have been to write with portable_simd .. I had a quick glance of the code and it seems to use mostly basic arithmetic instructions on fixed width simd vectors using some helper macros like SIMD_MUL(x, y) for _mm_mul_ps, etc. Some explicit simd intrinsics code for stuff like sin. That would've been pretty easy to write with portable_simd in Rust or the equivalent C/C++ language extensions (or maybe C++26 std::simd). You'd just use f32x4 (or add a typedef with attribute in C++) and then use x*y instead of SIMD_MUL. For basic stuff like this, you should get the exact same generated code. https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...