C like SIMD intrinsics for Rust

[siavashserver]

One of important features missing from Rust lang for me and other guys involved with game development, DSP, video encoding, etc is proper SIMD support.

It's disappointing to see that such important feature is not still core feature of Rust lang, or at least receiving more love from developers after waiting since Rust's early days.

The current means of writing SIMD code like https://crates.io/crates/simd in Rust trying to provide a unified interface for different archs and abstracting stuff are way suboptimal. I like the idea of https://crates.io/crates/llvmint though.

Please give us m128, m128i, m128d, etc data types and access to whatever available inside xmmintrin.h, etc. Let us deal with platform abstractions and safety stuff ourselves.

Thanks!

[BurntSushi]

Could you explain more about why the simd crate is "way suboptimal"?

[sanxiyn]

I am unsure what is being requested here, because #[repr(simd)] already give m128 and friends, and llvmint crate already gives everything inside xmmintrin.h and friends.

Is the request that repr_simd be stablized? Is the request that llvmint be included? (If so, why? It's a line away with Cargo.) Is the request for better documentation? Is the request to rename "simd" and "llvmint" to corresponding names in C so that they are more familiar?

[briansmith]

Is the request that repr_simd be stablized? Is the request that llvmint be included?

Whatever is needed to use llvmint using Rust Stable.

[siavashserver]

Could you explain more about why the simd crate is "way suboptimal"?

I have not looked deeper, but many functionalities available in C are missing there. To name a few stuff like prefetching (prefetchnta, etc), different load/store varieties (movntdqa and lddqu for example).

Is the request that repr_simd be stablized?

No; because of the given reasons up there.

Is the request that llvmint be included? (If so, why? It's a line away with Cargo.)

Kinda; SIMD support shouldn't be considered as some eye candy when advertising Rust as a high performance system programming language. It's not cool at all to see such essential feature to be handled by a single person as a hobby.

Is the request for better documentation?

Not really. It would be really appreciated if you guys use exactly same naming convention as C intrinsics or assembly ones to reduce the confusions. Besides, they are already documented very well in Intel's software manuals and all over the Internet, no need to redo. (for example: https://software.intel.com/sites/landingpage/IntrinsicsGuide/)

Is the request to rename "simd" and "llvmint" to corresponding names in C so that they are more familiar?

See above.

[briansmith]

It would be really appreciated if you guys use exactly same naming convention as C intrinsics or assembly ones to reduce the confusions. Besides, they are already documented very well in Intel's software manuals and all over the Internet,

I agree with this. Intel's names may not be the best, but using "better" names only makes things worse, IMO. I would like to have the exact-same names, and same better names for the generic abstraction on top.

[sanxiyn]

Thanks for replies. The initial post was quite light on details what "C like SIMD" entails, but replies were illuminating. The following is my understanding, please correct me if I misunderstood.

First, SIMD should be stable. I actually think everyone agrees. The reason it is not yet stable is because people disagree on the rest.

Second, SIMD should use Intel naming conventions. Note that this is not C naming conventions. As I understand, there are three different naming conventions: Intel, GCC, LLVM. Rust llvmint mechanically follows LLVM. (It is not the case Rust invented new naming scheme.) The suggestion is to mechanically follow Intel instead. Presumably, it is also suggested to follow ARM etc. for other platforms. The reason is that this allows reuse of existing documentation. I completely agree here and the reason is clear.

Here is an example with movntdqa: Intel: _mm_stream_load_si128. GCC: __builtin_ia32_movntdqa. LLVM: llvm.x86.sse41.movntdqa. Rust llvmint: sse41_movntdqa. I note that Intel deviates most from actual assembly name here.

Third, parts of SIMD support currently maintained as external library should be brought into the main Rust distribution. I am still unclear why, but it seems to me that it is hoped inclusion in the main distribution will bring more contribution. I agree it may be the case. Should it be part of std, or under rust-lang-nursery eventually moving to rust-lang like regex?

I am still unclear why current SIMD support shouldn't be stablized. RFC 1199 defined feature gate repr_simd for types, and platform_intrinsics for operations. It is true some operations are missing, but operations can be added incrementally, they are not breaking changes. So missing operations can't be the reason not to stablize. I don't think any types are missing.

I note that movntdqa and lddqu are in llvmint. For prefetchnta, llvmint only includes architecture generic form, not Intel architecture specific form, but architecture generic form is superset of Intel architecture specific form. Specifically, prefetchnta = _mm_prefetch(p, i) = prefetch(p, 0, i, 1). 0 is for read (1 is write), 1 is for data (0 is instruction). See http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic for LLVM documentation.

[eddyb]

I am still unclear why current SIMD support shouldn't be stablized.

One reason I wouldn't stabilize is shuffles that don't use generic constant parameters.
I've managed to hack it up on the MIR side so that the argument is guaranteed to be constant, but it doesn't scale and it definitely doesn't allow proxying.

The main reason, however, is that there's no type-safety, no bounds on the operations.
Also, the existing intrinsic function system is a terrible misuse of the FFI import feature, from the old days of ad-hoc infrastructure necessary to bootstrap, and shouldn't be exposed in this way.

[sanxiyn]

By the way, Rust follows LLVM naming because Rust ultimately compiles to LLVM. While I think rationale for Intel naming is strong, it does mean Intel naming to LLVM naming mapping has to be maintained by Rust.

[sanxiyn]

@eddyb, I am aware of those problems. But OP said SIMD shouldn't be stablized because prefetchnta, movntdqa, lddqu are missing, which is non sequitur. First, they aren't missing, second, even if they are missing that's no reason not to stablize.

[eddyb]

@sanxiyn Oh, I see. Sorry for misunderstanding.

[nagisa]

Duplicate of #280

[siavashserver]

@sanxiyn Thanks for clearing things up!

I do agree with the points you did made; current SIMD proposal (RFC #1199) + missing features from llvmint and following platform specific (Intel/ARM/...) naming conventions sounds perfect to me.

Is it possible to give SIMD support stabilization a little higher priority, so we can get our hands on it in may be less than 6 months? Pleeaassee! :)

[skade]

@siavashserver Please be aware that we get a lot of requests for "higher priority". The best way to bring these features to conclusion is finding people competent with SIMD and rust and maybe help out with code submissions by implementing the RFC proposal. I'm aware that this isn't always possible.

There's many things that are disappointing because they are missing, but engineering time is the biggest problem here and no one is served with a mediocre stable feature.

[eddyb]

@skade FWIW Work is underway for const generic parameters (MIR is central to supporting them), but it might be a while before we have anything tangible, the guts of the compiler have to change significantly.

[eddyb]

In other words, the language feature a better SIMD is blocked on are relatively high-priority, it's just quite non-trivial.

The changes to intrinsics naming and missing intrinsics (if any) can be done in parallel, if a RFC is proposed to use some convention which predates LLVM. The implementation that governs those is actually a Python script and some JSON files, so contribution barrier should be low.