// the find
RoaringBitmap/CRoaring
Roaring bitmaps in C (and C++), with SIMD (AVX2, AVX-512 and NEON) optimizations: used by Apache Doris, ClickHouse, Alibaba Tair, Redpanda, YDB and StarRocks
CRoaring is the reference C/C++ implementation of Roaring bitmaps — a compressed bitmap format that stores integers in three container types (array, bitset, run-length) and switches between them automatically based on density. It's the library that ClickHouse, Druid, Redpanda, and a dozen other production systems actually link against when they need fast set operations on large integer sets.
The SIMD coverage is genuine: runtime dispatch on x64 selects AVX-512, AVX2, or scalar at startup, and ARM NEON is handled separately — you don't opt in, it just runs the right path. The amalgamation story (two files: roaring.h + roaring.c) is the right answer for embedding in a larger project; no CMake required, no dependency hell. Serialization format is standardized and cross-language — a bitmap written in C can be read in Java, Go, or Python without any conversion layer. The library is continuously fuzz-tested through OSS-Fuzz, which matters more than unit tests for a data structure that will see untrusted serialized input in database engines.
The 64-bit C API (roaring64.h) is a second-class citizen compared to the 32-bit API — it arrived later and some bulk operations available for 32-bit don't have 64-bit equivalents yet. Thread safety is read-only: concurrent reads are fine, concurrent writes require external locking, which is easy to miss if you're building a shared cache. The C++ wrapper is thin and occasionally leaks the C API's manual-memory model through — copy-on-write mode is a global flag per bitmap, not an ownership type, so it's easy to write code that silently shares mutable state. Documentation lives mostly in header files and a long README; there's no searchable guide for the less obvious operations like bulk aggregation with a heap or range-based iteration.