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

61–70 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#61

Post by depressedpanda »

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 ran the tests on my Nexus 5X running stock Android 8.1.

Chrome: WebAssembly.instantiate took 12935.5 ms (1 MB/s)

Firefox Nightly: WebAssembly.instantiate took 1223.1 ms (10.1 MB/s)

Yikes, one order of magnitude in difference.

Re: Firefox’s new streaming and tiering compiler

#63

Post by sudhirj »

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…

DOM manipulation is already on the cards, should be out soon. This is likely a separate sub-team of people just working on making it as fast as possible.

Re: Firefox’s new streaming and tiering compiler

#64

Post by alexeldeib »

depressedpanda wrote: post #61
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 ran the tests on my Nexus 5X running stock Android 8.1. Chrome: WebAssembly.instantiate took 12935.5 ms (1 MB/s) Firefox Nightly: WebAssembly.instantiate took 1223.1 ms (10.1 MB/s) Yikes, one order of magnitude in difference.

Similar for me, a touch over 10x

FF: WebAssembly.instantiate took 280.3 ms (44.2 MB/s)

Chrome: WebAssembly.instantiate took 3022.4 ms (4.1 MB/s)

Re: Firefox’s new streaming and tiering compiler

#65

Post by chrisseaton »

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?

Do you think for something to be a JIT it must only compile code immediately before it's used?

In that case the only real JIT I know of is basic-block-versioning. I think almost all JITs will compile branches or methods to some extent before they are actually needed.

Yours is probably not a reasonable definition therefore. I think a JIT is just a compiler that can compile as the program is running.

Re: Firefox’s new streaming and tiering compiler

#66

Post by wlesieutre »

seren wrote: post #30
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?

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!

Re: Firefox’s new streaming and tiering compiler

#67

Post by hyperpape »

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 took quite awhile until we realized that was the cause. A cache of 256 mb was more than enough for us running a 2 million LOC monolith under Tomcat, so the absolute memory use isn't that significant. (Reference we found while researching: http://engineering.indeedblog.com/blog/2016/09/job-search-we...).

Once you know this is an issue, it's easy to monitor, but it is one more thing that can go wrong in the JVM.

Re: Firefox’s new streaming and tiering compiler

#68

Post by avaer »

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'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.

Re: Firefox’s new streaming and tiering compiler

#69

Post by felipellrocha »

white-flame wrote: post #35
stevemk14ebr wrote: post #12

Earlier quoted context omitted.

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

As far as not making sense goes, sorry but your post doesn't make any to me, either. Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, b…

You don't really write wasm by hand. You use a higher level language that compiles to it. I wouldn't mind using go for the web, for example, if I wanted more performance, and it takes care of all the concerns you mentioned above for you...

Re: Firefox’s new streaming and tiering compiler

#70

Post by hateduser2 »

white-flame wrote: post #35
stevemk14ebr wrote: post #12

Earlier quoted context omitted.

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

As far as not making sense goes, sorry but your post doesn't make any to me, either. Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, b…

They’re adding all those things to wasm. I think you’re mistaken about the future.
Post reply on HN