I'm interested to see that the rust code run as WASM takes 193ms, but natively runs in 56ms. That's some serious overhead from the runtime! I would have hoped running wasm was closer to native speed than that.
Added a runtime for a dynamic language and code that can run on any platform the runtime supports—not just the one you compiled for and including through remote network delivery such as a web browser—and it's ONLY 3-4x slower!?
I don't think you fully appreciate just how mindbogglingly impressive it is that it's SO CLOSE to native speed!
I don't agree at all. The JVM gets much much better performance than that, and it runs on a runtime that supports ~all platforms. Idiomatic Java and C code will be within ~25% of each other. [1]
Being 4x slower is pretty abysmal, honestly. I would expect a small penalty for running the JIT, but after that the jitted WASM code and native code should be identical. If the hype is to be believed, the jitted code should actually be better than native code.
Maybe running the JIT is just really slow? If the native program ran for a minute, would the WASM version run in 4 minutes, or 1.15 minutes?
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.
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.
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.
