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

181–190 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#181

Post by didibus »

rcthompson wrote: post #41
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…

Is it actually a JIT? It's just compiling everything unconditionally. I guess the fact that the second tier replaces previously compiled functions with more optimized versions makes it a JIT? Or does the definition of JIT require recompiling in response to information about which code would benefit most?

To me it's a JIT if the compiler is needed to run the code.

If it means compile on start, it still requires the compiler to be used at load time.

Non JIT would mean you can distribute the code without the compiler. If you can't do that, its JITTED or interpreted, if instead of requiring a compiler to be present you require an interpreter.

Re: Firefox’s new streaming and tiering compiler

#182

Post by vitorgrs »

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 tried Chrome Canary, Firefox Nightly and Edge. Edge was the fastest here! But I believe they are using streaming compilation already.

Re: Firefox’s new streaming and tiering compiler

#183

Post by adrianN »

krapp wrote: post #152
rmrfrmrf wrote: post #147

Earlier quoted context omitted.

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

Users could for example install plugins into their browser.

Re: Firefox’s new streaming and tiering compiler

#184

Post by pjmlp »

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

Slow and steady. :)

http://www.teavm.org/

https://github.com/JasonHuang3D/AJC-Flash-WebAssembly-Exampl...

http://www.mono-project.com/news/2018/01/16/mono-static-weba...

Re: Firefox’s new streaming and tiering compiler

#185

Post by pjmlp »

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.

There isn't anything about Electron that I feel it is simple over Delphi, WinForms, JavaFX, Android, Cocoa, Qt, XAML, other than being easier for those that grew with HTML/CSS.

Re: Firefox’s new streaming and tiering compiler

#186

Post by pjmlp »

eyko wrote: post #145
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.

You seem to ignore that even in desktop and mobile, HTML(ish)+CSS(ish)+JS is taking over.

On mobile surely not.

Re: Firefox’s new streaming and tiering compiler

#187

Post by pjmlp »

ajkjk wrote: post #118
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 modifiabl…

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

It used to be called Lisp Machines, Smalltalk, Oberon Juice, Java Jini, Inferno.

Re: Firefox’s new streaming and tiering compiler

#188

Post by pjmlp »

pcwalton wrote: post #173
jnordwick wrote: post #168

Earlier quoted context omitted.

If that is why out failed, then wouldn't wasm fail for the same reason? It looks like LiveConnect was a much bigger thing that MS pushed. I'm not really understanding how this means anything. Why not just compile js et al to java bytecode? Or is wasm just another NIH protect in a long list of them in the JavaScript world? That is what it is looking like. Sure hotspot itself couldn't be used straight up, but the chang…

> If that is why out failed, then wouldn't wasm fail for the same reason? Web Assembly targets C and C++ as source languages, unlike the JVM. > Why not just compile js et al to java bytecode? Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow. > Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm. The Web…

> Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow.

Nashorn seems to be pretty close to node.js.

Re: Firefox’s new streaming and tiering compiler

#189

Post by pcwalton »

swsieber wrote: post #178
pcwalton wrote: post #160

Earlier quoted context omitted.

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

But if you're making your own UI kit, couldn't you just eschew CSS and the like? I was under the impression that part of the reason browser rendering is such a gnarly process is because of the reflow issues that CSS and HTML layout quirks/changes can cause. I would assume that you can implement a couple of layouts that prevent those sort of pitfalls and thus speed up rendering... Please correct me (you know a lot, an…

Sure, you could get rid of CSS, but in favor of what? You probably need something just like flexbox, and it's not easy to beat an optimized implementation of CSS flexbox in terms of layout performance (especially if parallelized). You could eliminate the restyling step by not having cascading and selector matching, but that hurts productivity and maintainability, which is why you see frameworks like GTK+ moving toward CSS-like styling. There's no free lunch here...

Re: Firefox’s new streaming and tiering compiler

#190

Post by AlphaSite »

bad_user wrote: post #91
pjmlp wrote: post #32

Earlier quoted context omitted.

.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, f…

On .NET Core's focus, that's not actually true: http://mattwarren.org/2017/12/15/How-does-.NET-JIT-a-method-... Android optimizes for battery life, but it's also worth noting that Dalvik was a really rudimentary JIT, having no benefits from JIT compilation, only drawbacks, the ART with AOT being a good upgrade. But tiered compilation is in a different league, being about speculating what's going to happen depending o…

I think tiered and speculative optimisation are independent concepts.

Tiered is specifically that you have a fast compiler and a slow compiler (or further tiers). Speculative is as you describe.

Post reply on HN