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

Re: Firefox’s new streaming and tiering compiler

#111

Post by noir_lord » Wed, Jan 17, 2018, 8:07 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

Which ironically isn't really any faster than PHP7 in the real world outside of benchmarks.

7 was a phenomenal release, I saw 50% reductions in processing time across the board and on old array heavy systems 5-10x memory reduction.

Re: Firefox’s new streaming and tiering compiler

#112

Post by bzbarsky » Wed, Jan 17, 2018, 8:14 PM UTC

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…

SpiderMonkey has an interpreter too, in addition to the two JIT tiers.

Re: Firefox’s new streaming and tiering compiler

#113

Post by bobsc123 » Wed, Jan 17, 2018, 8:24 PM UTC

This cracks me up. Modern web browsers really started to evolve in the 90's when security problems really ramped up. You used to just download excecutables and run them on your computer because the functionality wasn't there otherwise. Flash and Java applets were the initial answer to that before Javascript and HTML evolved. We've come almost full circle to browsers basically being little VM's that can do anything again, the main reason they were developed in the first place. Most people's entire computer experience is now in the browser and here come executables again which will require another internal layer to mitigate problems.

Re: Firefox’s new streaming and tiering compiler

#114

Post by NanoWar » Wed, Jan 17, 2018, 8:32 PM UTC

bobsc123 wrote: post #113

This cracks me up. Modern web browsers really started to evolve in the 90's when security problems really ramped up. You used to just download excecutables and run them on your computer because the functionality wasn't there otherwise. Flash and Java applets were the initial answer to that before Javascript and HTML evolved. We've come almost full circle to browsers basically being little VM's that can do anything ag…

Actually, browsers are designed from the ground up to handle insecure code! That's pretty awesome, but comes at a cost: The mentioned additional layer, battery, speed? And it's platform independent!

Re: Firefox’s new streaming and tiering compiler

#115

Post by viraptor » Wed, Jan 17, 2018, 8:35 PM UTC

wlesieutre wrote: post #66

seren wrote: post #30

Earlier quoted context omitted.

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!

Not wasm yet, but you can definitely stick it into electron: https://bellard.org/jslinux/

Re: Firefox’s new streaming and tiering compiler

#116

Post by kbumsik » Wed, Jan 17, 2018, 8:35 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)

My old i5 Thinkpad L450:

Firefox 57: 5053.8 ms (2.4 MB/s)

Firefox Nightly 59: 454.6 ms (27.2 MB/s)

Chrome 63: 9034.9 ms (1.4 MB/s)

Wow, it's over x10 faster...

Re: Firefox’s new streaming and tiering compiler

#117

Post by jokoon » Wed, Jan 17, 2018, 8:43 PM UTC

That's cool, but until I see it coming to smartphones, that won't really be useful, except for gaming.

In theory this could really be the universal vm for the web everyone needed, but it's still lacking real sockets and dom support.

Re: Firefox’s new streaming and tiering compiler

#118

Post by ajkjk » Wed, Jan 17, 2018, 8:59 PM UTC

bobsc123 wrote: post #113

This cracks me up. Modern web browsers really started to evolve in the 90's when security problems really ramped up. You used to just download excecutables and run them on your computer because the functionality wasn't there otherwise. Flash and Java applets were the initial answer to that before Javascript and HTML evolved. We've come almost full circle to browsers basically being little VM's that can do anything ag…

The end state ends up looking a lot like (the user-facing side of) an operating system, except that:

* the filesystem is cloud storage (Drive/Dropbox/what have you -- the Unhosted (https://unhosted.org/) architecture)

* the apps are insecure but open-source by requirement (interpreted jS)

* ... running in a controlled sandbox (the browser)

* ... using a standard UI language (HTML/CSS)

* with functionality modifiable/overridable by user preference (extensions)

It's pretty much the ecosystem you would want if you were building this from scratch! Except you'd want Html/CSS/JS to be much more intelligently designed from the start (I'm waiting so eagerly for the day that browsers natively run more scripting languages than just JS...)

It never could be done in the 90s because everything ran too slowly, but it's feasible now.

Re: Firefox’s new streaming and tiering compiler

#119

Post by logn » Wed, Jan 17, 2018, 9:12 PM UTC

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…

@sjrd is talking about limitations for JS not other languages.

C, C++, Rust and others already have their own DOM/JS support.

WASM is exciting for statically typed languages especially. JS is not the target. It might eventually benefit from faster parsing but that's not the motive now.

Re: Firefox’s new streaming and tiering compiler

#120

Post by etep » Wed, Jan 17, 2018, 9:21 PM UTC

derefr wrote: post #48

callahad wrote: post #25

Earlier quoted context omitted.

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

An interesting benchmark would be the total energy usage of the CPU while loading a page in each browser. The compiler managing to idle waiting for network packets should theoretically allow some of the CPU cores to enter sleep states. (Not all, since others are still busy rendering the page, and at least one is busy doing whatever non-DMA kernel bits are involved with receiving the network packets.)

It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the idled core, albeit waste very little, accomplishing extra, but non-productive, work). Cannot let some other CPU parameter changes as a result of cores being idled (e.g. frequency gets boosted on non-idle cores as a result of dynamic frequency scaling with idle cores) to run this experiment. Thinking about CPU energy use is interesting :)