
Requesting C like SIMD intrinsics for Rust lang - siavashserver
https://github.com/rust-lang/rfcs/issues/1639
======
sanxiyn
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...](https://github.com/rust-
lang/rfcs/blob/master/text/1199-simd-infrastructure.md)

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.

~~~
eggy
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
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.

~~~
eggy
Thanks for explaining that aspect of it to me!

I'll do some homework, and keep plugging along on learning Rust.

My interest would be in Cuda programming with Rust instead of C.

------
dikaiosune
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
Inline assembly is bad. Compiler will go nuts and cancel out a lot of possible
optimizations.

------
valarauca1
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.

~~~
dbaupp
The JSON file exists because there's more than one place that needs to know
about the intrinsics---they allow generating the corresponding `extern` blocks
---and because there's classes of very similar functions that can be factored
out into a single definition. Keeping things in sync manually is error prone
and exceedingly annoying. However, I agree that the JSON syntax is a...
slightly complicated.

In any case, I'm not sure why you think you need a separate load intrinsic:
the compiler knows how to generate code for loading data. E.g. if you know
data is aligned, casting to a `*const i32x4` and loading that does the right
thing. The unaligned case is a little more subtle but it also can be made to
work via #[repr(packed)].

~~~
valarauca1
>They allow generating the corresponding `extern` blocks

Really? I was able to call the intrinsic I sloppy patched into the auto
generated files fine via extern platform.

>In any case, I'm not sure why you think you need a separate load intrinsic

Because it's a systems programming language?

~~~
dbaupp
> Really? I was able to call the intrinsic I sloppy patched into the auto
> generated files fine via extern platform.

Err... yes, that is exactly my point. You needed an `extern` block to call the
functions. It is much nicer if the `extern` block is written down once (just
like the _mmintrn.h files for gcc/clang) so that there's no risk of mistakes
or mismatches. The JSON files make this easy: both the compiler internals and
the external `extern` block are guaranteed to match. Note that this is
particularly important on a platform like AArch64, where there are hundreds of
intrinsics: hand-transcribing them twice (once for the compiler, once for the
libraries) is time consuming and error-prone.

> Because it's a systems programming language?

This is meaningless: being a systems language doesn't mean having intrinsics
for every possible operation, it just means being able to do everything; these
are not the same. The remainder of the paragraph you quoted explained how the
functionality already exists. The only benefit of having an intrinsic function
to call is that there is a function instead of built-in syntax, it doesn't add
_any_ new power: Rust is just as systems-y with or without the intrinsic.

