[dljsjr]

The JVM has a ton of different things going on, it's not an apples-to-apples comparison.

For one, the JVM isn't sandboxed by default. WASM is. That adds additional overhead.

Another consideration is that the JVM uses garbage collection. This doesn't just apply to the code itself, it includes things like the hot code cache and stuff. The JVM trades throughput for latency. WASM doesn't have a GC model.

Lastly, WASM doesn't define the runtime. There is no JIT for "WASM", that's just a bytecode spec. I'm actually not even sure if when you run it in a browser it will JIT the WASM bytecode.

[dahfizz]

V8 does JIT compile WASM[1].

I would also expect GC to be an advantage for WASM here, since it originated from a language without a GC. Having to run a GC is slower than not having to run a GC, and the WASM code from the article doesn't need garbage collection.

Sandboxing is a plausible explaination. I can't imagine seccomp filters hurt performance that bad, but who knows how V8 does its sandboxing.

[1] https://v8.dev/docs/wasm-compilation-pipeline

[josephg]

Are there any comprehensive benchmarks of WASM runtimes?

I've been using V8 to benchmark WASM code because its convenient, and because WASM in V8 is the obvious comparison to make when benchmarking against Javascript code. But if one of the other WASM runtimes does a better job optimizing, it might be interesting to see that.