google / cpu_features Goto Github PK
View Code? Open in Web Editor NEWA cross platform C99 library to get cpu features at runtime.
License: Apache License 2.0
A cross platform C99 library to get cpu features at runtime.
License: Apache License 2.0
I assume this library is alpha-stage currently, but please tag versions/releases so people know exactly which revision of cpu_features
they are currently using.
0.2 tag is already several months old.
Would you now be open to create a new tag (0.3.0 or whatever) ?
Kind
Opening this to track support for Power Architecture.
@grooverdan and I are currently sorting out our IBM approvals to work on this.
You've got a build system that depends on c++, // comments
in your code, and you use the inline
keyword in string_view.h, leaving aside the stdint.h
includes and uintxx_t types scattered everywhere.
Attempting to compile this even once with -std=c89 would have revealed these problems. I recommend you put, at least,
set(CMAKE_C_FLAGS "-std=c89 ${CMAKE_C_FLAGS}")
in your CMakeLists.txt file.
Thanks for the cpu_features
library.
It looks like the library is missing a define for ARMv7. ARMv7 is important for some hand tuned algorithms. For example, one might bundle Andy Polyakov's Cryptogams AES and SHA algorithms, and make the baseline ARMv7 with -march=armv7-a
.
There are several reasons to make ARMv7 the baseline. ARMv7 is mostly the de facto standard nowadays, so using ARMv7 addresses the common case out of the box. ARMv7 ISA also enjoys a performance boost over older ISAs, and provides additional loads and stores not available in ARMv6 and below. However, ARMv5 and ARMv6 will show up on occasion, like old dev-boards and iPads, so a fallback is needed on occasion.
At runtime, user code may do something like the following:
if (HasARMv7()) {
CRYPTOGAMS_aes_encrypt(data, blocks, subkeys);
} else {
CXX_aes_encrypt(data, blocks, subkeys);
}
We can't really use ARM_NEON
as a proxy for ARMv7 because some ARMv6 devices have NEON. And some ARMv7 dev-boards lack NEON.
It looks like Mozilla synthesises it from /proc/cpuinfo
on Linux; see Changeset 522951ff7046. Crypto++ library utilizes a SIGILL
probe using movw
and movt
because getauxval
does not provide a define (movw
and movt
are part of ARMv7 ISA):
int a;
asm volatile("movw %0,%1 \n"
"movt %0,%1 \n"
: "=r"(a) : "i"(0x1234));
hasARMv7 = (a == 0x12341234);
Unfortunately, SIGILL
probes have several of shortcomings. First, they are expensive when compared to getauxval
and friends. Second, they only work with the GNU Assembler (GAS) or compatible assemblers. Third, they trash a program on Apple platforms. Apple does not restore the context properly when a longjmp
is taken, so they can't be used on iPhones and iPads.
Positive statement first: All works fine when doing static builds. Our project that wants to use cpu_features
has to build its libraries shared, though, too, and there I'm running into problems:
I read and followed these suggestions (#44 ) as well as the subproject build instructions but to no avail:
cpu_features
"local" cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DBUILD_PIC=ON -H. -Bcmake_build
this is the result of make
on Ubuntu:/usr/bin/ld: CMakeFiles/utils.dir/src/string_view.c.o: relocation R_X86_64_PC32 against symbol `CpuFeatures_StringView_IndexOf' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
CMakeFiles/cpu_features.dir/build.make:100: recipe for target 'libcpu_features.so' failed
make[2]: *** [libcpu_features.so] Error 1
CMakeFiles/Makefile2:178: recipe for target 'CMakeFiles/cpu_features.dir/all' failed
make[1]: *** [CMakeFiles/cpu_features.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
make
:[ 95%] Linking C executable list_cpu_features
CMakeFiles/list_cpu_features.dir/src/utils/list_cpu_features.c.o: In function `CreateTree':
list_cpu_features.c:(.text+0x575): undefined reference to `GetX86Info'
list_cpu_features.c:(.text+0x57d): undefined reference to `GetX86CacheInfo'
list_cpu_features.c:(.text+0x585): undefined reference to `FillX86BrandString'
list_cpu_features.c:(.text+0x676): undefined reference to `GetX86Microarchitecture'
list_cpu_features.c:(.text+0x67d): undefined reference to `GetX86MicroarchitectureName'
list_cpu_features.c:(.text+0x6c9): undefined reference to `GetX86FeaturesEnumValue'
list_cpu_features.c:(.text+0x6d9): undefined reference to `GetX86FeaturesEnumName'
collect2: error: ld returned 1 exit status
src/cpu_features/CMakeFiles/list_cpu_features.dir/build.make:95: recipe for target 'src/cpu_features/list_cpu_features' failed
make[2]: *** [src/cpu_features/list_cpu_features] Error 1
CMakeFiles/Makefile2:432: recipe for target 'src/cpu_features/CMakeFiles/list_cpu_features.dir/all' failed
make[1]: *** [src/cpu_features/CMakeFiles/list_cpu_features.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
--> Key question: Is the use of cpu_features
as a shared lib not just discouraged, but even no longer supported? If so do you see any way how to integrate it into a project that has to build its libraries shared? If so could you update your guidance for integration ? Thanks in advance!
@gchatelet Can you please release 0.4 from the master so we can update the conda package (https://anaconda.org/conda-forge/cpu_features) for further usage of cache information?
I was interested in adding iOS, macOS and Windows support, but the layout of the code is not conducive to this. src/cpuinfo_aarch64.c is highly Linux-specific. For an ARM64 Windows implementation, where would the code go? (In Windows, the ARM64 implementation would be based around IsProcessorFeaturePresent.)
vpclmulqdq should be pclmulqdq. The "v" version of the instruction simply means to encode the instruction in AVX format instead of SSE format.
this should be a tiny bit faster than getauxval() when it is supported.
It would be helpful in many ways to have a small driver program that would exercise the features of this library and would emit output on stdout after detecting all available features. This would allow for easier testing of the library on new platforms, as well as making it possible to integrate cpu_features
into non-C99 applications.
I would appreciate it if the documentation would reflect the fact that this library downloads approximately 55,000 lines of code from github at build time. This can cause problems for people who expect a build to work within sandboxed package-build environments.
cpu_features_cache_info.h
is missing when installing cpu_features
Hey! The code at https://github.com/google/cpu_features/blob/master/src/cpuid_x86_clang.c#L21 (and in the other files) is returning a stack-allocated value, which I think is a problem? I thought you needed an output parameter for that kind of thing.
EDIT: Oh it ends up copying it. Well maybe not bad then, but not ideal either?
Following the work that lscpu
has done, report more details of Arm CPUs.
http://suihkulokki.blogspot.fi/2018/02/making-sense-of-proccpuinfo-on-arm.html has background, and Jon Masters has RHEL info at https://twitter.com/jonmasters/status/963423759955910656 .
I tried it on my bare-metal ARMv7 - C1 instance on scaleaway and it failed to compile again
root@tuffy:~/projects/code/c-shared-libs# cd cpu_features/
root@tuffy:~/projects/code/c-shared-libs/cpu_features# cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -H. -Bcmake_build
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /root/projects/code/c-shared-libs/cpu_features/cmake_build
root@tuffy:~/projects/code/c-shared-libs/cpu_features# cd cmake_build/
root@tuffy:~/projects/code/c-shared-libs/cpu_features/cmake_build# make
Scanning dependencies of target cpu_features
[ 6%] Building C object CMakeFiles/cpu_features.dir/src/linux_features_aggregator.c.o
[ 13%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_clang_gcc.c.o
[ 20%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_msvc.c.o
[ 26%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_aarch64.c.o
[ 33%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_arm.c.o
[ 40%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_mips.c.o
[ 46%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_ppc.c.o
[ 53%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_x86.c.o
[ 60%] Building C object CMakeFiles/cpu_features.dir/src/filesystem.c.o
[ 66%] Building C object CMakeFiles/cpu_features.dir/src/hwcaps.c.o
[ 73%] Building C object CMakeFiles/cpu_features.dir/src/stack_line_reader.c.o
[ 80%] Building C object CMakeFiles/cpu_features.dir/src/string_view.c.o
[ 86%] Linking C shared library libcpu_features.so
[ 86%] Built target cpu_features
Scanning dependencies of target list_cpu_features
[ 93%] Building C object CMakeFiles/list_cpu_features.dir/src/utils/list_cpu_features.c.o
[100%] Linking C executable list_cpu_features
libcpu_features.so: undefined reference to `GetXCR0Eax'
libcpu_features.so: undefined reference to `CpuId'
collect2: error: ld returned 1 exit status
CMakeFiles/list_cpu_features.dir/build.make:95: recipe for target 'list_cpu_features' failed
make[2]: *** [list_cpu_features] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/list_cpu_features.dir/all' failed
make[1]: *** [CMakeFiles/list_cpu_features.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
Am I doing something wrong here ?
Hi everyone,
I was wondering if you could please tell how I could compile this as a shared library ?
I tried using cmake
but so far, without any success. Please point me to a better direction
Hi and thank you for the great project!
Can you please add install()
lines to your CMake code? This would allow setting -DCMAKE_INSTALL_PREFIX
to the cmake call and installing the final library via make install
.
Here is an example on how to install targets in modern CMake:
If you want, you can also generate a little *Config.cmake
file on install which makes it easy to find the library in projects depending on it.
ART on Android works around quirks/bugs in /proc/cpuinfo and aux vector, has support for cross compilation, detection of features via C preprocessor, CPUID instructions, undefined instruction exceptions, supports MIPS, ARM, Intel 32 and 64, etc.:
https://android.googlesource.com/platform/art/+/master/runtime/arch/instruction_set_features.h#36
Android NDK has something simple:
https://developer.android.com/ndk/guides/cpu-features.html
V8 CPU feature detection:
https://github.com/v8/v8/blob/master/src/base/cpu.h#L32
As there are OS/CPU bugs that cause issues standardizing on 1 library makes sense. As an author of the ART code I'm have a bias :-)
I downloaded lib and copied it to my project directory. My CMakeLists.txt :
cmake_minimum_required(VERSION 3.6)
add_subdirectory(cpu_features)
add_library(
myLib
SHARED
app/src/main/cpp/test.cpp
)
link_libraries(myLib cpu_features)
My test.cpp file:
#include "test.h"
#include <cpu-features.h>
I have 10: fatal error: 'cpu-features.h' file not found
error.
Please tell me what I'm doing wrong.
Thanks.
So setting features true (= 1) does not comply with standards. (They can either be -1 or 0)
However getting them is not a problem since -1 is true. (-1 is true but true might not always be -1)
Some proposed changes are in this pull request: #42
CPU-Z shows that CPU's code name is Coffe Lake
, but this code's output is Kaby Lake
.
cmpxchg16b
is generally supported on most, decently modern CPUs, but since the timeline already goes back to the old Core 2's, I wonder whether this could be added.
It's an important instruction (if you want 16-byte atomics), which is not supported on earlier Core 2's and some special AMDs.
Just an idea, adding cpu_features would be a great addition to to https://github.com/microsoft/vcpkg
Although through cat /proc/cpuinfo
shows SSE3, SSE4.1, SSE4.2, list_cpu_features
doesn't list them out.
Output of list_cpu_features
(compiled using source of time of posting) :
arch : x86
brand : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
family : 6 (0x06)
model : 37 (0x25)
stepping : 2 (0x02)
uarch : INTEL_WSM
flags : aes,cx16,smx
leewp14@CTK942S:~/Desktop/cpu_features-master$
Output of cat /proc/cpuinfo
:
[sudo] password for leewp14:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
stepping : 2
microcode : 0xe
cpu MHz : 1199.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm pti tpr_shadow vnmi flexpriority ept vpid dtherm arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5319.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
stepping : 2
microcode : 0xe
cpu MHz : 1199.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm pti tpr_shadow vnmi flexpriority ept vpid dtherm arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5319.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
stepping : 2
microcode : 0xe
cpu MHz : 1199.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm pti tpr_shadow vnmi flexpriority ept vpid dtherm arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5319.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
stepping : 2
microcode : 0xe
cpu MHz : 1199.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm pti tpr_shadow vnmi flexpriority ept vpid dtherm arat
bugs : cpu_meltdown spectre_v1 spectre_v2
bogomips : 5319.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
leewp14@CTK942S:~$
Meaning of cpu features can be found here https://en.wikipedia.org/wiki/CPUID
clflushopt
clfsh
clwb
cx8
dca
fpu
hle
mmx
pclmulqdq
rdseed
rtm
sse2
sse3
sse
ss
tsc
vaes
Thread safe, no memory allocation, and raises no exceptions. cpu_features is suitable for implementing fundamental libc functions like malloc, memcpy, and memcmp.
The README claims the above. But while grepping through the code, memcpy
and memcmp
are at least used already in the code from the libc library. Hence when implementing such based on cpu_features
one would create a loop of dependencies. I assume that cpu_features
requires a re-work to not utilize libc functions internally.
Can you please release 0.3 from the master, so we can put it into conda?
The hwcaps.h MIPS constants
cpu_features/include/internal/hwcaps.h
Lines 53 to 62 in 4155ee7
Hi, when following your readme my compiler complained and I can't disagree with it: Your code
CPU_FEATURES_COMPILED_X86_AVX || features.avx;
after CPP expands to
defined(__AVX__) || features.avx;
and that doesn't compile (or is there a trick to get the CPP-command defined
to become executable?).
--> Wouldn't it be better to do something like this in cpu_features_macros.h
:
#ifdef (__AVX__)
#define CPU_FEATURES_COMPILED_X86_AVX 1
#else
#define CPU_FEATURES_COMPILED_X86_AVX 0
#endif
instead of the current
#define CPU_FEATURES_COMPILED_X86_AVX defined(__AVX__)
to make your sample code work?
Or should one use your sample code in a specific / different way than by simply gcc-ing it?
@gchatelet , I ran into an error while running this command on the macOS
system
Abhinavs-MacBook-Pro:cpu_features eklavya$ cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -H. -Bcmake_build
-- The C compiler identification is AppleClang 9.1.0.9020039
-- The CXX compiler identification is AppleClang 9.1.0.9020039
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/eklavya/projects/code/c-shared-lab/cpu_features/cmake_build
Abhinavs-MacBook-Pro:cpu_features eklavya$ cd cmake_build/
Abhinavs-MacBook-Pro:cmake_build eklavya$ make
Scanning dependencies of target cpu_features
[ 6%] Building C object CMakeFiles/cpu_features.dir/src/linux_features_aggregator.c.o
[ 13%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_clang_gcc.c.o
[ 20%] Building C object CMakeFiles/cpu_features.dir/src/cpuid_x86_msvc.c.o
[ 26%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_aarch64.c.o
[ 33%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_arm.c.o
[ 40%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_mips.c.o
[ 46%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_ppc.c.o
[ 53%] Building C object CMakeFiles/cpu_features.dir/src/cpuinfo_x86.c.o
[ 60%] Building C object CMakeFiles/cpu_features.dir/src/filesystem.c.o
[ 66%] Building C object CMakeFiles/cpu_features.dir/src/hwcaps.c.o
[ 73%] Building C object CMakeFiles/cpu_features.dir/src/stack_line_reader.c.o
[ 80%] Building C object CMakeFiles/cpu_features.dir/src/string_view.c.o
[ 86%] Linking C shared library libcpu_features.dylib
Undefined symbols for architecture x86_64:
"_CpuFeatures_GetPlatformType", referenced from:
_GetPPCPlatformStrings in cpuinfo_ppc.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libcpu_features.dylib] Error 1
make[1]: *** [CMakeFiles/cpu_features.dir/all] Error 2
make: *** [all] Error 2
It would be super-handy to have a -o json
or a --json
flag so that output from the CLI would be easy to parse and consume by other programs.
Inspired by #19
hello sir ...
may i translate into indonesia.agar bahasa indonesia is easier to read ..... ?
thank you very much for your attention
add support Macintosh Operating System (x86 and POWER) .
thank you =)
This would allow languages that can call into shared libraries to natively wrap this awesome library. ๐ I would submit a PR for this, but my CMake isn't so good.
Compiling ndk_compat for Android arm devices results in the error below:
/build/src/ndk_compat/cpu-features.c:118:21: error: no member named 'vfpv' in 'ArmFeatures' if (info.features.vfpv) g_cpuFeatures |= ANDROID_CPU_ARM_FEATURE_VFPv2; ~~~~~~~~~~~~~ ^ 1 error generated.
..and sure enough looking in include/cpuinfo_arm.h there is no vfpv property. Looking through the file history it seems there never was. I'm scratching my head here, am I doing something wrong or is this a bug that has been there forever?
Commenting out line 118 in ndk_compat/cpu-features.c solves the issue
Windows, the Win32 API in specific, has a function called ReadFile
, OpenFile
and CloseFile
. You define all three in filesystem.c, non-namespaced, and therefore overriding the Win32 syscalls for everybody who links with your library. This is a huge oversight and cost me a couple of hours of trying to figure out why my programs all start to crash when reading files out of a sudden.
Lines 24 to 30 in 7eca4a7
When trying to build with -DBUILD_SHARED_LIBS=ON :
...
[ 77%] Linking C shared library libcpu_features.so
cmake-3.13.3/bin/cmake -E cmake_link_script CMakeFiles/cpu_features.dir/link.txt --verbose=1
gcc-6.1.0/bin/gcc -fPIC -O3 -DNDEBUG -shared -Wl,-soname,libcpu_features.so -o libcpu_features.so CMakeFiles/cpu_features.dir/src/cpuinfo_x86.c.o CMakeFiles/utils.dir/src/filesystem.c.o CMakeFiles/utils.dir/src/stack_line_reader.c.o CMakeFiles/utils.dir/src/string_view.c.o -ldl
/usr/bin/ld: CMakeFiles/utils.dir/src/string_view.c.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
CMakeFiles/utils.dir/src/string_view.c.o: could not read symbols: Bad value
The static lib builds ok, so not a blocking bug (for me) but still.
TL;DR: I messed up with github settings, it auto subscribed many people, there's no way I can revert it and I can't even write to people that got subscribed. My apologies for the noise.
please do not respond here since it will be even worse
Click https://github.com/google/cpu_features/subscription and select "Not watching".
Provide a drop in replacement for the NDK's cpu-features.h
ParseCpuId is coded to require the XMM XCR0 bit in order to recognize SSSE3, SSE4.1, and SSE4.2, but this is not the right way to detect it. Machines without AVX will not have XCR0 at all, and will fail this check.
In the absence of XCR0, on x86-32, the proper way to detect SSE is to ask the operating system. (On x86-64, just assume yes.) In Windows, that's IsProcessorFeaturePresent(PF_XMMI_INSTRUCTIONS_AVAILABLE). In Linux, unfortunately, it's parsing /proc/cpuinfo. In macOS and iOS (simulator), it's sysctlbyname on hw.optional.sse, though you could also just assume yes.
Something could be said that the number of x86 machines without SSE in the CPU and OS is about zero now--it depends on how far back you want your library to support.
This looks like a fantastically useful library.
Just a point for consideration, given that one of the targets is to make it easier to write fast code:
https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/
Note that same generation, same feature set can have wildly different performance depending on if it's "Silver", "Gold" or "Platinum", none of which is exposed by flags. Silver, for example, is de-tuned for AVX-512 (as someone puts it in the comments there).
You can parse that out of /proc/cpuinfo, if you're solely looking at Linux use cases, but this seems like something that would be ideal to find out via this library.
Without having taken more than a brief look at the repo, what's the reason for not exposing the likes of /proc/cpuinfo
under x86? Is there a reason or will this be supported in the future?
There are demo snippets in the README showing how to use the library at the source level, and there is a building with cmake part about building it, but it would be nice to have a section that explains how to actually to add the library to your build: e.g., do you need to link against any binary? or just include the header?
You cover how a project using cmake should consume this, but a large number of projects aren't using cmake, so even though they'll build cpu_features itself with cmake, they should be able to then integrate the output into their own build system.
I guess one or two lines about that scenario would suffice.
swp
SWP instruction (atomic read-modify-write)_26bit
"26 Bit" Model (Processor status register folded into program counter)fpa
Floating point acceleratorcrunch
MaverickCrunch coprocessorthumbee
ThumbEEvfpd32
VFP with 32 D-registerslpae
Large Physical Address Extension (>4GB physical memory on 32-bit architecture)evtstrm
kernel event stream using generic architected timerfixed by #79
To test all code paths of apps that use cpu_features to select between different implementations of an algorithm, it would be useful to be able to mock having a CPU with fewer features than actually supported.
While this can be done in wrapper layer which uses cpu_features to query the real feature set, little prevents direct use of cpu_features functions that would break the purpose of the wrapper. Hence I think it would be useful if this was a core feature of cpu_features itself.
One complication is that for tests to be able to run concurrently this would have to be thread-local (assuming the tests are single-threaded). For multi-threaded tests a global mutex could be used to prevent concurrent execution from the point where cpu_features is provided with override options, to the point where they're removed.
Multiple users of cpu_features have to deal with this themselves currently, so having it as a core feature instead avoids duplicate effort and incompatible solutions which might have subtle bugs that are best fixed centrally.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.