Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC]: Portable SIMD Libs Project Group #2977

Merged
merged 3 commits into from
Sep 18, 2020
Merged

[RFC]: Portable SIMD Libs Project Group #2977

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
37bef38
Create 0000-stdsimd.md
KodrAus Aug 28, 2020
4769b9f
add calebzulawski to initial group
KodrAus Sep 9, 2020
9b3e975
RFC 2977 is "Portable SIMD Project Group"
KodrAus Sep 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions text/0000-stdsimd.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
- Feature Name: stdsimd_project_group
- Start Date: 2020-08-28
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

This is a project group RFC version of [`lang-team#29`].

This RFC establishes a new project group, under the libs team, to produce a portable SIMD API in a new `rust-lang/stdsimd` repository, exposed through a new `std::simd` (and `core::simd`) module in the standard library in the same manner as [`stdarch`]. The output of this project group will be the finalization of [RFC 2948] and stabilization of `std::simd`.

# Motivation
[motivation]: #motivation

The current stable `core::arch` module is described by [RFC 2325], which considers a portable API desirable but out-of-scope. The current [RFC 2948] provides a good motivation for this API. Various ecosystem implementations of portable SIMD have appeared over the years, including [`packed_simd`], and [`wide`], each taking a different set of trade-offs in implementation while retaining some similarities in their public API. The group will pull together a "blessed" implementation in the standard library with the explicit goal of stabilization for the [2021 edition].

# Charter
[charter]: #charter

## Goals

- Determine the shape of the portable SIMD API.
- Get an unstable `std::simd` and `core::simd` API in the standard library. This may mean renaming `packed_simd` to `stdsimd` and working directly on it, or creating a new repository and pulling in chunks of code as needed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we evaluate options other than packed_simd and stdsimd too or try experimenting more? Or are these already good enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely something to figure out when we kick off, and at the very least we should survey the various approaches out there. I’d love to take some time to dig into generic-simd properly.

In general I think we’d settled on a starting point based off packed_simd, without exposing a generic Simd<T> (so a public structure similar to wide), with a sprinkling of const generics for shuffles.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we evaluate options other than packed_simd and stdsimd too or try experimenting more? Or are these already good enough?

I think more experimentation carries a significant risk of not reaching the goal of getting to stable.

Notably, simd already existed before packed_simd, the initial design of packed_simd omitted something that simd already had (boolean/mask vectors) and ended up adding them back, so packed_simd ended up being like a more comprehensive version of simd with the internals rewritten.

That is, portable SIMD in Rust has already gone through the cycle of a change in the person working on it resulting in a rewrite that, while making things more comprehensive, on the high level ended up close to the old thing. While each such cycle might improved the design marginally, starting over means the distance to getting the stable gets reset to zero.

Copy link
Contributor

@pickfire pickfire Sep 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so the goal here is more of stabilizing it rather than having more experimentation to improve the existing ones and then only decide to go stable.

Copy link
Member

@calebzulawski calebzulawski Sep 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also like to mention that even though I started from scratch, generic-simd ended up particularly similar to packed_simd, and most of the features would be applicable to an implementation based on packed_simd.

The major differences of generic-simd are:

  • works on stable (likely irrelevant here)
  • a little bit more comprehensive traits (like num-traits, but for SIMD)
  • a different model for runtime feature selection (not sure if this is relevant)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually looking at the LLVM code some more, it seems you can bypass this check by using #[inline(always)]. Please ignore my previous comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just #[inline] goes on the core::simd function, and then the caller can choose to target_feature(enable) in a function that uses core::simd.

According to the docs for is_x86_feature_detected!, that alone should do it, without core::simd needing to be target feature aware at all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to use #[inline(always)] on the core::simd function otherwise LLVM will refuse to inline functions with mismatching target features. But otherwise you are correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about runtime selection? Is rust going to provide runtime selection for SIMD which may not be zero-cost? Or maybe users can opt-in for it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is what the multiversion crate (or similar) would do.

Actually putting that sort of mechanic in the standard library is probably a whole separate project.

- Produce a stabilization plan to allow portions of `std::simd` to be stabilized when they're ready, and coordinate with other unstable features.
- Respond to user feedback and review contributions to the API.
- Update [RFC 2948] based on the final API and stabilization plan.
- Stabilize `std::simd`!

## Non Goals

- This group isn't directly attempting to build out more `core::arch` APIs.

## Membership Requirements

- Group membership is open, any interested party can participate in discussions, repeat contributors will be added to appropriate teams.

## Additional Questions

### What support do you need, and separately want, from the Rust organization?

Support scaffolding a space to work and integrating `stdsimd` into `libcore` and input from engineers who are familiar with this space.

### Why should this be a project group over a community effort?

Community efforts have already produced libraries that are in use, but pulling those together in the standard library needs a group with permissions to get things merged.

### What do you expect the relationship to the team be?

The project group will regularly update libs on how things are going, whether there are any blockers

### Who are the initial shepherds/leaders? (This is preferably 2–3 individuals, but not required.)

- @BurntSushi
- @calebzulawski
- @hsivonen
- @KodrAus
- @Lokathor

### Is your group long-running or temporary?

Temporary

### If it is temporary, how long do you see it running for?

Until the 2021 edition, which is probably mid 2021.

### If applicable, which other groups or teams do you expect to have close contact with?

The project group will interact with:

- libs
- compiler

### Where do you see your group needing help?

There will be lots of feedback to gather from users and input from compiler developers on how to approach implementation.

[`packed_simd`]: https://github.com/rust-lang/packed_simd
[`wide`]: https://github.com/Lokathor/wide
[`stdarch`]: https://github.com/rust-lang/stdarch
[2021 edition]: https://github.com/rust-lang/rfcs/pull/2966
[RFC 2948]: https://github.com/rust-lang/rfcs/pull/2948
[RFC 2325]: https://rust-lang.github.io/rfcs/2325-stable-simd.html
[`lang-team#29`]: https://github.com/rust-lang/lang-team/issues/29