Yet another Hacker News

Fearless SIMD v1.0

54 points verdagon 2 days ago 9 comments

PoignardAzur 1 day ago | parent

Pretty happy this broke the 0.x curse!

the__alchemist 51 minutes ago | parent

The default system for Rust libs is ZeroVer: https://0ver.org/

meowface 37 minutes ago | parent

PuTTY out since 1999 and bumped to 0.82 in 2024 is pretty incredible

dang 1 hour ago | parent

Related. Others?

Towards fearless SIMD, 7 years later - https://news.ycombinator.com/item?id=43519823 - March 2025 (175 comments)

Towards fearless SIMD - https://news.ycombinator.com/item?id=18293209 - Oct 2018 (81 comments)

elendilm 44 minutes ago | parent

Congratulations.

Nice work. Looking forward to it.

JMKH42 44 minutes ago | parent

I started an early Rust SIMD crate with similar aims (SIMDeez) and so I know how hard it is to do this well, so wanted to say congratulations to everyone who worked on Fearless SIMD. Tools like this are really nice for being able to leverage the gigantic performance modern CPUs make available without having to write intrinsics for each platform.

modulovalue 23 minutes ago | parent

I’m currently working on adding better SIMD support to Dart (https://github.com/dart-lang/sdk/issues/64170) and I have a question for the author or others here.

Does Rust or any other language support customizing the compiler so that interprocedural analyses can track custom subsets of, for example, doubles so that the compiler can choose the most efficient instruction sequence for example for min/max? If we know a double is never NaN then we can emit only one instruction on x86, but have to emit one more on arm64. If we know a double is never zero and never NaN, we can emit a single instruction on both.

This whole conversation between relaxed SIMD and deterministic SIMD seems to only exist because our compilers are not smart enough and/or their whole program analyses don’t support any plugin-like capabilities.

There are other examples where if we know a SIMD bitmask is canonical (all 1s per lane) then we can implement horizontal reductions more efficiently. This is very niche and I doubt that any language supports interprocedural analyses with such a rich domain, so it feels like a hole in the programming language space.

athrowaway3z 16 minutes ago | parent

Last time i checked; no.

But I suspect you're overvaluing the potential savings. Knowing when a float is 0.0 or NaN beforehand is almost entirely impossible, except for the most trivial of cases - like when you first initialize a variable or first enter a loop. Everything after that is very hard or impossible with floats as they are.

Those cases can be const folded at compile time.

Those cases are never a measurable bottleneck.

The closest thing I know of in the realm of the optimization you're curious about is Rust NonZero* variants, but they're used for enum compression afaik.

VorpalWay 3 minutes ago | parent

Not yet that I know of, though perhaps LLVM might be able to infer simple cases (when loading from a known constant for example).

Pattern types could potentially maybe in the future allow for the compiler to know more details though. They are a nightly feature, and afaik only for enums, integers and pointers so far. The idea would be that you can define a custom type such as "an integer between 7 and 45" and everything else become niches for niche optimisation (e.g. for `Option<MyFunkyInt>` some of those impossible values would be used to represent the None case of the wrapping Option).

But I could envisage a future in which you could say "f64 without NaN" which would both make those available for niches and potentially tell LLVM about this. However, we are very far from any of that currently. And it might not be what you want, since you would need to add checks when you perform operations to ensure the value doesn't suddenly become a NaN. Which is way more complicated than ensuring integers don't become, say, zero. It will likely be much harder to optimise away the checks.