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

151–160 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#151

Post by QAkICoU7IDNkpFu »

kbumsik wrote: post #29
gigatexal wrote: post #7

Earlier quoted context omitted.

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.

>You can import C (and many others) libraries

This means compiling the lib to wasm, right? At first I was thinking of running JS clientside that imports some C lib somehow, which confused me.

Re: Firefox’s new streaming and tiering compiler

#152

Post by krapp »

rmrfrmrf wrote: post #147
white-flame wrote: post #35

Earlier quoted context omitted.

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…

> 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? Just wait until the JVM and Flash Runtime are ported to wasm. Downloaded and compiled on every page load :).

>Just wait until the JVM and Flash Runtime are ported to wasm. Downloaded and compiled on every page load :).

Why that, instead of caching common components like any other web asset, or even having the browser act as a dependency manager?

There are bound to better solutions than "download and compile on every page load."

Re: Firefox’s new streaming and tiering compiler

#154

Post by kabes »

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.

You can already replace dom with a canvas renderer. Flipchart does it with a react canvas renderer, but yet it doesn't take off, so why would wasm change that?

Re: Firefox’s new streaming and tiering compiler

#155

Post by hathawsh »

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…

I'm often reminded of the XKCD quip that web pages are in fact the easily installable executables that so much of the marketplace was looking for over the past few decades.

https://xkcd.com/1367/

Re: Firefox’s new streaming and tiering compiler

#156

Post by computerphage »

ehsankia wrote: post #81
luke_wagner wrote: post #76

Earlier quoted context omitted.

To wit, as described in their blog post: https://blogs.windows.com/msedgedev/2017/04/20/improved- Edge validates and compiles wasm code lazily. Thus, this simplistic benchmark isn't really measuring compile time on Edge. In contrast, Firefox, Chrome and Safari are doing some amount of AOT compilation before WebAssembly.instantiate() resolves.

Here's a stupid question, but is the result of the Firefox and Chrome "instantiate" the exact same? Is the compilation doing the same job, or one could be performing more optimizations? Aka faster compilation but slower execution.

They're doing slightly different things, but not to nearly the extent of Edge which is doing something very different.

Re: Firefox’s new streaming and tiering compiler

#157

Post by computerphage »

MrMid wrote: post #60
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) !!!

Wow. Firefox 59: 474 ms Edge 41: 164 ms The difference is smaller with newer FF, but that is amazing from Edge!

Edge is doing something very different, see the sibling comments for details.

Re: Firefox’s new streaming and tiering compiler

#158

Post by gpm »

pcwalton wrote: post #128
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.

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.

Are there any resources that describe the sort of UI rendering engine you think you would need to beat browsers?

Re: Firefox’s new streaming and tiering compiler

#159

Post by schance »

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)

Chrome Dev: WebAssembly.instantiate took 2254 ms (5.5 MB/s)

Firefox Nightly: WebAssembly.instantiate took 158.2 ms (78.3 MB/s)

Edge 41.16299.15.0: WebAssembly.instantiate took 99.2 ms (124.8 MB/s)

I did not expect Edge to be even faster.

Re: Firefox’s new streaming and tiering compiler

#160

Post by pcwalton »

gpm wrote: post #158
pcwalton wrote: post #128

Earlier quoted context omitted.

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.

Are there any resources that describe the sort of UI rendering engine you think you would need to beat browsers?

I don't think it's really possible to do much better than the next-gen browser architecture (Servo, fully-fleshed-out Quantum) if you support the entire feature set of browsers (once typed CSSOM is a thing, anyway). You can certainly do better in constrained environments, though. For example, Leo Meyerovich is doing really neat things with data viz, where all the elements to be laid out have the same shape and you can take advantage of that to do things like GPU layout.
Post reply on HN