Add fearless_simd v0.7 announcement - #148
Conversation
Shnatsel
changed the title
| No matter what level of abstraction you're after, be it autovectorization and multiversioning, portable SIMD, or safe access to raw intrinsics and nothing more, `fearless_simd` has you covered! | ||
|
|
||
| It features zero dependencies, short build times, safe public APIs, and [very little](https://gist.github.com/Shnatsel/61fc294987a1e051ce3835c97dc0fc19) `unsafe` under the hood - orders of magnitude less than the alternatives! |
There was a problem hiding this comment.
No action needed, but I do want to make sure we are cognisant of the cost of repeating the same blurb in every post (that people will start to skim past it and perhaps miss the first paragraph).
Perhaps just a reordering to put the "highlights" above these?
But keeping it as-is is fine - use your judgement.
There was a problem hiding this comment.
You'd also get all the info from the intro by skimming the headlines, so in this post I think it's fine. Something to consider in the future, certainly.
|
|
||
| No matter what level of abstraction you're after, be it autovectorization and multiversioning, portable SIMD, or safe access to raw intrinsics and nothing more, `fearless_simd` has you covered! | ||
|
|
||
| It features zero dependencies, short build times, safe public APIs, and [very little](https://gist.github.com/Shnatsel/61fc294987a1e051ce3835c97dc0fc19) `unsafe` under the hood - orders of magnitude less than the alternatives! |
There was a problem hiding this comment.
Has this been moved to your github.io blog as well? Should it be?
(Although I realise that then means there are three URLs for it...)
There was a problem hiding this comment.
Good catch! Updated.
|
|
||
| Keeping track of which intrinsics are part of which instruction set was also challenging, and getting it wrong would be a memory safety violation. However, in v0.5 we [made the compiler keep track of it for us](https://shnatsel.github.io/safe-simd-in-rust-even-on-the-inside/), which removed the vast majority of `unsafe` blocks from `fearless_simd` and made implementing operations with uneven hardware support much easier. | ||
|
|
||
| All the other integer vector types (`i8`,`u8`,`i16`,`u16`,`i32`,`u32`) and `f32`/`f64` were already supported by previous releases, so 64-bit integers were the last missing piece for full type coverage. We will investigate supporting `f16` once the type is stabilized in the standard library. |
There was a problem hiding this comment.
No action needed. I'm presuming that there isn't an hardware which has vectors with 128 bit elements.
There was a problem hiding this comment.
Nope. The closest I could find was POWER10 which has ILP for f128 but not SIMD.
|
|
||
| ## Build time improvements | ||
|
|
||
| Despite the addition of 64-bit integer vectors, more supported operations, and an entirely new SSE2 SIMD level, the compilation time of `fearless_simd` when used as a dependency stayed the same as v0.6: 2 seconds from scratch for x86 and 1 second from scratch for Aarch64. This is measured via `cargo clean && cargo build --release --timings` in an empty crate depending on `fearless_simd`. |
There was a problem hiding this comment.
We should specify the actual CPUs for this.
There was a problem hiding this comment.
Added a note in the next sentence
|
|
||
| These days x86 systems without SSE4.2 are [very rare](https://firefoxgraphics.github.io/telemetry/#view=system). However, since SSE2 is part of the baseline instruction set in both x86_64 and i686 Rust targets, the presence of SSE2 can be assumed, without any runtime dispatch or multiversioning. Certain crates only need a very limited set of vector instructions and don't benefit from later extensions, so forgoing runtime dispatch can simplify the code and reduce binary size. | ||
|
|
||
| To better serve this use case, Fearless SIMD now has an explicit `Sse2` level with operations expressed in terms of SIMD intrinsics, rather than relying on autovectorization of the `Fallback` level when SSE4.2 is not available. |
There was a problem hiding this comment.
Unfortunately, I don't have alternative phrasing to suggest, but I think this needs to be rewritten slightly - I think we should be more clear than this means that by default on x86 we get better performance without compiling in an extra level.
There was a problem hiding this comment.
I've added an extra clarifying sentence, hopefully that explains the practical implications
|
|
||
| Earlier releases didn't support 64-bit integer vectors due to hardware support being spotty. For example, AVX2 lacks hardware support for many operations on 64-bit integers, so it would require emulation using the available SIMD instructions for those operations to get decent performance. | ||
|
|
||
| Keeping track of which intrinsics are part of which instruction set was also challenging, and getting it wrong would be a memory safety violation. However, in v0.5 we [made the compiler keep track of it for us](https://shnatsel.github.io/safe-simd-in-rust-even-on-the-inside/), which removed the vast majority of `unsafe` blocks from `fearless_simd` and made implementing operations with uneven hardware support much easier. |
2 participants
No description provided.