Beyond the Baseline: Experimental WebAssembly for High Performance
summary
Benchmarks show an FP16 end-to-end prototype in toolchains and the runtime producing compute-kernel speedups of 75–125% and an application feature improvement around 60% with model size halved on ARM64; BF16 is proposed but not yet prototyped. A separate early memory-control prototype exposes memory.map and memory.unmap APIs to avoid copies and targets ~20% lower overhead, while concurrency, overlapping mappings, OS atomicity, and increased CVE risk from new features remain unresolved.
AI-written summary · about
chapters (16)
- 0:00WebAssembly at Google
- 1:01WebAssembly evolution
- 3:32Chromium’s WASM principles
- 7:23Browser performance nuances
- 8:07WASM success metrics
- 9:11Performance for web apps
- 10:55WASM compute extensions
- 11:59FP16 and BF16 extensions
- 15:33Programmability and detection
- 19:32Performance extension questions
- 19:53WASM memory footprint
- 23:46Memory control proposals
- 27:21Numeric extensions and detection
- 28:44Security trade-offs
- 30:09Summary and future
- 30:30Q&A
related talks
37mBridging the Architecture Divide: How Hardware Limits Wasm, and How We Can Do Better
34mPanel Discussion: Browsers & Wasm
29mPerformant Bounds Checking for 64-Bit WebAssembly
20mNot So Fast: Analyzing the Performance of WebAssembly vs. Native Code
45mWebAssembly's Post-MVP Futurer
31meBPF and Wasm: Unifying Userspace Extensions With Bpftime
27mWebAssembly for Performant Interactivity
29mNew Adventures for WASM