jz 0.6.0 → 0.8.0

package/bench/README.md

@@ -1,6 +1,6 @@
-# jz benchmark suite
+# JZ benchmark suite
 
-Cross-target workload suite for jz codegen quality. Each benchmark is a case
+Cross-target workload suite for JZ codegen quality. Each benchmark is a case
 folder under `bench/`:
 
 ```txt
@@ -10,7 +10,6 @@ bench/<case>/<case>.rs      optional Rust baseline
 bench/<case>/<case>.go      optional Go baseline
 bench/<case>/<case>.zig     optional Zig baseline
 bench/<case>/<case>.as.ts   optional AssemblyScript baseline
-bench/<case>/<case>.py      optional scalar CPython baseline
 bench/<case>/<case>.npy.py  optional NumPy baseline
 bench/<case>/<case>.wat     optional hand-written WAT baseline
 ```
@@ -30,8 +29,8 @@ drift as `DIFF`.
 npm run bench
 node bench/bench.mjs --targets=nat,rust,go,numpy,v8,jz
 node bench/bench.mjs --targets=jz --cases=biquad,mat4,poly,bitwise
-node bench/bench.mjs --targets=v8,deno,bun,spidermonkey,hermes,graaljs,qjs
-node bench/bench.mjs --cases=biquad,mat4,tokenizer,json,sort,crc32
+node bench/bench.mjs --targets=v8,deno,bun,spidermonkey,graaljs
+node bench/bench.mjs --cases=biquad,fft,synth,bytebeat,blur
 node bench/bench.mjs biquad
 node bench/bench.mjs mat4 --targets=nat,v8,jz
 ```
@@ -51,22 +50,80 @@ node bench/bench.mjs mat4 --targets=nat,v8,jz
 | [`json`](json/json.js) | runtime `JSON.parse` of one module-local source plus heterogeneous object/array walk with a stable inferred JSON shape |
 | [`sort`](sort/sort.js) | in-place heapsort over a typed array; exposes call-heavy nested loops and typed-array index propagation |
 | [`crc32`](crc32/crc32.js) | table-driven CRC-32 over a mutable byte buffer; exposes integer narrowing and typed-array parameter propagation |
+| [`dotprod`](dotprod/dotprod.js) | multiply-accumulate reduction; JZ reassociates to 4 SIMD accumulators, beating strict-fp serial native |
+| [`bytebeat`](bytebeat/bytebeat.js) | classic integer "bytebeat" one-line-song synthesis to 8-bit PCM; pure i32, bit-exact everywhere |
+| [`fft`](fft/fft.js) | radix-2 Cooley–Tukey FFT over a transcendental-free twiddle table; the canonical numeric/audio kernel |
+| [`synth`](synth/synth.js) | minisynth audio pipeline — polynomial oscillator + ADSR + biquad per sample; loop-carried f64 |
+| [`blur`](blur/blur.js) | separable box blur on an RGBA8 image; integer stencil with edge clamp, the canonical image pipeline |
+| [`conv2d`](conv2d/conv2d.js) | int8 quantized conv layer (Cin→Cout, 3×3, i32 MAC + ReLU requant); the spatial-convolution counterpart to dense `matmul`, the edge-ML inference kernel |
+| [`qoi`](qoi/qoi.js) | QOI lossless image codec encode + decode round-trip; loop-carried run/index/diff/luma ops that no target can vectorize — pure scalar-codegen race |
+| [`hash`](hash/hash.js) | MurmurHash3 x86_32 over a byte buffer; table-free multiply/rotate/xor mixing, a different ALU profile from `crc32` |
+| [`lz`](lz/lz.js) | LZSS compress + inflate round-trip; greedy sliding-window longest-match search — the match finder that dominates every LZ-family codec |
+| [`base64`](base64/base64.js) | Base64 encode + decode round-trip; table-driven 3→4 byte packing, the canonical codec / serialization kernel |
+| [`wav`](wav/wav.js) | PCM-16 WAV encoder; per-sample clamp + int16 quantization behind a RIFF/WAVE header, the audio serialization kernel |
+| [`raytrace`](raytrace/raytrace.js) | minimal sphere ray tracer — primary ray + closest-hit + Lambert/ambient shading to an f64 framebuffer; the canonical 3-D render kernel, a branchy loop-carried scalar `sqrt` pipeline no target vectorizes |
+| [`noise`](noise/noise.js) | 2-D Perlin gradient noise summed over 5 fBm octaves; the canonical procedural-generation kernel — integer permutation-table hashing interleaved with f64 smoothstep interpolation |
+| [`radixsort`](radixsort/radixsort.js) | LSD radix sort (4 × 8-bit counting passes) over u32 keys; histogram → prefix-sum → scatter with buffer ping-pong, the gather/scatter integer-sort counterpart to compare-swap `sort` |
+| [`levenshtein`](levenshtein/levenshtein.js) | Levenshtein edit-distance rolling-row dynamic program; the canonical sequence-alignment / fuzzy-match kernel — a branch- and min-reduction-heavy DP with a diagonal data dependency no target vectorizes |
+| [`nqueens`](nqueens/nqueens.js) | bitmask N-Queens solution counter (board sizes drawn from a runtime array so the recursion can't be constant-folded); deep backtracking recursion + per-node bitmask branch — the call/recursion-codegen probe |
+| [`dict`](dict/dict.js) | open-addressing hash table (build + probe) with linear probing; multiply-shift hash scatter + dependent-load gather + unpredictable probe-chain branches — the associative-container kernel |
+| [`sieve`](sieve/sieve.js) | Sieve of Eratosthenes over a byte array; pure strided scatter (j = i², i²+i, …) guarded by an outer branch — a non-contiguous write pattern |
+| [`vm`](vm/vm.js) | tiny bytecode interpreter — a fetch-decode-dispatch loop (if/else opcode chain + indirect code-array loads) running an integer recurrence; the canonical VM/regex-engine inner loop |
+| [`spmv`](spmv/spmv.js) | sparse matrix×vector in CSR form; the MAC inner loop gathers `x[col[k]]` through a column-index array — the data-dependent gather dense codegen handles worst (exact-integer f64, bit-identical everywhere) |
+| [`hashjoin`](hashjoin/hashjoin.js) | probe-dominated relational hash join (build small, stream a large probe side, sum matched payloads) — the database/dataframe kernel and JZ's boss case: `probe()` returns a typed-array element through a param JZ can't yet prove is i32, so `sum + probe()` lowers to a polymorphic number-or-string add per probe — the only case JZ trails V8; proving the return i32 measured 8.7 → 5.2 ms, jz then beats V8 1.3× |
 | [`watr`](watr/watr.js) | watr's WAT-to-wasm compiler on a small WAT corpus; compares jz-compiled compiler code with raw V8 |
 | [`jessie`](jessie/jessie.js) | the subscript/jessie JS parser over a realistic source corpus; branch-, allocation- and recursion-heavy front-end work |
-| [`jz`](jz/jz.js) | the jz compiler itself (scripts/self.js pipeline) compiling three small programs at L2 — the self-host row runs jz.wasm compiling JavaScript; output bytes are checksummed so the parity gate doubles as a determinism proof |
+| [`jz`](jz/jz.js) | the JZ compiler itself (scripts/self.js pipeline) compiling three small programs at L2 — the self-host row runs jz.wasm compiling JavaScript; output bytes are checksummed so the parity gate doubles as a determinism proof |
+
+The `watr`, `jessie`, and `jz` rows are self-referential — JZ (or its deps)
+compiling code. They stay runnable (`--cases=watr,jessie,jz`) and gated in
+`test/bench.js`, but are hidden from the bench page and the headline geomean SVG:
+they answer a different question (compiler throughput on itself) from the
+cross-language kernel comparison the page is about.
 
 Native rows for `json` are fixed-source references, not semantic equivalents
 of JavaScript `JSON.parse`: C/Rust/Zig hand-parse the known schema from a
 compile-time string, and Zig may constant-fold the whole parse+walk under
 ReleaseFast; Go uses `encoding/json` but still unmarshals the same compile-time
-string. The jz row parses a `let` source at runtime so `JSON.parse` is not
+string. The JZ row parses a `let` source at runtime so `JSON.parse` is not
 compile-time folded, while the compiler can still specialize the stable literal
 shape. External unknown-shape JSON still uses the generic runtime parser.
 
 Native-language rows are intentionally per case. NumPy rows are used only
-where a vectorized array implementation is a meaningful Python convention;
-scalar CPython is kept to the tokenizer row to avoid turning the suite into
-a Python loop-overhead benchmark.
+where a vectorized array implementation is a meaningful Python convention.
+
+Pure interpreters (CPython, QuickJS, Hermes) stay out of the **headline**
+geomean: it measures compiled-code quality, and an interpreter row inflates JZ's
+lead for free without answering a question a user actually has. Javy
+(embedded-QuickJS) is wired as a **fenced reference** — it appears per case as a
+hatched row so the cost of the "ship a JS interpreter in wasm" approach is
+visible, but it is excluded from `SVG_TARGETS` so it never moves the headline
+number. The headline field is wasm-vs-wasm, apples-to-apples: JZ against the
+other languages compiled to the same target — WebAssembly run in V8 — i.e. Rust,
+Go, C, and Zig (`wasm32-wasi`), AssemblyScript, Porffor, and MoonBit (the last on
+moonrun, MoonBit's V8 wasm runner), plus the JS JITs it replaces
+(V8/Bun/Deno/SpiderMonkey/GraalJS). Native C/Rust/Zig/Go and NumPy's
+vectorized C are the corpus reference band — the aggregate "what you give up by
+not rewriting", with native C the speed-of-light ceiling.
+
+**Coverage is reported, not hidden.** A target that is present but cannot compile
+or run a case (Porffor OOMs on most typed-array kernels; TinyGo's stdlib subset
+rejects some `.go`) records a `{ status: 'fail', reason }` entry in
+`results.json`, and the page renders it as a muted row with the reason — and as a
+`ran / attempted` count on the headline row. The geomean still averages only the
+cases a target completed correctly (you cannot ratio a run that never produced a
+number), but the gap is no longer invisible.
+
+The **per-case** view splits into two **same-class lanes**, so every bar in a
+card is a fair peer:
+
+- **WASM** — JZ vs Rust/Go/C/Zig→wasm, AssemblyScript, Porffor, and raw JS, all
+  run in this V8.
+- **Native** — JZ lowered to a native binary (`jz-w2c`: JZ wasm → `wasm2c` →
+  `clang -O3`) against the native toolchains (C/Rust/Go/Zig). This is the *fair*
+  native comparison — native-vs-native, not jz-wasm against a native binary — and
+  it's the axis for optimizing JZ's compile-to-native path. The lane hides where
+  no `jz-w2c` build is available (it needs wabt's wasm2c runtime + SIMDe headers).
 
 ### Parity classes
 
@@ -84,35 +141,39 @@ correctly-rounded; cascade is the same algorithm.
 | --- | --- |
 | `nat` | clang `-O3` native C baseline, when a matching C workload exists |
 | `natgcc` | gcc `-O3`, when real gcc is installed |
-| `rust` | Rust `rustc -C opt-level=3 -C target-cpu=native`, when a matching `.rs` exists |
-| `go` | Go native compiler, when a matching `.go` exists |
-| `zig` | Zig `build-exe -O ReleaseFast`, when a matching `.zig` exists |
-| `python` | scalar CPython, when a matching `.py` exists |
+| `rust` | Rust `rustc -C opt-level=3 -C target-cpu=native` — native baseline; the headline rival is `rust-wasm` |
+| `go` | Go native compiler — native baseline; the headline rival is `go-wasm` |
+| `zig` | Zig `build-exe -O ReleaseFast` — native baseline |
 | `numpy` | vectorized NumPy, when a matching `.npy.py` exists |
 | `v8` | raw JavaScript on Node/V8 |
 | `deno` | raw JavaScript on Deno/V8 |
 | `bun` | raw JavaScript on Bun/JavaScriptCore |
+| `jsc` | raw JavaScript on the standalone JavaScriptCore shell — Safari's engine (`jsc`; install via `jsvu --engines=javascriptcore`, or set `JSC_BIN`) |
 | `spidermonkey` | raw JavaScript on SpiderMonkey shell (`spidermonkey`, `sm`, `js128`, `js115`, `js102`, or `js`) |
-| `hermes` | raw JavaScript on Hermes |
 | `shermes` | Static Hermes — JS AOT-compiled to a native binary (`shermes -O`), when installed |
 | `graaljs` | raw JavaScript on GraalJS |
-| `jz` | jz output with host imports for timing/logging (measures wasm size without WASI console/perf bloat) |
+| `jz` | JZ output with host imports for timing/logging (measures wasm size without WASI console/perf bloat) |
 | `as` | AssemblyScript `asc -O3 --runtime stub`, when a matching `.as.ts` exists |
-| `jz-wasmtime` | jz output on wasmtime |
-| `jz-w2c` | jz wasm translated by wabt `wasm2c`, then clang `-O3` |
+| `rust-wasm` | Rust → `wasm32-wasip1` (`rustc --target wasm32-wasip1 -C opt-level=3`), run in node's V8 — the apples-to-apples Rust rival |
+| `go-wasm` | Go → `wasm32-wasip1` (`GOOS=wasip1 GOARCH=wasm go build`), run in node's V8 |
+| `c-wasm` | C → `wasm32-wasi` via clang/LLVM (`zig cc -target wasm32-wasi -O3` — zig supplies the wasi-libc that plain clang lacks; no emcc/wasi-sdk install), run in node's V8 |
+| `jz-wasmtime` | JZ output on wasmtime |
+| `jz-w2c` | JZ wasm translated by wabt `wasm2c`, then clang `-O3` |
 | `wat` | hand-written WAT baseline when a case provides `run-wat.mjs` |
-| `qjs` | QuickJS when installed |
 | `porf` | Porffor (`porf run`) when installed |
-| `jawsm` | jawsm when installed |
+| `jawsm` | jawsm (JS → WasmGC) when installed |
+| `javy` | Javy (`javy build` — JS in embedded QuickJS) when installed — fenced interpreter reference, never in the headline geomean |
+| `tinygo` | TinyGo → `wasm32-wasip1` (`tinygo build -target=wasip1 -opt=2`) — the Go corpus through LLVM, leaner wasm than `go-wasm`; run in node's V8 |
+| `moonbit` | MoonBit → `wasm` (`moon build --target wasm --release`), run on `moonrun` (MoonBit's V8 wasm runner, which supplies the monotonic clock) — a wasm-first-language rival, when `moon`/`moonrun` are installed |
 
 The `size` column reports the artifact size each target measures: the
 compiled native binary for `nat`/`rust`/`go`/`zig`, the produced
-`.wasm` for `jz`/`as`/hand-WAT/jawsm/`jz-w2c` (the C-translated
+`.wasm` for `jz`/`as`/`rust-wasm`/`go-wasm`/`c-wasm`/hand-WAT/jawsm/`jz-w2c` (the C-translated
 executable), or the source file for raw-JS interpreters where there is no
 compile step. For source files with imports, raw-JS size is only the entry file;
-jz size is the bundled wasm artifact.
+JZ size is the bundled wasm artifact.
 
-Note the preset trade: these speed tables build jz at the default
+Note the preset trade: these speed tables build JZ at the default
 (`optimize: 2`, speed-leaning — loop unroll + SIMD lift), while the dedicated
 size comparison (`npm run bench:size`) builds with `optimize: 'size'` —
 typically ~2× smaller on the same kernel (biquad: 3.5 kB default vs 1.6 kB
@@ -121,40 +182,40 @@ same artifact.
 
 Runtime command overrides:
 
-`watr` is intentionally compiled by jz with a size-oriented pass config
+`watr` is intentionally compiled by JZ with a size-oriented pass config
 (`watr:false`, `smallConstForUnroll:false`): on a large compiler bundle, the
 default WAT-level optimizer and small-loop unroll grow code more than they help.
-This keeps the target measuring the best current jz artifact for that workload.
+This keeps the target measuring the best current JZ artifact for that workload.
 
 ```sh
 BUN_BIN=/path/to/bun \
 DENO_BIN=/path/to/deno \
 SPIDERMONKEY_BIN=/path/to/js \
