4 ms·

Requesting C like SIMD intrinsics for Rust lang

17 points by siavashserver 10y ago

dikaiosune 10y ago
It's worth noting that this is an issue in the RFC repo, not a pull request. Which means it's not an RFC, so much as its a wishlist item. There are some simd items available with a feature on nightly, and there has been a little movement towards stabilization, but it's not there yet. On nightly there's also a helper crate for simd and multiple for cpuid feature detection, for example: https://crates.io/crates/simd https://crates.io/crates/simd https://crates.io/crates/x86 https://crates.io/crates/x86 https://crates.io/crates/raw-cpuid https://crates.io/crates/raw-cpuid Edit: also rust nightly has inline assembly which is slowly moving towards stabilization, so when compiler intrinsics and the crate don't cover the use case, it's inconvenient but technically possible to do simd work in asm. Edit 2: And as mentioned by the issue author themselves, there's the llvmint crate (https://crates.io/crates/llvmint https://crates.io/crates/llvmint) for LLVM intrinsics if you don't want to use the simd crate or roll your own with assembly. I don't get what's happening here.
- siavashserver 10y ago
  Inline assembly is bad. Compiler will go nuts and cancel out a lot of possible optimizations.
sanxiyn 10y ago
Everything requested is already in Rust. For rationale behind current design, read RFC 1199. https://github.com/rust-lang/rfcs/blob/master/text/1199-simd-infrastructure.md https://github.com/rust-lang/rfcs/blob/master/text/1199-simd... Rust SIMD support tries to be type safe, so there are some subtleties involved for comparison and shuffling. (C SIMD support is not type safe.) I can imagine people disagreeing with decisions here. For example, one may have better type safe design, or one may opine it should not be type safe. But the linked issue lacks any details and is not very useful.
- siavashserver 10y ago
  Let's move the discussion over the linked issue on github.
  - dikaiosune 10y ago
    So, respectfully, why post this to HN if you didn't want anyone to discuss it here?
    - siavashserver 10y ago
      To get HN readers interested in such feature involved in the created issue on github. :)
- eggy 10y ago
  I am new to Rust, and RFC 1199 answered most of the questions I had in relation to the original OP link. I understand the decision not to tie vendor-specific SIMD labels and such, but are the data types for SIMD, not vendor-specific headers, available in Rust std, or do you need to use crate? If it needs to be brought in via a crate, and not std, I think the OP link may have a point, since SIMD is so crucial and becoming standard to many fields of computing. For instance, for over 2-1/2 years, Dart has had SIMD types available in the DART SDK through dart:typed_data [1] Again, I am a Rust noob, so pardon any holes in my reasoning here, but it would flavor my evaluation of Rust being a general systems programming language. [1] https://www.dartlang.org/articles/simd/ https://www.dartlang.org/articles/simd/
  - sanxiyn 10y ago
    Data types for SIMD are part of the language and you do not need any external crate. On the other hand, this is an unstable feature, and can't be used on stable release of Rust. I am actually in favor of stablizing current Rust SIMD as-is. But as you can read on the issue, other people are not. That's why it's not yet stable.
    - 10y ago
valarauca1 10y ago
The SIMD crate doesn't uses fast load intrinsics for loads instead it falls back on derviving clone/copy. Honestly it should have a manual derefence trait as well. Also now that naked functions are implemented it should use these to (?). I can't patch this because I don't understand rust-macro's well enough to submit a PR against Huown's (sp?) crate. Which because these are repetitive traits/functions it abstracts away. So I go to write my own and find out __m128 load (either alligned or un-alligned) LLVM intrinsic isn't part of the rust-compiler. (Or __m256, or __m512) Soooo When I submitted a PR with changes for these LLVM intrinsics I was told that I was editing an auto generated Rust file. Instead I need to modify a series of JSON files+Python script. I gave up at that point. If we could just modify the intrinsic file directly that'd be helpful. Yes it'll be big and ugly, but so is every compilers SIMD source section. The current JSON based approach is annoying. Also a lot more JSOn files are needed for things that aren't SSE/AVX like MPX and Crypto extensions. Lastly the JSOn syntax feels bloated and ugly compared to Rust syntax so it is easier to understand args/typing requirements.
- sanxiyn 10y ago
  Can you link the PR? I am interested in getting it merged. I assume you are referring to code generator at https://github.com/rust-lang/rust/tree/master/src/etc/platform-intrinsics https://github.com/rust-lang/rust/tree/master/src/etc/platfo.... I haven't touched that code, but if you think hand editing is preferrable to code generator in terms of maintenance, and everybody agrees, I am sure it can be deleted and generated code be hand edited from now on. For others, here is an example PR adding AVX compare and blend to Rust, and how does change to JSON and change to generated Rust code compare: https://github.com/rust-lang/rust/pull/32231 https://github.com/rust-lang/rust/pull/32231
  - valarauca1 10y ago
    >Can you link the PR? I am interested in getting it merged. Sadly no. I had to delete my old github account due to IRL harresment. I can resubmit later tomorrow.
    - 10y ago

