Use cpuid

[bluss]

I think we should use cpuid to check for presence of sse4_2

[bluss]

Maybe https://crates.io/crates/cpuid

[shepmaster]

Yeah, this is probably a good idea. I might rather roll our own detection, as cpuid appears to be a binding to another library, which seems like a large requirement for the simple requirement we have:

//! Rust bindings for [libpcuid](https://github.com/anrieff/libcpuid)
//! CPU detection and feature extraction library.

Since we are already doing inline assembly, adding another chunk shouldn't be that hard, right? (Famous last words). I'd also like to be cautious about performance, perhaps caching the result of the check (global mutable state... yuck).

[bluss]

Absolutely, it should be done only once, using the once thing from libstd I think

[shepmaster]

Basic beginning in cpuid-rs.

[bluss]

Cool

[shepmaster]

An interesting question - at what level should this check be done? There are two I can think of:

1. At compile time, via a custom build script.
2. At run time.

Compile time has the nice benefit of producing just the code appropriate for the machine. Run time means that a single compiled program could run on multiple machines, but has at least some kind of overhead on a per-call basis.

I don't actually know what the base line of support that Rust itself offers with regards to compiling and running on different architectures.

[shepmaster]

Of course, there's always "add more feature flags" to support both options...

[ArtemGr]

Right now rustc generates a generic executable, people expect to be able to copy it to a compatibe machine and run there. -march=native isn't widely used. So it makes sense to default to the runtime check.

When -march=native builds become a norm (e.g. supported by cargo) then it'll make sense to detect such builds and do the compile time check optimization.