-HERMES_BIN=/path/to/hermes \
 SHERMES_BIN=/path/to/shermes \
 GRAALJS_BIN=/path/to/graaljs \
 PORF_BIN=/path/to/porf \
-node bench/bench.mjs --targets=bun,deno,spidermonkey,hermes,shermes,graaljs,porf
+node bench/bench.mjs --targets=bun,deno,spidermonkey,shermes,graaljs,porf
 ```
 
 ## Reading the numbers (darwin/arm64, M-class)
 
-Snapshots from `node bench/bench.mjs --targets=v8,jz,as`.
-Where jz lands relative to **V8 raw JS** (`v8/node`) and **AssemblyScript**
-(`as`) is the headline comparison. Native and hand-WAT rows are shown where
-available from earlier runs.
+Snapshots from `node bench/bench.mjs --targets=v8,jz,as` (the WASM lane).
+Where JZ lands relative to **V8 raw JS** (`v8/node`) and **AssemblyScript**
+(`as`) is the headline comparison; the hand-WAT row is the wasm-in-V8 floor.
+The fair native comparison lives in the page's separate **Native lane** (`jz-w2c`
+vs the native toolchains), not in these wasm snapshots — a native binary against
+wasm-in-V8 would be a wrong-class single-case compare.
 
 ### biquad — f64 typed-array DSP cascade
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **6.50 ms** | **1.90×** | **3.4 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 9.03 ms | 1.38× | 1.9 kB | ok |
-| V8 (node) raw JS | 12.35 ms | 1.00× | 3.2 kB | ok |
-| native C (clang -O3) | 5.32 ms | 2.32× | 32.7 kB | ok |
+| **JZ → V8 wasm** | **4.64 ms** | **1.94×** | **3.4 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 6.51 ms | 1.38× | 1.9 kB | ok |
+| V8 (node) raw JS | 8.98 ms | 1.00× | 3.2 kB | ok |
 | hand-WAT → V8 wasm | 6.49 ms | 1.90× | 767 B | ok |
 
-jz beats V8 raw JS by 1.9× and AS by 1.4×. The typed-array scalarization,
+JZ beats V8 raw JS by 2.1× and AS by 1.4×. The typed-array scalarization,
 offset-fusion, and base-hoisting pipeline delivers dense-f64 loop codegen
 that matches the hand-WAT floor.
 
@@ -162,13 +223,12 @@ that matches the hand-WAT floor.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **2.74 ms** | **4.37×** | **3.3 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 9.32 ms | 1.28× | 1.6 kB | ok |
-| V8 (node) raw JS | 11.96 ms | 1.00× | 1.2 kB | ok |
-| native C (clang -O3) | 2.76 ms | 4.33× | 32.8 kB | ok |
+| **JZ → V8 wasm** | **1.49 ms** | **5.75×** | **3.1 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 6.71 ms | 1.28× | 1.6 kB | ok |
+| V8 (node) raw JS | 8.57 ms | 1.00× | 1.2 kB | ok |
 | hand-WAT → V8 wasm | 8.12 ms | 1.47× | 414 B | ok |
 
-jz is 4.4× faster than V8 raw JS and 3.4× faster than AS. The scalarized
+JZ is 5.9× faster than V8 raw JS and 4.6× faster than AS. The scalarized
 SIMD hot path (unrolled 4×4 multiply) is the win; V8's JIT doesn't vectorize
 this from JS source.
 
@@ -176,11 +236,11 @@ this from JS source.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **0.37 ms** | **6.22×** | **1.2 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 1.15 ms | 2.02× | 1.3 kB | ok |
-| V8 (node) raw JS | 2.32 ms | 1.00× | 1014 B | ok |
+| **JZ → V8 wasm** | **0.13 ms** | **12.67×** | **1.4 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 0.81 ms | 2.07× | 1.3 kB | ok |
+| V8 (node) raw JS | 1.67 ms | 1.00× | 1014 B | ok |
 
-jz is 6.2× faster than V8 raw JS and 3.1× faster than AS. The bimorphic
+JZ is 12.9× faster than V8 raw JS and 5.9× faster than AS. The bimorphic
 `sum` (called with both `Float64Array` and `Int32Array`) stays on typed
 paths without falling back to generic dispatch.
 
@@ -188,13 +248,12 @@ paths without falling back to generic dispatch.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **1.40 ms** | **3.81×** | **1.2 kB** | **ok** |
-| V8 (node) raw JS | 5.32 ms | 1.00× | 1005 B | ok |
-| AssemblyScript (asc -O3 --runtime stub) | 12.13 ms | 0.44× | 1.5 kB | ok |
-| native C (clang -O3) | 1.31 ms | 4.06× | 32.9 kB | ok |
-| hand-WAT → V8 wasm | 4.88 ms | 1.09× | 355 B | ok |
+| **JZ → V8 wasm** | **1.01 ms** | **3.84×** | **1.2 kB** | **ok** |
+| V8 (node) raw JS | 3.87 ms | 1.00× | 1005 B | ok |
+| AssemblyScript (asc -O3 --runtime stub) | 9.15 ms | 0.42× | 1.5 kB | ok |
+| hand-WAT → V8 wasm | 3.59 ms | 1.11× | 355 B | ok |
 
-jz is 3.8× faster than V8 raw JS and 8.7× faster than AS. The i32 hot path
+JZ is 4.0× faster than V8 raw JS and 8.8× faster than AS. The i32 hot path
 (`Math.imul`, `|0`, `>>>0`) now lowers to raw `i32` ops without NaN-box
 overhead on every operation.
 
@@ -202,24 +261,22 @@ overhead on every operation.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| AssemblyScript (asc -O3 --runtime stub) | 0.08 ms | 2.63× | 1.6 kB | ok |
-| **jz → V8 wasm** | **0.10 ms** | **2.03×** | **1.7 kB** | **ok** |
-| V8 (node) raw JS | 0.21 ms | 1.00× | 2.0 kB | ok |
+| **JZ → V8 wasm** | **0.06 ms** | **2.26×** | **2.2 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 0.06 ms | 2.15× | 1.6 kB | ok |
+| V8 (node) raw JS | 0.13 ms | 1.00× | 2.0 kB | ok |
 
-jz is 2.0× faster than V8 raw JS. AS wins here by 1.3× because its
-`String#charCodeAt` is a direct memory load without NaN-box decode, while
-jz still boxes the string pointer. The gap is narrow (0.02 ms) and both
-are well ahead of V8.
+JZ is 2.4× faster than V8 raw JS and now edges out AS by ~1.2× on this
+`charCodeAt`-heavy scan. Both are well ahead of V8.
 
 ### callback — `Array.map` closure + i32 fold
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **0.03 ms** | **27.56×** | **1.4 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 1.49 ms | 0.59× | 1.9 kB | ok |
-| V8 (node) raw JS | 0.88 ms | 1.00× | 828 B | ok |
+| **JZ → V8 wasm** | **0.26 ms** | **2.37×** | **1.4 kB** | **ok** |
+| V8 (node) raw JS | 0.62 ms | 1.00× | 1.3 kB | ok |
+| AssemblyScript (asc -O3 --runtime stub) | 0.80 ms | 0.78× | 1.9 kB | ok |
 
