2 ms·
> Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript;
by jashmatthews 9y ago
> Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust.
WebAssembly is a VM bytecode for a stack-based VM. Unless you want things to run very, very slowly you still need a JIT to emit native code, rather than loop dispatching each WebAssembly instruction in a bytecode interpreter.
WebKit, for example, has a two-tier JIT for WebAssembly just like JS, but WebAssembly has already had all the high level language related optimizations performed and looks a bit like an intermediate representation anyway so the first pass is very fast.
- jnordwick 9y agoSo that means wasm has already been inlined and loops unrolled? How will this all interact with vectorization or insurrection choice? I think the VM is going to need to be just like every other VM (once inlining is introduced, why even bother with trying to optimize wasm before the JIT). If wasm is going to be so good, then you could retart java to it? I know a lot of high performance java shops that would love to get rid of the GC in Java. But Hotspot can be an optimizing beast.
- Rusky 9y agoYou can't get rid of GC in Java without essentially replacing Java.
- Rusky 9y agoYes, I do want a JIT in that sense. I just don't want it doing Javascript-style optimizations with profiling and speculation+deoptimization. What WebKit is doing is moving in that direction (unfortunately) but it still looks much more like an "-O0 -> -O3" sort of thing than what Javascript gets.