Support for SIMD types

[ralfbiedert]

I am creating a library where I would like to abstract math over scalar (f32) or packed SIMD types (f32x8) as defined in RFC 2366.

For example, I would like to express:

fn kernel<F>(a: F, b: F) -> F
where
    F: Float,
{
    (a - b) * (a - b)
}

And then call either kernel(1.0, 2.0) or kernel(f32x8::splat(1.0), f32x8::splat(2.0)), depending on what data structure I am operating with.

As part of that I was looking into num-traits, in particular I was about to create a num-packed crate, that implements Num & friends for RFC 2366 packed types.

The problem, however, is that many traits such as Integer, Float, Signed, ... not only provide f(Self) -> Self mathematical functions, but also f(Self) -> bool utilities, such as is_even or integer_decode, which do not directly make sense anymore.

Two questions:

• Do you think it would be feasible to either split out these utility functions into separate traits, or generalize them to be compatible with packed types?
• More generally, does num-packed make sense as an addition to num, or am I on the wrong path?

[cuviper]

Do you think it would be feasible to either split out these utility functions into separate traits, or generalize them to be compatible with packed types?

It would certainly be a breaking change to split up the traits. Maybe there's some useful commonality that we could redesign someday, just as I'd like to eventually revisit how FloatCore, Float, and Real interact. There's a danger that the traits could get harder to use by being too fine-grained though.

I think it would be easier to create new traits for SIMD, merely inspired by those in num-traits.

More generally, does num-packed make sense as an addition to num, or am I on the wrong path?

As a point of procedure, I'm not keen on taking on additional crates in the rust-num org, as I'm basically the only active maintainer. But generally, sure, a crate like num-packed makes sense to me.

[ralfbiedert]

I think it would be easier to create new traits for SIMD, merely inspired by those in num-traits.

From what I understand, there is no way to compatibly implement a standalone num-packed without some base support in num, as that would mean implementing foreign traits for foreign types (e.g., impl Num for f32x2), which Rust doesn't allow; please correct me if I'm missing something here.

So a standalone num-packed could not really have much in common with num, unless it also has its very own Num, Float, ... traits.

I'm not really set on any particular way of solving this (changing FloatCore, adding PackedFloat, ...), but I would like to avoid having a separate "packed" ecosystem, since that would kill many of num's benefits for 3rd party crates down the line.

It would certainly be a breaking change to split up the traits. [...] As a point of procedure, I'm not keen on taking on additional crates in the rust-num org, as I'm basically the only active maintainer.

Sorry for pushing a bit here, but I'm reading mixed messages.

Are you saying you don't want to change num due to maintenance concerns or because it conflicts with your vision? I can fully understand that and wouldn't mind closing the ticket and move on; no offense taken.

However, if you think packed support should be part of num eventually, do you think there is a constructive way forward that I / others could take to explore SIMD support and address your concerns?

[cuviper]

Are you saying you don't want to change num due to maintenance concerns or because it conflicts with your vision?

Are these necessarily exclusive? I don't want to make breaking changes to num, because I fear that would have a bad ripple effect across num's dependants. I don't want to add new crates to @rust-num, especially for a quickly-evolving area like SIMD, because I have little time for num as it is.

You're right that you can't implement foreign traits on foreign types. But right now, types like f32x2 are still in external crates of their own, so the answer is for those crates to depend on num-traits and implement those traits that are possible. It would be backwards for a conservative crate like this to depend on something experimental, as those implementations forge a public dependency.

When those types are stable in core/std, it will make sense to implement for them here.

[goertzenator]

@ralfbiedert , did you ever publish this library? Are you aware of any other crates or repos that address this?

[ralfbiedert]

I sort of gave up on this as packed_simd never really took off. I think I saw a math crate implement something similar (simba (?)) but haven't tried it.

[Congyuwang]

packed_simd is now in nightly rust std library. Any consideration for supporting them?