-jz is 27.6× faster than V8 raw JS and 49.7× faster than AS. Closure +
+JZ is 2.3× faster than V8 raw JS and 2.9× faster than AS. Closure +
 `Array.map` lowers to a preallocated typed loop with no per-iteration alloc.
 V8's JIT does not inline the closure across the `map` boundary.
 
@@ -227,11 +284,11 @@ V8's JIT does not inline the closure across the `map` boundary.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **1.62 ms** | **1.12×** | **1.8 kB** | **ok** |
-| V8 (node) raw JS | 1.82 ms | 1.00× | 1.1 kB | ok |
-| AssemblyScript (asc -O3 --runtime stub) | 1.91 ms | 0.95× | 2.2 kB | ok |
+| **JZ → V8 wasm** | **0.69 ms** | **1.93×** | **1.8 kB** | **ok** |
+| V8 (node) raw JS | 1.33 ms | 1.00× | 1.1 kB | ok |
+| AssemblyScript (asc -O3 --runtime stub) | 1.40 ms | 0.95× | 2.1 kB | ok |
 
-jz is 1.1× faster than V8 raw JS and 1.2× faster than AS. Schema-slot
+JZ is 1.9× faster than V8 raw JS and 2.0× faster than AS. Schema-slot
 reads are direct field offsets; the gap is small because the workload is
 memory-bound.
 
