
Asm.js in Firefox Nightly - aeosynth
https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/
======
hosay123
Actual numbers from the Groups link at the bottom:

    
    
        So I discovered from Alan today - asm.js was everything I hoped it would
        be. 
    
        One of the more intensive examples in OpenSCAD
        (https://raw.github.com/openscad/openscad/master/examples/example006.scad)
        gave me these metrics:
    
        Native: 402 seconds, 
        asm.js version: 605 seconds, 
        asm.js version in Chrome: 3724 seconds
    
    

And the exciting part? Backwards compatibility even with IE6, forwards
compatibility with optimizations that haven't been invented yet – and no 80s
era blob+VM architecture in sight. All without inventing any half baked new
language, file format, virtual machines or whatever else, and building on a
language spec that's already an ISO standard. Eat your heart out Native
Client!

~~~
pifflesnort
I'm not sure why you think asm.js _isn't_ a blob: in order to achieve those
performance levels that you see in Mozilla, you have to interpret JavaScript
as something that _is not_ JavaScript, which requires having a spec in hand,
dealing with potentially ambiguous encodings, and interpreting the asm.js as a
bytecode, rather than as standard JavaScript.

At that point, the only difference between "asm.js" and a "blob" is that
asm.js is unreadable ascii, which the blob is unreadable binary.

~~~
hosay123
But it's not, by your logic a compiler producing machine-generated K&R C in
the late 70s would also be a blob.

Only as anyone mining the web for esoteric code will attest, anything written
in standard C since probably the mid 80s and using only the ANSI C standard
library can still be fed to a compiler today and produce perfectly functioning
code, taking advantage of every advancement in compiler technology in the 30
years that have followed.

Those C source files do not, for example, make assumptions about Harvard/von
Neumann architecture, stack layout, calling conventions, the presence or
absense of SIMD instructions, and so on. C is called "high level assembler"
for a reason, just as "asm.js" is called "asm.js" for a reason.

Even if we had some standard binary format for describing software available
since the 80s, it would almost certainly lack sufficient descriptive power to
capture constructs that could be vectorized, or otherwise transformed using
more modern compilation techniques that simply didn't exist at the time.
Lowering to a binary form throws all that semantic information away. And the
more you add back the more the binary form starts to look like a pointless
transformation of the original source code.

Then there is the idea that such a format could ever have been designed in the
80s that would have lasted us to present day. Native Client proponents and
similar such "VM fundamentalists" are effectively claiming that we can invent
such a format, when it has never been done before in the history of computer
science.

(Pre-emptively rejecting boring VM counterexamples like Java for reasons that
can be extrapolated from what I just described. Every comment on this thread
brings it closer to HN's "controversiality" scoring penalty, and I'd very much
like for this link to stay on the front page all day)

~~~
rayiner
> Only as anyone mining the web for esoteric code will attest, anything
> written in standard C since probably the mid 80s and using only the ANSI C
> standard library can still be fed to a compiler today and produce perfectly
> functioning code, taking advantage of every advancement in compiler
> technology in the 30 years that have followed.

Have you ever actually tried this? It doesn't work.

~~~
tptacek
I have. When I started at Arbor Networks in the early 00's, we needed a fine-
grained timer library that was millisecond-granular and could efficiently
manage thousands of scheduled events. I stole mine from the MIT-licensed
Athena codebase, which dates back to the '80s.

~~~
rayiner
But was it generated code? I've had pretty bad luck with old scheme/lisp
implementations that compile to C.

------
jlongster
I am so excited about it. It's worth noting that I'm porting LLJS to compile
to asm.js already, and I have basic code already working with it:
<https://github.com/jlongster/LLJS>

I plan on polishing it up tonight and publishing/blogging about it tomorrow.

~~~
smrtinsert
Wow, your project looks amazing. My evenings plans just got cancelled.

~~~
jlongster
It's worth noting that LLJS itself came from a few smart guys from the Mozilla
Research team. I work for Mozilla but as a web developer and I'm just doing
the port.

The asm.js branch is highly unusable as is, but it should be somewhat stable
tomorrow!

------
kibwen
This post mentions IonMonkey, which is the newest enhancement to Firefox's
Javascript engine. According to <http://arewefastyet.com/> , it appears to be
doing pretty well so far (red is old Firefox, purple is current Firefox, black
is future Firefox, green is Chrome, lower is always better). Excited to see
what'll happen once OdinMonkey gets added to the mix.

~~~
mfunk
Small correction: purple is current Firefox, not red. Red is not shipped in
any build.

~~~
kibwen
Ah, I had no idea that IonMonkey had made its way to the stable release. Very
cool.

------
rayiner
Worse really is better. Asm.js fulfills the promise of formats like ANDF,
except by going through one of the shittiest intermediate languages you might
imagine.

~~~
MatthewPhillips
Already adopted is better than not already adopted.

~~~
rayiner
Hence my reference to: [http://www.stanford.edu/class/cs240/readings/worse-is-
better...](http://www.stanford.edu/class/cs240/readings/worse-is-better.html)

------
neeee
Quick test on the BananaBread benchmark: Without asm.js

    
    
      preload : 53.698 seconds
      startup : 11.904 seconds
      gameplay: 369.86 total seconds
      gameplay: 196.538 JS seconds

With asm.js

    
    
      preload : 55.513 seconds
      startup : 7.093 seconds
      gameplay: 75.848 total seconds
      gameplay: 54.318 JS seconds

------
cromwellian
Hoisting my comment up: Executable != useful. Saying asm.js runs in VMs that
have no special support for it breeds a false sense of portability.

If Firefox is the only browser that implements asm.js, it'll have about the
same issues as Dart or NaCL. That is, Dart also compiles to JS, but if Dart2JS
were 6x slower on Firefox than Chrome, no one would be cheering, and in fact,
this is a complaint Mozilla themselves raised in the beginning (that if DartVM
has an enormous performance advantage compared to Dart2JS it would make other
browsers look bad and fragment things)

If I'm writing a game in C and compiling it to asm.js, and it's gonna run 6x
slower everywhere else, I'm effectively developing it for Firefox only no
differently than if I had compiled C to NaCL/PNaCL.

For this to be effective, it has to be cross browser. At least, Mozilla and
WebKit/Chrome. (honestly, without WebGL support, I don't think it helps IE
with games anyway)

~~~
cliffbean
I agree with your point; while functionality portability is important, we
really want performance portability too.

A big challenge we seem to have with any of the available options is
convincing all the major browser makers to agree on _something_. And even
though asm.js won't have perfect performance portability at first, it looks
like it should be a much easier sell to browser vendors than Dart or NaCl
were.

With asm.js, browser vendors won't need to add a _new_ VM. They'll just need
new optimizations within their existing VM. There's no new security model to
understand, no API from someone else's browser to emulate, and no large set of
features which will be redundant between VMs.

And, asm.js has a lot lower risk of becoming a legacy nightmare if it doesn't
catch on. Or if the specification changes. It's just optimizations, so there's
room to maneuver when customers with old code demand that you support them
forever.

~~~
cromwellian
On security, I'm not sure I agree. Part of achieving optimizations is making
enough assumptions to perform them, and that leaves you open to holes in your
validator. If validation isn't correct, then you could potentially trigger the
optimizer to create bad code that would be exploitable.

We've basically moved to Java bytecode verification to asm.js verification.
This is just speculation, but I'm actually concerned about the potential
security implications.

------
xal
ASM.js is easily the hack of the year. Every hacker should walk around with a
smile on their face today.

------
benaiah
I think that compile-to-JS languages are going to explode in popularity even
more than they already have when they can compile to an optimized asm.js. I
might be misunderstanding its impact, but I'm hopeful.

~~~
kayoone
it doesnt really change the game for traditional web development though.
Thinks like GWT might be faster with asm.js but it didnt take off for other
reasons than speed.

------
lubos
This is huge. Never heard of Asm.js until now but this is the first time I'm
really excited about Javascript.

I feel like dropping everything right now and start playing with this.

------
fosap
Ok, everybody, Javascript is over. Now everybody will be able to use their
favorite language and chances are that it will be faster.

------
jahabrewer
Sorry I'm late to the party.

Could someone explain what this is? All I've found in search is talk about how
much faster it is. Devs write code in C/C++ and target js? Is that it?

~~~
masklinn
asm.js is a low-level statically typed subset of javascript, roughly
equivalent to C (that's not exactly it but close).

As a result, it can be AOT-compiled to machine code rather efficiently and
lead to excellent performances with special support, while still being 100%
compatible with browsers providing no special support (as it's a subset).

The idea is to make it an efficient (if low level) language to use out of the
box, and an efficient compilation target for higher-level non-javascript
languages (C and C++ are used for comparisons but e.g. clojurescript or elm
could compile to asm.js as well instead of their current javascript target).

Basically, as the name implies asm.js tries to be an assembly for the web, but
a backwards-compatible one (as opposed to NaCl)

------
kayoone
For traditional web development this wont change too much does it? i mean you
could write the business logic of your app in whatever compiles to
asm.js(which in pratice is mostly done server-side) but in the end you would
still do DOM manipulation using JS or not?

makes alot of sense for rich apps and games though.

~~~
manmal
Yes, I would love to see an adapation of MVC frameworks like Ember and Angular
to use asm.js - not really sure if it's necessary though, since they are
already that fast.

------
surrealize
There are some speed comparisons in the comments here; it would be really nice
to see some compiled-code-size comparisons between native and asm.js.

~~~
pcwalton
See [http://mozakai.blogspot.com/2011/11/code-size-when-
compiling...](http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-
javascript.html)

Comparable with native after you gzip.

Note that this wasn't asm.js, however, just vanilla Emscripten output. asm.js
output will be somewhat larger due to the strict type system.

~~~
surrealize
> asm.js output will be somewhat larger due to the strict type system.

That's the part I was wondering about.

I'm hoping that we'll see rust compile to asm.js! ISTM that there's some
similarity between web worker "transferable object" semantics and rust unique
pointer semantics. If ES "binary data" objects end up being "transferable
objects", maybe rust unique pointers can map onto transferable objects in rust
tasks that are compiled to asm.js and run as web workers.

------
mindcrime
I approve of this link, just for the Amon Amarth reference!

That said, I'm somewhat excited about this, but also discouraged by the lack
of commonality between major browsers in this regard. Now Firefox has asm.js,
Chrome has NaCl, and Microsoft has ??? and Opera has ???. Uugghh...

Still, anything that stands to make the web experience faster and more useful
is a good thing, I guess..

~~~
kibwen
The only reason that I'm excited for asm.js is the fact that it's cross-
browser, since it's literally just a subset of JS. Theoretically something
transpiled to asm.js would be executable even in IE6, though I'd really like
to see someone try.

~~~
cromwellian
Executable != useful though. This breeds a false sense of portability.

If Firefox is the only browser that implements asm.js, it'll have about the
same issues as Dart or NaCL. That is, Dart also compiles to JS, but if Dart2Js
were 6x slower on Firefox than Chrome, no one would be cheering, and in fact,
this is a complaint Mozilla themselves raised in the beginning.

If I'm writing a game in C and compiling it to asm.js, and it's gonna run 6x
slower everywhere else, I'm effectively developing it for Firefox only no
differently than if I had compiled C to NaCL/PNaCL.

For this to be effective, it has to be cross browser. At least, Mozilla and
WebKit/Chrome.

~~~
azakai
I agree that if that were the case, it would be a problem.

However, I don't think we will see a 6x slowdown here. JavaScript engines are
_already_ very fast on compiled code, because they have already been
optimizing for typed arrays and so forth for a while now. Google even added a
compiled C++ benchmark to Octane, for example.

In current benchmarks, asm.js gives you a speedup of anywhere from 1x (where
normal JS optimizations already got us very close to native) to 6x. So 6x is
the worst case, and there are plenty of cases in the middle. A 2x-3x
difference is not big enough to make something a false sense of portability,
the web has tolerated 2x-3x speed differences for a long time now, and these
things also change a lot in terms of who is fastest, on what, and by what.

Furthermore, I would not expect a 2x-3x difference to last very long, again,
because browsers have been competing on performance of this type of code for a
while now (Octane, etc.), and will continue to do so.

~~~
cpeterso
Much of the discussion of asm.js focuses on Emscripten-compiled code. Would
asm.js be useful for other tools that generate JS, such as CoffeeScript or
Dart2JS?

~~~
azakai
Possibly yes, depending on the language. For CoffeeScript likely not, it is
very close to normal JS, and lacks types.

For Dart, I don't know enough about how the VM works.

But in general, a language like Dart could work. For example, LuaJIT or PyPy
could be ported, the C parts compiled into asm.js, and the JITs would need a
new backend that emits asm.js instead of x86 or ARM. This could potentially
make a language like Lua, Python, Dart, etc. very fast on the web. However,
how feasible it is would depend on the VM architecture.

I hope to work on this kind of stuff later this year.

~~~
cromwellian
The problem is, you'll end up porting those language's Garbage Collectors as
well. I don't think it's that practical to compile GC'ed languages to asm.js
until GC support is added. The GCs that are in Firefox and Chrome are very
efficient low pause collectors, and IMHO, you really don't want to reimplement
collector in JS, especially since you can't take advantage of OS/MMU features,
and can't do multithreaded collection, etc.

Also, if you consider something like the Java Virtual Machine, it's practical
to make it work on NaCL, but JS doesn't support blocking/synchronous calls,
and how earth would you make all of those synchronous APIs, and multithreaded
APIs work in that context?

asm.js is not isomorphic to NaCL in terms of feature set, but asm.js +
something like OpenCL could probably work well for games.

~~~
azakai
GCing is a concern, yes. With the Binary Data API and some extensions, it
might be possible down the road to have GC'd objects in asm.js compiled code.
Definitely an interesting area to investigate.

Multhreading is another concern, if you want shared state (with the JVM would
need). It can't currently be done, but again, is worth thinking about and
perhaps new web APIs could enable it some day.

------
macspoofing
This is exciting. I hope Google (and eventually Microsoft, Opera and Safari)
jump on this.

------
vmind
Slight offtopic: if anyone installed Nightly to have a look at this, and the
UI is scaled strangely (might just be a windows thing related to HiDPI) you
can set the devPixelsPerPx in about:config to 1.0 to get the scaling back to
normal.

------
zobzu
Tried the demo in Chrome and FF-nightly like everyone, and like everyone I
guess, I was really impressed. it's visually twice faster in Firefox. Firefox
seems to have come a long way.

------
sowhatquestion
From the comments: "This can give a second life to the JS backend of PyPy."

That would be incredible. Any PyPy devs care to comment on this possibility?
:3

------
natmaster
I'd like to see a python->asm.js compiler. Then I throw that in my resource
generation pipeline and I am a happy programmer.

~~~
dnu
But could Python really take advantage of asm.js? I think that this is more
useful for compiling statically typed languages (C/C++/... maybe TypeScript?)
to JavaScript.

~~~
whatshisface
It's been said elsewhere, but you musn't forget that the python interpreter
itself must be compiled. The pypy project is a python interpreter written in a
restricted subset of python (rpython), and it would be doable to make the
rpython compiler output asm.js.

------
Kiro
How does this affect us "normal" JavaScript developers who don't know anything
about low-level stuff?

~~~
endemic
From what I can see, it means you write your code in another language, and
then it is "compiled" into performant JavaScript. Basically it would create
much more efficient JavaScript than you could write yourself. Nothing to stop
you from continuing to write regular JS, though =]

------
rsofaer
This could be very useful for getting numerical and other high performance
code into the browser.

------
jlebrech
Why can't we just have a universal bytecode that can be interpreted by any
browser.

~~~
cdi
because politics, control, money, power.

~~~
jlebrech
chrome compiles javascript into an intermediate language already, they just
need to allow that intermediate code directly from a script tag.

------
afshinmeh
Nice! I really need an environment to test asm.js.

------
camus
Just learned about asm.js , awesome ! but other browser vendors need to
support it ! great work again -moz ;)

------
haydenj0nes
friendly reminder that google's dart dev team has made claims that dart is
already 30% faster than js, and they plan to release VMs capable of surpassing
100% faster than js, so yeah.

keep in mind that if asm.js is half of native speed, dart is capable of
bridging the gaps of js.

~~~
cpeterso
How will a fast Dart VM help Firefox and IE users?

~~~
haydenj0nes
I don't understand how that's supposed to make sense. A competing product
doesn't have to take care of its other competitors.

~~~
zobzu
you seem to really care about standards! so basically, ActiveX is faster than
dart. you should probably use that. you know. its actual native performance:)

