Low level
One escape-time Mandelbrot kernel, written four times: plain JavaScript, WebAssembly compiled ahead of time, a worker pool writing into one SharedArrayBuffer, and a WebGPU compute shader. Every backend renders the identical tile, and a checksum proves it before any timing is reported.
Detecting…
| Backend | Time | vs JS | Pixels match | Notes |
|---|---|---|---|---|
| JavaScript | not run | — | — | |
| WebAssembly | not run | — | — | |
| Workers + SharedArrayBuffer | not run | — | — | |
| WebGPU compute | not run | — | — |
It is the same algorithm with the same squared-term reuse, writing into the same buffer shape. Benchmarking WebAssembly against deliberately naive JavaScript is the oldest way to produce an impressive and meaningless number. What is left measures what an ahead-of-time compiled module with a fixed memory layout buys over an optimising JIT on identical arithmetic — a real margin, and a smaller one than the demos usually claim.
SharedArrayBuffer needs COOP: same-origin and COEP: require-corp, and COEP blocks every cross-origin subresource that does not opt in. Site-wide it would break the OpenStreetMap frame on /reach-out and the OAuth avatars. So it is applied to this route only — the isolation is real here and nowhere else, which is the correct scope rather than a compromise.
Points inside the set run the full iteration count; points outside escape in two. Slicing the tile into contiguous bands therefore gives each worker very different amounts of work, and the speed-up lands well under the core count. That is the real load-imbalance problem parallel work has, and hiding it behind a workload that divides evenly would make the demo prettier and less true.
WGSL has no f64. At this zoom the reduced precision produces visible banding and a checksum that does not match the other three — which the table reports as differs rather than quietly loosening the comparison until it agreed. The GPU is doing enormously more arithmetic in parallel; it is not doing the identical arithmetic.
