Firefox’s new streaming and tiering compiler • Hacker News Board

Re: Firefox’s new streaming and tiering compiler

#11

Post by Yoric » Wed, Jan 17, 2018, 5:16 PM UTC

zach43 wrote: post #2

Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine. As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

Well, the difference between "interpreted" and "compiled" has become very blurry during the last 20 years. These days, most "interpreted" programming languages are actually compiled to machine code on the client system.

This includes the JVML, of course, but also JavaScript, Python (with PyPy), etc. PHP isn't quite there yet, but it's coming.

> As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

It's slightly different, but native code is typically compiled concurrently, too. The meat of it is often handled by the build system rather than the compiler itself, but that's not so different.

Re: Firefox’s new streaming and tiering compiler

#12

Post by stevemk14ebr » Wed, Jan 17, 2018, 5:17 PM UTC

sjrd wrote: post #5

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…

I don't think that's absurd at all. WebASM really should be the ASM of the web, everything should be compiled to it. A little pre-compilation of JS to WebASM makes sense to me

Re: Firefox’s new streaming and tiering compiler

#13

Post by nothrabannosir » Wed, Jan 17, 2018, 5:17 PM UTC

does someone here, familiar with webassembly semantics, know if it’s theoretically possible to start streaming execution of code? I.e. as soon as the “main” (?) function is in, and block on every function call which is not yet compiled, recursively? Or could the last block of webassembly bytecode potentially change the semantics of the first?

Sooner or later, that’s an avenue people will want to explore, I assume?

Re: Firefox’s new streaming and tiering compiler

#14

Post by sjrd » Wed, Jan 17, 2018, 5:18 PM UTC

icen wrote: post #8

sjrd wrote: post #5

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…

> 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.

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.

Re: Firefox’s new streaming and tiering compiler

#15

Post by lclarkmichalek » Wed, Jan 17, 2018, 5:18 PM UTC

Yoric wrote: post #11

zach43 wrote: post #2

Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine. As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

Well, the difference between "interpreted" and "compiled" has become very blurry during the last 20 years. These days, most "interpreted" programming languages are actually compiled to machine code on the client system. This includes the JVML, of course, but also JavaScript, Python (with PyPy), etc. PHP isn't quite there yet, but it's coming. > As a side note, it is interesting to see that multithreaded compilation o…

PHP is there with HHVM

Re: Firefox’s new streaming and tiering compiler

#16

Post by sjrd » Wed, Jan 17, 2018, 5:19 PM UTC

stevemk14ebr wrote: post #12

sjrd wrote: post #5

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…

I don't think that's absurd at all. WebASM really should be the ASM of the web, everything should be compiled to it. A little pre-compilation of JS to WebASM makes sense to me

See my answer here: https://news.ycombinator.com/item?id=16169705

Re: Firefox’s new streaming and tiering compiler

#17

Post by Yoric » Wed, Jan 17, 2018, 5:20 PM UTC

sjrd wrote: post #14

icen wrote: post #8

Earlier quoted context omitted.

> 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.

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 bui…

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

#18

Post by [deleted] » Wed, Jan 17, 2018, 5:21 PM UTC

gigatexal wrote: post #7

sjrd wrote: post #5

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That inclu…

Yeah I read the article too and thought: but what can I do with wasm?

[deleted]

Re: Firefox’s new streaming and tiering compiler

#19

Post by Yoric » Wed, Jan 17, 2018, 5:21 PM UTC

lclarkmichalek wrote: post #15

Yoric wrote: post #11

Earlier quoted context omitted.

Well, the difference between "interpreted" and "compiled" has become very blurry during the last 20 years. These days, most "interpreted" programming languages are actually compiled to machine code on the client system. This includes the JVML, of course, but also JavaScript, Python (with PyPy), etc. PHP isn't quite there yet, but it's coming. > As a side note, it is interesting to see that multithreaded compilation o…

PHP is there with HHVM

My bad, I hadn't looked at that project in some time and I hadn't realized they had advanced that far.

Re: Firefox’s new streaming and tiering compiler

#20

Post by JepZ » Wed, Jan 17, 2018, 5:22 PM UTC

Quoting Yehuda Katz, the co-creator of Ember.js, when it comes to JS-sizes is kinda hilarious (random google result):

https://gist.github.com/Restuta/cda69e50a853aa64912d

No offense to Yehuda in general (he is doing great work), but Ember.js so ignorant of any js-size recommendations, that it seems weird to quote Yehuda in that context.