Read the experiment
The conditions
are part of the result.
This project explores implementations of a π approximation using the Leibniz series. It measures a specific numerical task, with visible tradeoffs—not overall language quality.
What the numbers mean.
Elapsed time, in context
The table shows median wall time for the selected run. Smaller is faster for that implementation, workload and machine. Details preserve individual samples, spread and the exact command. Three samples are a practical starting point, not enough to declare every small difference meaningful.
Math and vectorization
Relaxed math permits transformations such as reassociation that can change floating-point results. “Compiler default” describes the declared math policy; it does not guarantee identical instruction sequences or bitwise output. “Explicit SIMD” labels implementations that explicitly use vector operations; its absence does not rule out automatic vectorization. Algorithm variants and native CPU flags are shown separately.
Correctness
Results are checked against a convergence tolerance for the requested number of terms. Passing that check is a numerical sanity check, not proof of identical arithmetic, exact π or equivalent behavior on every input.
Why a billion terms and repeated measurements? ↗
The current baseline
The September 5, 2026 snapshot uses one billion terms and three measured executions. It was collected by the native Devbox adapter on a shared x86_64 virtual machine. Two warmups and a separate output capture made six executions in that historical protocol. This site does not relabel it as a Dagger run or as a result from dedicated hardware.
Follow the evidence.
Start with a run’s measured source revision, then inspect the target’s build and run commands, requested packages, resolved Devbox lock, container image, CPU flags and workload. Nix helps identify dependencies; matching packages alone cannot recreate host load, virtualization or processor behavior.
Some old fields were never collected. The site displays these as “Not recorded,” while providing the untouched raw evidence. Other platforms in a package lock describe resolver outputs, not additional benchmark runs.
Fast feedback.
Deliberate reporting.
Contribution checks
A source change selects all affected language variants, including shared source dependencies. Shared execution or compiler settings broaden that selection. Report and website changes validate the report without scheduling benchmarks. Unavailable change history falls back to a full check.
The next reporting protocol
The agreed starting point is one warmup plus three measured executions, with output captured in the warmup. Full reports should run weekly only when benchmark inputs, protocol or runner conditions changed since the last successful publication. Close or noisy results need additional investigation. The billion-term workload remains the published reference; a shorter candidate still needs validation.
Rollout status
The unified Python Dagger runner prepares environments concurrently, reuses cached builds, then measures targets sequentially with fresh execution IDs. Production Argo integration and weekly scheduling await an isolated benchmark runner. The shared homelab production workers are not the intended Dagger execution host.