@@ -239,81 +296,177 @@ memory-bound.
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| AssemblyScript (asc -O3 --runtime stub) | 12.42 ms | 1.11× | 1.3 kB | ok |
-| **jz → V8 wasm** | **12.55 ms** | **1.10×** | **1.0 kB** | **ok** |
-| V8 (node) raw JS | 13.80 ms | 1.00× | 1.8 kB | ok |
+| AssemblyScript (asc -O3 --runtime stub) | 8.90 ms | 1.11× | 1.3 kB | ok |
+| **JZ → V8 wasm** | **8.45 ms** | **1.17×** | **1.4 kB** | **ok** |
+| V8 (node) raw JS | 9.90 ms | 1.00× | 1.8 kB | ok |
 
-jz is 1.1× faster than V8 raw JS and ties AS. The dense f64 hot loop with
+JZ is 1.1× faster than V8 raw JS and ties AS. The dense f64 hot loop with
 conditional break compacts to 1.0 kB — the smallest wasm in the suite.
 
 ### json — runtime `JSON.parse` plus stable-shape walk
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **0.23 ms** | **1.65×** | **7.7 kB** | **ok** |
-| V8 (node) raw JS | 0.38 ms | 1.00× | 1.2 kB | ok |
+| **JZ → V8 wasm** | **0.21 ms** | **1.28×** | **9.9 kB** | **ok** |
+| V8 (node) raw JS | 0.27 ms | 1.00× | 1.2 kB | ok |
 
