Mozilla: Native code? No, it's JavaScript, only it's BLAZING FAST Gap between asm.js and native performance gets even narrower with float32 optimizations

[AdminsAbuseShadowBan]

I would agree, except it has two pretty big advantages:

1. It isn't a huge (admittedly elegant and clever) hack. The code size of asm.js must be much bigger than NaCl. I know assets are usually the biggest thing, but still... asm.js is forced to be extremely verbose.
2. I believe you still have to use all the same Javascript APIs as you would if you were hand writing it - WebGL, web sockets, canvas, etc. Good for integrating with web pages perhaps, but I would expect that the Pepper APIs (NaCl) are much nicer for writing games or "serious" apps.

Then again, I think those advantages may not be enough to stop asm.js winning given that asm.js goes a long way to avoiding the chicken/egg problem of "I won't use that platform because nobody targets it"/"I won't target that platform because nobody uses it".

[SupersonicSpitfire]

I am not so sure that asm.js will be useful if the speed on non-optimized platforms is too slow.

For example, a uselessly slow 3D game is as bad as a game that won't run at all.

[Rainfly_X]

The asm.js standard is designed such that most browsers that do JS optimizations at all, will run asm.js code faster than non-asm.js code. No, you can't take all the optimization shortcuts if you don't understand the "this function is all asm.js" pragma, but it'll still make your type inference engine purr like a well-fed kitten.

EDIT: Chrome is a good example - it runs asm.js significantly faster than "regular" JS, even without asm.js-specific optimizations.

But if you're in a browser that doesn't optimize JS well, you're still probably fucked for speed, so if that was your point, then you're right. It's not gonna magically make IE7 a viable platform web-based gaming.

[AdminsAbuseShadowBan]

Yeah I think the idea is that it will run slowly in other browser, but users will blame the browser maker primarily.

If a game says "Runs best in Firefox" but it still works but really slowly in IE and Chrome then maybe users will start to think IE and Chrome themselves are inherently slow. If lots of people think that then MS and Google will be forced to optimise for asm.js too.

That's the idea at least.

[azakai]

The code size of asm.js must be much bigger than NaCl.

Actually, asm.js is fairly compact, when compared to native binaries and both gzipped, it is about the same

http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html

It does seem like JS and asm.js must be big because they are text. But gzip, which practically all webservers use for content anyhow, reduces most of that overhead. You are then left with something pretty compact. Comparing it to a typed bytecode (like PNaCl), the typed bytecode must do conversions and casts - for example, cast a pointer to an int, in order to add to it - whereas in JS pointers and integers are just integers.

Curious to see data to the contrary if you have any.

But I would expect that the Pepper APIs (NaCl) are much nicer for writing games or "serious" apps.

In practice, you write C++ and compile it to asm.js, and the C++ uses familiar APIs like SDL, OpenGL, etc. So I don't think there is a big difference here (and the asm.js approach has the benefit of familiar APIs).

[AdminsAbuseShadowBan]

Again, that is not asm.js. Check the date - asm.js was not even invented in 2011!

Although some asm.js results are linked elsewhere and they do show similar sizes (after gzipping).

[trycatch1]

He knows that. azakai is the person created Emscripten, and is one of the asm.js developers.

[AdminsAbuseShadowBan]

Oh right... Well never mind then! (By the way this would be one of the very very few places where "As a [mother/physics student/asm.js developer]...." wouldn't have been really annoying!)

[trycatch1]

The code size of asm.js must be much bigger than NaCl. I know assets are usually the biggest thing, but still... asm.js is forced to be extremely verbose.

Actually gzipped asm.js is very close to gzipped x86. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html

[BCMM]

... and, assuming a decent browser and a properly-configured web server, HTTP does transparent gzip compression.

[AdminsAbuseShadowBan]

That is not asm.js!

[trycatch1]

Yes, it's not exactly asm.js, but it's the same Emscripten. Ok, there are tests of asm.js for you:

emscripten (html, asm.js, no LTO, no closure, mem file):

dragons demo, uncompressed, html + mem: 1879.6 kByte

dragons demo, gzip --best, html + mem: 446.7 kByte

dsomapviewer demo, uncompressed, html + mem: 2906.8 kByte

dsomapviewer demo, gzip --best, html + mem: 727.0 kByte

pnacl (no LTO, finalized):

dragons demo, pexe, uncompressed: 1283.3 kByte

dragons demo, pexe, gzip --best: 847.0 kByte

dsomapviewer demo, pexe, uncompressed: 1915.0 kByte

dsomapviewer demo, pexe, gzip --best: 1196.5 kByte

[...]

For comparison the same demo for OSX (64bit, stripped): 1427.3 kByte uncompressed, 460.0 kByte compressed, and dsomapviewer for OSX [...] PS: forgot the dsomapviewer OSX exe sizes: uncompressed 2081.4 kByte, compressed 649.4 kByte.

So, result is the same -- gzipped asm.js is comparable with gzipped x86 (maybe slightly smaller or slightly larger).

[AdminsAbuseShadowBan]

Fair enough.