Asm.js - JavaScript acceleration

So there's been some news lately about this thing called asm.js. I don't entirely understand what it is, but it seems to be a way to pre-compile JavaScript so that it's even faster.

asmjs.org

I didn't pay that much attention to it even after Mozilla showed it off by running unreal engine 3 in web browsers using HTML5 - and unreal engine 4 will apparently export to html5 as well - because I've seen new web technologies deployed before that didn't gain any traction with other browser makers, like nacl. However, Google appears to be actually planning to support it as well as Mozilla.

news.cnet.com/8301-1023_3-57576903-93/google-shows-interest-in-asm.js-mozillas-plan-for-fast-web-apps

esterday, Mozilla held a coming-out party for ASM.js, announcing a cooperation with Epic to bring its Unreal game engine to ASM.js. The same day, Google effectively announced a plan to support it within Chrome's V8 engine that processes JavaScript.

"Optimizations should be added to V8 to generate good code for the ASM.js subset of JavaScript," Chrome programmer Kenneth Russell said in a Chrome feature-tracking item for ASM.js. "The implementation cost should be small compared to the potential upside -- the ability to run significant existing code bases with close to the speed of C inside the JavaScript engine."

There's no official word yet from Google, but it's sounding good.

I don't know how it works exactly, but since it's apparently backwards compatible for non-asm.js supporting browsers it would be cool if c2 could use it.

I've been following asm.js with interest. It looks very cool, but it appears to be mainly for languages which compile to JS - things like Unreal Engine, where presumably they have lots of C/C++ code, and they want to port that to a browser. The JS code that you tend to get with this kind of conversion naturally ends up looking like assembly, since that's what existing compilers do well. You have basically one giant array representing memory, then a lot of JS code that basically shunts numbers around - just like the real assembly you get after compiling C traditionally. Mozilla have figured out how to optimise this special subset of machine-like JS to be within 2x the speed of real assembly. And the very cool thing is it runs on older browsers without specific support; it's all still standards-compliant Javascript, so any browser can run it, although they may be slower at it.

If this was around when we first started Construct 2, it would definitely have been considered as an option. However we already have tens of thousands of lines of JS code hand-written and hand-optimised. I believe this hand-written code already performs very well. If we wanted to go further and take advantage of asm.js, we would effectively have to rewrite the entire engine in another language which compiles to asm.js. This is too much work to justify for a probably small performance boost, and will probably introduce difficult problems around how to handle existing plugins and behaviors. On top of that most games are still renderer-bottlenecked, even on mobile - so it may not even provide any actual framerate improvement at all for many games. So while it's very cool and I'm going to keep an eye on it, I don't think we'll be using it.

Ashley

Thanks for your lucid explanation of asm.js. Wow! - back to the future!

You make a very persuasive point about the real bottleneck generally being the renderer - in any optimisation exercise, it certainly doesn't pay to have a myopic focus on any one part of the end-to-end process.

Drat, that's frustrating. A way to speed up JavaScript, except you can't use JavaScript to use it. Argh.

Thanks for the explanation!

Well if it's truely optimization for other codebases to be translated into ASM style JS, then it should be possible to have JS re-translated into that. However with Ashley's statement I don't see that being a benefit VS improving what they already have created so far with Construct 2 unless they got the time/hired another person to re-write a lot of their existing code. That and compared to their recent blogpost on how the C2 renderer is faster than the Native Construct Classic engine they had before shows how much they've optimized.

Although with the real possibility of high level applications like the Unreal Engine 3 and 4 being ported to ASM.js it'll be easier for traditional programmers to make web apps, in which I think Construct 2 might be better off focusing on becoming the HTML5 replacement for Flash. It's coming along that way pretty well even if it's missing native keyframe animation control. It's easy to use, accessible(free), and can do many things.

Maybe sometime down the line it can be looked at again.

This would be the best course to go if Ashley had taken the path of writing C2 in Cpp + OpenGL. It would then be a matter of compiling the engine to JS using Emscripten generating Asm.js code . Right now the idea of Asm.js is to formalize a subset of JS that can be heavily optimized by a specialized JS engine like SpiderMonkey / V8 which can then generate much faster native code from JS . So right now the path is C/C++ -> JS/JS Asm. But there's work with JS -> JS Asm too (LLJS) . So using Asm.js in C2 could be possible in the future, but not right now.

kiyoshi

Ah, so someone already is making a JS>ASM.js? Sweet.

Well if it turns out good it shouldn't take too much to test it out with C2 output and include it.

Although I'm confused, people say it's backwards compatable, but the article says that V8 should support ASM.js and that browsers to need to support codebases. Are they just talking about NaCL and Dart that Chrome uses as examples and ASM.js would be more optimized on newer browsers that have more direct support for it, but still work fine on older ones?

Not really from a coding background so I can't say I understand too many things on a deep coding level. But I do love how accessible JS and HTML5 is and want to see it bloom to as a competing technology.

kiyoshi - ah, cool. I hope it doesn't require any major rewrites.

ASM.js is new technology, actually is not supported yet to actual browsers, so we will see what happens.

ASM.js is new technology, actually is not supported yet to actual browsers, so we will see what happens.So then it's not backwards compatible?

It is backward compatible, since it's just standard javascript. All Asm.js will do is more efficiently convert javascript written in a certain style into fast machine language. The code will work in older browsers, but it will take a newer browser that does the conversion to see any speed improvements.

> ASM.js is new technology, actually is not supported yet to actual browsers, so we will see what happens.So then it's not backwards compatible?

Yes, according this presentation

http://kripken.github.com/mloc_emscripten_talk/#/32

Basically, it says "Not supported yet: C++ exceptions, setjmp/longjmp"

I'm sure i'm wrong when i said is not supported all browsers due to Ashley's post that he will not use it.

The technology is very promising but very new. Give it a couple of months. Be it Asm.JS or whatever HTML5 gaming has a bright future, since everyone is targeting it and working hard to make it better, specially Mozilla. PC's are already more than covered. Now there's only mobile and consoles left. I'm specially excited with consoles (Ouya).