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

21–30 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#21

Post by MaxBarraclough »

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 compiler. https://github.com/dotnet/coreclr/issues/4331

HotSpot uses three tiers these days (counting direct interpretation as a tier) - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/pe...

JavaScriptCore/Nitro seems to use four - https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

Edge's Chakra engine has two - https://blogs.msdn.microsoft.com/ie/2014/10/09/announcing-ke...

V8 seems to use two - https://v8project.blogspot.co.uk/2017/05/launching-ignition-...

Firefox's SpiderMonkey JS engine uses two - https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Sp...

Re: Firefox’s new streaming and tiering compiler

#22

Post by sjrd »

Yoric wrote: post #17
sjrd wrote: post #14

Earlier quoted context omitted.

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.

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

#23

Post by gkya »

I'm not familiar with Web Assembly, but the recent trend is that as the downloads become faster, web performance in a vanilla browser becomes slower, because websites just send more stuff to you. Pages grow toward infinity. Also, if, like @sjrd mentioned, this code can't manipulate DOM or can use only a restricted set of JS objects, the where will the gain be? Is this intended to be used for number crunching code in the browser runtime? Help bitcoin miner scripts? What's the purpose then?

Re: Firefox’s new streaming and tiering compiler

#24

Post by kllrnohj »

Twirrim wrote: post #10

Out of curiosity, using just released versions of browsers on this 2015 mac pro: Firefox 57: WebAssembly.instantiate took 2990.2ms (4.1mb/s) Chrome 63: WebAssembly.instantiate took 8736.9ms (1.4mb/s) Safari 11.0.2: WebAssembly.instantiate took 10341ms (1.2mb/s) If more speed is about to arrive, wow. I'm curious what optimisations are needed / valuable for wasm files to improve streaming performance. I'm assuming if,…

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 is the "link" step in a typical AOT compilation chain, or done by the loader if it's a dynamic dependency)

Re: Firefox’s new streaming and tiering compiler

#25

Post by callahad »

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 believe that's not even using the streaming compilation mentioned in the article

That's correct. Streaming compilation would finish earlier, but might actually benchmark more slowly because you'd be adding in the time that the compiler is idle and waiting for the network to catch up.

Preloading the .wasm file in the test lets us measure just the speed of the compiler, independent of the network.

Re: Firefox’s new streaming and tiering compiler

#26

Post by jahewson »

Yoric wrote: post #17
sjrd wrote: post #14

Earlier quoted context omitted.

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.

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

#27

Post by pcwalton »

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

> 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, that's because typically all cores are maxed out during a parallel build of large-scale C++ software, so there's no need to go any further.

With link-time optimization it's a different story…hence the work some compilers (like rustc for Rust) are doing to parallelize builds of single compilation units.

Re: Firefox’s new streaming and tiering compiler

#28

Post by styfle »

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)

Where did you even find that repo? Was that mentioned in the article or is this your code?

Re: Firefox’s new streaming and tiering compiler

#29

Post by kbumsik »

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?

You can import C (and many others) libraries without re-implementing it in JS for browsers. In my company's case, we compile C-written libopus almost directly to encode audio streams into Opus on browsers, not on servers. In this way we benefit much less data traffic and server CPU loads.

Re: Firefox’s new streaming and tiering compiler

#30

Post by seren »

gkya wrote: post #23

I'm not familiar with Web Assembly, but the recent trend is that as the downloads become faster, web performance in a vanilla browser becomes slower, because websites just send more stuff to you. Pages grow toward infinity. Also, if, like @sjrd mentioned, this code can't manipulate DOM or can use only a restricted set of JS objects, the where will the gain be? Is this intended to be used for number crunching code in…

Running a native app compiled to wasm into the browser ? So the opposite of running an Electron app?
Post reply on HN