Check x86 features even in no_std

[nazar-pc]

This makes it possible to use accelerated versions with runtime feature detection in no_std environment.

This is nice in projects where bare-metal implementation is needed or when most all the code is already no_std and requiring std just to get a faster version of blake3 is inconvenient.

I went with well known and well maintained cpufeatures, though eventually previously used macros should become usable from ::core: rust-lang/rfcs#2725

Note that cpufeatures already handles cases where features are enabled at compile time, so there is no need for explicit #[cfg(target_feature = "X")] blocks anymore.

The only thing that still depends on std feature now is std::io.

[oconnor663]

Interesting, this is my first time looking at the cpufeatures crate. I'll need to read the docs.

[oconnor663]

Do you know what this line means in their docs?

NOTE: target features with an asterisk are unstable (nightly-only) and subject to change to match upstream name changes in the Rust standard library.

avx512f and avx512vl both have stars next to their names, even though they appear to work on the stable toolchain. Are the docs out of date?

[nazar-pc]

There was a drama around AVX10 versions with both 512-bit and 256-bit-only vector support, but eventually Intel decided to roll it back and settled on 512-bit only. I think it is related to that, see rust-lang/rust#138843

I don't know if avx512f and avx512vl will ever go away, but I'd speculate that probably not because there are existing CPUs that don't support any version of the AVX10, but do support some of those instructions and there must be a way to detect that.

I just tested on AMD 7970X CPU (Zen 4, AVX512-capable) and performance both before and after is the same, meaning the features are detected the same way.

Maybe @tarcieri can share some more details about this if he has time.

[nazar-pc]

I think this is a better link, AVX512 features are about to be stabilized: rust-lang/rust#138940

[oconnor663]

❤️

[oconnor663]

Follow-up doc changes in f3e0184.

[nazar-pc]

I'd appreciate 1.8.3 release with this change included, it has been a while since PR was merged

[oconnor663]

Good idea, done!