* Switch all conversion routines to use starch.
main user-visible changes:
* ensure you check out submodules ('git clone --recurse-submodules")
* --version shows the CPU features and DSP implementations in use
* --wisdom allows overriding of the built-in architecture wisdom
* --dcfilter no longer supported
* "starch-benchmark" binary will benchmark all options on the
current machine and can produce a wisdom file to feed to
the --wisdom option
If you have a usecase for --dcfilter, please get in touch and
let me know - it's an edge case and for now there's no starch/DSP
support for it, but support can be written if needed.
In almost all cases the new conversion routines are slightly or
substantially faster than the old conversion routines. The only case
that is slower is SC16/SC16Q11 on a Pi 0, which is around 10% slower
due to changing from heavily approximated lookup tables to higher
quality results (but SC16 is probably already out of reach of a Pi 0)
* No need to build with SC16Q11_TABLE_BITS any more
* Add oneoff/uc8_capture_stats
(reads a UC8 capture; measures min/max/mean I and Q)
* Switch UC8 conversion to 127.4 center, 128 range.
Looking at actual UC8 captures from a RTL2832, the mean I and Q
are actually at 127.4, so use that as the zero point.
This means that the resulting I/Q maximum values could be as large as
127.6. Switch to 128 for simplicity.
* Switch to the new UC8 zero offset in benchmarks, fix some bugs
* Fix some bugs in SC16/SC16Q11 validation, tighten the max error requirements
* Ditch UC8 approximation path, add a NEON VRQSQRTE path.
* Tweak the SC16 exact path, add a new impl that uses a mix of
u32 & floats.
* SC16Q11 impl tweaks:
* add a u32->float exact path
* ditch the approximation path
* add a NEON VRSQRTE path
* add a 12-bit table path (using the full signed I/Q value, not absolute value)
* Ditch SC16 approximation path, add NEON vrsqrte path
* Add oneoff/dsp_error_measurement
This runs sample input through the DSP functions that are
allowed to be inexact and dumps the results as a TSV suitable for
feeding to gnuplot to look at the actual errors.
* Update make clean, make wisdom targets
* Update wisdom based on benchmarking
* Preserve the raw wisdom benchmark data
* Update to latest starch
* Update .gitignore for new wisdom files
* Update starch generated code
* Build starch-benchmark as part of the 'all' target
* Use wisdom from /etc/dump1090-fa/wisdom.local if present
* Package starch-benchmark and a helper script to generate local wisdom data
* Remove submodules in preparation for importing them directly
* Import cpu_features v0.6.0 from https://github.com/google/cpu_features/releases/tag/v0.6.0
* Import starch at commit a725c8491dc33a321565d451b385131e589d8490
from https://github.com/flightaware/starch
|
||
|---|---|---|
| .. | ||
| cmake | ||
| include | ||
| ndk_compat | ||
| scripts | ||
| src | ||
| test | ||
| .clang-format | ||
| .gitignore | ||
| .travis.yml | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| WORKSPACE | ||
| appveyor.yml | ||
README.md
cpu_features

A cross-platform C library to retrieve CPU features (such as available instructions) at runtime.
Table of Contents
- Design Rationale
- Code samples
- Running sample code
- What's supported
- Android NDK's drop in replacement
- License
- Build with cmake
Design Rationale
- Simple to use. See the snippets below for examples.
- Extensible. Easy to add missing features or architectures.
- Compatible with old compilers and available on many architectures so it can be used widely. To ensure that cpu_features works on as many platforms as possible, we implemented it in a highly portable version of C: C99.
- Sandbox-compatible. The library uses a variety of strategies to cope
with sandboxed environments or when
cpuidis unavailable. This is useful when running integration tests in hermetic environments. - Thread safe, no memory allocation, and raises no exceptions.
cpu_features is suitable for implementing fundamental libc functions like
malloc,memcpy, andmemcmp. - Unit tested.
Code samples
Note: For C++ code, the library functions are defined in the CpuFeatures namespace.
Checking features at runtime
Here's a simple example that executes a codepath if the CPU supports both the AES and the SSE4.2 instruction sets:
#include "cpuinfo_x86.h"
// For C++, add `using namespace CpuFeatures;`
static const X86Features features = GetX86Info().features;
void Compute(void) {
if (features.aes && features.sse4_2) {
// Run optimized code.
} else {
// Run standard code.
}
}
Caching for faster evaluation of complex checks
If you wish, you can read all the features at once into a global variable, and then query for the specific features you care about. Below, we store all the ARM features and then check whether AES and NEON are supported.
#include <stdbool.h>
#include "cpuinfo_arm.h"
// For C++, add `using namespace CpuFeatures;`
static const ArmFeatures features = GetArmInfo().features;
static const bool has_aes_and_neon = features.aes && features.neon;
// use has_aes_and_neon.
This is a good approach to take if you're checking for combinations of features when using a compiler that is slow to extract individual bits from bit-packed structures.
Checking compile time flags
The following code determines whether the compiler was told to use the AVX
instruction set (e.g., g++ -mavx) and sets has_avx accordingly.
#include <stdbool.h>
#include "cpuinfo_x86.h"
// For C++, add `using namespace CpuFeatures;`
static const X86Features features = GetX86Info().features;
static const bool has_avx = CPU_FEATURES_COMPILED_X86_AVX || features.avx;
// use has_avx.
CPU_FEATURES_COMPILED_X86_AVX is set to 1 if the compiler was instructed to
use AVX and 0 otherwise, combining compile time and runtime knowledge.
Rejecting poor hardware implementations based on microarchitecture
On x86, the first incarnation of a feature in a microarchitecture might not be the most efficient (e.g. AVX on Sandy Bridge). We provide a function to retrieve the underlying microarchitecture so you can decide whether to use it.
Below, has_fast_avx is set to 1 if the CPU supports the AVX instruction
set—but only if it's not Sandy Bridge.
#include <stdbool.h>
#include "cpuinfo_x86.h"
// For C++, add `using namespace CpuFeatures;`
static const X86Info info = GetX86Info();
static const X86Microarchitecture uarch = GetX86Microarchitecture(&info);
static const bool has_fast_avx = info.features.avx && uarch != INTEL_SNB;
// use has_fast_avx.
This feature is currently available only for x86 microarchitectures.
Running sample code
Building cpu_features (check quickstart below) brings a small executable to test the library.
% ./build/list_cpu_features
arch : x86
brand : Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
family : 6 (0x06)
model : 45 (0x2D)
stepping : 7 (0x07)
uarch : INTEL_SNB
flags : aes,avx,cx16,smx,sse4_1,sse4_2,ssse3
% ./build/list_cpu_features --json
{"arch":"x86","brand":" Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz","family":6,"model":45,"stepping":7,"uarch":"INTEL_SNB","flags":["aes","avx","cx16","smx","sse4_1","sse4_2","ssse3"]}
What's supported
| x86³ | ARM | AArch64 | MIPS⁴ | POWER | |
|---|---|---|---|---|---|
| Android | yes² | yes¹ | yes¹ | yes¹ | N/A |
| iOS | N/A | not yet | not yet | N/A | N/A |
| Linux | yes² | yes¹ | yes¹ | yes¹ | yes¹ |
| MacOs | yes² | N/A | not yet | N/A | no |
| Windows | yes² | not yet | not yet | N/A | N/A |
- Features revealed from Linux. We gather data from several sources
depending on availability:
- from glibc's getauxval
- by parsing
/proc/self/auxv - by parsing
/proc/cpuinfo
- Features revealed from CPU. features are retrieved by using the
cpuidinstruction. - Microarchitecture detection. On x86 some features are not always implemented efficiently in hardware (e.g. AVX on Sandybridge). Exposing the microarchitecture allows the client to reject particular microarchitectures.
- All flavors of Mips are supported, little and big endian as well as 32/64 bits.
Android NDK's drop in replacement
cpu_features is now officially supporting Android and offers a drop in replacement of for the NDK's cpu-features.h , see ndk_compat folder for details.
License
The cpu_features library is licensed under the terms of the Apache license. See LICENSE for more information.
Build with CMake
Please check the CMake build instructions.
Quickstart with Ninja
- build
list_cpu_features
cmake -B/tmp/cpu_features -H. -GNinja -DCMAKE_BUILD_TYPE=Release
ninja -C/tmp/cpu_features
/tmp/cpu_features/list_cpu_features --json
- run tests
cmake -B/tmp/cpu_features -H. -GNinja -DBUILD_TESTING=ON
ninja -C/tmp/cpu_features
ninja -C/tmp/cpu_features test