4 ms·

Any reason to stick with the horrible intel intrinsic C API ? TBH I find assembly kernels generally more readable as long as one keep a few comments in there t

by obl 8y ago

Any reason to stick with the horrible intel intrinsic C API ? TBH I find assembly kernels generally more readable as long as one keep a few comments in there to explicit register allocation.

stagger87 8y ago
I mean, if you are being serious, there are tons of reasons to use the C API. I heavily use intrinsics in C++ templates. Clever use of templates allows me to write a function once which can compile to SSE/AVX/AVX-512 and different data types (float/double) and different arch (x86/x64). In most situations this will be faster than assembly since I can inline everything wherever I want. When the need arises I will drop down to assembly to try to get any last perf gains, but otherwise I found that clang/icc/msvc are pretty good at generating assembly.
- obl 8y ago
  I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly. I absolutely agree that once wrapped up there are good reasons to use a language-level interface instead of asm for most things.
  - gameswithgo 8y ago
    As I get more familiar with rust macros I may compress this down a bunch. It will make it easier to maintain.
  - stagger87 8y ago
    As another example, this morning I needed to perform a small convolution in an inner loop. Since I'm targeting x64 under the msvc compiler I can't write an external assembly function and have it inlined into the inner loop. Therefore I was left with just using the raw intrinsics from intrin.h for like, 10 lines of code. The simplicity of the convolution means the compiler will have no problems generating optimal code.
    - gameswithgo 8y ago
      For me the ugliness of the intrinsics has gone away, like parens do for a lisp programmer.
  - burntsushi 8y ago
    > I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly. The compiler is aware of many of those intrinsics and can perform optimizations around them. Hand rolling all of that in Assembly would be quite the chore. Using these intrinsics is, IMO, considerably easier.
pornel 8y ago
Rust chose to adopt the vendors' naming schemes exactly as they were defined, instead of inventing their own. The idea was that these intrinsics are official, well-understood and people will build higher-level abstractions on top of them anyway.
- kibwen 8y ago
  To elaborate a bit, the intention is to first stabilize the platform-dependent low-level intrinsics just as specified by each vendor, under the "arch" namespace in the standard library (e.g. `use std::arch::x86_64::whatever`, which is quite self-explanatorily nonportable). This will hit stable Rust as of the next release, on June 21. Future work will focus on building a more portable, more Rust-like, higher-level API on top of these intrinsics under the "simd" namespace in the standard library; you can see the current state of this work at https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/simd/index.html https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/s... .

by obl 8y ago

Any reason to stick with the horrible intel intrinsic C API ? TBH I find assembly kernels generally more readable as long as one keep a few comments in there to explicit register allocation.

stagger87 8y ago

I mean, if you are being serious, there are tons of reasons to use the C API. I heavily use intrinsics in C++ templates. Clever use of templates allows me to write a function once which can compile to SSE/AVX/AVX-512 and different data types (float/double) and different arch (x86/x64). In most situations this will be faster than assembly since I can inline everything wherever I want. When the need arises I will drop down to assembly to try to get any last perf gains, but otherwise I found that clang/icc/msvc are pretty good at generating assembly.

obl 8y ago
I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly. I absolutely agree that once wrapped up there are good reasons to use a language-level interface instead of asm for most things.
- gameswithgo 8y ago
  As I get more familiar with rust macros I may compress this down a bunch. It will make it easier to maintain.
- stagger87 8y ago
  As another example, this morning I needed to perform a small convolution in an inner loop. Since I'm targeting x64 under the msvc compiler I can't write an external assembly function and have it inlined into the inner loop. Therefore I was left with just using the raw intrinsics from intrin.h for like, 10 lines of code. The simplicity of the convolution means the compiler will have no problems generating optimal code.
  - gameswithgo 8y ago
    For me the ugliness of the intrinsics has gone away, like parens do for a lisp programmer.
- burntsushi 8y ago
  > I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly. The compiler is aware of many of those intrinsics and can perform optimizations around them. Hand rolling all of that in Assembly would be quite the chore. Using these intrinsics is, IMO, considerably easier.

pornel 8y ago

Rust chose to adopt the vendors' naming schemes exactly as they were defined, instead of inventing their own. The idea was that these intrinsics are official, well-understood and people will build higher-level abstractions on top of them anyway.

kibwen 8y ago
To elaborate a bit, the intention is to first stabilize the platform-dependent low-level intrinsics just as specified by each vendor, under the "arch" namespace in the standard library (e.g. `use std::arch::x86_64::whatever`, which is quite self-explanatorily nonportable). This will hit stable Rust as of the next release, on June 21. Future work will focus on building a more portable, more Rust-like, higher-level API on top of these intrinsics under the "simd" namespace in the standard library; you can see the current state of this work at https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/simd/index.html https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/s... .