Performance

Method first, because a performance number without a method is a marketing claim.

How we measure

Benchmarks that compare against C have a matched C reference implementing the same algorithm — not a different algorithm that happens to produce the same output. Not every kernel in the suite currently has a live C counterpart; the comparison set is smaller than the benchmark set.

Every figure on this page is measured on native arm64. A native x86_64 re-run is outstanding, and where we have run it the instruction counts differ from the arm64 ones by up to 50% per kernel. Do not read these as architecture-independent.

We count retired instructions under Valgrind, not wall-clock time. Retired instruction counts are deterministic and reproducible on any machine, so a result you read here is one you can reproduce rather than approximate. Two ratios are reported for each kernel: against gcc -O0, which isolates the raw per-operation code-generation gap, and against gcc -O2, which is the total gap — code generation plus the optimizations we do not have yet.

Wall-clock figures, where quoted, are advisory and secondary.

What the optimizer achieved

The most recent optimizer package, measured across the whole benchmark corpus:

Bounds-check elimination contributes to the MatrixMultiply improvement: every guard in the kernel is proven away. The array index domain is known to the type system, so value-range propagation can prove indices in range and remove the check rather than execute it.

Vectorization and carriers

All of it bit-identical to the serial result at every carrier count — see determinism.

Compile throughput

A 100,000-line program compiles fully optimized in about 8.86 seconds as part of the gate run, and about 5.4 seconds when it is the only thing running.

Where gcc still leads

On general-purpose code, gcc -O2 is ahead of us, and we are not going to suggest otherwise. Decades of investment in an optimizer is a real thing.

Specific favourable numeric loops reach or pass parity. A Mandelbrot kernel lands slightly below gcc’s instruction count on arm64; on native x86_64 it is above gcc -O2, which is exactly the kind of difference the architecture caveat above is warning about. The region allocator does beat our own per-cell plug-in substantially on an allocation-bound workload, because bulk reclaim beats per-object free — that comparison is in-house and we trust it more than the cross-toolchain one.

We publish the gap rather than selecting benchmarks around it, and it is the number we work to reduce each release.

Figures from the most recent release record, 2026-07-22.