[rust-dev] RFC: Tuple Swizzling/Shuffling

Jens Nockert jens at nockert.se
Fri Jan 17 03:28:35 PST 2014


I’m delighted that this topic is on the mailing list again, last time it wasn’t very popular, and I think rustc is more ready for this now than last time when I tried to implement it. Especially syntax extensions and feature flags.

I wrote a bit of thoughts after my last attempt on my blog (http://blog.aventine.se/post/55669497784/my-vision-for-rust-simd) and I know my preference is significantly different from other peoples, but you might find something you like there. It had some nice thoughts, I think.

On 2014/01/17, at 8:57, Richard Diamond <wichard at vitalitystudios.com> wrote:

> On Thu, Jan 16, 2014 at 5:33 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> A float16 is accessed like v.s#, where v is a float16 type and # is a single hex digit. It ain't pretty if one's not used to it.

Nothing is pretty if you are not used to it. I have a feeling that almost any syntax for arbitrary shuffles of more than 16 elements will look horrible.

> 1. Not everyone speaks English; in fact, most people don't. Granted, most people on the Internet do.

All other keywords are also in English, I don’t think this is an issue.

> 2. 'Most' SIMD types doesn't cut it for inclusion in a systems language or for the future in general; there's a lot of future left, so expect eventual use of SIMD types of unbounded size.

My personal opinion is that f64, followed by f32 are the most important SIMD types. Arbitrary shuffles of these types are unusual, and the OpenCL-like syntax can expand to these specific shuffles. (Transpose?)

Old vector systems used very large vectors, so there is obviously the possibility, I don’t think they will make a comeback, but I wouldn’t be surprised if they did.

> 3. There's nothing more natural for a systems language than offset indexing. There's nothing more generic either. I'm not saying that such a language shouldn't have features that make life easier for us mere mortals; I'm saying turning to the alphabet in this case would be a Bad Idea because they would be fulfilling the exact same role as a thing that does that role Better.

OpenCL notation uses indexes, there’s just a different syntax for indexing. And the difference in syntax shows the user that there’s a difference in semantics.

> 4. OpenGL/OpenCL's notation is tacky (subjective, I know).

My love for OpenCL notation is also subjective, I just happen to be brainwashed by OpenCL.

> 5. i8x32 is already out of the question (and that's AVX1).

There are no 8-bit shuffles in AVX, but I think they arrived in AVX2, so I think you have a point.

> 6. someSimd.xyzw alphabet ordering/memory layout nonsense. What order is one actually using? Plus, apropos to #2 & #5, there aren't enough letters to support ze present or ze future.

a.s0123 = b.s6431 is quite obvious in my opinion, but no, there are not enough indices for more than 16 elements. I personally don’t think that is much of a weakness, but if someone has a use-case for long 8-bit vector shuffles, then it would be cool to have a nice syntax for that too.

> 7. SIMD types are N-sized arrays of a primitive type; frankly, it's pretty smelly that rustc stipulates the use of tuple structures for this in the first place (not to mention the loss of inherent, simple element indexing), though I will acknowledge that the flaky support for stuffs like 'type f32x4 = [f32, ..4]; impl f32x4 {}' or the lifetime hell of 'struct f32x4([f32x4]);' / 'strust f32x4 { priv d: [f32x4] };' makes the use of arrays less than ideal (the former plus compile time constant expressions in generics and, of course, swizzling, are going to make all the difference in the world to this end though) for SIMD use.

I agree, there was at one point talk about a SIMD4<T> type and so on, that could evolve into SIMD<T, N> or something like that. But I don’t think that ended up anywhere due to a small bug in the compiler at the time.

In order of preference, my type declaration syntax preferences would be <f32, ..4>, simd!(f32 * 4), #[simd(4)] f32, #[simd] [f32, ..4], #[simd] (f32, f32, f32, f32). I don’t know how much stuff could be done in a syntax extension these days, but I think it is critical that SIMD types should be named, because that becomes confusing fast when implementing functions passing them around. You suddenly need a lot of types floating around, especially for intrinsics and so on.

> Following in the footsteps of OpenGL/OpenCL/mathematicians (particularly the latter, who I think are well known for their 1337 software engineering skillz && experience) in this regard would be a grave blunder for Rust.

I disagree, but this comment made my day, it was hilarious, thanks.

> That said, I think that supporting generic even/odd/etc masks (particularly for certain swizzle--binop expressions that map to a somewhat common instruction) would be advantageous, but that can be easily done without involving rustc now that Mr. Fackler's external syntax extensions PR has landed.

I agree, if we can implement the syntax outside of the compiler, then that would be nicer. Most people don’t need SIMD, and most people that need SIMD don’t need shuffles. (They only use libraries)

More information about the Rust-dev mailing list