
The cpu_features library - stablemap
https://opensource.googleblog.com/2018/02/cpu-features-library.html
======
jwilk
GCC has the __builtin_cpu_supports() function on some architectures, so you
may want to use that instead.

It's supported:

* on x86 since GCC 4.8

* on PowerPC since GCC 6 (you will also need glibc ≥ 2.23)

Documentation:

[https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-
Functions.ht...](https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-
Functions.html)

[https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-
Function...](https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-
Functions.html)

~~~
bringtheaction
Does clang have anything similar?

~~~
jwilk
Since Clang 3.8 at least, it has __builtin_cpu_supports() too.

------
smhx
an alternative library
[cpuinfo]([https://github.com/Maratyszcza/cpuinfo](https://github.com/Maratyszcza/cpuinfo))
is a similar offering but also additionally exposes more information such as
cache sizes, topology information (number of sockets, etc.) and information on
attached integrated GPU.

------
CoolGuySteve
I guess this is helpful for new projects, but most high performance
programmers are already parsing cpuid output.

I was hoping for a more convenient hwloc replacement for discovering NUMA
topology and logical/physical cores.

I guess what I mean is that if you're already at the level of caring what avx
you have, then parsing cpuid isn't too difficult.

------
pjmlp
They already had a cpu features library on the Android NDK.

[https://android.googlesource.com/platform/ndk.git/+/master/s...](https://android.googlesource.com/platform/ndk.git/+/master/sources/android/cpufeatures/)

~~~
gchatelet
FYI I'm the author of the library. I designed it with the help of the person
who wrote the code for the Android NDK. We agreed that the end goal is to
replace Android NDK specific code with this library - the NDK will expose the
exact same API but using this library under the hood.

------
wyldfire
> features are retrieved by using the cpuid instruction. *Unfortunately this
> instruction is privileged for some architectures, in which case we fall back
> to Linux.

What's the rationale for making this instruction privileged for the other
procs? I can kinda understand making system registers privileged reads but if
you have your own encoding there's "no reason" not to give this to everyone,
right?

~~~
valarauca1
several

1\. Malware can infer details from CPUID to guess if it’s in a VM or not.
Useful to avoid detection/analysis.

2\. When processes execute in a legacy mode you may trap on CPUID to hide
details the library won’t understand, or doesn’t expect to exist. To avoid
backwards compatibility issues... better safe then sorry.

3\. When developing SIMD related libraries which need to be portable across
multiple CPU versions you may set up a CPUID mask (so trap, then hide
features) to ensure compatibility on legacy computers.

Overall having the ability to trap, and rewrite the CPUID instruction is
incredibly useful. The difference between denying, and rewriting just boils
down to if a callback is provided or not. Both features require disabling
native CPUID execution.

~~~
dbaupp
_> 3\. When developing SIMD related libraries which need to be portable across
multiple CPU versions you may set up a CPUID mask (so trap, then hide
features) to ensure compatibility on legacy computers._

Huh? My impression was CPUID was exactly the opposite: using it properly
allows ensuring compatibility on older computers while still getting maximum
performance, since one can dynamically dispatch to an implementation that uses
only what is supported. (E.g. switch between an SSE2 version and an AVX
version.)

~~~
haberman
I think GP is saying that unit tests for such dynamically-dispatching code
will want to be able to inject older CPUIDs, so the compatibility fallbacks
have test coverage. If CPUID is a native instruction, it's harder to inject a
fake value.

I'm not sure I find this compelling though. It's easy to make your own CPUID
function that doesn't actually call "CPUID" in a test build.

------
anonymfus
AMD's Family 12h processors (Llano) are unknown to this library.

VIA also apparently does not exist.

~~~
gchatelet
Can you please file an issue on github?

------
jcoffland
Intel has really made a mess out of CPUID. It's supposed to be an easy way to
query CPU features, and for some things it is, but they keep changing the way
it works especially for newer features line AVX2. It's like they cannot even
follow their own APIs.

------
IronWolve
Wonder if dmidecode could be updated to include more cpu details, the cache
features and other flags are limited.

    
    
            Version: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
            Voltage: 0.8 V
            External Clock: 100 MHz
            Max Speed: 2900 MHz
            Current Speed: 2300 MHz
            Status: Populated, Enabled
            Upgrade: Other
            L1 Cache Handle: 0x004C
            L2 Cache Handle: 0x004D
            L3 Cache Handle: 0x004E
            Serial Number: To Be Filled By O.E.M.
            Asset Tag: To Be Filled By O.E.M.
            Part Number: To Be Filled By O.E.M.
            Core Count: 4
            Core Enabled: 4
            Thread Count: 8

~~~
Hello71
dmidecode decodes the dmi. lshw lists the hardware. lscpu lists the cpus.

------
vram22
The std.parallelism library in D lets you get some basic CPU info:

[https://dlang.org/phobos/std_parallelism.html#.totalCPUs](https://dlang.org/phobos/std_parallelism.html#.totalCPUs)

num_cores: find number of cores in your PC's processor

[https://jugad2.blogspot.in/2016/09/numcores-find-number-
of-c...](https://jugad2.blogspot.in/2016/09/numcores-find-number-of-cores-in-
your.html)

You can also use the library for some simple parallel processing, as the name
indicates:

Simple parallel processing in D with std.parallelism

[https://jugad2.blogspot.in/2016/12/simple-parallel-
processin...](https://jugad2.blogspot.in/2016/12/simple-parallel-processing-
in-d-with.html)

------
saagarjha
Is this something that can be done at compile time? Would the compiler not
have access to this information?

~~~
EKLM-ZK88
The CPU you compile on will probably not be the CPU your program runs on. If
you know what CPU you're running on I guess you can just make assumptions
about what features that chip supports, but it's much safer to use something
like this to verify at runtime that you support avx or whatever features you
need.

~~~
saagarjha
I was getting at cross-compilation, where you _do_ know the CPU you're running
on, but I see that this breaks down because the binaries can run on CPUs that
support different features.

