Stream: t-lang/meta

Topic: Promoting packed_simd to std::simd


view this post on Zulip Henri Sivonen (Jun 22 2020 at 11:56):

It appears that work on https://github.com/rust-lang/rfcs/pull/2366 and packed_simd has stalled due to lack of roadmap commitment: https://github.com/rust-lang/packed_simd/issues/213#issuecomment-549282056 .

How could we get consensus at least on the 128-bit part of packed_simd to become std::simd? The formulation of the types was waiting for const generics, but: 1) the user will use u8x16, u16x8, etc., anyway without caring about the lower-level formulation and 2) the types need to be zero-cost transmutable to core::arch types anyway, so low-level representation issues are already constrained by whatever has been shipped to stable under core::arch.

view this post on Zulip Josh Triplett (Jun 23 2020 at 20:18):

As mentioned by email, I think the next step would be to file an MCP for a portable SIMD project group, to consider what the shape of portable SIMD in std should look like.

view this post on Zulip Josh Triplett (Jun 23 2020 at 20:19):

This is likely something that crosses over between libs and lang, which should be doable given appropriate liaisons from both teams.

view this post on Zulip Josh Triplett (Jun 23 2020 at 20:21):

I would also not take it as a given that the correct outcome will be to merge an unmodified version of any particular crate from the ecosystem.

view this post on Zulip Henri Sivonen (Jun 24 2020 at 15:19):

Before starting a group, I wanted a place for answering the questions that, from experience, I know will come up. To that end, I created a fork of the closed RFC with a FAQ section added.

Due to the history of the simd crate and the packed_simd crate, I still wish to push for merging the existing crate instead of starting from starting discussion as if running code didn't already exist. packed_simd is already an attempt to start from scratch. We should value running code. With a task this large, otherwise, there's the risk of always getting almost there, the project getting abandoned and the next person redesigning the whole thing, getting almost there, and the cycle continuing. For this reason, I think it's important that effort is cumulative towards getting the running code into the standard library instead of starting from scratch again. (As a practical matter, I may have the bandwidth to advocate from packed_simd, but I for sure don't have the bandwidth to implement a different design.)

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:52):

I want to be clear about something here: it is entirely possible that the net result of the discussion will be to merge some form of packed_simd into std. The concern is that that cannot be the starting point of the discussion. We can't start the discussion of "how do we solve this problem" with "we're going to solve it this specific way or not at all".

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:53):

We cannot just have a pro-forma discussion of "how are we going to rubber-stamp this particular library without any actual discussion or changes".

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:53):

Also, nobody is saying "let's redesign from scratch".

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:56):

I don't think it's unreasonable to make sure we're in agreement on the requirements and that we will have a solution that meets them. I don't think it's reasonable to decide in advance that the requirements are "whatever this specific crate does because we're not changing it".

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:57):

I very much understand the scenario you're concerned about, and I do not want to see that happen either.

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:57):

I don't think anyone does. Wasted effort is a terrible thing.

view this post on Zulip Josh Triplett (Jun 24 2020 at 17:58):

Also, portions of that FAQ are incredibly useful. There are a few answers in that FAQ that I would disagree with, but much of it I'm in complete agreement with.

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:01):

In any case, I really don't want to litigate specific points of that FAQ point-by-point right now. My concern is that we need to be able to have that discussion, without the answers being "no, because that's not what packed_simd currently does".

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:09):

To give just two specific examples:

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:09):

These are exactly the kinds of things a project group could talk through and find solutions to. And they would not necessarily result in a massive amount of additional work or rework or rewriting.

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:15):

FWIW, a few points of the FAQ I enthusiastically agree with, and very much want to see remain as requirements: yes, we should absolutely have shuffles even if not every platform uses them; yes, we should absolutely pick a layout that lets people rely on endianness; and I don't think we should wait on const generics either.

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:16):

(That last one is a major reason why I want to make sure we have a good solution for runtime detection, because I think it'll be critical for people to know if their platform has 128/256/512-bit vectors and write algorithms accordingly.)

view this post on Zulip Josh Triplett (Jun 24 2020 at 18:18):

Also, regarding ABI, if the target supports SIMD vectors of a given width, and the portable SIMD types are guaranteed to be zero-cost transmutable, then making it possible to pass those in the ABI-defined vector registers seems valuable. That doesn't have to happen in the very first version, but having it as a requirement and putting it on the roadmap will help make sure we don't have a design decision that makes it impossible to do so.

view this post on Zulip Henri Sivonen (Jun 25 2020 at 11:49):

I filed an MCP, but I fail to find the Zulip stream that I'm supposed to post it to.

Regarding cpuid-based run-time multiversioning, I think portable SIMD should not be blocked by it. It has applicability beyond SIMD to e.g. popcnt, so I think it should be a separate project on its own.

I agree that adding From and .into() as appropriate makes sense. It's not essential for it to be part of the initial landing. It could be added later. Or at the initial landing. I'm not at all suggesting that nothing could be added to packed_simd. I'm interested in getting it landed after which for sure people will think of features to add.

view this post on Zulip bjorn3 (Jun 25 2020 at 12:12):

Henri Sivonen said:

I filed an MCP, but I fail to find the Zulip stream that I'm supposed to post it to.

https://rust-lang.zulipchat.com/#narrow/stream/233931-xxx/topic/Portable.20SIMD.20project.20group.20compiler-team.23321

view this post on Zulip bjorn3 (Jun 25 2020 at 12:16):

NEON is opt-in in the third two-bit case

*thirty-two-bit

view this post on Zulip bjorn3 (Jun 25 2020 at 12:17):

my bother
*why

view this post on Zulip Henri Sivonen (Jun 25 2020 at 15:49):

Thanks for the link to the right stream. I fixed the errors you found. Thanks.

view this post on Zulip nikomatsakis (Jun 25 2020 at 21:15):

heh, that should probably have been a lang-team MCP

view this post on Zulip nikomatsakis (Jun 25 2020 at 21:15):

sorry @Henri Sivonen :) that is, on this repo https://github.com/rust-lang/lang-team/

view this post on Zulip nikomatsakis (Jun 25 2020 at 21:16):

anyway, I think my take is that it is indeed a good idea to not start from a frame of "just adopt this thing" but I also wouldn't want to spend too much time relitigating everything, there is value in continuity

view this post on Zulip Josh Triplett (Jun 25 2020 at 23:32):

That's a reasonable phrasing. I don't want to see anything relitigated, I just want to make sure there's alignment on the requirements and understanding of how to achieve those requirements with whatever plan we go with.

view this post on Zulip Henri Sivonen (Jun 26 2020 at 08:44):

OK. I filed a lang team MCP. Should I close the compiler one?

view this post on Zulip nikomatsakis (Jun 26 2020 at 20:52):

@Henri Sivonen yep


Last updated: Jan 26 2022 at 08:21 UTC