
Asm.js AOT compilation and startup performance - bzbarsky
https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/
======
flohofwoe
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...](http://www.slideshare.net/andreweissflog3/gdce2013-cpp-ontheweb)

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

~~~
BrendanEich
> 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

~~~
lstamour
This kind of post and response, meaningless in the grand scheme of things, is
why I come to HN. You never know who will be next to say X sucks and then have
someone personally involved in creating X speak up unexpectedly. Makes you
want to apologize for saying X sucks in the first place, except you're not
because without it you wouldn't get the resulting conversation. ;-) It does
make me wonder, what things have I said about somebody's creation and then
have them come along and see it. Sometimes it's just hard to remember there
are real humans on the other side of this screen. ... And with that, I know
I'm up too late. Good night all, and thanks for the post, Brenden. I did want
to point out though... You forgot IE 10 and especially 11, plus the fun Opera
Mini must have had remotely executing JS for a brief time. But these wouldn't
significantly revise the numbers up too much. I'd add Adobe to the mix, but
ActionScript and AIR are maybe too far from a browser to count for much
evolution in JS terms.

~~~
BrendanEich
Right, see EDIT for Chakra, and yes, I forgot Opera. Lars Thomas Hansen, then
Chris Pine, on LinearB and Futhark; then Jens Lindstrom and (I heard) a small
team in Sweden on Carakan.

Also (ahem), I forgot Mozilla in the post-2003 era.

Still, no matter the addenda and the crazy $1M/person-year, nowhere near even
$1B.

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

~~~
exDM69
> 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.

~~~
anon1385
>No-one really likes the situation

That isn't true. Mozilla likes the situation. That is why they are pushing
Javascript so damn hard: as the only language for the web, as the only
language for apps, as the only language your phone can run, as the only
language your tablet can run and so on. If Mozilla disliked Javascript why
would they create an operating system that forces you to use Javascript? None
of the backwards compatibility concerns apply there.

It's just politics and a power grab. If all user facing software has to run
inside the Javascript sandbox then the people that control that sandbox are
given massive power. That is why Mozilla and Google want a web-app future. It
hands them the keys to everything. In a web app world if, for example,
Microsoft brings out a new input device (like kinect), nobody will actually be
able to develop software for it until the gatekeepers of the 'web standards'
decide to design an API for it. Since those gatekeepers are mostly Microsofts
competitors they would likely block it if they saw it as any kind of threat,
or at least till they had developed their own competing version.

Javascript/web standards based OSs will be a huge roadblock to innovation.

~~~
pgeorgi
"In a web app world if, for example, Microsoft brings out a new input device
(like kinect), nobody will actually be able to develop software for it until
the gatekeepers of the 'web standards' decide to design an API for it."

What stops Microsoft (in this example) to implement kinect support in IE as a
new API, propose it as a standard and evolve the interface like every other
web API - that is, in parallel to the standardization process?

If it's any good, Google and Mozilla will scramble to implement it to prevent
users to defect to IE.

~~~
anon1385
Firstly they would be pilloried for having a "proprietary" browser and being
"anti-standards".

More importantly, IE can't run on your Firefox OS phone or your ChromeOS
chromebook or your iOS tablet. 'Deflecting' to IE would mean buying entirely
new hardware (and in the case of phones, probably a new multi-year contract).
That isn't an accident. The best way to ensure your browser remains relevant
(i.e. you retain veto power over any new standards) is to create OSs that can
only run a single browser. You then have millions of users that are locked
into your browser to use as bargaining chips.

A world where all user-facing software has to target a single standard gives
vast power to the owners of that standard. Very few people seem to be
considering this problem. No matter how benevolent you think Google or Mozilla
are today, it is madness to place so much trust in them. Their interests do
not align with yours, and there are very few checks or balances to the system:
end users or independent developers have basically zero say in the web
standards process.

------
kibwen
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.

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

