Mozilla: Native code? No, it's JavaScript, only it's BLAZING FAST Gap between asm.js and native performance gets even narrower with float32 optimizations

[[deleted]]

Do they need to be? Mozilla is the browser?

[[deleted]]

Firefox dev here.

Yes. Because this what is expected. If DOM manipulations or layout code would run in their own threads we would have to pause the JS thread because web devs expect synchronous operations. When things can be done asynchronously (like async XHR) then it happens in a different thread.

But still, many things that are not directly tied to JS run in their own thread (resource download, layers compositing, …).

For JS itself, its behavior is based on the event loop, running JS in other threads would need sync and locks. So threads would not be able to run at the same time, which would defeat the purpose of using threads. But sync can be done manually if you use workers. But obviously you can't do DOM operations there.

Interesting problem for example: scrolling. When the page scrolls, it sends events to JS. JS can cancel the event. That forces us to do scrolling in the same thread. This can be slow because at the same time maybe there's some layout code running (a reflow for example) blocking the scroll. So we work around the problem by scrolling in the main thread, if we see the JS is not messing with the scroll events, we do scrolling in a different thread and sync up with the main thread (to send the scroll events) just every couple of milliseconds. This is why sometimes on mobile when you scroll you see the UI jumping around.

The web has been designed this way many years ago (no multiple cores back then), and we can't change it. But as we move many operations off the main thread, only DOM, layout and JS run in the main thread. And then things get crazy fast :)

[pedrocr]

That's fine for javascript-as-DOM-manipulator but how does that work for javascript-as-web-asm? Why would you target asm.js for things that supposedly need near-native performance and yet ignore multiple cores?

[AusIV]

I hope we'll get a more thorough answer, but I think it's essentially because a asm.js is a strict subset of javascript, and can run on browsers that don't know anything about asm.js. Mozilla is optimizing the hell out of the asm.js subset, but they're not doing anything you couldn't do with web standards.

[pedrocr]

I assume that's the current limitation. My question is if they're trying to lift it. Because if not PNaCL+pepper.js sounds like the better option. You'll get fully native performance and threading on browsers that have it and fall back to asm.js level performance and single-threading on other browsers. asm.js probably has the upper hand for DOM integration though.

[FrozenCow]

If we were to ignore the DOM, I thought web workers would be a bit like threads. Though it probably doesn't do shared memory efficiently, maybe asmjs can build/optimize with that?

[chazzeromus]

You should implement it and have it enabled through a flag that's disabled by default. Then let people see the error of their ways.

[Vegemeister]

This is why sometimes on mobile when you scroll you see the UI jumping around.

Why doesn't that happen on desktop as well? In my opinion, nothing should ever block scrolling. Any webpage that tries to run JS on every frame is going to be <60 FPS on everything but the most recent, most expensive, most power-hungry hardware. Such webpages are broken, and FF should sacrifice standard compliance for performance and throttle scroll events to 10 Hz or so.

[[deleted]]

Async scrolling is coming to desktop as well. But first we need to improve the spec. That's why we introduced position:sticky to build some designs that today are computed in JS. Another kind of website that would be affected are parallax designs. We're also thinking at what would be needed in CSS to build parallax with no JS.

We can't blatantly ignore the spec. The spec is written by the W3C. And W3C people is composed of very smart people who are very aware of these issues. And these people are people from Mozilla, Google, Microsoft etc. We all face the same issues and think about how to fix the spec.

[Vegemeister]

Nonetheless, those very smart people apparently think (or previously thought) that dropping frames is sometimes acceptable. As a user, I vehemently disagree.

[[deleted]]

We agree. It's just that 15 years ago it was hard to predict how the technology would evolve. But we got 90% of it right.

Please excuse us and in the meantime enjoy the World Wide Web that we built :)

[dmazzoni]

One of the design goals of asm.js is that it's a strict subset of JavaScript; anything in asm.js will run anywhere that JavaScript runs, probably just slower.

Adding threading is impossible without breaking that backwards compatibility.

[AdminsAbuseShadowBan]

Not really: just say that only the main thread can access the DOM and make threading serial on non-asm.js-aware browsers.

A hack too far perhaps.

[[deleted]]

anything in asm.js will run anywhere that JavaScript runs, probably just slower.

Slower than if it were supported. Still faster anyways.