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

191–200 of 229 posts

Re: Firefox’s new streaming and tiering compiler

#191

Post by rplnt »

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

I have similar, just slightly higher numbers on 2017 Mac Pro. What's baffling to me is that they are something like 30% lower than they are on my over 6 year old low end desktop with i3.

Re: Firefox’s new streaming and tiering compiler

#192

Post by lloeki »

chongli wrote: post #174
yjftsjthsd-h wrote: post #132

Earlier quoted context omitted.

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.

Indeed the most dramatic improvement I saw in battery life was when macOS and Safari started cooperating around timer coalescing using App Nap.

Re: Firefox’s new streaming and tiering compiler

#193

Post by MaxBarraclough »

caf wrote: post #169
MaxBarraclough wrote: post #129

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.

Source-based distros essentially do that, they just cache the binaries.

Various research OSs are JIT-based, of course. It looks like JX (a Java operating system) caches its native code, so it's not 'pure JIT' https://github.com/mczero80/jx/blob/5fbeae79/libs/compiler_e...

It looks like Cosmos (a C# operating system) does the same https://en.wikipedia.org/wiki/IL2CPU

Re: Firefox’s new streaming and tiering compiler

#194

Post by tspiteri »

etep wrote: post #166
yjftsjthsd-h wrote: post #132

Earlier quoted context omitted.

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

I think it is linear for frequency and non-linear for voltage, i.e. P~f C V^2. But in many current CPUS, the feature that adjusts frequency also adjusts voltage. That's why I stipulated that, for my comments to be true, such shenanigans as dynamic frequency (and voltage) scaling must be "turned off." I think the OP was asking, what happens to CPU energy if you load the web page with and without the optimized compilat…

To increase the frequency, you also have to increase the voltage so that the transistors charge faster, otherwise they won't be able to switch in the shorter time.

Re: Firefox’s new streaming and tiering compiler

#196

Post by Dolores12 »

littlestymaar wrote: post #143
Dolores12 wrote: post #139

Guess what, downloading compiled executable code is even faster. Is that where we are heading to? Flash 2.0? Wouldn't it be great to save all the electric power that was used to compile very same code on millions of computers every day?

Downloading a bigger executable wouldn't necessarily be faster actually, it depends on the size difference and the client bandwidth.[1] Additionnally, it wouldn't be portable (executable compiled for desktop wouldn't run on mobile). [1] See this comment : https://news.ycombinator.com/item?id=16171133

What you are saying is that source code is less in size than compiled native code which is nonsense.

Re: Firefox’s new streaming and tiering compiler

#197

Post by Zekio »

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…

Wonder if there will ever be a version of typescript that compiles to wasm

Re: Firefox’s new streaming and tiering compiler

#198

Post by ghettoimp »

pjmlp wrote: post #185
kowdermeister wrote: post #97

Earlier quoted context omitted.

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.

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. Add button2 to the box. Tell the box to grow button2 when it is resized. Create button 3..."

The declarative style of HTML/CSS seems so much better. The grouping of elements becomes apparent just by looking at how they are nested, with no need to keep track of what gets added to what. And CSS gives you a really rich ability to select groups of elements, style them, try out new styles, reuse styles across pages, and so on.

CSS has definitely gotten really complicated. But then, I could never build anything in a GUI toolkit without constantly referencing the API docs to figure out how to do this or that, either...

Re: Firefox’s new streaming and tiering compiler

#199

Post by pas »

sudhirj wrote: post #63
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…

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

Re: Firefox’s new streaming and tiering compiler

#200

Post by pas »

logn wrote: post #119
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…

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

Post reply on HN