This works as expected:

    println!("{}", wide::f32x4::from(-1.25f32).fract()[0]); // -0.25
    println!("{}", (-1.25f32).fract()); // -0.25

    println!("{}", wide::f32x4::from(1.25f32).fract()[0]); // 0.25
    println!("{}", (1.25f32).fract()); // 0.25

This does not:

    println!("{}", wide::f32x4::from(-0.25f32).fract()[0]); // 0
    println!("{}", (-0.25f32).fract()); // -0.25

    println!("{}", wide::f32x4::from(0.25f32).fract()[0]); // 0
    println!("{}", (0.25f32).fract()); // 0.25

~/Local/widetrunc $ rustup show
Default host: x86_64-pc-windows-gnu

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc (default)
nightly-x86_64-pc-windows-msvc

active toolchain
----------------

stable-x86_64-pc-windows-msvc (default)
rustc 1.36.0 (a53f9df32 2019-07-03)

Right now we call sin and cos by calling sin_cos and then taking one or the other. However, we should verify that "the right thing" happens and it skips the final calculation of the non-used value.

It looks like the only tools from bytemuck being used are cast, cast_mut, cast_ref, Pod, Zeroable for a series of already known good casts (like m128 -> [f32; 4]). This might be able to be removed for a raw transmute. This would marginally improve performance probably.

would enable better sqrt outside of x86, possibly other things

There's no Ceil or Floor method implemented for the wide types.

Based off of Issue #15, it appears that only Intel has intrinsics for floor/ceil, and other architectures will need a manually implemented version.

I'm trying to switch from f32x4 to f32x8 in my project, which is fairly straight-forward thanks to wide's fallback mechanism. But I also use a lot of i32x8/u32x8, which means that on SSE2 I'm stuck with scalar, which is very slow.

Is there a reason why i32x8/u32x8 doesn't support SSE2 fallback? f32x8 also uses two m128, but requires only SSE2 and not SSSE3.
I can try implementing SSE2 fallback for i32x8/u32x8 if you're interested.

We probably screwed it up somewhere.

An implementation of this would be really useful for monte carlo simulations (pricing), and anywhere where 4 or 8 random independent randoms are needed.

https://github.com/lemire/simdpcg or
https://mathoverflow.net/questions/104915/pseudo-random-algorithm-allowing-o1-computation-of-nth-element

I'm not sure how "good" it needs to be for the purposes of this library.

I think the second one could be quite simple and efficient to implement.

Specifically _mm_cvttps_epi32.

Looks like it missing or I could not find it.

pathfinder_simd implements it via f32x4. It's very useful when working with points/vectors.

Waiting on rust-lang/rust#64693

Right now it looks like

f32x4(0.99997190.999972160.99997260.9999726)

Currently, the crate has two dependencies, and for such a simple and low-level crate I would assumed that it should not have any dependencies at all. At least this is what I'm trying to do with my crates.

Would you be interested in removing all the dependencies?

I understand that this is a controversial question, but it's weird to see a Rust crate that doesn't follow Rust's code style, like basically everyone else.

Is there a chance you would switch to the default code style?

For @termhn

Needed for spherical linear interpolation

The create doesn't have dedicated SSE/AVX features and relies on target_feature, but it's kinda broken. How do you test the scalar implementations?

should work the same as how VectorType::from(ScalarType) works now, just another more explicit name for it

This one fits into 256bits, so it can be implemented via AVX.

Is there a method to get the wide type content as a slice of primitive types? Like f32x4 -> [f32; 4]?

We should probably support this I guess. Low priority though.

The Debug output for, let's say, f32x4 looks like this:

(1.95763, 1.95276, 1.9478897, 1.9430195)

Maybe it would be better to have something like:

f32x4(1.95763, 1.95276, 1.9478897, 1.9430195)

I tried to use the wide::sin_f32 and wide::cos_f32 functions. I got some confusing results so I plotted some of the results. This plot shows the functions' results as well as the real sin and cos values on the interval -6.5..6.5 (about minus 2pi to 2pi):

What gives?

_mm_rcp_ps and _mm_rsqrt_ps correspondingly.

It would be great to have a documentation, especially Intel-like: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=3333,100,100&text=_mm512_add_epi32

FOR j := 0 to 15
	i := j*32
	dst[i+31:i] := a[i+31:i] + b[i+31:i]
ENDFOR
dst[MAX:512] := 0

The only hardware move mask instruction is for i8, so it's unclear what we should do for the other integer types. They could just not support move mask at all, or we could try to... just have them give 16 bits of into even if they're less lanes wide? That's weird, but it is fast.

Something to think about I guess.

For use with "mask" values returned after comparison ops.

for example,

if thing.cmp_eq(other_thing).any() {
   // do_the_thing
}

some people like the increased type safety.

this is a breaking change so it'd be in 0.6, but otherwise it's not hard.

It would be nice to continue with stable releases and have access to safe_arch_m256 functions

We can't implement the literal PartialEq and PartialOrd traits, but we can provide methods that do a wide comparison and then give a wide output of some sort.

I benched the SSE4.1 truncate with the SSE2 truncate and found the SSE4.1 version to be 5%-15% slower. Might not be worth keeping?

    pub fn trunc41(self) -> Self {
        unsafe { f32x4(_mm_round_ps(self.0, _MM_FROUND_TO_ZERO | _MM_FROUND_NO_EXC)) }
    }

    pub fn trunc2(self) -> Self {
        unsafe { f32x4(_mm_cvtepi32_ps(_mm_cvttps_epi32(self.0))) }
    }

Due to #62 Moved cmp operators into traits. No usability changes. which now requires one to import the trait to be able to use the functions which is a breaking change. Due to this ultraviolet doesn't compile anymore for example.

This is ofc just assuming this crate intends to stay semver compatible in minor versions prior to a 1.0 release.

or something

The following functions are not available in core, not even as nightly intrinsics, so we can't flip on no_std until we have some way to do them ourselves.

• acos
• acosh
• asin
• asinh
• atan
• atan2
• atanh
• cbrt
• cosh
• exp
• exp_m1
• hypot
• ln_1p
• log
• log10
• log2
• sinh
• tanh
• fract
• mul_add
• signum
• sin_cos

The impl From<i32> for i32x4 uses new(i32, i32, i32, i32) always. There's an intrinsic to not do that.

impl From<i32> for i32x4 {
  #[inline]
  #[must_use]
  fn from(i: i32) -> Self {
   magic( _mm_set1_epi32(i))
  }
}

Line 138 in lib.rs needs to be changed to:

unsafe { core::intrinsics::sqrtf32(x) }

Otherwise the build will fail on nightly for platforms without SSE support. I found this when I tried to build ultraviolet for Wasm.

for example ONE, ZERO, FRAC_PI_BLAH, etc.

Right now they're only SIMD with intel, but it should be easy enough to make them SIMD all the time.

There is is_nan(), but it returns Self and I'm looking for bool. Something like all_true.

Useful for a lot of pricing simulations

A simplistic CI run shows that there's at least some errors, but probably nothing crazy?

This will make the interface a bit more ergonomic and allow extending types easier.

• exp
• log/ln

Deprecated

• abs_sub

Unstable (but stable soon!)

• div_euclid
• rem_euclid
• clamp

Needs Other Types

• to_bits
• from_bits

Not Sure How To Handle Bools Yet

• is_finite
• is_infinite
• is_nan
• is_normal
• is_sign_negative
• is_sign_positive

Right now we have an i32x4 version and a f32x4 version but really we just need a 128-bit version and then have all sorts of types within it.