Asm.js AOT compilation and startup performance

https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/

by bzbarsky • 13 years ago

162 83 13 years ago

blog.mozilla.org

kibwen• 13 years ago

Regardless of how you feel about the political implications of asm.js, this is a fascinating technical article on the challenges of implementing a world-class Javascript interpreter.

flohofwoe• 13 years ago

Author of the mentioned Nebula3 demos here. I must say it was extremely impressive to watch how quickly the AOT compilation time for asm.js code in Firefox was improved within only a couple of weeks. I think when I first tried to compile the demos to asm.js in a very early Odinmonkey build, Firefox froze for 10..15 seconds on start. Today it takes about half a second and everything is done asynchronously (no freeze or stuttering). This is especially impressive when looking at the time PNaCl currently requires when spinning up the demo for the first time (after that first compilation pass the result is cached though, and the next start is basically instant). Here's a bit more info on demos (lines of code, compiled binary size of various platforms, etc...): http://www.slideshare.net/andreweissflog3/gdce2013-cpp-onthe...

Ygg25• 13 years ago

It's funny that time and time again MIT approach over Hacker approach fails. Worse is better so to say ;)

On a simply theoretical ground having LLVM in browser sounds like an amazing thing. It elegantly solves all the problems of using different languages in browser, having super optimization of native LLVM project, etc.

Then you look at Javascript. It was written in a week. It's a sloppy mess of Java, Self and Scheme merged into a single horrible entity. But It just works™. And now it works fast :D

Good job Mozilla.

Refefer2• 13 years ago

Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more accurate to say that Javascript has succeeded despite its limitations.

There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. That said, a well entrenched language supported (and, crucially, maintained) by multiple vendors with loads of developer intellectual investment should win this competition.

natural2193• 13 years ago

I think that's the thesis of the "worse is better" approach.

http://www.jwz.org/doc/worse-is-better.html

azakai2• 13 years ago

There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well.

Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises.

Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.

Ygg25• 13 years ago

That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists.

Some kid from Zambia develops JavScript 2.0 in two weeks.

Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?!

People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait....

A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS).

Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad. Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars.

...

Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2

...

Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid.

Compare this situation with many other examples of Worse is Better.

BrendanEich23• 13 years ago

Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades.

No, that's an exaggeration in time and dollars.

JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64.

On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48.

Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42.

Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100.

64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion".

You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code.

EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price.

/be

jokoon6• 13 years ago

I'd say that there is not any relevant business model that could bring developers to do impressive work and easily reach their audience.

That's how hackers can win in the end. Business models get the market stuck somewhere, but you can't prevent hackers to find a difficult, hard path to reach their goals.

ASM.js is an impressive tech yes, but as always, I'm curious if it can really attract more devs into releasing gaming software.

The real advantages of ASM.js is security and the non requirement to install something new like NaCL.

_random_• 13 years ago

"The real advantages of ASM.js is security" - isn't NaCl sand-boxed?

jlebar• 13 years ago

Not to pick nits -- it's not the thrust of your argument -- but web browsers have a complex relationship with worse is better today.

Yes, browsers started as a hack and it's reasonable to attribute a lot of their success to worse is better "survival characteristics". But having been in the trenches for a few years, I can say that these days, we operate primarily on the MIT approach. For example, WebSQL is worse-is-better; it was rejected in favor of IndexedDB, which is the "right way" (and was a ton more work). At least at Mozilla we were /obsessed/ with making the "right" api; a hack that we felt placed burden on users, like Unix's solution to the lusering problem, would be seriously looked down upon.

Indeed I'd argue that the fact that so much work happens in standards bodies may be browsers' biggest concession to the "right way".

There are, of course, plenty of modern counterexamples to this too. Like I say, it's a complex relationship...

Ygg25• 13 years ago

True. I'm not making it look like Worse is Better ALWAYS wins. But it is funny how often it does, contrary to common conceptions.

The 'fight' between (P)NaCl and asm.js is by no means over. It's hasn't even begun. I have no clue if NaCl is popular for games, I've saw some on Chrome Store, but they always felt weird.

I just like to remind myself that making something is often more important than making it right.

lmm• 13 years ago

I don't see this as good job Mozilla; I see this as Mozilla using their muscle to keep everyone stuck on Javascript. If Mozilla had been willing to adopt the elegant approach then it would have succeeded. This is a triumph of politics, not of hacking - or to be more charitable, of hacking around politically-imposed constraints rather than fixing them.

BrendanEich23• 13 years ago

From my throne of skulls (https://t.co/CJUs7E3x43), I'm flexing and posing.

Muscle, that's a laugh! Who is the big company with all the money in the world to throw at developers and publishers to use a plugin API supported only in their browser, and still the devs and pubs say no? We heard from another such developer just this week.

s/politically-imposed/physics-imposed/ -- fixed it for you.

natural2193• 13 years ago

I know very little about compilers, low-level optimization, or any of these topics beyond a rudimentary understanding of basic computer systems. It speaks volumes that Mozilla is able to explain some of these concepts in ways that I sort-of grasp, even if the specifics mostly go over my head.

Excellent, excellent article. I look forward to more improvements to asm.js and the future of Javascript. Maybe one day I will actually learn this shit.

jokoon6• 13 years ago

Maybe one day I will actually learn this shit.

I'd strongly discourage it. ASM.js is the most horrible hacky thing. It gets the job done, but there are no good things to learn about how it works. Low level and compiler backend optimization are the most hurtful programming problems. It's optimization for a tons of bad reasons. That's like send a car into space. There are no way it's a technology you can reuse later for other purposes.

I'm sure ASM.js must be quite cool to just use, but to understand how it works, I fear that it could get hairy very quickly.

That's why I have my doubts about it. If you run into a problem with ASM.js and there are not enough guidelines, you might run into 10 walls, solve it through, and still run into walls that noone else will have solved before you.

CmonDev2• 13 years ago

People are using C#, Java and C++ just fine without understanding MSIL, bytecode and assembly. Asm.js might be a hacky thing but it may be the only way to defeat the dominance of a certain hacky scripting language.

exDM692• 13 years ago

ASM.js is the most horrible hacky thing. It gets the job done, but there are no good things to learn about how it works.

There's no denying this, ASM.js is an awful hack but that is for a good reason.

You're just going to have to accept the fact that JavaScript will be the only language supported by all major web browsers for the near future. No-one really likes the situation but there's nothing that can really be done about it, at least in the short term.

So if you're doing software for the web browser, it must be compatible with JavaScript. That is a fact you can't escape. And as much as asm.js is a dirty hack, it retains JavaScript compatibility while being a more sensible intermediate representation for compilers.

You're not supposed to like (or dislike) asm.js, it's intended to be written and consumed by computer programs, not humans.

jokoon6• 13 years ago

It's funny that after all, native code is still what devs wants. Even on top of a super JS engine JIT I-don't-know-what.

There was a HTML browser, then a scripting language, and it seems it was the easiest, hackiest way to massively deploy native-fast software, and it's done through a browser.

Asm.js AOT compilation and startup performance

Related Stories