Hacker News Reader

The gap to native code will, most likely, always be there. Information is lost during the translation to WASM that an optimizer could have leveraged on the target architecture, not to mention WASM itself is adding overhead to satisfy the portability & security goals it is targeting.

Similarly WASM will always lag behind the state of the art for native code (eg, new SIMD or other accelerated instructions). That's the price of portability after all.

View on HN

But how large is this gap? I.e. 10%, 50%, 100% or 1000%. Size of this gap affects trade offs of using WASM vs native code a lot.

It varies by the runtime, and the codegen of the WASM itself. From some benchmarks & anecdotes I've seen, the faster runtimes (v8, Spidermonkey, WAVM) are within about 10-50% of native speeds, give or take. There's also some runtimes (like Wasmer & WAVM) which provide the option to AOT compile your WASM module to native. In those cases, the gap from native is much smaller. But so far the JIT for WASM is just immature.

That said, from what I've read, it looks like starting up a new WASM instance is pretty fast, so some places are using it for when they need to spawn up tons of instances all at once, without having to wait for a whole process to warm up.

Reply on news.ycombinator.com