-jz is 1.7× faster than V8 raw JS. The runtime parser is specialized to the
+JZ is 1.3× faster than V8 raw JS. The runtime parser is specialized to the
 inferred JSON shape; AS is skipped because it cannot parse JSON at runtime.
 
 ### sort — in-place heapsort over typed array
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **5.96 ms** | **1.87×** | **1.6 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 10.22 ms | 1.09× | 1.9 kB | ok |
-| V8 (node) raw JS | 11.13 ms | 1.00× | 1.6 kB | ok |
+| **JZ → V8 wasm** | **4.65 ms** | **1.67×** | **1.8 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 7.96 ms | 0.98× | 1.9 kB | ok |
+| V8 (node) raw JS | 7.79 ms | 1.00× | 1.6 kB | ok |
 
-jz is 1.9× faster than V8 raw JS and 1.7× faster than AS. Call-heavy
+JZ is 1.6× faster than V8 raw JS and 1.4× faster than AS. Call-heavy
 nested loops with typed-array index propagation stay on the i32 path.
 
 ### crc32 — table-driven CRC-32 over byte buffer
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| **jz → V8 wasm** | **12.12 ms** | **1.11×** | **1.2 kB** | **ok** |
-| AssemblyScript (asc -O3 --runtime stub) | 12.19 ms | 1.10× | 1.4 kB | ok |
-| V8 (node) raw JS | 13.43 ms | 1.00× | 1.8 kB | ok |
+| **JZ → V8 wasm** | **8.74 ms** | **1.11×** | **1.5 kB** | **ok** |
+| AssemblyScript (asc -O3 --runtime stub) | 8.76 ms | 1.11× | 1.4 kB | ok |
+| V8 (node) raw JS | 9.71 ms | 1.00× | 1.8 kB | ok |
 
