Nihilai Collective Logo

PAPERS

Whitepapers and Technical Write-ups

The benchmark is the proof. These papers document the methods and measurements behind the libraries published here — what was tried, what worked, what didn't, and what the numbers actually say.

Each paper is written as an engineering write-up rather than an academic submission: problem, approach, measurements with caveats, and an honest read of when the technique helps versus when it doesn't.

Jsonifier Serialization
October 2026 · Jsonifier
Design and Performance
One size pass, one resize, then a write pass that never checks capacity. Every byte the schema already knows — keys, quotes, colons, commas, indentation — is packed into integer constants at compile time, and nearly every copy is a compile-time power-of-2 size that lowers to a single load and store. Covers branchless bools (one subtraction, one 8-byte store), integers written 4 digits per store from compile-time tables with division replaced by multiplies, and SIMD-then-SWAR string escaping. Results across five platform/compiler builds: fastest in 111 of 115 converged tests against Glaze and simdjson's C++26 reflection writer, with full-document leads of 1.1–1.7× minified and about 3× prettified on the closest build.
Topics: JSON serialization · compile-time reflection · SIMD · integer formatting · branchless code
Schema-Free, On Demand
September 2026 · Jsonifier
Generic JSON Parsing in Jsonifier
A schema-free, tape-driven parser shaped like simdjson's On Demand API, but re-accessible. In-order reads cost a cursor increment and a key compare; out-of-order reads go through a SIMD SwissTable-style field index that is only built once an object has skipped enough keys to earn it. Covers the shared forward cursor, zero-copy strings with a fixed-slot arena, why whole-document indexing made the target workload 2.3x slower, and the per-platform threshold sweep. Results across five platform/compiler builds: 289 wins, 15 ties, 44 losses against simdjson On Demand, including 69 wins and 2 losses in 76 full-document reverse-order tests, across in-order, reverse, sparse and sparse-reverse reads. A new section covers multi-document streams through iterateMany, the counterpart of simdjson's iterate_many: 84 wins, 4 ties, 9 losses across NDJSON and comma-separated streams, including 22 wins in 25 results on ports of simdjson's own streaming benchmarks and 28 wins in 32 reverse-order stream results.
Topics: SIMD · JSON parsing · On Demand APIs · hash tables · out-of-order access
Two Stages, On Demand
July 2026 · Jsonifier
The Stage-1 + Stage-2 Architecture in Jsonifier
Two-stage SIMD parsing is a specialized tool, not a mandatory front door. Full-document parses into reflected types skip the structural tape entirely and take a single fused pass; the tape is reserved for partial reading, prettifying, and minifying — where it actually pays for itself. Covers the per-(ISA × compiler)-tuned step geometry, the folded stepped drain, and a distributed UTF-8 validation scheme that costs zero additional memory bandwidth. Direct comparisons to simdjson throughout, including the honest finding that both libraries converge on the same tzcnt-burst extraction primitive.
Topics: SIMD · JSON parsing · compile-time reflection · UTF-8 validation · schema-directed parsing
Batched Drain, Fused Scan
July 2026 · Jsonifier
The Architecture of Jsonifier's Stage 1
Six architectural divergences from simdjson's stage-1 structural indexing: a batched drain that decouples mask production from tape emission, per-(ISA × compiler)-tuned step geometry, UTF-8 validation fused into string unescaping and carried across SIMD width transitions, and a compile-time minified specialization. Includes a case study on relocating control-character validation from stage 1 to stage 2, and full cross-platform results — 99 wins, 1 tie, 12 losses against simdjson across 112 AVX2/NEON tests, with a perfect 23-0-0 sweep under MSVC, plus 56-1-12 across 69 tests on three AVX-512 targets.
Topics: SIMD · JSON parsing · UTF-8 validation · AVX-512 · compiler-specific tuning
OACC
January 2026 · v1.0 (Revised)
Order-Agnostic Constexpr Configuration with Compile-Time Uniqueness Checking
A C++20 configuration pattern where settings are passed in any order, duplicates are a build error rather than a silent overwrite, and the entire machinery erases completely under consteval — field values appear as immediates in the output. Includes the one subtlety that makes or breaks the guarantee: why the uniqueness concept must constrain the whole argument pack, not each argument individually.
Topics: C++20 · concepts · consteval · type routing · API design
CAFBERIHT
December 2025 · v1.0 (Revised)
Constexpresh Aggregated and Filtered Bases for Efficient Runtime Iteration of Heterogeneous Types
A filtered, tag-dispatched aggregate over heterogeneous types with per-component boilerplate reduced to a single inheritance line. Dispatch overhead is zero — verified by assembly diff against a hand-written baseline at -O1 and above. Includes compile-time scaling measurements across GCC, Clang, and MSVC, and an honest account of where the pattern degrades and when a plain std::tuple is the better tool.
Topics: C++20/23 · CRTP · heterogeneous collections · compile-time dispatch · template metaprogramming
Compile-Time Division Elimination
June 2026 · v1.0
Granlund–Montgomery for Zero-Overhead Tensor Indexing in CUDA Kernels
Removing hardware IDIV from indexing-bound kernels by hoisting divisors into the type system. Measured 12–30× operation-level speedup on RTX 5070 Ti across 16 divisors at 32-bit and 64-bit widths. Includes the honest finding that all three magic-number delivery mechanisms are statistically tied — the win is Granlund–Montgomery itself, not the compile-time encoding.
Topics: CUDA · template metaprogramming · integer division · Granlund–Montgomery

About These Papers

The papers here are not peer-reviewed in the academic sense. They are engineering documents: the techniques they describe are in production use in the libraries listed on the projects page, the benchmarks are reproducible from the harnesses in the organization's repositories, and the numbers are taken on hardware that anyone can buy.

Where a technique has limits — where it doesn't apply, where the compiler already does the equivalent, or where the win is smaller than it looks in isolation — those limits are stated in the paper rather than left for the reader to discover. A speedup number without its caveats is not a result; it's a marketing claim.

If you spot something that looks wrong, the channels to flag it are the GitHub issues on the relevant repository and the Discord.

Philosophy
Cathedral Architecture — the methodology these papers apply.
Projects
The libraries the methods are tested against.