
Asm.js: The JavaScript Compile Target - dave1010uk
http://ejohn.org/blog/asmjs-javascript-compile-target/
======
joblessjunkie
Where everyone seems to be focused on performance, it strikes me that
performance is just the flip side of _efficiency_ , and that asm.js might be a
great way to stretch battery life on mobile. Will asm.js web pages run with
less power than traditional JS? Also I suspect this can help with the sluggish
performance of mobile browsers in general.

~~~
wmf
Yes, code that runs faster also uses less battery.

~~~
kevingadd
Well, not _always_ , but it's pretty safe to assume that if a program
completes in 1 second instead of 10 seconds, it's gonna use less power.

Modern CPUs tend to be able to adjust their clock speed in response to load,
and I think there are even some shipping processors that can switch off entire
cores. GPUs are the same way. In practice, running an asm.js version of some
normal JS might load your CPU more evenly and use more of its resources, but
it's going to run so much faster that you should come out ahead.

The power draw (measured at the wall by my UPS) from my current desktop PC can
bounce from 100W to 400W at the drop of a hat (from the GPU and CPU both
clocking up, respectively). So, in that case, code that 'runs faster' (by
using the GPU) could potentially actually use more power. But I bet in
practice most GPGPU applications end up using less power in total too since
they run so much faster.

~~~
wmf
Running faster may use more power but it generally uses less energy which is
the constraint in a battery-powered device.

~~~
rictic
Agreed. Summarized in the phrase "race to sleep" - see
<http://en.wikipedia.org/wiki/Dynamic_frequency_scaling>

------
crazygringo
This is the first I've heard of Portable Native Client (PNaCl), which sounds
very interesting.

I think ASM is a great idea for "hacking", but the thing that doesn't make a
lot of sense to me, is that you're usually only going to bother compiling to
ASM for things which need the performance. The idea that they'll "still work"
in non-optimized browsers doesn't seem too convincing -- games would probably
be unplayable, and you'd see messages saying "This game only supports Firefox"
etc.

And I don't see there being that many things written in C, etc., that one
would want to port to the web, that _aren't_ particularly processor-intensive.

Presumably PNaCl would be close to native code speed, a big improvement over
ASM. And it seems like what's needed is cross-platform _fast_ execution -- not
backwards compatibility with JavaScript that will still run, but run much more
slowly.

But nevertheless, it's super-interesting watching what's going on with ASM.

~~~
chc
PNaCl sounded interesting — I was really excited when I heard about it — but
it's been pretty much dead for a long time now. Even normal NaCl got a lot
more attention, and NaCl has not exactly been heartily embraced.

People are only recently starting to talk about PNaCl because it's the only
alternative to asm.js, and for some reason some people have such strong
negative reactions to the idea of a highly performant language that isn't a
bytecode that they'll support a defunct Google experiment before a low-level
JavaScript subset.

~~~
walid
The problem with NaCl is that it is platform dependent. It is the 386 real
mode instruction set which means it is bad for mobile platforms since nearly
all of them are ARM based. NaCl will be slower to run since ARM devices will
have to emulate the 386 instruction set.

~~~
hiker
Not true.

With NaCl one has to provide multiple EXEs for each platform that one wants to
support be it ARM, x86 or x64.

PNaCl was designed to solve the multiple EXEs problem by just providing one in
LLVM bytecode to be jitted runtime.

~~~
josteink
> With NaCl one has to provide multiple EXEs for each platform that one wants
> to support be it ARM, x86 or x64.

So websites written today wont be viewable/runnable on architectures created
tomorrow unless someone goes back, updates the NaCl tooling, gets the updated
NaCl tooling to the original author and convinces the original author to fix
his broken, platform-dependent website.

Excuse me if I say that sounds like a bunch of horseshit. If this had been
invented (and embraced) before the advent of mobile-devices, half the internet
would be unusable on smart-phones and tablets now.

