Simd: a hand-written SIMD image processing and ML library for x86, ARM and Hexagon
C++ image processing and machine learning library with using of SIMD: SSE, AVX, AVX-512, AMX for x86/x64, NEON, SVE for ARM, HVX for Hexagon
At a glance
- What is it?
- The Simd Library ships image processing, detection and neural network primitives written directly against SSE, AVX-512, AMX, NEON, SVE and HVX, with a C API plus C++ wrappers and a CMake build that cross-compiles to Hexagon. Its value is kernel-level control; its cost is a build matrix you have to manage yourself.
- Who is it for?
- Adopt Simd if you are writing C or C++ and need pixel format conversion, scaling, filtering, motion detection or Haar/LBP cascade detection with kernel-level control over which CPU extensions are used, and if you are willing to own a CMake configuration with per-target flags. Do not adopt it if you want a broad algorithm catalogue, a stable ABI, or bindings for languages other than the Python wrapper the repository ships.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Simd solves: pixel-level performance without a framework
Image pipelines spend most of their time in a small number of loops: converting between pixel layouts, resizing, blurring, thresholding, computing statistics. A general-purpose compiler will vectorize some of these, but the result depends on the optimizer, the flags and the loop shape. Simd takes the other route. The README describes it as a library that provides high performance algorithms for pixel format conversion, image scaling and filtration, extraction of statistic information from images, motion detection, object detection and classification, and neural networks, with the algorithms optimized using different SIMD CPU extensions. The intended audience is C and C++ programmers who want to call a function such as a resize or a conversion and know that the inner loop was written for the vector unit, not left to chance.
The supported extension list is unusually wide for a single codebase: SSE, AVX, AVX-512 and AMX for x86/x64, NEON, SVE and SVE2 for ARM, and HVX for Hexagon. That last one is the tell. HVX means Qualcomm Hexagon DSPs, which is not a target you reach for casually. A library that carries a Hexagon path is built for people deploying image or vision code onto embedded accelerators, not only onto servers.
There is also a machine learning side. The repository contains a data/network directory described as holding examples of trained networks, and the README names object detection and classification among the algorithm families. That points at the Synet framework, which the build options reference directly through SIMD_SYNET.
How the dispatch and build options fit together
The mechanism visible in the material is compile-time selection plus runtime selection. The CMake options control which instruction sets are compiled in: SIMD_AVX512 enables AVX-512F, AVX-512CD, AVX-512VL, AVX-512DQ and AVX-512BW and is on by default; SIMD_AVX512VNNI enables the VNNI extension and is also on by default; SIMD_AMXBF16 enables AMX-BF16, AMX-INT8 and AVX-512-BF16 and is off by default; SIMD_SVE and SIMD_SVE2 are off by default. Then SIMD_RUNTIME, on by default, is described as enabling runtime faster algorithm choice. So the binary can contain several implementations of the same operation and pick one based on what the CPU reports at run time.
That split matters because the defaults are not uniform. AVX-512 is compiled in unless you turn it off, but AMX and SVE are not. If you build for an ARM server with SVE and never pass SIMD_SVE, you get the NEON path. If you build for a Sapphire Rapids machine and want the AMX-BF16 matrix units, you must pass SIMD_AMXBF16 explicitly. The defaults encode a guess about what most users run.
The codebase is organized so the SIMD kernels live in simd/src/Simd/, the test framework in simd/src/Test/, and usage examples in simd/src/Use/. A Python wrapper sits in simd/py/SimdPy/ and is enabled by SIMD_PYTHON, on by default. There is also SIMD_HIDE, off by default, which hides internal functions, and SIMD_PERF, off by default, which enables internal performance statistics. SIMD_PERF is the honest way to find out whether a given kernel is actually the one running on your machine, rather than assuming.
Getting it built: CMake, vcpkg and the target flags
On Linux the README gives a native build that is three commands. Create a build directory, then run cmake against ../prj/cmake with empty SIMD_TOOLCHAIN and SIMD_TARGET, then make. For cross-compilation you fill those in. ARM 32-bit uses -DSIMD_TOOLCHAIN pointing at an arm-linux-gnueabihf-g++ and -DSIMD_TARGET="arm". ARM 64-bit uses aarch64-linux-gnu-g++ with -DSIMD_TARGET="aarch64". Hexagon uses the Hexagon Clang toolchain, hexagon-linux-musl-clang, with -DSIMD_TARGET="hexagon". All three examples add -DCMAKE_BUILD_TYPE="Release".
On Windows the primary path is the Visual Studio 2022 project files under simd/prj/vs2022/. The README notes a default that will surprise people: under Visual Studio the library builds as a DLL, whereas in the other cases the default type is a static library. To get a static build you change the Configuration Type property of the Simd project and uncomment #define SIMD_STATIC in simd/src/Simd/SimdConfig.h. Missing that second step is a plausible source of link errors.
There is also a MinGW path through CMake with -G "MinGW Makefiles" and mingw32-make. And if you prefer a package manager, the README documents vcpkg: clone Microsoft/vcpkg, run ./bootstrap-vcpkg.sh, ./vcpkg integrate install, then ./vcpkg install simd. The README states that the vcpkg port is kept up to date by Microsoft team members and community contributors and asks that you file an issue or pull request on the vcpkg repository if the version is out of date. That is a warning worth reading literally: the port's version and the repository's version are maintained separately.
Headers are split by use. C code includes Simd/SimdLib.h. C++ code includes Simd/SimdLib.hpp. The detection API needs Simd/SimdDetection.hpp and the motion API needs Simd/SimdMotion.hpp. For conversion between Simd and OpenCV types, you define SIMD_OPENCV_ENABLE before including the Simd headers. Note that this is a macro you define, not a CMake option in the list above.
Where Simd is the wrong choice
The first limitation is scope. Simd is not a computer vision framework. The README lists pixel format conversion, scaling, filtration, statistics extraction, motion detection, object detection and classification, and neural networks. There is no mention of camera calibration, stereo reconstruction, feature descriptors, optical flow variants, or a graph execution engine. If your work is closer to a vision application than to a kernel, you will spend your time writing the layer Simd does not provide.
The second is the build matrix. Supporting SSE through AMX plus NEON, SVE, SVE2 and HVX in one repository means the configuration surface is large, and the defaults are opinionated in ways that differ per platform. A team that ships one binary to a fleet of mixed CPUs has to reason about SIMD_RUNTIME dispatch and about whether the AVX-512 path compiled in by default is safe on every machine in that fleet. The material does not describe the dispatch policy in detail, so this is something to verify rather than assume.
The third is integration surface. The library exposes a C API and C++ wrappers, and the repository contains a Python wrapper under simd/py/SimdPy/ enabled by SIMD_PYTHON. If your stack is Rust, Go, Java or .NET, the material shows no binding for you, and you would be writing FFI against the C API yourself. That is a real cost, and it is not one the project appears to have paid down.
Finally, the release cadence is high. Three releases appear in the supplied list within roughly two months, v7.2.163 through v7.2.165, and the version numbers carry a third component that moves. Frequent releases are not a defect, but they do mean that pinning a version and reading the diff before upgrading is the sane policy, not tracking master.
OpenCV as the alternative, and where the two diverge
The obvious comparison is OpenCV, and the repository itself points at it: simd/data/cascade/ is described as containing OpenCV cascades in HAAR and LBP form, and SIMD_OPENCV, off by default, lets the test framework use OpenCV. The interop macro SIMD_OPENCV_ENABLE exists precisely because people move data between the two.
The difference in approach is what each project optimizes for. OpenCV is an algorithm catalogue with a broad, stable, widely bound API, and its performance work is spread across many backends including its own dispatch layer. Simd is a narrower set of primitives with hand-written kernels for a specific and unusually long list of instruction sets, including AMX and HVX, which are not the targets a general framework prioritizes. If you need a resize that runs on Hexagon HVX, or an AVX-512 path with VNNI, that is the gap Simd is filling.
The practical consequence is that the two are complements more often than substitutes. The conversion macro suggests a workflow where Simd handles the hot pixel loops and OpenCV handles everything else. That is a reasonable architecture, and it is cheaper than porting your whole pipeline.
A second alternative worth naming for the neural network portion is to use a dedicated inference runtime rather than Simd's own network code. The material shows trained network examples and a SIMD_SYNET option, but it does not describe the network format, the operator coverage, or the tooling for importing models. Without that, treating Simd as a general inference engine is a leap the documentation as supplied does not support.
Licence, maintenance and what an upgrade actually costs
The repository is MIT licensed. That is permissive and short, and it is the licence most teams can accept without a review cycle, but the usual caveat applies: MIT grants copyright permissions and says nothing about patents. If your product depends on AMX-INT8 or VNNI paths, patent exposure is a question for your own counsel, not something the licence resolves. Nothing in the supplied material indicates additional terms, exceptions, or a contributor licence agreement.
The maintenance cost is dominated by the build configuration, not by the API. Every target you add (a new ARM board, a Hexagon DSP, an AVX-512 server) means another CMake invocation with its own SIMD_TOOLCHAIN and SIMD_TARGET values and its own set of SIMD_* feature flags. That is a per-target cost you pay once and then re-pay whenever you bump the library version, because a new version can add or change a flag. The SIMD_GET_VERSION option, on by default, calls a script to obtain the library version, which implies the version is resolved at configure time; if you cache build artifacts, that is a detail to check.
Upgrade cost is also shaped by the release cadence. With a new tagged release roughly monthly in the supplied list, the sensible posture is to pin a tag, read the changes between your pinned version and the new one, and rebuild your full target matrix in CI before merging. The test framework is in the repository under simd/src/Test/, and SIMD_TEST is on by default, so the build already produces a test application; running it on each target is the cheapest way to catch a regression introduced by a kernel change on an architecture you do not develop on day to day.
One more cost is the OpenCV coupling. If you define SIMD_OPENCV_ENABLE, your build now depends on OpenCV headers as well, and the version compatibility between the two becomes part of your upgrade problem. Teams that only need the conversion helpers should weigh whether the dependency is worth it.
Editorial conclusion
Adopt Simd if you are writing C or C++ and need pixel format conversion, scaling, filtering, motion detection or Haar/LBP cascade detection with kernel-level control over which CPU extensions are used, and if you are willing to own a CMake configuration with per-target flags. Do not adopt it if you want a broad algorithm catalogue, a stable ABI, or bindings for languages other than the Python wrapper the repository ships. Before committing, verify three things against your own hardware and toolchain: that the AVX-512, AVX-512VNNI and AMX-BF16 build options you intend to enable are actually supported by your target CPUs and accepted by your compiler, that SIMD_RUNTIME dispatch behaves as you expect on a binary deployed to machines older than your build host, and that the MIT licence text is what your legal review expects, since the repository states MIT and nothing in the supplied material adds patent terms or exceptions.
Community notes