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

Re: Firefox’s new streaming and tiering compiler

#51

Post by flavio81 » Wed, Jan 17, 2018, 5:58 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…

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.).

DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs.

Mark my words.

Re: Firefox’s new streaming and tiering compiler

#52

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

jnordwick wrote: post #34

kllrnohj wrote: post #24

Earlier quoted context omitted.

Function declarations are independent from function bodies. So think C/C++ headers/source file splits. You don't need to know what code is in bar if you know it takes 1 argument of type int and returns an int. That's all you needed to know how to call it successfully, so you can compile foo in your example perfectly fine. You just need to patch up the call location later when bar is resolved to actual address (this i…

Considering the major optimization in compiling is inlining, knowing the function body is very important to compilation, but I guess that can be pushed off until the next tier.

[deleted]

Re: Firefox’s new streaming and tiering compiler

#53

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

markdog12 wrote: post #3

https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s) Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s) Wow. (Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)

I'm running Firefox 57, and even here, Firefox is significantly faster; 3182.3ms (3.9mb/s) in Firefox, 7575ms (1.6mb/s) in Chrome 63.

Re: Firefox’s new streaming and tiering compiler

#54

Post by callahad » Wed, Jan 17, 2018, 6:02 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

There's a simple-but-useful WebAssembly Explorer at https://mbebenita.github.io/WasmExplorer/ that interactively shows the C/C++ -> WASM Text -> x86 ASM path that WebAssembly takes.

I wrote up a short article and video demonstrating it last year at https://hacks.mozilla.org/2017/03/previewing-the-webassembly...

Re: Firefox’s new streaming and tiering compiler

#55

Post by vurpo » Wed, Jan 17, 2018, 6:06 PM UTC

jnordwick wrote: post #44

I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference? Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.

wasm is not a browser plugin, it is part of the browser. That means the plugin architechture does not need to exist (which has already been removed by all major browsers). Building wasm support into browsers was not an easy task, and "just embed hotspot" is not any easier.

Re: Firefox’s new streaming and tiering compiler

#56

Post by SubiculumCode » Wed, Jan 17, 2018, 6:08 PM UTC

markdog12 wrote: post #3

https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s) Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s) Wow. (Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)

Chrome: WebAssembly.instantiate took 22861.1ms (0.5mb/s)

Nightly:WebAssembly.instantiate took 1825.3ms (6.8mb/s)

Mine was a laptop in low power mode. Yours was much faster all around.

Re: Firefox’s new streaming and tiering compiler

#57

Post by ake1 » Wed, Jan 17, 2018, 6:09 PM UTC

flavio81 wrote: post #51

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…

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

do you know of any ongoing work?

Re: Firefox’s new streaming and tiering compiler

#58

Post by kllrnohj » Wed, Jan 17, 2018, 6:09 PM UTC

jnordwick wrote: post #34

kllrnohj wrote: post #24

Earlier quoted context omitted.

Function declarations are independent from function bodies. So think C/C++ headers/source file splits. You don't need to know what code is in bar if you know it takes 1 argument of type int and returns an int. That's all you needed to know how to call it successfully, so you can compile foo in your example perfectly fine. You just need to patch up the call location later when bar is resolved to actual address (this i…

Considering the major optimization in compiling is inlining, knowing the function body is very important to compilation, but I guess that can be pushed off until the next tier.

WebAsm is an intermediate not a source language. Initial in-lining & other optimization have already been performed long before it hit your browser. There could potentially be a JIT or similar to do a secondary optimization pass in the browser if something is hot, but it's probably going to be largely considered a codegen issue rather than a runtime issue.

Re: Firefox’s new streaming and tiering compiler

#59

Post by sehugg » Wed, Jan 17, 2018, 6:22 PM UTC

That's great news. On http://8bitworkshop.com/ I'd like to offer some additional WASM modules on-demand but they take 15+ seconds to load. (It seems 50% of the time is parsing and 50% module instantiation)

Re: Firefox’s new streaming and tiering compiler

#60

Post by MrMid » Wed, Jan 17, 2018, 6:22 PM UTC

axelfontaine wrote: post #49

Using https://lukewagner.github.io/test-tanks-compile-time/ Chrome 63: 3143.7ms (3.9mb/s) Firefox 57: 1499ms (8.3mb/s) Edge 41: 97.3ms (127.2mb/s) !!!

Wow.

Firefox 59: 474 ms

Edge 41: 164 ms

The difference is smaller with newer FF, but that is amazing from Edge!