Perhaps for your OpenGL games, but for some business application originally written for VB4 that basically draws a bunch of forms and puts stuff in a database, that's more than fast enough for some compiler that took VB4 and turned it into JS.

This is basically the reason d'etre for NaCl as far as I can tell: it was at various points advertised as for games and other 'high performance' stuff, but the more probable commercial reason for it is to leverage companies on to a non-Microsoft platform through an easy migration path. So I think the hypothetical VB4 compiler comparison (or a million similar "business app migration" examples) is pretty fair.

[edit: per subsequent comment, the notion that GC somehow can't be implemented is nonsensical]

>the notion that GC somehow can't be implemented is nonsensical

http://asmjs.org/faq.html

"The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection."

Sure, nothing stops you from emulating a complete CPU. Of course you can do anything.

However, how large will that JavaScript file be? Also, will it be fast enough to be usable?

I think the difficulty of implementing GC would be the lack of access to stack primitives, something that would be impossible to provide in a way that was backward compatible.

By that I mean the ability to inspect the stack and determine the values present there and determine whether or not they point to 'heap' allocated memory.

From the asm FAQ, it seems like GC will happen:

Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR? A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages.

I took that to be actually talking about the other way around -- accessing JS GC'd objects from the asm.js code's heap and having it work correctly (which is currently onerous). I don't think that helps implement GC of the asm.js heap.

VB uses garbage collection. You can't compile it to the JS subset of asm.js.

That's like saying you can't implement python in x86... if it can run code, it can run code.

You were able to do the same without asm.js.

Problem is, it's way too large and way too slow. People aren't doing these things because they simply aren't feasible.

If you could compile Python directly into that asm.js subset of JavaScript, things would be okay. However, emulating a whole CPU and running some Python interpreter on top of that won't be okay. Even if you would magically reach 100% of the regular speed, it just would be way too fat.

V8 is about 100 times (seriously) faster than IE6's JS engine. So, yes, "backward compatible with IE6" doesn't really mean anything.

After executing 5 million statements, IE will ask you if you want to continue. It will ask you many times. You'll probably sit there all day long clicking the whatever button.

When the 'competition' is being advertised as an easy migration path for old software, then "backward compatible with IE6" means everything - it's just another way of measuring how much pain is involved in migrating some software over, only here instead of having to switch your entire corp and customers to Chrome, the change is mostly restricted to the developer toolchain.

You're continuing to perpetuate the notion that asm.js only has implications for high performance software, despite replying to a comment where I gave you a very real use case that has nothing to do with performance. And as I suspect you already know, since you seem knowledgeable, GC can easily be implemented in about a million different ways using an emulated heap on top of a typed array, so yes, even a naive implementation of VB4 could easily be made to work.

It doesn't make IE6 any faster, but the code will still run. I suspect that's what they mean by "backward compatible": it can't work miracles, but will at least do no harm.

"Run". Yes, just ~600 times slower. At that speed it probably won't be very useful. You have ~50 msec for an operation which is perceived as instantaneous. If it takes 30 seconds (600 times as long), people will not use it. It simply isn't feasible.

This stuff is only ES3 compatible because it didn't need anything from ES5. A low-level compiler target doesn't need any of these things: http://kangax.github.com/es5-compat-table/

>if Chrome gets a 6x perf hit

Who said Chrome gets a 6x perf hit?

You just have the numbers with asm.js.

If Chrome hasn't been optimized for asm.js style code, then those numbers would either be what Chrome already achieves with JS (e.g plain old V8 speed), or slightly faster than regular JS (because of the more streamlined, easy to JIT nicely asm code).

You're missing the point. The current optimized-for-normal-javascript Chrome takes a 6x hit on asm.js code, compared to odinmonkey. That's kind-of crappy but it's not a killer, and it could get asmjs support (maybe, who knows). The fear I was talking about was browsers which are already much slower than Chrome , and have no chance in hell of ever getting asmjs support, hence the mention of IE6.