17 points by siavashserver 10y ago

It's worth noting that this is an issue in the RFC repo, not a pull request. Which means it's not an RFC, so much as its a wishlist item. There are some simd items available with a feature on nightly, and there has been a little movement towards stabilization, but it's not there yet. On nightly there's also a helper crate for simd and multiple for cpuid feature detection, for example: https://crates.io/crates/simd https://crates.io/crates/simd https://crates.io/crates/x86 https://crates.io/crates/x86 https://crates.io/crates/raw-cpuid https://crates.io/crates/raw-cpuid Edit: also rust nightly has inline assembly which is slowly moving towards stabilization, so when compiler intrinsics and the crate don't cover the use case, it's inconvenient but technically possible to do simd work in asm. Edit 2: And as mentioned by the issue author themselves, there's the llvmint crate (https://crates.io/crates/llvmint https://crates.io/crates/llvmint) for LLVM intrinsics if you don't want to use the simd crate or roll your own with assembly. I don't get what's happening here.

siavashserver 10y ago
Inline assembly is bad. Compiler will go nuts and cancel out a lot of possible optimizations.

sanxiyn 10y ago

Everything requested is already in Rust. For rationale behind current design, read RFC 1199. https://github.com/rust-lang/rfcs/blob/master/text/1199-simd-infrastructure.md https://github.com/rust-lang/rfcs/blob/master/text/1199-simd... Rust SIMD support tries to be type safe, so there are some subtleties involved for comparison and shuffling. (C SIMD support is not type safe.) I can imagine people disagreeing with decisions here. For example, one may have better type safe design, or one may opine it should not be type safe. But the linked issue lacks any details and is not very useful.

siavashserver 10y ago
Let's move the discussion over the linked issue on github.
- dikaiosune 10y ago
  So, respectfully, why post this to HN if you didn't want anyone to discuss it here?
  - siavashserver 10y ago
    To get HN readers interested in such feature involved in the created issue on github. :)
eggy 10y ago
I am new to Rust, and RFC 1199 answered most of the questions I had in relation to the original OP link. I understand the decision not to tie vendor-specific SIMD labels and such, but are the data types for SIMD, not vendor-specific headers, available in Rust std, or do you need to use crate? If it needs to be brought in via a crate, and not std, I think the OP link may have a point, since SIMD is so crucial and becoming standard to many fields of computing. For instance, for over 2-1/2 years, Dart has had SIMD types available in the DART SDK through dart:typed_data [1] Again, I am a Rust noob, so pardon any holes in my reasoning here, but it would flavor my evaluation of Rust being a general systems programming language. [1] https://www.dartlang.org/articles/simd/ https://www.dartlang.org/articles/simd/
- sanxiyn 10y ago
  Data types for SIMD are part of the language and you do not need any external crate. On the other hand, this is an unstable feature, and can't be used on stable release of Rust. I am actually in favor of stablizing current Rust SIMD as-is. But as you can read on the issue, other people are not. That's why it's not yet stable.
  - 10y ago

valarauca1 10y ago

The SIMD crate doesn't uses fast load intrinsics for loads instead it falls back on derviving clone/copy. Honestly it should have a manual derefence trait as well. Also now that naked functions are implemented it should use these to (?). I can't patch this because I don't understand rust-macro's well enough to submit a PR against Huown's (sp?) crate. Which because these are repetitive traits/functions it abstracts away. So I go to write my own and find out __m128 load (either alligned or un-alligned) LLVM intrinsic isn't part of the rust-compiler. (Or __m256, or __m512) Soooo When I submitted a PR with changes for these LLVM intrinsics I was told that I was editing an auto generated Rust file. Instead I need to modify a series of JSON files+Python script. I gave up at that point. If we could just modify the intrinsic file directly that'd be helpful. Yes it'll be big and ugly, but so is every compilers SIMD source section. The current JSON based approach is annoying. Also a lot more JSOn files are needed for things that aren't SSE/AVX like MPX and Crypto extensions. Lastly the JSOn syntax feels bloated and ugly compared to Rust syntax so it is easier to understand args/typing requirements.

sanxiyn 10y ago
Can you link the PR? I am interested in getting it merged. I assume you are referring to code generator at https://github.com/rust-lang/rust/tree/master/src/etc/platform-intrinsics https://github.com/rust-lang/rust/tree/master/src/etc/platfo.... I haven't touched that code, but if you think hand editing is preferrable to code generator in terms of maintenance, and everybody agrees, I am sure it can be deleted and generated code be hand edited from now on. For others, here is an example PR adding AVX compare and blend to Rust, and how does change to JSON and change to generated Rust code compare: https://github.com/rust-lang/rust/pull/32231 https://github.com/rust-lang/rust/pull/32231
- valarauca1 10y ago
  >Can you link the PR? I am interested in getting it merged. Sadly no. I had to delete my old github account due to IRL harresment. I can resubmit later tomorrow.
  - 10y ago