10 ms·

Asm.js: The JavaScript Compile Target

218 points by dave1010uk 14y ago

dave1010uk 14y ago
John Resig's blog posts never fail to impress. The bit comparing Asm.js to Google's Native Client is interesting.
niggler 14y ago
Wow, Mozilla is making a really big marketing push for asm.js.
- robin_reala 14y ago
  What makes you think this is a marketing piece instead of a normal blog post by John?
  - niggler 14y 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?
    - jlongster 14y ago
      It sounds more like you're looking at all of this through a strong negative filter.
      - niggler 14y ago
        If objectivity is strongly negative, so be it. You'd ask similar questions if Resig wrote an article of PNaCl without testing it himself.
    - jeresig 14y ago
      Ok, I'll bite. - I did not run performance benchmarks on my system because Asm.js does not yet support OS X (which is my primary OS). I fully intend to run some tests, and hopefully make some of my own, when that time comes. In the meantime it's not really beneficial for me to just re-run the same benchmarks that others have run on those platforms. - I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path. - That's complete nonsense. I can't believe I have to say this but yes, I wrote those sentences.
      - mistercow 14y ago
        >- I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path. I think the parent was asking for an explanation for why Chrome does so much worse than the non-asm.js Firefox. Which I guess is kind of a weird question given that Chrome beats non-asm.js FF in one of the three benchmarks, and is roughly tied with it in another.
        jeresig 14y ago
        Ah! In that case I'm not sure - but according to mraleph's comment above it looks like there might be some issues in V8 for some of the benchmarks: https://code.google.com/p/v8/issues/detail?id=2223 https://code.google.com/p/v8/issues/detail?id=2223
- k3n 14y 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.
  - niggler 14y 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?
    - k3n 14y ago
      > 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.
    - glhaynes 14y ago
      Why? If you have reasons to think that the performance tests that he references are invalid or inapplicable, those should be addressed; otherwise, why should he spend his time recreating low-level tests to talk at a higher level about the subject?
- dave1010uk 14y 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 14y 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.
- jeresig 14y 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 https://github.com/mbebenita/Broadway
- robin_reala 14y 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 https://github.com/mbebenita/Broadway
- dave1010uk 14y 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-ported-to-javascript-for-all http://badassjs.com/post/17218459521/webm-and-webp-hand-port...
- ysangkok 14y ago
  Wasn't Firefox 20 supposed to have H264 support?
  - fakeer 14y 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 14y ago
In theory, would it be possible to take an ActiveX or NPAPI plugin and compile it down to asm.js-compatible javascript?
- JoshTriplett 14y 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 14y 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 14y 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.
  - mtgx 14y 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.
    - jlongster 14y ago
      What about the fact that they've ported Unreal Engine 3 and are running it now with full speed inside the browser? I hope we get our hands on it soon, but you can watch the videos of it for now. It runs OK without asm.js, but it's liquid smooth with it. What else do you need?
aroman 14y 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...
- jeresig 14y 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 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.
  - tracker1 14y 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 14y ago
  V8 doesn't support Asm.js.
  - aaronharder 14y ago
    ...not yet, anyway.
  - falcolas 14y ago
    ... in an optimized fashion. Being valid JS, V8 could run Asm.js code.
    - coldtea 14y ago
      Which doesn't matter in this case, as this fact doesn't give any incentive to Node folks to use it in V8.
Charlesmigli 14y 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-javascript-compile-target http://tldr.io/tldrs/515c59e49ac882db1600010b/asm-js-the-jav... Asm.js's support should make sense for Chrome OS no?
- bti 14y ago
  Nice summary, never heard of tldr.io, looks useful.
opinali 14y 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 14y ago
  Sure, the Unreal Engine 3 demo (Epic Citadel) had been already ported to Flash one year ago. http://www.unrealengine.com/flash/ 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 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 14y 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.
- azakai 14y 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_ 14y 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 14y 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 https://github.com/kripken/emscripten/wiki
- kevingadd 14y 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.
melling 14y 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 14y 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 14y 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 14y ago
    Great comparison, thanks.
stcredzero 14y 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 14y 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.
- wmf 14y ago
  Yes, code that runs faster also uses less battery.
  - kevingadd 14y 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.
    - wmf 14y ago
      Running faster may use more power but it generally uses less energy which is the constraint in a battery-powered device.
      - rictic 14y ago
        Agreed. Summarized in the phrase "race to sleep" - see http://en.wikipedia.org/wiki/Dynamic_frequency_scaling http://en.wikipedia.org/wiki/Dynamic_frequency_scaling