-jz is 1.1× faster than V8 raw JS and ties AS. Integer narrowing and
+JZ is 1.2× faster than V8 raw JS and ties AS. Integer narrowing and
 typed-array parameter propagation keep the LUT lookup on raw i32.
 
+### Audio + image showcase (cross-language, bit-exact)
+
+Four standard kernels added to make the audio story concrete. All are written so
+the output is **bit-identical** across every engine and native target — integer
+math (bytebeat, blur) or transcendental-free f64 (fft, synth: in-source Taylor
+polynomials, not `Math.sin`, which differs per libm). Go's arm64 auto-FMA gives
+the documented `fma` parity class on the f64 cases.
+
+| case | JZ | vs V8 | vs AS | vs fastest native | JZ wasm |
+| --- | ---: | ---: | ---: | --- | ---: |
+| **synth** — osc + ADSR + biquad | **2.32 ms** | **1.33×** | **1.07×** | **beats all** (Rust 0.89×) | 2.0 kB |
+| **fft** — radix-2 Cooley–Tukey | **1.14 ms** | **1.27×** | **1.13×** | **ties** (Rust 1.07×) | 2.3 kB |
+| **blur** — RGBA box blur | **0.90 ms** | **9.4×** | **5.8×** | trails (native SIMDs the stencil, 1.5×) | 3.4 kB |
+| **bytebeat** — integer one-liner | **0.67 ms** | **3.7×** | **5.4×** | trails (native vectorizes, 1.3×) | 1.5 kB |
+
+The headline: JZ beats the JS field (V8, AssemblyScript) on **every** audio/image
+case, **ties native on FFT**, and is the **fastest of all targets on the synth
+pipeline** — its per-sample loop is loop-carried (oscillator phase + biquad
+feedback), so native can't auto-vectorize it either, and JZ's tight scalar f64
+codegen with no NaN-box overhead wins outright. The two stateless integer kernels
+(bytebeat, blur) are where `clang`/`zig`/`rustc` auto-vectorize an
+embarrassingly-parallel loop JZ emits as scalar — native is the floor there, but
+JZ still beats the JS field by 3.7–9.4× there. (Numbers: darwin/arm64, Apple M4 Max; the live snapshot
+is [results.json](results.json).)
+
+### General-codegen kernels — 3-D render, procedural, sort, sequence DP
+
+Four kernels added to probe JZ's **general** scalar/branch/gather-scatter codegen,
+beyond the SIMD-friendly reductions and stencils above — the cases a graphics,
+procedural, data, or text workload actually hits. All bit-identical across targets
+(`raytrace`/`noise` are transcendental-free f64, so Go's arm64 auto-FMA is the
+documented `fma` class; `radixsort`/`levenshtein` are pure integer, exact
+everywhere).
+
+| case | JZ | vs V8 | vs AS | vs fastest native | JZ wasm |
+| --- | ---: | ---: | ---: | --- | ---: |
+| **radixsort** — LSD u32 sort | **2.75 ms** | **1.21×** | **1.19×** | trails (clang 1.5×) | 1.6 kB |
+| **noise** — Perlin fBm (5 oct) | **6.59 ms** | **1.36×** | 0.23× | trails (Rust 5.2×) | 8.0 kB |
+| **raytrace** — sphere render | **2.00 ms** | **1.07×** | 0.89× | trails (Rust 1.9×) | 4.8 kB |
+| **levenshtein** — edit-distance DP | ~6 ms | ~1.0× | 0.35× | trails (clang ~3×) | 7.5 kB |
+
+These are the honest mixed bag — and the point. JZ beats raw V8 on three of four
+(and the smallest wasm of the whole field on `radixsort`, 1.6 kB), but it only
+beats AssemblyScript on `radixsort`; it **trails AS** on `noise` (~4.3×) and
+`levenshtein` (~2.5–2.9×), and only **ties V8** on `levenshtein` (the median
+straddles 1.0× run-to-run). The two AS gaps localize the next codegen work:
+`noise`'s nested permutation-table indirection (`perm[perm[X]+Y]`) and
+`levenshtein`'s branchy `min`-reduction DP over a rolling typed-array row are
+exactly the scalar/gather shapes JZ does not yet lower as tightly as AS's
+`asc -O3`. They sit out the curated regression gate (`test/bench.js`) — like
+`heat`/`matmul`/`nbody`/`particle`/`lorenz` — until JZ closes the gap and they
+ratchet in as wins.
+
+### Control-flow & gather/scatter kernels — recursion, hashing, sieve, VM, sparse
+
+A second probe set, aimed squarely at the patterns the first batch flagged —
+recursion, branchy probe chains, scatter, and indirect gather — to map where JZ's
+general (non-SIMD) codegen actually stands. All bit-identical across every target
+(`spmv` is f64 over exact small integers, so even Go-native FMA agrees; `nqueens`
+draws its board sizes from a runtime array so clang/rustc can't fold the recursion
+to a constant).
+
+| case | JZ | vs V8 | vs AS | vs native C | what it probes |
+| --- | ---: | ---: | ---: | ---: | --- |
+| **vm** — bytecode dispatch | **7.30 ms** | **1.55×** | **2.20×** | **1.13×** | if/else opcode dispatch + indirect fetch |
+| **spmv** — sparse A·x (CSR) | **2.67 ms** | **1.78×** | **1.25×** | 0.90× | indirect gather `x[col[k]]` |
+| **sieve** — Eratosthenes | **7.18 ms** | **1.53×** | **1.30×** | 0.80× | strided scatter + outer branch |
+| **nqueens** — backtracking | **6.05 ms** | **1.29×** | 0.93× | 0.78× | deep recursion + bitmask branch |
+| **dict** — hash table | 4.11 ms | 0.78× | 0.81× | 0.39× | hash scatter + probe-chain gather |
+
+The split is sharp and informative. **JZ is excellent at dense dispatch and
+in-cache gather**: it wins `vm` against the *entire* field — including native
+`clang -O3` (the if/else interpreter loop lowers to tight branches with no
+NaN-box overhead, where AS pays per-access bounds checks), and wins `spmv`/`sieve`
+over the JS field while sitting near native. But it **loses `dict` to both V8
+(1.28×) and AS (1.24×)** — open-addressing's hash-scatter + dependent-load probe
+chain is the same gather/branch shape as `noise` and `levenshtein`, and the
+clearest, most reproducible deficiency the suite has surfaced. `nqueens` is a
+near-tie with AS on recursion. Together the nine new cases triangulate it: JZ's
+gap to the AS/native frontier is concentrated in **scatter-heavy hashing and
+dependent-gather / branchy-DP** kernels, not in dense scalar or dispatch loops.
+Like the batch above, these stay bench-only (out of `test/bench.js`) until the gap
+closes.
+
 ### watr — WAT-to-wasm compiler on small corpus
 
 | target | median | ×v8 | size | parity |
 | --- | ---: | ---: | ---: | --- |
