provide Standard for x86 __m128/256i on stable Rust, add 128xN/sizexN SIMD types

[TheIronBorn]

No description provided.

[vks]

Looks good! I wonder how to document this, it is not very discoverable at the moment. Should we document this in the README?

[TheIronBorn]

Hmm. We don't have any documentation on Standard for SIMD stuff. We could probably mention the features there. Perhaps Uniform as well. There's also the experimental rustdoc cfg stuff of course

[dhardy]

The use of unsafe needs attention; after that I'd like to do another review.

[newpavlov]

I don't think we need the SampleNativeEndian trait. Instead it should be enough to directly implement intrinsic_native_le_impl by simply copying simd_impl without the to_le call. Amount of code duplication will be minuscule.

[TheIronBorn]

The extra internal NE trait might reduce code duplication for future architectures, but it's still probably minimal

[TheIronBorn]

packed_simd failure on latest nightly. Exactly why this is useful

[TheIronBorn]

Noticed we mention SIMD Standard and Uniform here https://rust-random.github.io/book/guide-dist.html#uniform-sampling-by-type

[dhardy]

We only want two items, right? I'm not so keen on using glob imports.

[TheIronBorn]

4 items now. Added 2 setzero intrinsics

[dhardy]

True, though if you make the change below those will go away.

[dhardy]

I'm baffled: (1) the types exist without additional target features while the constructors require (sse2 / avx), and (2) the constructors are unsafe. Maybe I should learn a little more about SIMD here...

Stupid questions, but:

1. This code will fail to compile without sse2 / avx, right?
2. Is there a reason we shouldn't simply transmute an array with suitable alignment? Especially since we're mostly doing that with the pointer-cast anyway.

[newpavlov]

AFAIK there are no dedicated instructions for the setzero intrinsics. Usually they get compiled either down to XORing the same register or to writing zero bytes to memory. I am also a bit surprised that they are gated on sse2/avx, while types themselves are not.

I agree that transmuting arrays would be a simpler solution, but instead of creating an array with proper alignment I think it will be easier to write something like this:

let mut buf = [0u8; mem::size_of::<$ty>()];
rng.fill_bytes(&mut buf);
unsafe {  mem::transmute_copy(&buf) }

transmute_copy will handle the alignment requirements and in practice should be properly optimized out by compiler.

[TheIronBorn]

It will compile just fine but without see/avx it will fail to run

[newpavlov]

@TheIronBorn
Using intrinsics without properly checking required target features (either at compile or at run time) is considered UB.

[dhardy]

I think this is correct, but we should really use from_bits like the old code to avoid unsafe (but do use fill_bytes instead of gen).

Unfortunately from_bits is not documented on docs.rs; I just dropped a PR for that.

[TheIronBorn]

I'm confused by this. Do you mean use fill_bytes on a regular array and then from_slice_unaligned? That would avoid all unsafe.

[dhardy]

Hmm, I hadn't figured on Simd<[u8; 2]> etc. being hard to construct from an array. Maybe my suggestion doesn't make sense then.

[TheIronBorn]

We could do something like

let mut bytes = [0_u8; mem::size_of::<$ty>()];
rng.fill_bytes(&mut bytes);
let vec = $ty::from_bits($u8xN::from_slice_unaligned(&bytes));
vec.to_le()

but usizexN don't have from_bits,