Live data from Hacker News

Firefox’s new streaming and tiering compiler

hacks.mozilla.org

171–180 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#171
post #137

Earlier quoted context omitted.

That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "en…

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 (say with frequency f) you use 1/2 C V^2 energy f times per second (energy per unit time is power). Normally the capacitance is ignored when discussing how power changes because for a given design the capacitance is a fixed quantity.

Re: Firefox’s new streaming and tiering compiler

#172
post #82

Total Aside. As a compiler and runtimes guy, I'm super excited for streaming compilation. I think stuff like this and ethereum for distributed computation is really cool stuff! :D

Streaming compilation is the way it was always historically done. One reason is that computers used to not have enough RAM to store whole non-trivial programs in it in AST or another intermediate form. Second reason is that this approach matches how the underlying theory of languages and automatons works. One can view modern AST producing compiler frontend as compiler that compiles it's input into program that builds…

Yes, which is likely why in older languages like C you must declare symbols before you use them etc.

Re: Firefox’s new streaming and tiering compiler

#173

Earlier quoted context omitted.

This was tried (search for "LiveConnect"). It failed for many reasons, but the one that's most relevant to today is probably that most interesting client-side stuff (that isn't already written in JS) is written in C and C++, not a JVM language.

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 Assembly VM shares as much code as possible with the engine's JS VM. This is obviously better than using HotSpot, as the relevant code is already shipping in browsers.

Nobody is going around rewriting code for no reason.

Re: Firefox’s new streaming and tiering compiler

#174
post #120

Earlier quoted context omitted.

It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the i…

I don't think that's true; isn't the relationship between clock speed and power non-linear?

The real killer with energy usage in browsers is idle wake ups per second. If you've got a lot of tabs open and they're all running timers, waking up, hitting the network, etc. then they're keeping the CPU from going into low power state and thus wasting a lot of energy.

Even though I'd prefer to use Firefox I tend to stick with Safari due to the battery life advantage which really shows when you open a lot of tabs.

Re: Firefox’s new streaming and tiering compiler

#175
post #117

That's cool, but until I see it coming to smartphones, that won't really be useful, except for gaming. In theory this could really be the universal vm for the web everyone needed, but it's still lacking real sockets and dom support.

It's available on android now...

Re: Firefox’s new streaming and tiering compiler

#176
post #169

Earlier quoted context omitted.

> Is it actually a JIT? It's just compiling everything unconditionally. Still counts as JIT in my book, but you're right that it's a bit subtle. Unix-style configure/build/install isn't considered JIT. Installing a .Net application is pretty similar, but we don't consider it JIT. In the usual .Net model, what's distributed is IR rather than source-code. Compilation to native code happens at install time. The build-an…

It might be fun to make a source-based distribution where every binary in /usr/bin started off as a link to a script that built and installed the requested executable (over the top of the link), before executing it.

Or how about a fuser filesystem on Linux to do the same? That sounds like an interesting idea. Just don't make the mistake of accidentally typing some obscenely large binary like firefox, chrome, or clang...

I think it would need to be integrated into the package management system pretty tightly (or have one of its own) to get all of the shared library dependencies.

Re: Firefox’s new streaming and tiering compiler

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

We’re nowhere near the point where that would be even vaguely feasible on one crucial point: accessibility.

If you’re talking about rendering everything on a canvas, well, there’s been the occasional discussion about making it a11y-friendly, exposing content in it to screen readers and so forth, but nothing has really happened with it.

Your WebAssembly GUI toolkit is going to be completely invisible to screen readers.

Re: Firefox’s new streaming and tiering compiler

#178
post #158

Earlier quoted context omitted.

Are there any resources that describe the sort of UI rendering engine you think you would need to beat browsers?

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, and I'm betting some of my assumptions are wrong).

Re: Firefox’s new streaming and tiering compiler

#179

does someone here, familiar with webassembly semantics, know if it’s theoretically possible to start streaming execution of code? I.e. as soon as the “main” (?) function is in, and block on every function call which is not yet compiled, recursively? Or could the last block of webassembly bytecode potentially change the semantics of the first? Sooner or later, that’s an avenue people will want to explore, I assume?

Yes, it's possible. No, the last block won't change the semantics of the first.

Re: Firefox’s new streaming and tiering compiler

#180
post #137

Earlier quoted context omitted.

That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "en…

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

Even for purely resistive loads, power is proportional to the square of the voltage:

  P = V * I
But,

  I = V / R
So,

  P = V * (V / R)
    = V^2 / R
Post reply on HN