6 ms·

The cpu_features library

183 points by stablemap 9y ago

CoolGuySteve 9y ago
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.
smhx 9y ago
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.
IronWolve 9y ago
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 9y ago
  dmidecode decodes the dmi. lshw lists the hardware. lscpu lists the cpus.
wyldfire 9y ago
> 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 9y ago
  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 9y ago
    > 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.)
    - jcranmer 9y ago
      Your impression is correct.
    - haberman 9y ago
      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.
  - jcranmer 9y ago
    CPUID on x86 is a user-level instruction. When you're doing processor-assisted emulation, CPUID is an instruction that does cause an exit to the hypervisor, which does allow you to do CPUID emulation. You clearly don't need such instructions to be privileged to do emulation games with CPUID.
pjmlp 9y ago
They already had a cpu features library on the Android NDK. https://android.googlesource.com/platform/ndk.git/+/master/sources/android/cpufeatures/ https://android.googlesource.com/platform/ndk.git/+/master/s...
- gchatelet 9y ago
  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.
saagarjha 9y ago
Is this something that can be done at compile time? Would the compiler not have access to this information?
- def- 9y ago
  Comment from the post: > Just in case anyone is tempted, please do not write code that assumes the host on which it is compiled will always be the host on which it will be executed.
  - bobbyi_settv 9y ago
    A related note: Don't assume that all AWS EC2 instances of a given type use identical CPUs.
    - mbajkowski 9y ago
      very good point, this has been my experience as well, particularly for burstable instances such as the T2s
    - _msw_ 9y ago
      When the processor model varies for more recent generations of EC2 instances it is documented here: https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/ Scroll down to get to the table that includes Physical Processor, Intel AVX, Intel AVX2, etc. T2 instances do run on a number of different processor models, therefore it is listed as "Intel Xeon Family." M4 instances run on Intel Xeon E5-2676 v3 (Haswell) or Intel Xeon E5-2686 v4 (Broadwell), though m4.10xlarge only runs on Haswell and m4.16xlarge only runs on Broadwell. Pay close attention to the * in the table for those instances that run on either Haswell or Broadwell. Generally you will find that the recent generations of EC2 instances for C and R have identical CPUs within a generation.
- mnx 9y ago
  Only if you are compiling and running on the same machine, no?
- 9y ago
jwilk 9y ago
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.html https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.ht... https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-Functions.html https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-Function...
- bringtheaction 9y ago
  Does clang have anything similar?
  - jwilk 9y ago
    Since Clang 3.8 at least, it has __builtin_cpu_supports() too.
vram22 9y ago
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-cores-in-your.html https://jugad2.blogspot.in/2016/09/numcores-find-number-of-c... 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-processing-in-d-with.html https://jugad2.blogspot.in/2016/12/simple-parallel-processin...
anonymfus 9y ago
AMD's Family 12h processors (Llano) are unknown to this library. VIA also apparently does not exist.
- gchatelet 9y ago
  Can you please file an issue on github?
jcoffland 9y ago
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.
deleted 9y ago
[deleted]

183 points by stablemap 9y ago

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.

smhx 9y ago

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.

IronWolve 9y ago

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 9y ago
dmidecode decodes the dmi. lshw lists the hardware. lscpu lists the cpus.

wyldfire 9y ago

> 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 9y ago
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 9y ago
  > 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.)
  - jcranmer 9y ago
    Your impression is correct.
  - haberman 9y ago
    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.
- jcranmer 9y ago
  CPUID on x86 is a user-level instruction. When you're doing processor-assisted emulation, CPUID is an instruction that does cause an exit to the hypervisor, which does allow you to do CPUID emulation. You clearly don't need such instructions to be privileged to do emulation games with CPUID.

pjmlp 9y ago

They already had a cpu features library on the Android NDK. https://android.googlesource.com/platform/ndk.git/+/master/sources/android/cpufeatures/ https://android.googlesource.com/platform/ndk.git/+/master/s...

gchatelet 9y ago
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.

saagarjha 9y ago

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

def- 9y ago
Comment from the post: > Just in case anyone is tempted, please do not write code that assumes the host on which it is compiled will always be the host on which it will be executed.
- bobbyi_settv 9y ago
  A related note: Don't assume that all AWS EC2 instances of a given type use identical CPUs.
  - mbajkowski 9y ago
    very good point, this has been my experience as well, particularly for burstable instances such as the T2s
  - _msw_ 9y ago
    When the processor model varies for more recent generations of EC2 instances it is documented here: https://aws.amazon.com/ec2/instance-types/ https://aws.amazon.com/ec2/instance-types/ Scroll down to get to the table that includes Physical Processor, Intel AVX, Intel AVX2, etc. T2 instances do run on a number of different processor models, therefore it is listed as "Intel Xeon Family." M4 instances run on Intel Xeon E5-2676 v3 (Haswell) or Intel Xeon E5-2686 v4 (Broadwell), though m4.10xlarge only runs on Haswell and m4.16xlarge only runs on Broadwell. Pay close attention to the * in the table for those instances that run on either Haswell or Broadwell. Generally you will find that the recent generations of EC2 instances for C and R have identical CPUs within a generation.
mnx 9y ago
Only if you are compiling and running on the same machine, no?
9y ago

jwilk 9y ago

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.html https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.ht... https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-Functions.html https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Built-in-Function...

bringtheaction 9y ago
Does clang have anything similar?
- jwilk 9y ago
  Since Clang 3.8 at least, it has __builtin_cpu_supports() too.

vram22 9y ago

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-cores-in-your.html https://jugad2.blogspot.in/2016/09/numcores-find-number-of-c... 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-processing-in-d-with.html https://jugad2.blogspot.in/2016/12/simple-parallel-processin...

anonymfus 9y ago

AMD's Family 12h processors (Llano) are unknown to this library. VIA also apparently does not exist.

gchatelet 9y ago
Can you please file an issue on github?

jcoffland 9y ago

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.

deleted 9y ago

[deleted]