11 ms·

Asm.js AOT compilation and startup performance

162 points by bzbarsky 13y ago

kibwen 13y 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 13y 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-ontheweb http://www.slideshare.net/andreweissflog3/gdce2013-cpp-onthe...
Ygg2 13y 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.
- Refefer 13y 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.
  - natural219 13y ago
    I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
  - azakai 13y 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.
    - Refefer 13y ago
      Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
      - azakai 13y ago
        > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
- jokoon 13y 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_ 13y ago
    "The real advantages of ASM.js is security" - isn't NaCl sand-boxed?
    - jokoon 13y ago
      I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.
- jlebar 13y 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...
  - Ygg2 13y 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 13y 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.
  - BrendanEich 13y ago
    From my throne of skulls (https://t.co/CJUs7E3x43 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.
natural219 13y 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.
- jokoon 13y 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.
  - CmonDev 13y 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.
  - exDM69 13y 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.
jokoon 13y 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.

162 points by bzbarsky 13y 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 13y 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-ontheweb http://www.slideshare.net/andreweissflog3/gdce2013-cpp-onthe...

Ygg2 13y 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.

Refefer 13y 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.
- natural219 13y ago
  I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
- azakai 13y 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.
  - Refefer 13y ago
    Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
    - azakai 13y ago
      > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
jokoon 13y 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_ 13y ago
  "The real advantages of ASM.js is security" - isn't NaCl sand-boxed?
  - jokoon 13y ago
    I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.
jlebar 13y 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...
- Ygg2 13y 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 13y 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.
- BrendanEich 13y ago
  From my throne of skulls (https://t.co/CJUs7E3x43 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.

natural219 13y 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.

jokoon 13y 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.
- CmonDev 13y 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.
- exDM69 13y 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.

jokoon 13y 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.