Live data from Hacker News

Firefox’s new streaming and tiering compiler

hacks.mozilla.org

141–150 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#141

Earlier quoted context omitted.

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

>No hate, I just don't get why hhvm doesn't get any love for what they did.

I don't know - I expected to see a ton of Hack projects show up here but it's like no one cared about the language except as a wake-up call to PHP. Maybe the involvement of Facebook put people off.

Re: Firefox’s new streaming and tiering compiler

#142

Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power that was used to compile very same code on millions of computers every day?

Sigh... let's have this thread again. Needs to be effectively sandboxed. Modern JS as a compiler target is just as opaque. JIT compilation is a win on energy relative to the energy spent in a slow interpreter. JITing WASM will take less energy than JITing emscripten-js (nevermind the energy to send over the wire)

Re: Firefox’s new streaming and tiering compiler

#143

Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power that was used to compile very same code on millions of computers every day?

Downloading a bigger executable wouldn't necessarily be faster actually, it depends on the size difference and the client bandwidth.[1]

Additionnally, it wouldn't be portable (executable compiled for desktop wouldn't run on mobile).

[1] See this comment : https://news.ycombinator.com/item?id=16171133

Re: Firefox’s new streaming and tiering compiler

#144

Earlier quoted context omitted.

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

> Nothing was happening in the PHP language for freaking three years.

To be fair that's not because they where sleeping, but because they attempted to do something that proved too hard (unicode support) and they had to abandon it. That's why PHP skipped version 6.

Re: Firefox’s new streaming and tiering compiler

#145
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 seem to ignore that even in desktop and mobile, HTML(ish)+CSS(ish)+JS is taking over.

Re: Firefox’s new streaming and tiering compiler

#146

Earlier quoted context omitted.

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

[deleted]

Re: Firefox’s new streaming and tiering compiler

#147

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…

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

Re: Firefox’s new streaming and tiering compiler

#148

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)

In Firefox 58 beta I get: WebAssembly.instantiate took 200.9 ms (61.6 MB/s)

In Safari 11.0.2 I get: WebAssembly.instantiate took 2885.9 ms (4.3 MB/s)

In Vivaldi 1.13.1008.40 I get: WebAssembly.instantiate took 7719 ms (1.6 MB/s)

Re: Firefox’s new streaming and tiering compiler

#149
post #141

Earlier quoted context omitted.

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

>No hate, I just don't get why hhvm doesn't get any love for what they did. I don't know - I expected to see a ton of Hack projects show up here but it's like no one cared about the language except as a wake-up call to PHP. Maybe the involvement of Facebook put people off.

[deleted]

Re: Firefox’s new streaming and tiering compiler

#150
> But there’s no good reason to keep the compiler waiting. It’s technically possible to compile WebAssembly line by line. This means you should be able to start as soon as the first chunk comes in.

Maybe they can optimize further by speculating what the next line will be...

Post reply on HN