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

201–210 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#201

Post by pjmlp »

ghettoimp wrote: post #198
pjmlp wrote: post #185

Earlier quoted context omitted.

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.

Caveat: It's been a long time since I've used GUI toolkits like Gtk+ and QT, so this may be an out-of-date perspective. What I think of GUI toolkits, I think of lots of imperative code to build out an interface, e.g., "Create a window. Add a vertical box layout. Create button1. Change button1.font to xxx. Change button1.style to bold. Set the minimum height of button1 to 20px. Add button1 to the box. Create button2.…

Gtk+ is quite basic compared to RAD UI tooling, even today I wouldn't pick Glade over VB 6 or Delphi.

Qt always had a nice UI designer, with layout managers for responsive UIs, no need for imperative code to build out an interface.

Since version 5 they have QML, a JavaScript like declarative language, quite similar to J3 the first version of JavaFX.

Usually imperative UI code tends to be a thing only among developers that dislike RAD tooling, or game devs using immediate mode UIs.

Re: Firefox’s new streaming and tiering compiler

#202

Post by xg15 »

white-flame wrote: post #35
stevemk14ebr wrote: post #12

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…

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

If C++-to-WASM via clang catches on, I think this is exactly what will happen.

Re: Firefox’s new streaming and tiering compiler

#203

Post by xg15 »

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.

So in the end we really do end up in the alternate future where every website is just a single giant SWF file - except instead of Flash, it's WASM. Hooray! /s

Re: Firefox’s new streaming and tiering compiler

#204

Post by Filligree »

etep wrote: post #171
naikrovek wrote: post #167

Earlier quoted context omitted.

Can you explain the voltage squared thing? To me, power = voltage * current.

For chips, power scales with voltage squared. Is also true that P=IV (since both are true, these observations cannot be in contradiction). Apparently, for chips, the current must be proportional to voltage also. Glossing over some details, turning on (off) a transistor is the same as charging (discharging) a capacitor. The energy stored on a capacitor is 1/2 C V^2. If you turn on and off the transistor periodically (…

Running a processor at higher frequency also requires increasing voltage, which increases effective capacitance by that same formula.

That's not the primary cause of the power = frequency^2 rule, but actually adds a factor on top of that.

Re: Firefox’s new streaming and tiering compiler

#205

Post by xg15 »

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.

I'm not so sure. You don't need to reinvent everything that the DOM does as the DOM is is burdened down with all kinds of backwards compatibility concerns and conflicting design philosophies.

E.g., I don't think any sane design of a UI toolkit would include the ability to read and modify the string representation of the UI code at runtime - yet it's a critical feature for the DOM.

Likewise, you wouldn't necessarily need the ability to access and mutate arbitrary nodes of the document tree at any time. (including mutations that might change which CSS selectors apply to a node) E.g., you could only expose higher-level widgets instead or only expose variables that feed into a template. That would allow optimisations which aren't possible with CSS and DOM.

Finally, a WASM toolkit would be shipped with a particular website anyway, so it wouldn't need to be general-purpose.

On the other hand, there is a great incentive for website operators to make their site into a single unparseable blob: Ad-blockers. If every site had it's own internal data representation and internal rendering engine, that would make it almost impossible for ad-blockers to modify certain parts of the site while leaving others intact.

Re: Firefox’s new streaming and tiering compiler

#206

Post by steveklabnik »

pas wrote: post #200
logn wrote: post #119

Earlier quoted context omitted.

@sjrd is talking about limitations for JS not other languages. C, C++, Rust and others already have their own DOM/JS support. WASM is exciting for statically typed languages especially. JS is not the target. It might eventually benefit from faster parsing but that's not the motive now.

> C, C++, Rust and others already have their own DOM/JS support. What does that mean? Could you expand on that? Can Rust code compiled to wasm manipulate the DOM?

Via calling through JavaScript, yes. Wasm itself can't directly manipulate the DOM.

I'm not sure what your parent means.

Re: Firefox’s new streaming and tiering compiler

#207

Post by flobbers »

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.

Safari 11.0.2: 4.7mb/s Chrome: 1.2mb/s

This is on MacOS 10.13.2. I'd love to run Firefox but the battery savings and reduced heat from using Safari makes it too hard to pass up in this regard.

Re: Firefox’s new streaming and tiering compiler

#208

Post by yoklov »

breatheoften wrote: post #100

Does wasm do runtime code specialization? I wonder if there will end up being a way to do to timing attacks against the optimizing wasm compiler/linker step ... Is it possible to setup code such that the optimization time depends on the runtime inferred type of an 'x' that you aren't supposed to have access to ...?

The term you’re looking for is speculation, not specialization, but no, I don’t think it does either. C++ and other languages targeting WASM often do type specialization, but it’s entirely done before the browser sees WASM, and has nothing to do with what you’re describing. (Which would be speculative compilation).

I’d imagine that nobody does speculative compilation since the benefit is too low given how fast the network is. Also, yes, there would be security concerns.

Re: Firefox’s new streaming and tiering compiler

#209

Post by ygra »

hthh wrote: post #165
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…

What is "Nitro"?

Safari's JS engine, as far as I know.

Re: Firefox’s new streaming and tiering compiler

#210

Post by [deleted] »

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)

[deleted]
Post reply on HN