Roast — tests passing and fully-passing files, per release #

A file counts as fully passing only when every single test in it passes — one failure anywhere and the whole file drops out of the count. That strict bar is why the right-hand number is small next to the 90% of individual tests passing on the left. Both series start before the first tag, mined from ROAST.md's own git history — one point per day; the %-series begins on Jul 10, when the current "declared" denominator was defined (earlier percentages used a different counting method and would not be comparable).

Documentation conformance — every documented example, run three ways #

The same coloured verdicts the conformance page shows as dots, counted over time. ok is the one to watch: documentation, Rakudo and Raku++ all agreeing. Raku++ differs is the work list. The other three are not ours to fix — docs stale is where both engines agree against the documentation, Rakudo differs where Rakudo is the odd one out, and needs a human where all three disagree. Each point is one run of the comparison, not one release, so the line is only as dense as the snapshot has been taken.

Ecosystem — how many modules run under Raku++ #

The whole Raku ecosystem — every distribution in the REA index, latest release of each — swept end to end: a dist counts when its own test suite passes under Raku++. Every distribution and its result, listed →

Benchmarks — kernel wall time in ms, lower is better #

Three ways to run the same program: the Raku++ interpreter, the same source compiled to a native binary with --exe, and Rakudo as the reference — plus, on hashfill alone, the same program in Perl 5 as a second dashed reference. From the 2026.08 release a second Rakudo lane joins them: the same Rakudo compiled through RakuAST, the new frontend that Rakudo 2026.09 makes the default and that earlier releases reach with RAKUDO_RAKUAST=1. It is not another engine — it is the same binary in the same sitting with one environment variable set, and every kernel is checked to print the same in both lanes before either is timed — so the distance between the two dashed Rakudo lines is the frontend swap and nothing else. And it is a swap of the frontend, not of the runtime: timed with raku -c, which compiles without running, the two lanes compile these kernels in the same time to within a few percent (RakuAST is a shade faster on several). The whole of each gap is in the run — 94–106% of it on every kernel — which is to say it is the code the new frontend emits, executed on the same unchanged MoarVM. On objects, the widest, the compile is 1.09× and the run 2.79×. All ten kernels of the BENCHMARKS.md tables, ordered as that file orders them — string building first, where the gap is widest, down to the closest-run kernels — plus startup, the eleventh program in tools/bench/, last. (startup was a row in the tables early on, left them for a long stretch, and returned as its own section on 2026-08-22, so its series has a real gap in the middle.) Use the log scale when you want to read the distance between the interpreter and --exe: on a linear axis every chart is bounded by its Rakudo line, which squeezes both Raku++ series onto the baseline — worst on exactly the kernels where the lead is largest. Absolute times as committed at each release; the measuring machine changed at v3.6.0 (the file's own note records it), so read ratios across that boundary, not milliseconds. A point labelled by date rather than a version is a re-measure of main between releases: every sitting is kept as its own point, so a fresh measurement adds to the series instead of overwriting the last reading. A kernel is missing from a point only when that release's table did not carry it — except hashfill, whose tagged points are retrospective: every tagged release binary from GitHub, re-run on one machine in one sitting (2026-08-21), with that day's Rakudo and perl as fixed references — the one series here that is comparable in milliseconds end to end. (Its main point comes from the committed tables like every other kernel's, so the last step carries ordinary sitting-to-sitting noise.)

The -O optimizer #

A different comparison from the kernels above: the same five programs of tools/optbench/ compiled twice — plain --exe against --exe -O, with Rakudo alongside as the reference. The interpreter does not appear because -O is a codegen flag. Each program is written to exercise one of the speculative passes, and is verified to produce identical output all four ways before anything is timed. This series has a point only where the table was actually re-measured — the -O table is not re-run every release, and it was carried forward unchanged from v1.0.0 to v3.6.0, so drawing a point per release would show a dozen sittings agreeing where there was one sitting repeated. Gaps here mean "not measured", not "unchanged".