Asm.js: The JavaScript Compile Target

http://ejohn.org/blog/asmjs-javascript-compile-target/

by dave1010uk • 13 years ago

218 103 13 years ago

ejohn.org

dave1010uk3• 13 years ago

John Resig's blog posts never fail to impress.

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

niggler6• 13 years ago

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

robin_reala2• 13 years ago

What makes you think this is a marketing piece instead of a normal blog post by John?

niggler6• 13 years ago

Other than rehashing the exact arguments and diagrams presented in the mozilla marketing material and including an extensive "interview" with a mozilla engineer:

- I would have expected him to have tried it. There's no evidence in the post that he even fired up firefox nightly and ran even a simple test. The performance graph is straight out of asm.js marketing material

- In discussing chrome's performance, he just writes "A 4-10x performance difference is substantial" without explaining why chrome's performance suffers so much relative to firefox without asm.js (take the skinning demo. Why is chrome significantly worse than firefox?) This is a point that many have discussed, including some here in various posts about asm.js

- Certain sentences seem artificial. If you've read other posts by him, does "It is interesting to see such a large performance chasm appearing between Asm.js and the current engines in Firefox and Chrome. A 4-10x performance difference is substantial (this is in the realm of comparing these browsers to the performance of IE 6). Interestingly even with this performance difference many of these Asm.js demos are still usable on Chrome and Firefox, which is a good indicator for the current state of JavaScript engines. That being said their performance is simply not as good as the performance offered by a browser that is capable of optimizing Asm.js code." sound like something he would write? At all?

k3n2• 13 years ago

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.

niggler6• 13 years ago

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?

dave1010uk3• 13 years ago

Whether this the aim of this post was marketing or not (as I believe), it's a really in depth and interesting read if you're a programmer. Even more so if you use JavaScript. It would be great if all corporate marketing was like this!

jcampbell1• 13 years ago

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.

jeresig5• 13 years ago

I believe one has already been ported using Emscripten - but this was a while ago, I'd be curious to see how fast it runs now with Asm.js: https://github.com/mbebenita/Broadway

robin_reala2• 13 years ago

Fairly easily if you start with Broadway: it’s an Emscripten port of Android’s H264 software decoder that writes to a WebGL canvas.

https://github.com/mbebenita/Broadway

dave1010uk3• 13 years ago

The reverse has been done: WebM has been ported to JavaScript with Emscripten, which means all browsers (IE9+) can play WebM to some degree.

http://badassjs.com/post/17218459521/webm-and-webp-hand-port...

ysangkok• 13 years ago

Wasn't Firefox 20 supposed to have H264 support?

fakeer• 13 years ago

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

theycallmemorty• 13 years ago

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

JoshTriplett• 13 years ago

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.

crazygringo• 13 years ago

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.

buo• 13 years ago

> The idea that they'll "still work" in non-optimized browsers doesn't seem too convincing

The BananaBread demo ran very smoothly at fullscreen, 1920x1200, on Firefox 19. I was very impressed. I'm running on old hardware: a 3GHz Core2 Duo and NVidia Quadro 1700. I know it's not a full game, but it's awesome anyway.

mtgx2• 13 years ago

I don't think BananaBread was that good of a demo for asm.js. It was a demo for regular WebGL (so for most Javascript engines), done a while ago. If they want to sell us on the combination of asm.js with WebGL, they need to show something even more impressive.

Locke1689• 13 years ago

