17 releases (4 breaking)

✓ Uses Rust 2018 edition

0.4.3 Jan 8, 2020
0.4.1 Dec 11, 2019
0.3.2 Nov 27, 2019

#35 in Hardware support

Download history 307/week @ 2019-12-10 39/week @ 2019-12-17 65/week @ 2019-12-24 211/week @ 2019-12-31 447/week @ 2020-01-07 438/week @ 2020-01-14 499/week @ 2020-01-21 354/week @ 2020-01-28 153/week @ 2020-02-04 221/week @ 2020-02-11 413/week @ 2020-02-18 364/week @ 2020-02-25 305/week @ 2020-03-03 237/week @ 2020-03-10 239/week @ 2020-03-17 283/week @ 2020-03-24

407 downloads per month
Used in 12 crates (via ultraviolet)

Zlib license

195KB
5K SLoC

License:Zlib Minimum Rust Version travis.ci AppVeyor crates.io docs.rs

wide

A crate to help you go wide.

For more info see the docs.

CI coverage:

  • Tested on: x86, x86_64, wasm
  • Built on: armv7, aarch64, thumbv7neon

lib.rs:

A crate to help you go wide.

Specifically, this crate has data types for blocks of primitives packed together and used as a single unit. This works very well with SIMD/vector hardware of various targets. Both in terms of explicit SIMD usage and also in terms of allowing LLVM's auto-vectorizer to do its job.

All SIMD usage is on a best effort basis. Results will vary based on target, optimization level, method, and if you're using a Nightly compiler or not. Otherwise you get a "fallback" implementation, which will just do the normal computation on each lane individually.

  • Note: The crate will auto-detect if you're using Nightly and take advantage of it. You don't do anything on your part. Activate the always_use_stable feature if you'd like to suppress this effect such as for testing purposes.

What About packed_simd?

Compared to the packed_simd RFC efforts, this crate is less concerned with complete coverage of all possible intrinsics and being totally generic across all widths. Instead, I focus on having a very simple, easy to understand setup that avoids generics and tries to just be plain and obvious at all times. The goal is that using a wide type should be as close as possible to using the scalar version of the same type. Some function designed for f32 inputs and outputs should "just work" when you change it to f32x4 inputs and outputs.

Also, packed_simd is Nightly-only, whereas this crate works on Stable. Even on Stable this crate will give you reasonable levels of SIMD just from LLVM's auto-vectorizer being pretty good at its job when you give it code that it recognizes.

When packed_simd eventually makes it into Stable it might make this crate obsolete. However, in September of 2019 I asked the packed_simd folks if there was any kind of ETA, 6 months, 12 months, or more, and they just said "no ETA". So I'm not gonna wait around for packed_simd.

Dependencies