search

shepmaster / jetscii

A tiny library to efficiently search strings for sets of ASCII characters and byte slices for sets of bytes.
Apache License 2.0
113 stars 20 forks source link

Use cpuid #8

Open bluss opened 9 years ago

bluss commented 9 years ago

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

bluss commented 9 years ago

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

shepmaster commented 9 years ago

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 commented 9 years ago

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

shepmaster commented 9 years ago

Basic beginning in cpuid-rs.

bluss commented 9 years ago

Cool

shepmaster commented 9 years ago

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 commented 9 years ago

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

ArtemGr commented 8 years ago

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.