I disagree. Granted, I'm an unusual case as I'm a compiler developer for a living, but my use of Asm.js would primarily be to write compilers for interesting or research programming languages to JS (granted, so I don't have to write JS). In this case the primary benefit isn't performance, it's having a reliable compile target that I can do profiling on. You wouldn't believe how important it is to have a stable (and well-specified) target language when you're writing a compiler.

skymt3• 13 years ago

I don't think it's necessarily true that only projects that need ASM.js's speed will target it. There are already several languages or tools in increasingly common use that target vanilla JavaScript, like Haxe or GWT. Developers don't use those because they can't make JavaScript perform, but because developing in another language is more convenient in some way: better syntax or easier code sharing. If these compilers could be modified to target ASM.js, you'd get the performance bump for free without sacrificing the existing state of usability in browsers that don't natively support it.

fijal• 13 years ago

if you do that, ASM.js has definitely wrong level of interfacing with DOM and you're screwed.

chc• 13 years ago

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.

walid2• 13 years ago

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.

Arelius2• 13 years ago

It's not really about working everywhere. It's about providing the existing browser vendors their own parser, and reference implementation to help promote implementation. It's a small well constrained subset of what they already have. And just now have to provide a compiler for. Not trivial, but significantly easier then implementing the PNACL spec. The LLVM bitcode spec itself is large enough to ward of a second implementation.

aroman• 13 years ago

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

jeresig5• 13 years ago

That certainly could be a theoretical future for Asm.js! In my post I link to a pure-JavaScript port of SQLite that runs in Node.js (using Emscripten): https://github.com/kripken/sql.js

Presumably either Node would have to switch to Mozilla's Spidermonkey or V8 would have to implement full performance support for Asm.js.

tracker13• 13 years ago

Hopefully the V8 guys have more respect for asm.js than they do E4X, which would be really nice to have in NodeJS. Even though V8 is from Google devs and not directly associated with NodeJS, I think they should be at least considerate of features that are useful outside the browser, but need integration into the engine itself.

Offler• 13 years ago

V8 doesn't support Asm.js.

aaronharder• 13 years ago

...not yet, anyway.

falcolas2• 13 years ago

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

Joeri• 13 years ago

But if you're cross-compiling from C++ to get asm.js, what would be the advantage? The upside is easier distribution of code, but presumably in the case of node that wouldn't be a big upside.

tracker13• 13 years ago

Considering compilation differences between 32/64 bit versions across Linux, Windows and OSX, let alone different versions of NodeJS most native modules require a build system on the platform... As someone who's stuck with windows deployments for NodeJS work, it's been a little painful... I'd take the little performance hit for modules that load/run transparently.

andreypopp• 13 years ago

I think, that having code in C/C++ is much better than in obscure dialect of JavaScript.

olalonde• 13 years ago

Most of Node's core is already written in Javascript. Also, I can't see what would be the benefit of using Asm.js vs calling C/C++ libraries directly using FFI.

Charlesmigli• 13 years ago

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

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

bti• 13 years ago

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

opinali• 13 years ago

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• 13 years ago

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

Arelius2• 13 years ago

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

azakai6• 13 years ago

We also demoed an Unreal Tournament level, Sanctuary, at GDC, both in our presentation and at the booth where people could play it. Frame rate is good even with lots of bots.

_pmf_• 13 years ago

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.

euroclydon• 13 years ago

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

kevingadd3• 13 years ago

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.

melling3• 13 years ago

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• 13 years ago

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• 13 years ago

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

teeja• 13 years ago

Great comparison, thanks.

coldtea5• 13 years ago

>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?

"So much slower"?

Perhaps you haven't been around this web scene for more than 5-6 years. JS is so much faster now it's not even funny. JS used to be in the "slow as molasses" category pre-2005.

Now it's like 10 times faster than Python for pure algorithmic code.

melling3• 13 years ago

I'm asking to have C/C++ compared to JIT'ed Javascript. You are explaining how Javascript is so much faster than it used to be, and that it's 10x faster than Python. The fact that I mentioned JIT'ed Javascript should have given away that I understand Javascript's current performance.

If Javascript were fast enough, we wouldn't be looking for "4-10x" improvements with ASM.js and NaCL. Are we close to the limit of what can be done to improve Javascript performance? Perhaps another 2x?

curiousdannii• 13 years ago

Type safety basically. JITs can produce good code which performs very well, but it still must check that the data it has is of the type it expects. A good JIT may only check occasionally, but it still must check. asm.js can guarantee that its data's types cannot change through static analysis.

vidarh• 13 years ago

> Can't a subset of Javascript be converted to ASM.js JS that'll run around the same speed?

ASM.js code is a subset of javascript. The point is that they have defined a subset of javascript and a set of rules that, while it will run in a normal javascript engine, clearly indicates to the engine that if it supports it, it can do additional optimizations that could break things for "normal" javascript.

E.g. javascript doesn't have proper integers. Doing everything with floats is a performance killer, and for the JS engines to figure out when they can safely substitute integers is extremely hard without hints, so ASM.js specifies how to "fake" integers in a way that ensures the code will still work in standard JS engines (by using bitwise operators to coerce the value to integer values all over the place) while allowing an engine that knows about the ASM.js conventions to optimize the code further.

Nothing stops you from writing javascript code manually this way in the first place (apart from tedium), though it is admittedly a "workaround" to features in javascript that are incredibly hard to optimize well that would've been handled cleaner by language modifications.

The advantage of ASM.js is that the code still works in other JS engines, while if they'd started adding actual extensions to the language we'd be in portability hell for years.

stcredzero• 13 years ago

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.

joblessjunkie• 13 years ago

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.

wmf2• 13 years ago

Yes, code that runs faster also uses less battery.

kevingadd3• 13 years ago

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.

Asm.js: The JavaScript Compile Target

Related Stories