Closed ralfbiedert closed 6 years ago
Sounds like a good way to get some drive-by commits from people who know of, say, an SSE2 polyfill for an SSE4 intrinsic, too. I think printing to stderr once per function if a certain feature is enabled is a pretty good way to go about this.
SIMD never looked this good:
test tests::kernel_i16 ... ok
🚄 faster is using HARDWARE acceleration here (src/arch/x86/intrin/sum.rs:168).
🚄 faster is using HARDWARE acceleration here (src/arch/x86/intrin/upcast.rs:249).
test tests::kernel_i32 ... ok
â›” faster is using SOFTWARE emulation here (src/arch/x86/intrin/sum.rs:259).
test tests::kernel_i64 ... ok
test tests::kernel_i8 ... ok
â›” faster is using SOFTWARE emulation here (src/arch/x86/intrin/sum.rs:259).
🚄 faster is using HARDWARE acceleration here (src/arch/x86/intrin/sum.rs:104).
test tests::kernel_u32 ... ok
test tests::kernel_u16 ... ok
test tests::kernel_u8 ... ok
test tests::kernel_u64 ... ok
Resolved by #52. Thanks a lot!
Faster should have a way to hint at performance issues.
From a user's point of view it is hard to predict whether SIMD intrinsics are issued, or a fallback implementation is used. Ideally there should be a method, macro, compiler flag, ... to enable performance metrics or warnings.
In the most simple form, each fallback implementation could call something like
fallback!
, which in turn could be enabled or disabled with a compile feature. That macro could then emit warnings (maybe even with file names and line numbers).As a user I could then either change my code, file an issue, or implement the missing intrinsic myself.