Osprey compiles through LLVM to a native binary, so the fair question is how it sits against other native-compiled languages. This page measures CPU time and peak memory against Rust, C, OCaml, and Haskell on classic compute benchmarks — the same naive algorithm, the same parameters, in every language.

The tables below are generated mechanically from the benchmark harness output by benchmarks/report.py — never hand-edited. The Osprey column is highlighted; the fastest cell in each row is emphasised, and ★ marks a benchmark Osprey wins outright (strictly faster, or lighter, than every other language).

Osprey is the fastest of all five languages on digitsum, factorial, hanoi, josephus, primes, tak. Lower is better; ★ marks an Osprey win.

CPU time

Peak memory

Methodology

Every benchmark is implemented identically in all five languages under benchmarks/cases/<name>/, compiled to a native binary, checked for correct output, then timed.

1. Build once, time the binary. osprey … --compile emits a persistent native executable; we time that, never --run (which would fold compile and link into the measurement). Every language uses its standard optimizing release flags.
2. Correctness oracle. Each binary runs once and its output is compared to the case's expected.txt. A mismatch or build failure is excluded from timing — we never publish a number for a program that computed the wrong thing. Every case has a single deterministic integer result, so output is byte-comparable across languages.
3. CPU. hyperfine -N --warmup 3 --min-runs 10 per case → statistical mean ± standard deviation.
4. Memory. /usr/bin/time peak resident set size (-l on macOS, -v on Linux), max over a few runs.

Compile commands

Reading the numbers fairly

• Same algorithm everywhere. Identical naive algorithm and parameters in every language — no memoization, closed forms, SIMD, or parallelism. We measure the language/compiler/runtime, not who is cleverest. Ranges match Osprey's half-open range(a, b) = [a, b) exactly.
• Osprey does checked arithmetic on every + - * % (each returns Result<int, MathError>, overflow-checked). The others do not by default — we even pass -C overflow-checks=off to Rust to match its release profile. Part of any Osprey gap is the cost of that safety, a real language semantic.
• Osprey loops via range |> fold, not deep linear recursion, because it has no tail-call optimization yet (a 1e6-deep recursion overflows the stack). The work is identical; only the iteration mechanism differs.
• OCaml is built without flambda (stock ocamlopt), so its numbers are conservative versus an flambda build.
• Single machine, wall clock. Treat ratios as indicative; re-run locally with make bench. The exact set of outright wins shifts run-to-run because Osprey, Rust, and C now sit within measurement noise of one another.

Where the gap remains: memory

On compute, Osprey is at parity with C and Rust and ahead of OCaml and Haskell. Peak memory matches C on every case except binarytrees. That benchmark builds, holds, and checksums millions of small heap nodes — they genuinely escape, so the optimizer cannot statically free them, and Osprey's default allocator does not reclaim memory during a run yet.

This is the contract of the Memory Management spec: allocation funnels through one swappable backend boundary, so a reclaiming manager (reference counting, a tracing collector, or an arena) can be linked in to close this last gap without changing a line of Osprey source.

Reproduce it

make bench                       # build everything, run the whole suite
BENCH_FILTER=fib make bench      # only cases whose name contains "fib"

Results land in benchmarks/results/ — results.html (this report, standalone), results.json (structured), and the per-case hyperfine exports.