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

131–140 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#131

Post by rickycook »

kowdermeister wrote: post #97
flavio81 wrote: post #51

Earlier quoted context omitted.

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

No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s. Last time I checked C/C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die. That's the reason we have so many Electron based apps, because it makes UI building really simple.

drawing the parallel between electron and gui toolkits probably isn’t right. i think there are lots of things at play here. just for starters:

- abstracts lots of file handling

- js is much easier than most languages to pick up and learn

- js has a large dev base because of the web

- people are well versed in coding for the web, and adding a “native” layer on top of that is actually quite easy

- cross platform c/c++ in general is not so simple even without the GUI

Re: Firefox’s new streaming and tiering compiler

#132

Post by yjftsjthsd-h »

etep wrote: post #120
derefr wrote: post #48

Earlier quoted context omitted.

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 i…

I don't think that's true; isn't the relationship between clock speed and power non-linear?

Re: Firefox’s new streaming and tiering compiler

#133

Post by solidr53 »

noir_lord wrote: post #111
lclarkmichalek wrote: post #15

Earlier quoted context omitted.

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.

Thanks to pressure from HHVM I assume. Nothing was happening in the PHP language for freaking three years.

To be fair the benchmarks usually take a wordpress or drupal installation and do a requests per second measurement, which IMO is a real world benchmark.

No hate, I just don't get why hhvm doesn't get any love for what they did. Maybe because from HPHPc to HHVM they seriously gave the PHPc a competition and people kind of got mad.

https://kinsta.com/blog/the-definitive-php-7-final-version-h...

Re: Firefox’s new streaming and tiering compiler

#134

Post by kybernetikos »

emn13 wrote: post #123
rcthompson wrote: post #110

Earlier quoted context omitted.

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 need…

Like TCCBoot? https://bellard.org/tcc/tccboot.html

Re: Firefox’s new streaming and tiering compiler

#136

Post by weaksauce »

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.

mine was even a bit more of a change.

Chrome: WebAssembly.instantiate took 13692.8 ms (0.9 MB/s)

Firefox: WebAssembly.instantiate took 330.8 ms (37.4 MB/s)

Re: Firefox’s new streaming and tiering compiler

#137

Post by ethbro »

yjftsjthsd-h wrote: post #132
etep wrote: post #120

Earlier quoted context omitted.

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 i…

I don't think that's true; isn't the relationship between clock speed and power non-linear?

That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips.

I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller).

* For serious values of "energy"

+ Where the same work is not always true for a given task, if one optimizes an algorithm

Re: Firefox’s new streaming and tiering compiler

#138

Post by markdog12 »

StreamBright wrote: post #126

What are the security implications of wasm?

Good writeup here: http://webassembly.org/docs/security/

It runs in existing browser VMs, which have been pretty battle tested.

Another interesting note is that threads are now on hold for WebAssembly due to Spectre, that is, SharedBufferArray has been disabled. Hopefully it can be enabled in the future.

Re: Firefox’s new streaming and tiering compiler

#140

Post by krapp »

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!

I realize this is likely to be the most likely way native WASM apps are implemented because it's the most obvious to web developers, but I also think it's the wrong approach.

Webassembly.org's own docs mention that it's intended to be agnostic about its runtime environment[0]. Electron is for packaging HTML, CSS and JS into a "native" application, but WASM doesn't actually need that if it's running outside the web.

Why not a native runtime on top of a cross-platform library like SDL? Just because it's "Web Assembly" doesn't mean it has to be limited to webdev paradigms.

[0]http://webassembly.org/docs/non-web/

Post reply on HN