4 ms·
The other thing is that the semantics of JS force some constraints on the JIT that make it harder for it to optimize code aggressively. Specifically, JIT compil
by duped 4y ago
The other thing is that the semantics of JS force some constraints on the JIT that make it harder for it to optimize code aggressively. Specifically, JIT compilers for JavaScript need to implement dynamic de-optimization when optimized code paths turn out to be wrong (because JS can do things like overwrite a method, meaning inclined calls to the method are now invalid).
Afaict it's much easier to write a high performance JIT for WASM because those cases aren't possible. And consequently, it's easier for something compiling to WASM to get high performance out.
- thrashh 4y agoDoesn’t it depend on the source language? If you compile JS to WASM, you’d have the same problem. I imagine Python performance isn’t too great either. Whereas if you compiled (or translated — not sure how comparable the WASM instruction set is) x86 bytecode to WASM, it’d be a walk in the park.
- duped 4y agoSure, but that's the problem of the hosted language's compiler and not the JIT. Then the optimization pass turns into compiling the redefined method to WASM which can then be JIT compiled and inlined, so deoptomization isn't as bad (at least only the compilation unit has to be ditched)