Wasm vs JavaScript benchmark Browse Catalog Experiment Evidence data v1

Compiler & Language Workload · 7 Implementations of 2 Kernels

Multi-Language WebAssembly Kernels

The same two kernels — a u32 array reduction and an FFT butterfly — written in JavaScript, raw WAT, AssemblyScript, C, C++, Rust, and Dart (WasmGC), compiled to WebAssembly where applicable, and compared side by side on this machine.

Run Benchmark Loop

Ready. Select loop iterations, then click Start.

Source & build provenance

Every implementation runs the identical algorithm: sum_u32 reduces 1,000 u32 integers; fft_butterfly runs a radix-2 Cooley–Tukey butterfly over 512 float pairs. The linear-memory variants (WAT, AssemblyScript, C, C++, Rust) operate on raw memory pointers. The Dart variant is a WasmGC module that consumes the same data zero-copy through dart:js_interop typed-array views. C/C++/AssemblyScript/ Rust/WAT use an f32 polynomial sin/cos (wasm32 has no hardware trig); JavaScript and Dart use f64 Math.sin/Math.cos — disclosed per variant.

Language Kernel Source Compiler / Toolchain Artifact
JavaScript build script (JS baselines) V8 JIT (in-browser) n/a — source only
Raw WAT sum-u32.wat Handwritten WAT → wasm (pinned artifact) sum_wat.wasm (96 B)
AssemblyScript sum_u32.ts · fft_kernel.ts asc -O3 --bindings none sum_asc.wasm · fft_asc.wasm
C / Wasm sum_u32.c · fft_kernel.c clang --target=wasm32 -O3 -nostdlib sum_c.wasm · fft_c.wasm
C++ / Wasm sum_u32.cpp · fft_kernel.cpp clang++ --target=wasm32 -O3 -nostdlib sum_cpp.wasm · fft_cpp.wasm
Rust / Wasm sum_u32.rs · fft_kernel.rs rustc --target wasm32-unknown-unknown -O (no_std cdylib) sum_rs.wasm · fft_rs.wasm
Dart / WasmGC fft_kernel.dart dart compile wasm (dart2wasm, WasmGC) fft_dart.wasm + glue

Cold Start & Runtime Footprint

Managed WasmGC runtimes carry real cost: the Dart module is ~39.7 KB with 380 imports and its instantiation glue; the prebuilt Kotlin/Wasm document-edit module is ~37 KB with 216 imports. By contrast the linear-memory kernels are 94–2,479 bytes with zero imports. Measured cold-instantiation and per-workload warm timings are in the static report and the JSON report.

Source & build provenance

JavaScript is off. Sources, artifacts, and measured reports remain available through the links above.