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

31–40 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#31

Post by callahad »

styfle wrote: post #28
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)

Where did you even find that repo? Was that mentioned in the article or is this your code?

Linked in the article under "give it a try" in the sixth paragraph.

The repo itself is at https://github.com/lukewagner/test-tanks-compile-time

Re: Firefox’s new streaming and tiering compiler

#32

Post by pjmlp »

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…

.NET focus always was native code, either AOT with NGEN or JIT on load.

The only variants of .NET with interpreter support were from 3rd party implementations, and the .NET Micro Framework, used in NETduino.

And now their focus seems to be to improve their AOT story.

Another interesting evolution was Android, with Dalvik and its basic JIT, ART with AOT on installation, to ART reboot with an interpreter in Assembly, followed by JIT and AOT code cache with PGO.

Re: Firefox’s new streaming and tiering compiler

#33

Post by kroltan »

icen wrote: post #8
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…

> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!" Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.

JS is a garbage-collected language. It would require reimplementing most of the runtime, or be stuck with code that does marshalling for everything and would possibly be slower than plain JS.

Re: Firefox’s new streaming and tiering compiler

#34

Post by jnordwick »

kllrnohj wrote: post #24
Twirrim wrote: post #10

Out of curiosity, using just released versions of browsers on this 2015 mac pro: Firefox 57: WebAssembly.instantiate took 2990.2ms (4.1mb/s) Chrome 63: WebAssembly.instantiate took 8736.9ms (1.4mb/s) Safari 11.0.2: WebAssembly.instantiate took 10341ms (1.2mb/s) If more speed is about to arrive, wow. I'm curious what optimisations are needed / valuable for wasm files to improve streaming performance. I'm assuming if,…

Function declarations are independent from function bodies. So think C/C++ headers/source file splits. You don't need to know what code is in bar if you know it takes 1 argument of type int and returns an int. That's all you needed to know how to call it successfully, so you can compile foo in your example perfectly fine. You just need to patch up the call location later when bar is resolved to actual address (this i…

Considering the major optimization in compiling is inlining, knowing the function body is very important to compilation, but I guess that can be pushed off until the next tier.

Re: Firefox’s new streaming and tiering compiler

#35

Post by white-flame »

stevemk14ebr wrote: post #12
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…

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, because it's all built on top of raw asm?

Webasm is not for JS-style code! You can't have "a little pre-compilation of JS to WebASM", that makes zero sense. We already have the incredibly complex JIT compilation of JS to x64/ARM/etc, which necessarily interacts with the garbage collector, type system, permissions & security, browser debugging/profiling tools, etc, all of which wasm does not have any notion.

Wasm is a raw C-ish sandbox environment for cross-compilation of static languages to expose their behavior to javascript, for straight-line CPU performance in number crunching as in games, software rendering, numerical analysis, compression/decompression, etc.

Re: Firefox’s new streaming and tiering compiler

#36

Post by pjmlp »

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…

I don't see lack of GC as limitation, just bring your alongside.

Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it.

Interaction with DOM can be achieved with a few imported functions.

Re: Firefox’s new streaming and tiering compiler

#37

Post by nabla9 »

Yoric wrote: post #11
zach43 wrote: post #2

Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine. As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

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…

And then modern microprocessors receive x86-64 instructions and decode them into underlying microcode.

Re: Firefox’s new streaming and tiering compiler

#38

Post by yzmtf2008 »

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…

Examples of applications that require a lot of number crunching: gaming, visualization, graphics processing.

The list goes on, but the idea is that certain hot spots in an application will be able to benefit from having a fast number crunching engine.

Re: Firefox’s new streaming and tiering compiler

#39

Post by jahewson »

sjrd wrote: post #22
Yoric wrote: post #17

Earlier quoted context omitted.

On the other hand, you could compile well-behaved subsets of JavaScript into wasm. Kind of what asm.js was doing. Whether that's useful in practice is an open question, but it's plausible.

asm.js was not a well-behaved subset of JavaScript. It was a well-behaved subset of assembly that happened to be encoded in JavaScript. There is virtually no human-written JS code that is amenable to compilation to wasm in a meaningful way. At the very least, you need a (mostly) sound type system to be able to compile to wasm with a positive expected ROI. The speed of wasm comes in a large part from the fact that it…

Exactly, plus in a dynamic environment a tracing JIT can outperform AOT compiled code. This is true for both the JVM and .NET CLR, both mature platforms.

Re: Firefox’s new streaming and tiering compiler

#40

Post by pjmlp »

Yoric wrote: post #11
zach43 wrote: post #2

Interesting article...I did not realize that the WASM needs to be compiled into machine code on the client system, I just assumed it would be directly interpreted by the JS engine. As a side note, it is interesting to see that multithreaded compilation of a single page provides significant performance benefits here...this is usually not done with C/C++ code compilation from what I understand about it

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…

It was always like that on the mainframe world.

Assembly was actually bytecode, with a micro-coded CPU doing the actual execution.

All Xerox computers were like that. The first boot step was to load the right kind of micro-code for the environment being started.

The AS/400 native environment (nowadays known as IBM i), is based on bytecode TIMI, which gets AOT compiled via a kernel level JIT.

Post reply on HN