Why on earth would we ant to create that sort of problems for the future?
Websites tend to stick around, maintained or not, and new things will _always_
emerge.

NaCl is a bad idea for any cross-platform medium and the internet in
particular. End of story. The only people rallying NaCl are Google-fanboys who
can't even see past their Google Chrome browser when testing _regular_
websites.

I can't wait for this non-standard monstrosity to die.

~~~
justincormack
Half the internet was unusable on mobile, the flash part...

------
Charlesmigli
This post is fundamental to understand the ins and outs of Asm.js this was
really helpful. It deserves its summary to make it even more understandable!
[http://tldr.io/tldrs/515c59e49ac882db1600010b/asm-js-the-
jav...](http://tldr.io/tldrs/515c59e49ac882db1600010b/asm-js-the-javascript-
compile-target)

Asm.js's support should make sense for Chrome OS no?

~~~
bti
Nice summary, never heard of tldr.io, looks useful.

------
opinali
Unimpressed by the "Unreal" demo. Just a simple scene flyover, no dynamic
lights or scenario, characters, particle effects etc. etc. I bet one can put
together a demo of similar quality with vanilla JS and WebGL.

~~~
NinjaWarrior
Sure, the Unreal Engine 3 demo (Epic Citadel) had been already ported to Flash
one year ago. <http://www.unrealengine.com/flash/> Since ActionScript VM is
far slower than JavaScript, I'm afraid I have to say the Mozilla's demo does
not prove the performance of asm.js at all.

And here's the latest Unreal Engine 4 demo.
<http://www.youtube.com/watch?v=dO2rM-l-vdQ>

I know there are improvements on the web platform each year but I wish people
would be very very cautious to say "we've achieved nearly native
performance!".

To begin with, I think it's difficult to run 3D games (including Flash and
Unity) on browsers because of the asset loading (and AOT compilation) time. If
people must wait for seconds and even minutes to start a game, we can't do
business with it. As many web developers says, immediate page loading is must.
I'm personally running Flash and HTML5 games and I observe 80% people leave
just in a few seconds loading.

To solve this issue, game stores (PS3, Xbox 360, App Store, Google Play, Steam
and many others) are using the "reserve download and play it later" model.
After all, traditional install apps are not that bad architecture...

~~~
Arelius
> Since ActionScript VM is far slower than JavaScript

This is actually incorrect. While ActionScript is actually far slower than
Javascript, the VM is actually really good at running C code compiled to it.
Providing about a 30x speed up over Actionscript.

------
dave1010uk
John Resig's blog posts never fail to impress.

The bit comparing Asm.js to Google's Native Client is interesting.

------
_pmf_
I think it's really great of a man who has some very high stakes in
traditional Javascript to be so open to Asm.js; I fully expected to read some
passive-aggressive dismissal.

------
jcampbell1
Does anyone know how hard it would be to port an h264 decoder to asm.js? If it
worked, it could be used to shim h264 support into Firefox.

~~~
ysangkok
Wasn't Firefox 20 supposed to have H264 support?

~~~
fakeer
Yes. But it hasn't somehow on Mac, because I have been reading it's already
there on Windows(never tried myself though).

------
theycallmemorty
In theory, would it be possible to take an ActiveX or NPAPI plugin and compile
it down to asm.js-compatible javascript?

~~~
JoshTriplett
Yes, but you'd need to implement a compatible API for it to call. And both
ActiveX and NPAPI expect access to privileged APIs not normally available to
sandboxed Javascript code. So you'd either need browser support for equivalent
privileged APIs for Javascript or some kind of emulation layer that fakes the
access those APIs expect.

------
aroman
As a node developer, I'm curious to know what if anything asm.js can do for
node? Maybe I'm misunderstanding something, but wouldn't asm.js allow
basically all of node's core to be written in JavaScript itself, rather than
in C/++? I think that would be a tremendous advantage, but maybe I'm missing
part of the picture...

~~~
Offler
V8 doesn't support Asm.js.

