Benchmarks

The benchmark suite runs the same workloads written in Sakura Lang and by hand in JavaScript, Rust, Go, OCaml and Koka. Every program has an oracle: a cell is measured only after it returns the recorded checksum for every input. The numbers are specific to these workloads and this one machine. They are not a language ranking.

What is measuredCopy Anchor Link

The primary metric is instructions retired per call, read from macOS's /usr/bin/time -l. As with rustc-perf, the reason is repeatability: the count barely moves when other programs share the machine, so the suite runs while other work goes on and needs no idle night (design §17.264).

Each cell is one program at one input size n on one engine. The harness calibrates a call count k, then runs five pairs of fresh processes: one calls run(n) once, the other 1 + k times. Start-up, module loading and the first call's compilation are in both, so the difference over k is the cost of a warm call. The cell is the median of the five pairs, and its spread is (max − min) / median.

An instruction count is not a time. It does not see cache misses, branch mispredictions or how many instructions a core retires per cycle, and two engines can retire the same instructions at different speeds: in the first counted runs one Wasmtime cell's ratio of counts and its ratio of times differed by half. A ratio below is a ratio of counts, never of times.

ResultsCopy Anchor Link

Every value is instructions retired per call (or per process, for the compiler) on the reference Mac at commit 320c9980, at each program's largest size. A ratio is Sakura's count over hand JavaScript's on the engine named. K, M and G are thousands, millions and billions. Node runs with V8's --predictable flag, which keeps its garbage collector and compiler on the main thread so that their counts do not depend on scheduling.

JavaScript backendCopy Anchor Link

WebAssembly backendCopy Anchor Link

Sakura compiled with --target wasm, run on Node's WebAssembly engine and on Wasmtime, over the same hand JavaScript on Node. json_validate has no Wasmtime cell: it needs JSON decoding, which only the Node host implements.

Native controlsCopy Anchor Link

The same workloads in Rust (with overflow checks, the matched lane), Go, OCaml and Koka. A dash means the program has no port in that language.

CompilerCopy Anchor Link

One sakura process per run, after a warm-up: check and build of generated packages and of a new project. test_hello counts the CLI's own process, not the Node process it starts.

Against the targetsCopy Anchor Link

Design §17.109 set a ceiling per program on the ratio of Sakura to hand-written JavaScript on the same engine, and asked for a median of at most 1.5 over the fifteen programs. Those are same-engine ratios, so a ratio of counts can be read against them (design §17.265). At the largest size, six of the fifteen meet their ceiling on Node and five on Bun; the median is 2.24 on Node and 2.47 on Bun.

Read plainly: on the JavaScript backend, most of the suite runs within 1.5–3× of hand-written JavaScript, and five programs are 4.5–12× behind: nbody, deltablue, map_set:int, handled_fwd and sieve. Where Sakura is ahead (pipeline, tokenizer, handled on Node) the cause is a specific mechanism, fusion of the pipeline, ownership of the consumed string, or a handler compiled to a direct call, and it says nothing about other programs. The WebAssembly backend is first-release code: 2–124× behind hand JavaScript by count on this suite, far from native, with its worst cells on contracts, handlers and scalar loops. The native backend is experimental, left out of release binaries, and not measured here.

Design §17.109 also set an envelope against Rust, Go, OCaml and Koka. Those ceilings were set on wall time, and a count across different engines is not a time, so the envelope is reported as information and not as a release gate (design §17.265). On these counts it is not met: Sakura WebAssembly on Node is a geometric mean of about 27× Rust and 25× Go on the numeric kernels, 11× OCaml and 12× Koka on the allocation kernels, with tokenizer the one kernel inside its ceiling. The native backend, experimental today, is where that comparison will be made again.

What comes next, in order, each landing with a counted before and after against the blessed baseline: flat Float, Bool and Int lists and in-place Float records (nbody, spectral_norm, sieve); the Int-key path of Map (map_set:int); what remains in deltablue; forwarding handlers (handled_fwd); then the WebAssembly cliffs, starting with contracts and the superlinear tokenizer cost (design §17.265 (6)).

SpreadCopy Anchor Link

The spread is (max − min) / median over a cell's five pairs.

On Node and Wasmtime every cell over 1% is one pair out of five; the middle three agree within 1%, so the median holds. Most native cells over 1% are Go, whose garbage collector runs concurrently. Bun is noisier: 48 of its cells spread over 1% even in their middle three, and JavaScriptCore's concurrency switches did not narrow them. Read a Bun count with its spread.

ReproduceCopy Anchor Link

On a Mac with the toolchains pinned in bench/toolchains.toml:

git checkout 320c9980
bench/bench run --suite js --instructions --json js.json
bench/bench run --suite wasm --instructions --json wasm.json
bench/bench run --suite native --lane matched --instructions --json native.json
bench/bench compile --instructions --json compile.json

Counts from another machine are not comparable with these: a different CPU, OS or engine build retires different instructions. The full result files, with every size, every raw count and the wall time beside it, are in bench/results (2026-10-19-320c9980-*). The procedure that turns a run into a baseline is docs/release.md §2.