-| V8 (node) raw JS | 1.45 ms | 1.00× | 2.6 kB | ok |
-| **jz → V8 wasm** | **1.56 ms** | **1.07×** | **144.4 kB** | **ok** |
+| V8 (node) raw JS | 1.38 ms | 1.00× | 2.6 kB | ok |
+| **JZ → V8 wasm** | **1.17 ms** | **1.17×** | **238.4 kB** | **ok** |
 
-jz is 1.07× slower than V8 raw JS on this large compiler bundle. The size
+JZ is 1.07× slower than V8 raw JS on this large compiler bundle. The size
 (144 kB) is the full jz-compiled watr parser + encoder + optimizer; V8's JIT
 has the advantage of profile-guided tiering on a long-running compiler.
 
 ### Where the gaps live
 
-Aggregate geomean (jz / target):
+Aggregate geomean (JZ / target):
 
 | target | speed | size |
 | --- | ---: | ---: |
-| V8 (node) | **0.41×** | — |
-| AssemblyScript | **0.40×** | **0.85×** |
-| Porffor | **0.32×** | **0.04×** |
-| wasm-opt slack | — | **0.91×** |
+| V8 (node) | **0.40×** | — |
+| AssemblyScript | **0.36×** | **1.16×** |
+
+JZ wins or ties V8 on every kernel case; the only V8 losses are the
+self-hosting rows `watr` (1.07×) and `jessie` (1.28×). AS is beaten on
+speed across the shared cases. On size JZ is ~1.1× AS (geomean 1.16×,
+median 1.10×) — JZ wins on speed, AS on bytes.
 
