lux/benchmarks/RESULTS.md

Lux Language Benchmark Results

Generated: Feb 16 2026

Environment

• Platform: Linux x86_64 (NixOS)
• Lux: Tree-walking interpreter (Rust-based)
• C: gcc with -O3
• Rust: rustc with -C opt-level=3 -C lto
• Zig: zig with -O ReleaseFast

Current Status

Important: Lux currently runs as an interpreted language. The C compilation backend exists but has bugs that prevent it from working on all programs. The numbers below reflect interpreter performance.

Summary

Benchmark	C (gcc -O3)	Rust	Zig	Lux (interp)	Ratio
Fibonacci (35)	0.028s	0.041s	0.046s	0.254s	~9x slower than C

Honest Assessment

Lux as an interpreter is approximately:

• 9x slower than C (gcc -O3)
• 6x slower than Rust (with full optimizations)
• 5.5x slower than Zig (ReleaseFast)
• Comparable to other interpreted languages (faster than Python, similar to Lua)

This is expected for a tree-walking interpreter. The focus of Lux is on:

1. Developer experience - effect system, type safety, good error messages
2. Correctness - not raw performance
3. Future compilation - the C backend will eventually provide native performance

Benchmark Details

Fibonacci (fib 35)

Tests: Recursive function calls

fn fib(n: Int): Int = {
    if n <= 1 then n
    else fib(n - 1) + fib(n - 2)
}

Language	Time	Notes
C (gcc -O3)	0.028s	Baseline
Rust (-C opt-level=3 -C lto)	0.041s	~1.5x slower than C
Zig (ReleaseFast)	0.046s	~1.6x slower than C
Lux (interpreter)	0.254s	~9x slower than C

Analysis: Lux's interpreter performance is typical for a tree-walking interpreter. The overhead comes from:

• AST traversal
• Dynamic dispatch
• No JIT compilation
• Reference counting

Why Lux is Slower (For Now)

Tree-Walking Interpreter

Lux currently uses a tree-walking interpreter written in Rust. This means:

• Every expression is evaluated by traversing the AST
• No machine code generation
• No JIT compilation
• Every operation goes through interpreter dispatch

C Backend Status

Lux has a C compilation backend (lux compile) that generates C code, but it currently has bugs:

• Some standard library functions have issues in generated code
• Not all programs compile successfully
• When working, it would provide C-level performance

Future Performance Improvements

Planned improvements that would make Lux faster:

1. Fix C backend - Enable native compilation for all programs
2. Bytecode VM - Intermediate representation faster than tree-walking
3. JIT compilation - Runtime code generation for hot paths
4. Optimization passes - Inlining, constant folding, etc.

Running Benchmarks

# Enter nix development environment
nix develop

# Run Lux benchmark (interpreter)
time cargo run --release -- benchmarks/fib.lux

# Compare with other languages
nix-shell -p gcc rustc zig --run '
  gcc -O3 benchmarks/fib.c -o /tmp/fib_c && time /tmp/fib_c
  rustc -C opt-level=3 -C lto benchmarks/fib.rs -o /tmp/fib_rust && time /tmp/fib_rust
  zig build-exe benchmarks/fib.zig -O ReleaseFast && time ./fib
'

Comparison Context

For context, here's how other interpreted languages perform on similar benchmarks:

Language	Typical fib(35) time	Type
C	~0.03s	Compiled
Rust	~0.04s	Compiled
Zig	~0.05s	Compiled
Go	~0.05s	Compiled
Java (JIT warmed)	~0.05s	JIT Compiled
Lux	~0.25s	Interpreted
Lua (LuaJIT)	~0.15s	JIT Compiled
JavaScript (V8)	~0.20s	JIT Compiled
Python	~3.0s	Interpreted
Ruby	~1.5s	Interpreted

Lux performs well for an interpreter without JIT compilation.

Note on Previous Benchmark Claims

Earlier versions of this document made claims about Lux "beating Rust and Zig." Those claims were incorrect:

• The C backend was not actually working
• The benchmarks were not run fairly
• The comparison methodology was flawed

This document now reflects honest, reproducible measurements.