~~~
falcolas
... in an optimized fashion. Being valid JS, V8 could run Asm.js code.

~~~
coldtea
Which doesn't matter in this case, as this fact doesn't give any incentive to
Node folks to use it in V8.

~~~
falcolas
Not yet, but if Chrome takes the route of optimizing the asm.js subset of
javascript, node.js could gain a lot of traction as a generic high performance
asynchronous platform.

And that may just be worth getting excited for.

~~~
tracker1
NodeJS is already gaining traction as a high performance asynchronous
platform... Though it's best fit has been in situations that are more IO bound
than CPU bound, where it's been a bad fit. This could make it a better fit for
CPU tasks, with high IO.

Right now, I have a few workers managed in node, that run compiled code. It
works pretty well, but having more of that as modules directly available in
Node, with nearly the same performance would be really compelling.

Not needing to compile certain NodeJS modules is what I'd find really
compelling.

------
euroclydon
I'm surprised the list of Emscripten projects does not contain a linear
algebra library. Is that because all the common matrix transforms can already
be offloaded to native browser APIs?

<https://github.com/kripken/emscripten/wiki>

~~~
kevingadd
No native browser offers anything resembling a matrix API (or even a complete
mathematics api; JS's Math api is pretty minimalistic). People implement it
themselves, using libraries like glmatrix.

------
melling
Why are C/C++ so much faster than JIT'ed Javascript? Can't a subset of
Javascript be converted to ASM.js JS that'll run around the same speed? loops,
arrays, conditional statements, etc. Why does Javascript have to be so much
slower?

~~~
tomjen3
C maps datatypes and actions to the underlying hardware, Javascript does not.
C puts everything on the stack by default (cheap) while Javascript puts it in
the heap (expensive). C uses copy semantics, while Javascript does not (fucks
caches, but more importantly now you have to do two loads for each value you
want to read).

Javascript is dynamically typed, and comes with eval, so that you can never
really be sure what type x is (and therefore what binary code the processor
should run), so you have to check and make allowances, which cost performance.

In C you always know the type of a variable so you can match + to either a
float, double or integer addition at compiler time, in Javascript you have to
(dynamically) check the type of both, possibly convert one or more and then
either perform a float or integer addition or string concatenation.

I C you always know the size of all structs, and they can't change so
allocating them is cheap and fast, whereas you have to create a hash table in
Javascript and access the objects that way (which is a lot more expensive, and
potentially you have to walk the chain of several objects due to usage of the
prototype property).

The same thing goes for Arrays, in C they are a pointer, in Javascript they
are far more complicated.

~~~
pjscott
> C maps datatypes and actions to the underlying hardware, Javascript does
> not.

That's not _entirely_ true. A lot of 8-bit microcontrollers, for example, do
not have hardware support for arithmetic on 32-bit integers; nevertheless, C
code using int32_t or uint32_t will compile just fine for those processors.
This goes double for floats, if you'll pardon the completely unintentional
pun.

It's a matter of degree, of course. C is still a lot closer to the metal than
JS.

------
stcredzero
Here's how to think of it. Right now, JavaScript is the best compiler target
on the web. It's far from perfect, but it works. Asm.js makes it a better
compiler target.

------
niggler
Wow, Mozilla is making a really big marketing push for asm.js.

~~~
k3n
You know Resig isn't employed by Mozilla anymore, right?

This is just a JS enthusiast (understatement of the year, perhaps) discussing
a JS topic.

~~~
niggler
Maybe I'm a bit old-fashioned here, but I'd expect a discussion of JS
performance to be coupled with a performance test _conducted by the author_.
Is that too much to ask?

~~~
k3n
> Is that too much to ask?

If it were a paid service, perhaps not. But, it's not....the blog is a free
service. Not trying to be rude, but the adage applies: you can 'take it or
leave it'.

I'm not sure why you feel so entitled that he seemingly owes you something.

If you feel that it's inappropriate for HN, then flag it.

