Re:Firefox’s new streaming and tiering compiler
by Yoric on Wednesday January 17, 2018 @12:20PM
(#16169726)
On the other hand, you could compile well-behaved subsets of JavaScript into wasm. Kind of what asm.js was doing.
Whether that's useful in practice is an open question, but it's plausible.
Re:Firefox’s new streaming and tiering compiler
by jahewson on Wednesday January 17, 2018 @12:31PM
(#16169843)
It’s really inaccurate to call that “JavaScript” any more. You’re talking about a subset of JS that would never need to perform a GC! Really just “the subset of JavaScript which also happens to be C”.
Re:Firefox’s new streaming and tiering compiler
by sjrd on Wednesday January 17, 2018 @12:26PM
(#16169783)
asm.js was not a well-behaved subset of JavaScript. It was a well-behaved subset of assembly that happened to be encoded in JavaScript.
There is virtually no human-written JS code that is amenable to compilation to wasm in a meaningful way. At the very least, you need a (mostly) sound type system to be able to compile to wasm with a positive expected ROI.
The speed of wasm comes in a large part from the fact that it is entirely statically typed, which means we don't need the speculative optimizations (and their deoptimization guards) all over the place.
Re:Firefox’s new streaming and tiering compiler
by Zekio on Thursday January 18, 2018 @06:29AM
(#16176306)
Wonder if there will ever be a version of typescript that compiles to wasm
Re:Firefox’s new streaming and tiering compiler
by jahewson on Wednesday January 17, 2018 @12:41PM
(#16169962)
Exactly, plus in a dynamic environment a tracing JIT can outperform AOT compiled code. This is true for both the JVM and .NET CLR, both mature platforms.
Re:Firefox’s new streaming and tiering compiler
by hateduser2 on Wednesday January 17, 2018 @01:54PM
(#16170612)
They’re adding gc and dom support to wasm
Yes, it is absurd. Because your wasm that was compiled from JS needs to embed an entire implementation of the dynamic nature of JS. And to make all those dynamic features remotely fast, you cannot just compile them as is. You need to use a JIT to be able to perform speculative optimizations. But then, where's the JIT? Oh, it's built inside your wasm code. And basically you end up shipping a JS interpreter+compiler+JIT as part of your wasm, instead of just the .js code. Parsing and compiling all of that will be much, much worse than parsing the .js code and feed it to the already existing JS interpreter+compiler+JIT that is in the browser.