50× speedup, guided by one benchmark

The benchmark as a probe

The core of the simulation:

bm:         {[n]  sqrt(-2.0*log(1.0-?n)) * cos(2.0*pi*?n)  }
price_path: {[w]  S0 * exp(+\((w*vol_dt)+drift))            }

za:        {(bm nsteps)}' !npairs       // Phase A: BM draws
pos_paths: price_path' za               // Phase B: GBM paths
neg_paths: price_path' {neg x}' za      // Phase B: antithetic
paths:     pos_paths , neg_paths

finals:    {last x}' paths              // Phase C: reduce
payoffs:   0 | (finals - 1.05*S0)
price:     exp(-0.05*T) * (+/ payoffs) % (2*npairs)

Three phases isolate costs cleanly:

Starting point: three root causes

Before any work, at 1,000 paths: mu takes ~287 ms, C takes ~2.4 ms. A profile immediately shows three causes:

1. Output printing (~64% of wall-clock). Every assignment x: val calls val_fprint → __dtoa. For a 252-float array, 252 formatted writes per line. --quiet alone drops 287 ms → 102 ms.
2. Linear string scan per env lookup. env_get("vol_dt") runs strlen + memcmp against every live name in the frame (~16 entries). Called millions of times per run.
3. Per-element heap boxing. +\ and element-wise * each allocate a fresh value_t node (24 bytes) per output element — 252 allocations per operation per path.

The eleven fixes — 102 ms to 5.5 ms

All measurements at 1,000 paths / 500 pairs, --quiet. The bar tracks the running total; each fix removes one class of overhead.

Current state: head-to-head at 10,000 paths

Current μ at ~46 ms is faster than Python+NumPy (~53 ms) on this workload. Phase A is well ahead (~18 ms vs ~22 ms). Phase B is where the gains are largest: μ's fused GBM kernel (~8 ms) beats NumPy's vectorised path construction (~25 ms) because NumPy must allocate and broadcast full n_paths × n_steps matrices, while μ processes each path independently with a single tight C loop. The remaining overhead vs C is Phase B's per-path float_alloc and function dispatch — architecture-level cost, not algorithmic.

What was not done, and why

Antithetic-path fusion. The benchmark runs price_path on both za and za_neg. A benchmark-specific optimisation could fuse both passes, halving Phase B's iteration count. Rejected: it does not generalise to any other μ program. The general fix (F11b) eliminated the per-call overhead instead.

SIMD / vectorised BM. NEON intrinsics could give 2–4× throughput on the BM kernel. Not done: Phase A is already at C parity. Complexity without proportional gain.

What comes next

μ is now faster than Python+NumPy overall. The interesting remaining question is whether the per-phase advantage can be widened. Phase B (~8 ms) is the main target — NumPy takes ~25 ms here, so there is headroom, but also a structural cost:

1. Per-path allocation and dispatch. Each of the 10,000 calls to price_path' enters apply_func_once and allocates a float[252] output slab. Batching all paths into a single 2D kernel (n_paths × n_steps) would eliminate this but requires a different adverb evaluation strategy.
2. The neg pass. {neg x}' za calls eval_expr per element — O(n_paths) AST dispatch. Recognising {neg x}' as a map-negate kernel is a straightforward extension of the existing fusion patterns.

The {neg x}' map-negate pass is the simplest win: recognising it as a built-in map kernel would eliminate O(n_paths) eval_expr dispatch with a trivial pattern addition. Beyond that, closing further vs C requires the 2D batch kernel — a larger architectural change with diminishing returns given the Python comparison is already won.

General lessons

1. Profile before fixing. F1–F3 alone covered ~80% of the total reduction. Guessing would have produced far worse leverage.
2. One bottleneck hides the next. String comparison → boxing → rand allocation → env copy → pool pressure — the waterfall shape in the fix table is not coincidence.
3. Every fix must generalise. Interned env, packed arrays, and fused kernels all benefit any μ program that hits those patterns.
4. Fused kernels are a force multiplier. F8 + F10 together dropped Phase B from ~118 ms to ~19 ms, not by being clever, but by writing structurally identical code to the C reference.
5. Guard conditions in the optimiser need care. F11a's conservative safety check in frame_is_inlinable_for_body silently blocked a correct, high-value transformation. The fix was two lines; the diagnosis required understanding the full opt pipeline.