-jz wins or ties V8 on every case except `watr` (1.07×). AS is beaten on
-all cases except `tokenizer` (AS 0.08 ms vs jz 0.10 ms). The size geomean
-is 0.85× AS — jz output is smaller on average despite beating AS on speed.
+Against the systems languages compiled to the same target — **WebAssembly, run in
+V8** — JZ is **2.4× faster than C, 2.6× than Rust, and 4.8× than Go** (geomean).
+That apples-to-apples wasm field is the headline chart above, and JZ holds
+**geomean parity with native `clang -O3`** itself (1.11×) — the lone non-wasm
+reference row, the speed-of-light ceiling, never a per-case beat-claim.
 
 Case-by-case summary:
 
-* **biquad, mat4, poly, bitwise, callback: large wins.** jz beats V8 by
-  1.9–27.6× and AS by 1.4–49.7×. Typed-array scalarization, i32 narrowing,
+* **biquad, mat4, poly, bitwise, callback: large wins.** JZ beats V8 by
+  2.0–12.9× and AS by 1.4–9.1×. Typed-array scalarization, i32 narrowing,
   and closure lowering are the drivers.
-* **tokenizer, aos, mandelbrot, sort, crc32: modest wins.** jz beats V8 by
-  1.1–2.0× and ties or beats AS. These are memory-bound or branch-heavy
+* **tokenizer, aos, mandelbrot, sort, crc32: modest wins.** JZ beats V8 by
+  1.1–2.4× and ties or beats AS. These are memory-bound or branch-heavy
   workloads where codegen quality matters less than data layout.
-* **json: solid win.** jz beats V8 by 1.7× on runtime JSON parsing; AS
+* **json: solid win.** JZ beats V8 by 1.3× on runtime JSON parsing; AS
   cannot run this case.
-* **watr: near parity.** jz is 1.07× slower than V8 on a 144 kB compiler
-  bundle. This is the only case where V8's profile-guided JIT tiers beat
-  jz's AOT wasm.
+* **alpha: the native floor.** JZ beats V8 2.0× and every wasm rival (Rust/C/Go
+  → wasm), but trails the native-C reference ~14× (374 µs vs 26 µs) — alpha's hot
+  path is an unsigned i32 multiply. JZ already lifts it to 128-bit SIMD (an i16x8
+  widening byte-map); native C pulls ahead on width alone — 256-bit AVX2 with a
+  fused byte multiply-add, run as native code with no per-load bounds checks. The
+  residual is the wasm-v128-vs-AVX2 ceiling, not a missing pass. A known gap we
+  publish rather than hide.
+* **watr: near parity.** JZ is 1.07× slower than V8 on a 144 kB compiler
+  bundle. It is one of two self-host rows (with jessie) where V8's
+  profile-guided JIT tiers beat JZ's AOT wasm.