Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox’s new streaming and tiering compiler

hacks.mozilla.org

Post reply on HN
Print view View original

121–130 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#121

Post by Rusky »

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

You can interpret wasm if you want, but considering the motivation for wasm is performance that kind of defeats the point.

Re: Firefox’s new streaming and tiering compiler

#122

Post by MaxBarraclough »

hyperpape wrote: post #67
MaxBarraclough wrote: post #21

A two-tier JIT. Interesting to see tiered JIT compilation catch on the way it has. I seem to remember a few years ago reading that the Java HotSpot team had given up on tiered JIT compilation as being not worthwhile. How far we've come. A whirlwind tour of todays JITs (apologies for the million links): .Net Core seems not to use tiered compilation. It never interprets the IR; everything is run through the same JIT co…

I'm not aware of any effort to retire tiered compilation. It was even promoted to be the default in Java 8 (2014). http://www.oracle.com/technetwork/articles/java/architect-ev... The only downside I'm aware of is that it increases the pressure on the code cache. If your code cache is not large enough, it will thrash as methods are discarded then recompiled. We had significant performance problems with a server and it…

Oops, I wasn't clear. I'd meant that, if I recall correctly, the HotSpot team initially experimented with combining the 'client' and 'server' JITs for tiered compilation, but decided it was a lot of complexity for little gain, and didn't commit.

Only a couple years later did they re-attempt it and stick with it.

I could be mistaken here, and I wasn't able to find anything online to support me.

Re: Firefox’s new streaming and tiering compiler

#123

Post by emn13 »

rcthompson wrote: post #110
chrisseaton wrote: post #109

Earlier quoted context omitted.

No these terms never have precise meanings, and trying to debate them too much doesn't achieve much. But if your definition doesn't actually work for any examples of the thing you're defining at all except one then it's probably wrong.

Ok, fair enough. I was worried that there was some precise definition I had missed, but if that's not the case, I agree there's no point in debating it.

Well, there's at least one definition that's pretty noncontroversial, if not terribly satisfying or precise: it's not a JIT if you compile well in advance of any indication the program needs to be run.

Whether that lazy-compilation strategy is fine-grained or not isn't clearcut, I believe. I think if you distribute a C program with a bash bootstrapper calling plain old gcc to compile and run the C code only when needed, even gcc might be considered a (coarse-grained, rather rudimentary) JIT in that context.

Re: Firefox’s new streaming and tiering compiler

#124

Post by wlesieutre »

swsieber wrote: post #104
wlesieutre wrote: post #66

Earlier quoted context omitted.

Calling it now: 1) Write a Windows app 2) Run it in the browser with wasm 3) Stuff that into Electron and distribute to Mac/Linux/Windows Why distribute the electron wrapped wasm on Windows instead of using the real native Windows app? It's more consistent this way! Single codebase! Developer efficiencies!

Small deviation - write a native linux or mac app (instead of targeting Windows for the initial app)... mostly because I feel like developing on those platforms is so much more enjoyable.

Good point. Linux is probably the easier one because you'd need to build your UI toolkit into it and we don't have the source for Cocoa or whatever this year's Windows UI toolkit is called.

Re: Firefox’s new streaming and tiering compiler

#125

Post by mr_toad »

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.

The DOM will be around as long as the web has documents.

Re: Firefox’s new streaming and tiering compiler

#127

Post by DiThi »

isaacaggrey wrote: post #75
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) !!!

Could someone explain how Edge is performing so well or any references to what they have done in this regard? Has the Edge team already implemented this streaming and tiering compiler technique?

You tell Edge, "compile this", Edge replies "done!" when what it has done is just verifying it's valid WASM. When you then call a function, it's compiled.

Re: Firefox’s new streaming and tiering compiler

#128

Post by pcwalton »

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.

I'm nearly certain that this will not be the case. Once you reinvent everything that the DOM does, it's highly unlikely you'll end up faster than the DOM.

Everyone thinks that the rendering engines in browsers are easy to beat in terms of performance. I thought that too, until I implemented one. They are definitely beatable, but not easily, and certainly not with an architecture like that of Qt or GTK.

Re: Firefox’s new streaming and tiering compiler

#129

Post by MaxBarraclough »

rcthompson wrote: post #41
MaxBarraclough wrote: post #21

A two-tier JIT. Interesting to see tiered JIT compilation catch on the way it has. I seem to remember a few years ago reading that the Java HotSpot team had given up on tiered JIT compilation as being not worthwhile. How far we've come. A whirlwind tour of todays JITs (apologies for the million links): .Net Core seems not to use tiered compilation. It never interprets the IR; everything is run through the same JIT co…

Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more optimized versions makes it a JIT? Or does the definition of JIT require recompiling in response to information about which code would benefit most?

> Is it actually a JIT? It's just compiling everything unconditionally.

Still counts as JIT in my book, but you're right that it's a bit subtle.

Unix-style configure/build/install isn't considered JIT.

Installing a .Net application is pretty similar, but we don't consider it JIT.

In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-and-install process is less explicit than the Unix way, and it's less error-prone (fewer dependency issues and issues with the compiler not liking your source code).

Really it's a very similar model to the Unix one, but we call one JIT and not the other.

Oracle Java, of course, only ever compiles to native code at runtime, and never caches native code. 'Proper' JIT. (This may be set to change in the near future though.)

Interestingly, .Net seems to be moving in the direction of full static compilation, or they wouldn't be asking devs to rebuild UWP apps to incorporate framework fixes - https://aka.ms/sqfj4h/

Re: Firefox’s new streaming and tiering compiler

#130

Post by qznc »

DiThi wrote: post #127
isaacaggrey wrote: post #75

Earlier quoted context omitted.

Could someone explain how Edge is performing so well or any references to what they have done in this regard? Has the Edge team already implemented this streaming and tiering compiler technique?

You tell Edge, "compile this", Edge replies "done!" when what it has done is just verifying it's valid WASM. When you then call a function, it's compiled.

So it is actually sad. It means you just downloaded a lot of stuff and only used a fraction of it.
Post reply on HN