Chapter 14 · 13 July – 9 October

Against the reference compiler

Every released Raku++ binary up to v5.3.0, re-run on one machine, against the Rakudo that was current on each release's day. This is the fairest picture of how the speed moved. Each release's own benchmark table was measured on whatever machine it had, and for a while with Rakudo emulated.

How it was measuredThe released rakupp-macos-universal archive for each tag, checked against its published checksum, arm64 slice, on one Apple M3. Each kernel runs seven times; the first run is discarded and the fastest of the other six kept. Rakudo is built from source for each monthly release and assigned to Raku++ releases by date. The first sitting, on 31 August, timed every tag up to that day; six more on the same machine added each release after it, the last on 13 October. Then the M3 was out of reach, and an Apple M4 stood in (chapter 16). Its milliseconds are not the M3's, so these charts stop at v5.3.0, the last release the M3 timed. Hover any point for the release and its time.

fib: recursive calls.

loopsum: an integer loop.

streq: string comparison.

hash: hash reads and writes.

objects: construction and attributes.

regex: matching.

strcat: building a string.

startup: an empty program.

How to read them

Three drops stand out. v3.6.0 to v3.7.0 is the value shrinking to 128 bytes and variables becoming slots (the values chapter): fib 536.4 → 369.8 ms, loopsum 206.2 → 97.2. v3.26.0 to v3.27.0 is object construction: 411.8 → 319.4 ms. And the largest, v5.1.0 to v5.2.0, is the integer and loop kernels (chapter 16): fib 392.2 → 14.1 ms, loopsum 80.9 → 5.6.
Two rises. fib went from 736 ms at v0.5.1 to 898.5 at v1.2.6, while correctness came first. And v5.0.0 paid for 100% of Roast: fib 308.6 → 400.6, streq 237.3 → 335.2. Chapter 15 is the round that won most of it back.
At v5.1.0, compiled Raku++ was faster than Rakudo on 16 of the 17 kernels, and interpreted it still took longer on fib (1.3×), streq (1.4×), objects (1.8×) and a multi-dispatch kernel with where clauses (3.2×). By v5.3.0, the last release the M3 timed, compiled Raku++ was faster on 17 of 18 (all but multiwhere, 1.06×), and only objects (1.03×) and multiwhere (1.07×) were still slower interpreted. On the M4, v5.5.0 is faster on all eighteen both ways.
Startup is a few milliseconds against about 75: an interpreter that parses its program directly, against a VM that loads its runtime first. On one run that is nothing. On the two-hundredth run of an edit-and-regenerate loop, it is the difference you notice.
Rakudo moves too. The dashed line steps at each monthly release, and 2026.09 made RakuAST its default front end. Its September rows come from a Homebrew bottle, which ran 2026.08 about 13% slower than a source build, so read that step with care.

The full table, with every kernel and the other engines, is on the dashboard.