Feature/comparisons

[calebzulawski]

This isn't quite done, but I figure I should get some more opinions before moving on to testing.

In this PR I introduce the framework for multiple mask types:

• Opaque mask types are available as maskNxM, and have unspecified layout. These can be conditionally compiled on architecture.
• Specified-layout masks are still available, and the operations on those are provided by the MaskExt trait.
• I have not yet implemented single bit masks, but these will be provided with additional MaskExt implementations.

[programmerjake]

Looks good, except I think we should use the shortest names for the unspecified layout masks, since those would be optimal on all architectures, whereas the full masks would be optimal only on some architectures. People will prefer the types with the shortest names and we should guide them towards the masks that work well everywhere as opposed to just on some architectures.

[calebzulawski]

I'm open to different naming, but I used m8 etc to mirror i8/u8. mask8x8, mask16x8, mask32x8, and mask64x8 could all be implemented with m1x8 on some architectures in the future.

[programmerjake]

How about using m16x8 or b16x8 or bool16x8 for the unspecified layout masks and full_mask16x8 or mask16x8 for the full-width masks?

[Lokathor]

I think that the masks are sufficiently "weird" compared to the rest of the plain element types that maskNxK should be the shortest version (unspecified layout), and then we can also have full_maskNxK and bit_maskNxK (or other naming schemes) for the options with a specified layout.

[workingjubilee]

I agree with Lokathor here, there's no particular reason to use abbreviations in what will generally be a not-common type.

[workingjubilee]

Aside from that quibble, this seems like it would be fine (if it compiled)!

[calebzulawski]

Awesome, I've been too busy to look at this recently but should have more time going forward. Fixing the tests should be easy enough, I just forgot to update them 🤞

[calebzulawski]

My thoughts on the naming convention right now:

• maskNxM for the general-use masks. It's short and fairly obvious what it means, I think.
• mNxM for the full-width masks. I figure mN is kind of like uN or iN, but a little different semantics.
• m1xM for the single-bit masks. There's no u1 or i1, but that's kind of what it is.

I'm not opposed to longer/more descriptive names for the layout-specified masks but frankly I couldn't think of anything that I was happy with.

[calebzulawski]

Also, very odd wasm errors: https://travis-ci.com/github/rust-lang/stdsimd/jobs/445441280#L4786-L4790

---- ops::ops_impl::mask128::mask128x2::bitxor_scalar_rhs output ----

    error output:

        panicked at 'assertion failed: `(left == right)`

          left: `[true, false]`,

         right: `[true, false]`', crates/core_simd/tests/ops_impl/mask128.rs:1:1

[programmerjake]

Also, very odd wasm errors: https://travis-ci.com/github/rust-lang/stdsimd/jobs/445441280#L4786-L4790

---- ops::ops_impl::mask128::mask128x2::bitxor_scalar_rhs output ----

    error output:

        panicked at 'assertion failed: `(left == right)`

          left: `[true, false]`,

         right: `[true, false]`', crates/core_simd/tests/ops_impl/mask128.rs:1:1

I'd guess that somehow the mask elements are set to something other than 0 or !0, try dumping the raw bits.

[programmerjake]

My thoughts on the naming convention right now:

• maskNxM for the general-use masks. It's short and fairly obvious what it means, I think.
• mNxM for the full-width masks. I figure mN is kind of like uN or iN, but a little different semantics.
• m1xM for the single-bit masks. There's no u1 or i1, but that's kind of what it is.

I'm not opposed to longer/more descriptive names for the layout-specified masks but frankly I couldn't think of anything that I was happy with.

What about mNxM for general use masks and wmNxM for full-width masks ("wide mask") and bitxM for single-bit masks? Those are all sufficiently short, yet mNxM is still shortest or the same length (ignoring 128-bit per element masks, they're uncommon).

another option would be mNxM for general use masks, em1xM for single-bit masks, em4xM for 4-bit masks (used on ARM SVE iirc), and emNxM for full masks. em is "Exact-width Mask".

[Lokathor]

bitmN, wmN, emN etc are getting a little "C-ish" for my taste. Let's throw an underscore in there for the longer names of a specific mask form.

[thomcc]

bitmN, wmN, emN etc are getting a little "C-ish" for my taste. Let's throw an underscore in there for the longer names of a specific mask form.

Existing primitive types are all very abbreviated, and don't have any underscores AFAIK.

[Lokathor]

Right, and the "default" mask type would stay just as mNxL or whatever short thing, just the extra detail variants would have longer names.

For example

• we don't have wu8 we have Wrapping<u8>
• we don't have au8 we have AtomicU8

[calebzulawski]

Right, and the "default" mask type would stay just as mNxL or whatever short thing, just the extra detail variants would have longer names.

For example

• we don't have wu8 we have Wrapping<u8>
• we don't have au8 we have AtomicU8

I generally agree with this. The opaque masks are already questionable, and should maybe be MaskNxM. I'm not opposed to something like FullMaskNxM because of the length, but more because "full" doesn't seem to be very meaningful here.

[calebzulawski]

I forgot to mention, I don't think the opaque masks should be mNxM or whatever because that seems to imply (to me, at least) they're constructed of a particular primitive mN, since that's what it means for iN, uN, fN.

[calebzulawski]

Note--my latest commit didn't fix the wasm issue. As far as I can tell it's fixed by a recent update to nightly. The bug only occurred with comparing the equality of the u128 vectors (the vectors matched bit for bit, but failed equality for some reason).

[calebzulawski]

Closing this. Comparisons will be added as part of #49.