Add automatic CPU feature detection #21
Conversation
| #[multiversion::multiversion(targets("x86_64+avx512f+avx512bw+avx512cd+avx512dq+avx512vl", // x86_64-v4 | ||
| "x86_64+avx2+fma", // x86_64-v3 | ||
| "x86_64+sse4.2", // x86_64-v2 | ||
| "x86+avx512f+avx512bw+avx512cd+avx512dq+avx512vl", |
There was a problem hiding this comment.
Is 32-bit x86 with AVX-512 common enough to bloat the binary with dedicated code for it? Ditto for AVX2.
There was a problem hiding this comment.
Hard to say, I really don't know. This code only gets generated when building for x86, not x86-64. What do people run x86 on these days? Is it more likely someone is running on some Pentium 4 or just a modern CPU in 32-bit mode? I'm not really sure.
|
Hi @calebzulawski, Thank you for the kind words and your contribution! I'm going to try to figure out why the coverage check is failing, and then I'll re-run the benchmarks on the same machine. Best, |
Correct--standard aarch64 has neon, so no need to detect it. You can have nonstandard aarch64 without it, but then there is no need to detect it. SVE actually can map to portable SIMD, but it will need more support from the compiler. E.g. you can have separate SVE-128 and SVE-256 target features that each refer to a specific SVE register size, detected at runtime. I digress... |
calebzulawski
force-pushed
the
multiversion
branch
from
4985516 to
f34eb32
Compare
|
I rebased--not sure if that's expected to fix the code coverage issue. |
|
Here are the benchmark results. Since your PR was already merged, I ran this from the main branch.
|
|
Thank you! I think that looks comparable to the old benchmark results, what do you think? |
|
This looks great! Thank you for your contribution. This was the last thing I wanted merged prior to releasing the next version. |
|
Just wanted to add that I re-ran the benchmarks for Best, |
|
Awesome! Excited to see a new release! |
I love this project! I joined the
std::simdteam originally after getting frustrated writing myfouriercrate.Full disclosure--the
multiversioncrate is mine, but I think it works perfectly here, especially considering the desire to forbid unsafe code.I removed all references to
-Ctarget-cpu=nativeand the like--I believe with this change, it should make no difference, at least on x86(-64) and aarch64. Plus, in my opinion, it's only useful for research and not commercial/enterprise software, since it's not really possible to redistribute-Ctarget-cpu=nativecode. I think this benchmark is more faithful to real use.This PR is going to need a follow-up commit updating the benchmark results.