Cross-platform benchmarks

Per-primitive benchmark results across five CPU microarchitectures and four operating systems. Each cell is the Criterion median of the primitive’s own (MMF-backed) operation; baselines are shown where the contrast is the point (B-tree vs Mutex<BTreeMap>, blocked vs standard Bloom, shared cell vs RwLock).

Criterion --sample-size=12 --warm-up-time=1 --measurement-time=2, single-threaded unless the op name says otherwise. Cells marked † are a later re-capture on the Zen+ host; everything else is one sweep. All primitives run with the per-op observation sidecar gated by the process-global armed flag, so a raw handle pays a hot-path load and a predicted branch and nothing else - the numbers below are with observation present but unarmed, the production shape.

The four Zen columns read left to right as a clean microarchitecture ladder: Zen+ is roughly 2x the Zen3 across the board; Zen2 sits between. Zen3 on Linux and Zen3 on FreeBSD land within a few percent of each other (same silicon class), with each OS marginally ahead on different ops - the allocator and syscall paths differ even when the CPU does not. The fifth column is the outlier: a 2012 Intel Core i5 (Ivy Bridge) on macOS, a 13-year-old 2-core part that lands well behind the Zen chips and flips a handful of cells where its memory subsystem or low core count dominates rather than its clock.

Atomics, cells, and sub-nanosecond reads

The cheapest ops, where the push_op observation gate matters most: an unarmed observation is a single hot-global load, so these stay at the hardware floor.

SharedCell::get vs an in-process RwLock<struct> (Zen+ 3.75 vs 17.5 ns; Zen3 2.2 vs 4.3 ns; the 2012 Mac 10.4 vs 62.1 ns) is the lock-free-read win that holds on every platform.

Ordered and keyed maps

† Zen+ / Win cells re-measured in a later run; see the note at the bottom of this page.

The B-tree, the substrate’s ordered-map primitive, leads Mutex<BTreeMap> at 100 keys on four of the five platforms - the mutex lock/unlock dominates at small N - and trails it at 100k keys, where the in-process map’s pointer-direct nodes win over the mmf’s seqlock + position-independent addressing. Zen+ / Windows is the exception at small N: on re-measurement the two are level on hits (25.2 vs 26.0), though the miss case still favours the B-tree. Read the small-N result as “a cross-process ordered map costs nothing here”, not as a win.

Probabilistic sketches

The blocked Bloom’s single-cache-line contains is 1.7-2.1x the standard filter’s scattered-probe contains on every platform once the filter (16M items, ~19 MB) exceeds L3, where the standard filter’s n_hashes probes each miss to RAM. Below L3 the two tie (the out-of-order core overlaps the standard filter’s independent probes).

Coordination, clocks, and topology

Sequences, regions, and graphs

The SharedGraph::add_node / add_edge figures are cold-MMF measurements: the bench creates a fresh graph per iteration, so the timed add includes the first-write page-fault on a freshly mapped file. Windows mmap commit makes that page-fault roughly 10x the Linux cost, which is the microsecond-scale Zen+ column; the 2012 Mac’s mmap first-touch is slower still (715 µs add_node). Steady-state allocation into a warm region is the SharedRegion::allocate row (75 ns on Zen+).

Method

On the † cells. The shared_btree_map and shared_blocked_bloom_filter benches were re-run on the Zen+ / Windows host under the same flags, and those cells carry the later capture. They moved enough to change one conclusion, which is why they were replaced rather than left: SharedBTreeMap::get_hit at 100 keys had read as a 1.26x win over Mutex<BTreeMap> and re-measures as a tie. The other four columns are unchanged from the original sweep - they are different hosts and were not re-run - so the Zen+ column is a later capture than the row it sits in. That matters for reading a single row across platforms; it does not affect any within-column comparison, which is where every claim on this page actually lives.

Timings on the same host move 20-40% between runs. Ratios within a column are the durable part; the digits are one capture.

Each Zen platform ran the full Criterion suite - 68 bench targets today, shared_btree_map and shared_blocked_bloom_filter among them - under the same flags. The 2012 Mac ran the same suite minus the 8-thread capacity-adaptive-ring stress bench, which is pathological on a 2-core CPU. MMF files were backed by disk on every host (the benches that mmap large files need a backing store with free space, not a small tmpfs). The per-primitive reference pages carry the full op tables, contender rationale, and trade-off discussion for the canonical (Zen+) hardware; this page is the cross-platform summary.