refreshed by cargo run --release --example bench_runner

What does each tier cost?

ZynML microbenchmarks measured through every tier of the Zyntax runtime: the BC interpreter alone, the BC interpreter after the HIR optimization pipeline (run_interp_safe_opts), the Cranelift JIT after tier-up, and the full ladder (Cranelift → LLVM) when built with the llvm-backend feature. Each kernel matches its rayzor / HaxeBenchmarks counterpart parameter-for-parameter. Mandelbrot is 875 × 500 / max_iter 1000 (reference checksum 112 798 515), n-body is the five-body solar system over 20 × 500 000 = 10 M advance steps returning Std.int(energy · 1 000 000), fib is the naive recursive fib(40) = 102 334 155. Two rows share the fib source and differ only in pipeline: the second compiles with cross-branch pure-call PRE off, so what that pass is worth on a recursive call tree is a published number rather than a claim. The page exposes where the runtime needs work; source lives at crates/zynml/benchmarks.

Median of 9 · 3 warmup runs discarded Wall-clock · compile + execute timed separately Result pinned · output checked every run Tiered · BC interp → opt → Cranelift JIT → LLVM

Loading benchmark results…

Shorter bars are better. compile execute Each kernel runs through three tiers: the BC interpreter on raw HIR, the BC interpreter after the optimization pipeline (const-folding, CSE, load-CSE, leaf inlining, LICM, loop and reduction vectorization, CFG simplification, alloca→malloc promotion, drop-site insertion), and the Cranelift JIT after tier-up. Tiered mode cold-starts on the interpreter; the asynchronous Cranelift compile lands during the kernel's first few iterations and the timed call dispatches through native code from then on. Output is verified to match across tiers before each run is recorded.

Reading the tier-2 (LLVM) column. The zyntax-tiered-llvm column lowers HIR to LLVM IR, stamps each function with the host's target-cpu and target-features, and installs it through an in-process MCJIT engine. Nothing outside the process is involved, on either macOS aarch64 or Linux x86_64. On several kernels the two tiers land within noise of each other. That is not a fallback: it is how little is left for LLVM to do once the HIR passes have reshaped a numeric loop. Where there is work left the gap is wide on the same runner that produced the close numbers, n-body among them.