search

Lokathor / wide

A crate to help you go wide. By which I mean use SIMD stuff.
https://docs.rs/wide
zlib License
288 stars 24 forks source link

Add fast type conversion methods where possible #117

Open shssoichiro opened 1 year ago

shssoichiro commented 1 year ago

For SIMD types that have intrinsics for quickly converting to another type, methods were added to leverage these intrinsics for fast conversion.

shssoichiro commented 1 year ago

As someone who is not an expert on wasm, I have no idea why the wasm tests are failing saying that f32 and f64 do not have a round method. :confused:

Lokathor commented 1 year ago

@CryZe you're the wasm person, shouldn't round be a normal method? or is this a no_std related thing maybe?

CryZe commented 1 year ago

From a quick glance this looks like a no_std problem, as any libm call (round, sin, cos, ...) requires std or the usage of the libm crate.

shssoichiro commented 1 year ago

Is there a recommended fix? The one that comes to mind for me is to only include the round methods if std is included.

Edit: I see that there's e.g. a f32x4::round() method although it claims that the fallback implementation is quite slow...

Lokathor commented 1 year ago

The fallback is to call libm and do it in hardware. However, that fallback ends up being called only with no_std outside of x86 or x86_64. So... maybe that's okay?

Lokathor commented 1 year ago

I guess for new methods, we should make the method not exist if it can't perform well. people can always turn on the std feature.

shssoichiro commented 1 year ago

It probably makes sense to add this std fallback on round, so I posted #118

shssoichiro commented 1 year ago

Likewise I fixed this PR up to use the f**x*::round functions, which will benefit from the patch in #118 once that's merged as well.

shssoichiro commented 1 year ago

I'm also noticing that a few of these do have existing functions, for example f32x4::fast_round_int which I didn't see before because I was looking for the wrong thing probably. What should we do in those cases? Have f32x4::to_i32x4 call through to fast_round_int perhaps? (Even though this results in two methods that do the same thing, I personally like the idea of having consistent naming for all casting methods, so it's easy for users to find.)

Lokathor commented 1 year ago

I agree that naming consistency would be best.

Let's make the old names just call to the new name version, and then we can mark the old names as deprecated with a note that people should move to the new names instead. Then eventually we can remove the old names entirely in 0.8 or 0.9 or whenever.