clpeak is a cross-platform synthetic micro-benchmark that measures peak achievable compute performance (FLOPS/TOPS), bandwidth, latency, and AI inference throughput across CPUs, GPUs, and NPUs. It supports eight hardware backends: OpenCL, Vulkan, CUDA, ROCm/HIP, Metal, oneAPI/SYCL, native CPU (with per-ISA dispatch), and ONNX Runtime. The tool is architected as a set of backend-specific static libraries orchestrated by a common framework, with two front-ends: a CLI tool (`clpeak`) and a Flutter desktop/mobile GUI. The GUI communicates with the native library via a C-ABI FFI bridge, streaming structured events for live display. Results are serialized to a versioned JSON schema (v3) and can be compared against baselines. The codebase is notable for its meticulous anti-optimization engineering (MAD chains, compiler barriers, calibration probes) and its protobuf-free ONNX model generator. It is a mature, actively maintained project with extensive CI coverage and packaging for multiple platforms.
ArrayFire is a mature, production-grade tensor and array computing library implemented in C++, exposing both a C API (af_* functions) and a C++ API (af::array). It provides hundreds of accelerated numerical operations — dense and sparse linear algebra (LU, QR, SVD, Cholesky, solve), FFT and signal processing, image transforms and filtering, computer vision feature detection (FAST, SIFT, ORB, SUSAN, homography), statistics, and random number generation — across four hardware backends: CPU, CUDA, OpenCL, and oneAPI/SYCL. The architecture is layered: thin C API wrappers and C++ classes in src/api/c and src/api/cpp dispatch through a unified runtime layer (src/api/unified) that lazily loads backend shared libraries via a symbol manager; each backend implements the same templated operation set over device-resident arrays with backend-specific kernels under src/backend/*/kernel. The genuinely interesting engineering lives in src/backend/common: a JIT expression-tree system that fuses array operations into compiled kernels, deterministic hash-based kernel caching, a memory manager with JIT-pressure eviction heuristics, FFT plan caching, and cross-platform dynamic library loading. The test suite is unusually rigorous for a numerical library — well over 100 gtest programs covering correctness across all dtypes, large dimensions, random-number quality via PractRand, and death tests — while examples span image processing, machine learning, financial Monte Carlo, and PDE simulation. Maintenance is active (commits through 2026, CI workflows, source releases), but technical drift is medium: the oneAPI backend is explicitly incomplete with many operations stubbed as ONEAPI_NOT_SUPPORTED, deprecated compatibility APIs remain (include/af/compatible.h), the four backends duplicate a large amount of near-identical code, and some packaging artifacts (Tegra toolchain pinned to gcc-5, vendored vcpkg LAPACK patches, Debian postinst hardcoding MKL/CUDA paths) are stale. This is a software library rather than a data pipeline — there are no notebooks, datasets, or analytical artifacts — though its algorithms are directly applicable to computer vision and scientific computing workloads.
OpenMM is a high-performance molecular dynamics simulation library that provides a unified API across CPU (with SIMD and JIT compilation via AsmJit) and GPU backends (CUDA, OpenCL, HIP). The codebase is structured into several layers: the public API (`openmmapi`) defines `System`, `Force`, `Integrator`, and `Context` classes; the OLLA layer abstracts kernel dispatch; platform modules (`reference`, `cpu`, `cuda`, `opencl`, `hip`) provide concrete kernel implementations; and plugins extend functionality with AMOEBA polarizable force fields, Drude oscillators, and ring-polymer MD. The project supports standard force fields (AMBER, CHARMM, GROMACS, Tinker), advanced algorithms (PME, GB/SA, custom forces via the Lepton expression parser), and features like metadynamics, replica exchange, checkpointing, and XML serialization. It is primarily a library for computational chemistry and biophysics, designed to be used through Python (with extensive application-level tools in `openmm.app`) or C++.
rspirv is a Rust workspace providing comprehensive SPIR-V module processing functionality. It includes a core library (rspirv) with a low-level data representation (DR) for raw instructions and a higher-level structured representation (SR) with type-safe indices. The project also features a binary parser, an assembler, a disassembler CLI (rspirv-dis), and a code generator (rspirv-autogen) that derives Rust types from the official SPIR-V JSON grammar. The parser supports custom consumers via the Consumer trait, enabling streaming or custom processing. The builder (dr/build) allows programmatic construction of SPIR-V modules. The lift module converts from DR to SR, bridging the two representations. The codebase is heavily auto-generated from the SPIR-V specification, ensuring spec compliance, but this also introduces risks of drift if the grammar submodule is not updated. The project is actively maintained with CI/CD pipelines, and the multi-crate workspace is designed for both library reuse and standalone tool usage.
nvml-wrapper is a Rust workspace providing safe, high-level bindings to the NVIDIA Management Library (NVML). It is a library crate, not an application: there are no binaries, servers, or CLIs. The workspace is split into `nvml-wrapper-sys` (low-level FFI bindings, including runtime loading of `libnvidia-ml.so`/`nvml.dll` via `libloading`) and `nvml-wrapper` (a safe, typed API). The primary entry point is `Nvml::init()`, which loads the NVML library and returns a handle; from there, `Device` exposes 100+ methods for querying GPU state such as memory, clocks, temperature, power, ECC, NvLink, vGPU, MIG, and GPM metrics. The crate also supports mutating operations like setting application clocks and fan speed, and includes a `legacy-functions` feature for older NVML versions.