218 points by dave1010uk 14y ago

dave1010uk 14y ago

John Resig's blog posts never fail to impress. The bit comparing Asm.js to Google's Native Client is interesting.

niggler 14y ago

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

robin_reala 14y ago
What makes you think this is a marketing piece instead of a normal blog post by John?
- niggler 14y 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?
  - jlongster 14y ago
    It sounds more like you're looking at all of this through a strong negative filter.
    - niggler 14y ago
      If objectivity is strongly negative, so be it. You'd ask similar questions if Resig wrote an article of PNaCl without testing it himself.
  - jeresig 14y ago
    Ok, I'll bite. - I did not run performance benchmarks on my system because Asm.js does not yet support OS X (which is my primary OS). I fully intend to run some tests, and hopefully make some of my own, when that time comes. In the meantime it's not really beneficial for me to just re-run the same benchmarks that others have run on those platforms. - I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path. - That's complete nonsense. I can't believe I have to say this but yes, I wrote those sentences.
    - mistercow 14y ago
      >- I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path. I think the parent was asking for an explanation for why Chrome does so much worse than the non-asm.js Firefox. Which I guess is kind of a weird question given that Chrome beats non-asm.js FF in one of the three benchmarks, and is roughly tied with it in another.
      - jeresig 14y ago
        Ah! In that case I'm not sure - but according to mraleph's comment above it looks like there might be some issues in V8 for some of the benchmarks: https://code.google.com/p/v8/issues/detail?id=2223 https://code.google.com/p/v8/issues/detail?id=2223
k3n 14y 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.
- niggler 14y 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?
  - k3n 14y ago
    > 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.
  - glhaynes 14y ago
    Why? If you have reasons to think that the performance tests that he references are invalid or inapplicable, those should be addressed; otherwise, why should he spend his time recreating low-level tests to talk at a higher level about the subject?
dave1010uk 14y 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 14y 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.

jeresig 14y 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 https://github.com/mbebenita/Broadway
robin_reala 14y 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 https://github.com/mbebenita/Broadway
dave1010uk 14y 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-ported-to-javascript-for-all http://badassjs.com/post/17218459521/webm-and-webp-hand-port...
ysangkok 14y ago
Wasn't Firefox 20 supposed to have H264 support?
- fakeer 14y 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 14y ago

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

JoshTriplett 14y 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 14y 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 14y 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.
- mtgx 14y 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.
  - jlongster 14y ago
    What about the fact that they've ported Unreal Engine 3 and are running it now with full speed inside the browser? I hope we get our hands on it soon, but you can watch the videos of it for now. It runs OK without asm.js, but it's liquid smooth with it. What else do you need?

aroman 14y 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...

jeresig 14y 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 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.
- tracker1 14y 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 14y ago
V8 doesn't support Asm.js.
- aaronharder 14y ago
  ...not yet, anyway.
- falcolas 14y ago
  ... in an optimized fashion. Being valid JS, V8 could run Asm.js code.
  - coldtea 14y ago
    Which doesn't matter in this case, as this fact doesn't give any incentive to Node folks to use it in V8.

Charlesmigli 14y 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-javascript-compile-target http://tldr.io/tldrs/515c59e49ac882db1600010b/asm-js-the-jav... Asm.js's support should make sense for Chrome OS no?

bti 14y ago
Nice summary, never heard of tldr.io, looks useful.

opinali 14y 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 14y ago
Sure, the Unreal Engine 3 demo (Epic Citadel) had been already ported to Flash one year ago. http://www.unrealengine.com/flash/ 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 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 14y 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.
azakai 14y 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_ 14y 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 14y 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 https://github.com/kripken/emscripten/wiki

kevingadd 14y 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.

melling 14y 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 14y 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 14y 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 14y ago
  Great comparison, thanks.

stcredzero 14y 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 14y 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.

wmf 14y ago
Yes, code that runs faster also uses less battery.
- kevingadd 14y 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.
  - wmf 14y ago
    Running faster may use more power but it generally uses less energy which is the constraint in a battery-powered device.
    - rictic 14y ago
      Agreed. Summarized in the phrase "race to sleep" - see http://en.wikipedia.org/wiki/Dynamic_frequency_scaling http://en.wikipedia.org/wiki/Dynamic_frequency_scaling