search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
95.16k stars 12.28k forks source link

Tracking issue for SIMD support #27731

Closed alexcrichton closed 5 months ago

alexcrichton commented 8 years ago

This is a tracking issue for the unstable core_simd feature in the standard library. SIMD support is quite a thorny topic, but it's largely covered in https://github.com/rust-lang/rfcs/pull/1199, being implemented in https://github.com/rust-lang/rust/pull/27169, and @huonw will be creating an external crate for full-fledged SIMD support.

cc @huonw

Amanieu commented 4 years ago

@jethrogb What platform do you need intrinsics for? The main issue at the moment is that non-x86 intrinsics are not fully implemented yet.

Lokathor commented 4 years ago

Myself I would appreciate more vector math / neon stuff available on Stable.

jethrogb commented 4 years ago

@Amanieu what do you mean by “not fully implemented”? I can imagine the following

  1. Functions exist but their existence is questionable (like nop)
  2. Functions exist but they don't work properly
  3. Functions don't exist

Reasons 1 and 2 are clearly a blocker to stabilization of those specific functions. I don't think reason 3 should necessarily block stabilization of functions that do exist? Reason 3 also applies to x86 which does have a lot of stable functions.

And yeah I was thinking mostly about ARM vector stuff.

Amanieu commented 4 years ago

From this comment it seems that only about 500 out of 4300 NEON intrinsics have actually been implemented. This is very incomplete and I would be against stabilizing the intrinsics in their current state.

jack-signal commented 3 years ago

On NEON even basic functionality such as vdupq_n_u32 and all of the memory store instructions (!) are missing.

Lokathor commented 3 years ago

We're at about 12% neon coverage. I'm not aware that people are actively working on in, but some of the arm devs said that they would like to get to it "soon".

oli-obk commented 3 years ago

In https://github.com/rust-lang/rust/pull/80652 it was noticed that repr_simd introduces two new post-monomorphization errors:

I propose that we add a const evaluatable bound onto these structs. Instead of checking for validity in the compiler, we can instead change types like

#[repr(simd)]
struct SimdF32<const N: usize>([f32; N]);

to

#[repr(simd)]
struct SimdF32<const N: u16>([f32; {validate_lane_length(N)}]);

const fn validate_lane_length(n: u16) -> usize {
    if n.is_power_of_two() {
        n as usize
    } else {
        panic!("lane lengths for SIMD types must be a power of two")
    }
}

This will ensure that any uses of SimdF32 must guarantee that N is a power of two. cc @lcnr

Lokathor commented 3 years ago

Actually we need to support non-power-of-2 lane counts.

oli-obk commented 3 years ago

ok, in that case I guess we just add the n as usize cast in there. This way the type system guarantees that we have a value lower than 2^16. If there are any other checks, we can also add them to the const fn.

calebzulawski commented 3 years ago

This conversation may be more appropriate in https://github.com/rust-lang/stdsimd/issues/63? But generally we have been opposed to the implications of using a const fn in the generic array length.

workingjubilee commented 3 years ago

I would like to hear more fully the benefits and disadvantages of using a const fn here before making a full decision, because our previous objections were predicated on certain type signatures. This might not have the exact same concerns, or it might.

Here, I guess my question is "what does using a const fn get us? Better legibility for users? What kind of lock in does it give to the decisions inside the const fn, or is the const fn relatively opaque?"

coastalwhite commented 11 months ago

Sorry to bump this issue, but after reading the discussions here, I am not 100% clear as to why the RISC-V intrinsics are tied to this issue. With the ARM, wasm32, x86 and x86_64 intrinsics being available on stable, is SIMD the blocker for RISC-V instrinsics? Since the vector extension (as well as other extensions) are ratified and available through a target-feature, is there a chance of merging those into a more stable release?

If so, I am willing to pick up this issue of getting them ready for a more stable release.

Amanieu commented 11 months ago

I'm in the process of splitting all std::arch intrinsics into their own separate target features.

The main blocker for RISC-V vector intrinsics is support for scalable vectors, which is tracked in https://github.com/rust-lang/rfcs/pull/3268.

coastalwhite commented 11 months ago

Would you be open to having me slowly including other extensions in the core::arch module? For example, the Zbb (Basic-Bit Manipulation) and Zkn (NIST Algorithm Suite) immediately come to mind as being very useful.

Amanieu commented 11 months ago

Zbb doesn't need to be exposed as intrinsics, all of the functionality is already available as methods on plain integer types.

Crypto intrinsics are fine to add though, but please open a new tracking issue for them when you send a PR.

Lokathor commented 5 months ago

@workingjubilee bors has run rampant with power, this issue isn't done.

CryZe commented 5 months ago

The commit explicitly says that this issue got split into various smaller issues. The question is rather where are they?

ChrisDenton commented 5 months ago

The commit explicitly says that this issue got split into various smaller issues. The question is rather where are they?

Presumably: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen++label%3AA-simd+label%3AC-tracking-issue

zachs18 commented 5 months ago

I think the new tracking issues are:

From running git diff f4528dd6e85d97bb802240d7cd048b6e1bf72540 5ef6eb42bdcfef6891517a6e4c77a89c18722f18 --unified=0 | grep '^[+]' | grep issue | sed -nE 's/^.*feature = "([^"]*)".*issue = "([^"]*)".*$/\1 = \2/p' | sort | uniq on https://github.com/rust-lang/stdarch/compare/f4528dd6e85d97bb802240d7cd048b6e1bf72540...5ef6eb42bdcfef6891517a6e4c77a89c18722f18 (the submodule update introduced in #117372, the PR which closed this issue). I didn't thoroughly vet this list so ymmv. Also some intrinsics were changed from unstable(feature = "stdsimd") to stable(feature = "something") which this list does not include. This also does not include any feature declarations that were split onto multiple lines, if any exist (I didn't check).

Amanieu commented 5 months ago

Here is the full set of new tracking issues for what stdsimd was previous tracking: