Benchmarks

Benchmarks

Full methodology and every benchmark's source in benchmarks/RESULTS.md and benchmarks/{c,julia,nirdosha}/ — this page summarizes the numbers and states the caveats up front, the same discipline the source doc uses.

Methodology, stated plainly

• Machine: Intel Core i7-8550U (4C/8T, 1.8 GHz base), Linux 7.0.10-zen1.
• Toolchains: julia 1.12.6, gcc 16.1.1, clang 22.1.8. Nirdosha's own codegen shells out to clang under the hood, so "Nirdosha-compiled" and "C via clang" share a backend — gcc is included too as the more common baseline.
• Each program run 3 times, best wall-clock time reported.
• Correctness verified first, for every pair, before any timing was trusted: every output was diffed by hand. det/matmul/dot/kalman use the exact same algorithm across all three languages (translated line-for-line, not each language's own built-in routine), so the comparison measures runtime overhead, not algorithmic or numerical differences.

Group A — scalar / control flow (the credible comparison)

Nirdosha compiled (-O2, default) vs. C — the natural baseline for a language whose stated goal is hardware-native speed with no runtime.

Benchmark	C (gcc -O2)	Nirdosha (-O2)
fib(35)	0.018 s	0.026 s
floatloop (2×10⁸)	0.443 s	0.436 s

Within 1.4× of gcc -O2 on fib, and noise-level tied with C on floatloop — exactly where a thin LLVM-backed AOT compiler should land. For reference: interpreted Nirdosha on fib(35) was 16.1 s — 620× slower than compiled — which is the entire reason native codegen for this path was prioritized (see Architecture's codegen.rs section).

Group B — dense linear algebra (Julia-derived features)

Nirdosha compiled vs. C vs. Julia (JIT), 200,000 iterations per benchmark (drifting inputs each iteration so nothing constant-folds away).

Benchmark	C (gcc -O2)	Nirdosha (compiled)	Julia (JIT)	vs. Julia	vs. C
matmul (4×4)	0.0102 s	0.0018 s	0.794 s	441× faster	5.7× faster
det (4×4)	0.0093 s	0.0272 s	0.993 s	36.5× faster	2.9× slower
dot (8-vec)	0.0023 s	0.0017 s	0.418 s	246× faster	1.4× faster
kalman (4-state)	0.0798 s	0.3274 s	2.735 s	—	4.1× slower

The caveat on the Julia column, stated honestly: these numbers include Julia's JIT compilation overhead, not steady-state execution after warmup — an AOT-compiled binary vs. a JIT session isn't a fair fight, and the "vs. Julia" gap is mostly measuring that, not raw execution speed. Treat the Julia column as directional, not a benchmark claim; the vs. C column is the one worth trusting.

On that measure, Nirdosha wins matmul/dot (fully unrolled at codegen time into straight-line IR — see codegen.rs's geometry/linalg helper cluster in Architecture) and loses det/kalman (a runtime-parameterized native call LLVM can't inline for a fixed size n=4). A future per-size monomorphization pass would likely close that gap — tracked as an open follow-up, not hidden as a win.

Why this is presented this way

An LLM (or a human) reading a benchmark table implicitly trusts that the comparison was apples-to-apples unless told otherwise. This page states where that's true (Group B's "vs. C" column, same algorithm, verified bit-identical output) and where it isn't (Julia's JIT-inclusive numbers, det/kalman's current loss) in the same table the wins appear in — the same "checkable, not asserted" standard the rest of this wiki holds every other claim to.