5 ms·

> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!" Is this this absurd? Given you can compile WAS

by icen 9y ago

> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!" Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.

sjrd 9y ago
I can't tell whether you're being sarcastic or not, so I will answer as if you are not. 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.
- Yoric 9y ago
  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.
  - sjrd 9y ago
    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.
    - jahewson 9y ago
      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.
    - Zekio 9y ago
      Wonder if there will ever be a version of typescript that compiles to wasm
  - jahewson 9y ago
    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”.
- hateduser2 9y ago
  They’re adding gc and dom support to wasm
kroltan 9y ago
JS is a garbage-collected language. It would require reimplementing most of the runtime, or be stuck with code that does marshalling for everything and would possibly be slower than plain JS.

by icen 9y ago

sjrd 9y ago

I can't tell whether you're being sarcastic or not, so I will answer as if you are not. 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.

Yoric 9y ago
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.
- sjrd 9y ago
  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.
  - jahewson 9y ago
    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.
  - Zekio 9y ago
    Wonder if there will ever be a version of typescript that compiles to wasm
- jahewson 9y ago
  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”.
hateduser2 9y ago
They’re adding gc and dom support to wasm

kroltan 9y ago

JS is a garbage-collected language. It would require reimplementing most of the runtime, or be stuck with code that does marshalling for everything and would possibly be slower than plain JS.