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

211–220 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#211

Post by protomikron »

pjmlp wrote: post #201
ghettoimp wrote: post #198

Earlier quoted context omitted.

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…

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

Actually I think that most game UIs (the menus, settings, inventories - not the actual game) are done quite well - maybe immediate mode GUIs have a place outside of gamedev?

Re: Firefox’s new streaming and tiering compiler

#212

Post by MaxBarraclough »

didibus wrote: post #181
rcthompson wrote: post #41

Earlier quoted context omitted.

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.

I like this definition.

Re: Firefox’s new streaming and tiering compiler

#213

Post by jnordwick »

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…

This whole reply doesn't pass the smell test.

> Web Assembly targets C and C++ as source languages, unlike the JVM.

So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true.

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

Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.

Once you add gc into wasm, it is almost guaranteed to be closer to java than c/c++.

Re: Firefox’s new streaming and tiering compiler

#214

Post by tmzt »

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.

Is there a good way to experiment with exposing native calls from Firefox/Quantum to WASM?

I'm looking into building an extension to build Quantum Display Lists from a WASM vdom.

Re: Firefox’s new streaming and tiering compiler

#215

Post by pcwalton »

jnordwick wrote: post #213
pcwalton wrote: post #173

Earlier quoted context omitted.

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

This whole reply doesn't pass the smell test. > Web Assembly targets C and C++ as source languages, unlike the JVM. So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true. > Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow. Given javas JavaScript implementation is pretty co…

> So wasm…are closer c/c++ than to java?

Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has.

> Considering all the UB in C, this cannot possibly be true.

Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be relatively free of undefined behavior.

> Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.

I would highly doubt it's performance competitive at the level that browsers are at now. It strikes me as likely impossible to get performance competitive on, say, SunSpider if you aren't highly tuned for it.

Re: Firefox’s new streaming and tiering compiler

#216

Post by pcwalton »

xg15 wrote: post #205
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.

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

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

Those can largely be avoided, and they typically don't cause global performance impacts.

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

That isn't a problem. innerHTML is lazily computed from the tree structure: if you don't use it, you don't pay for it.

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

The main benefit of this would be to eliminate restyling, but cascading is really useful from a design point of view. That's why we've seen native frameworks such as Qt and GTK+ move to style sheets. And if you reinvent restyling, it'll be a ton of work to do better—remember that Servo and Firefox Quantum have a parallel work-stealing implementation of it. I've never seen any native toolkit that even comes close to that amount of performance effort.

Re: Firefox’s new streaming and tiering compiler

#217

Post by logn »

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?

Rust -- https://github.com/koute/stdweb

C++ -- https://github.com/mbasso/asm-dom

I don't know exactly how these work but Emscripten allows interop both ways (embedding JS in native code and calling native code from JS) -- https://kripken.github.io/emscripten-site/docs/porting/conne...

Re: Firefox’s new streaming and tiering compiler

#218

Post by xg15 »

pcwalton wrote: post #216
xg15 wrote: post #205

Earlier quoted context omitted.

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

> 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. Those can largely be avoided, and they typically don't cause global performance impacts. > 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 - y…

> That isn't a problem. innerHTML is lazily computed from the tree structure: if you don't use it, you don't pay for it.

I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.)

And they can't drop it because a lot of sites rely on it - however, if you wrote a new, limited-purpose renderer on top of WASM, you could decide to drop it and simplify the implementation without losing much utility.

> And if you reinvent restyling, it'll be a ton of work to do better

But that's kind of my point - if you can control which parts of the tree are exposed and which mutations are valid, you might not need to implement restyling at all. (Or in reduced scope)

I'm not talking about cascading in general, but about how you can make arbitrary changes to the DOM after initial load, which the restyler has to fully support.

Re: Firefox’s new streaming and tiering compiler

#219

Post by pcwalton »

xg15 wrote: post #218
pcwalton wrote: post #216

Earlier quoted context omitted.

> 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. Those can largely be avoided, and they typically don't cause global performance impacts. > 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 - y…

> That isn't a problem. innerHTML is lazily computed from the tree structure: if you don't use it, you don't pay for it. I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.) And they can't drop it because a lot of sites rely on it…

> I'm not paying for it, the DOM implementation is - with increased complexity. (E.g., HTML parsing suddenly becomes a time-critical operation because some wiseguy decided to implement animations for his website using setTimeout and innerHTML.)

We're talking about performance here, not implementation complexity. Besides, it's not a win in terms of complexity if sites ship a limited subset of the Web stack to run on top of the full implementation of the Web stack that's already there.

> But that's kind of my point - if you can control which parts of the tree are exposed and which mutations are valid, you might not need to implement restyling at all. (Or in reduced scope)

Sure, you can improve performance by removing useful features. But I think it'll be a hard sell to front-end developers. Qt and GTK+ didn't add style sheets and restyling for no reason. They added those features because developers demanded them.

Re: Firefox’s new streaming and tiering compiler

#220

Post by linclark »

pas wrote: post #199
sudhirj wrote: post #63

Earlier quoted context omitted.

DOM manipulation is already on the cards, should be out soon. This is likely a separate sub-team of people just working on making it as fast as possible.

Could you give details on "soon"? All I was able to find is this issue: https://github.com/WebAssembly/design/issues/1079 with not activity for a long time

With the more recent host bindings proposal[1], direct DOM access was decoupled from GC. This is expected to move much more quickly.

[1] https://github.com/WebAssembly/host-bindings/blob/master/pro...

Post reply on HN