Got 2,984 running Chrome 38 and 8,778 on Firefox 33, but I think now it's just fair to wait for couple of iterations of Chrome to identify bottlenecks and fix them.
It's not uncommon for benchmarks to focus on some particular strength/weakness that is easily fixable. The same happened with Firefox and Octane 2.0.
I'm not sure if Chrome is ever going to catch up to Firefox here. It's been slower than Firefox at asm.js ever since it was announced, because Chrome doesn't do AOT compilation for it.
EDIT: Although I suppose JIT compilers would love asm.js as it has all the type info they want, but there's probably tons of overhead there thus explaining how Chrome has worse results.
Chrome is currently slower, but the v8 team is working on a new optimizing compiler called TurboFan. There are indications in the source code that it detects asm.js code as a compiler hint of some form, hopefully this means it will eventually get quite fast on that type of content.
I don't really understand how asm.js is any different...
you've still got applications compiled into binary blob, the difference between NaCl and asm.js being that asm.js just happens to be binary encoded as executable JavaScript.
It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago. It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.
When Dart was introduced years ago, Brendan Eich was all over HN complaining about how Dart2JS doesn't solve the problem, because DartVM would be more performance, and introduce a tendency to optimize JS VMs towards those semantics. Well, here we have a different problem. If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.
Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.
Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.
Imagine I took the Java language, removed "new" and forced all code to allocate DirectBuffers, and then said, all classes must consist of static final methods (no polymorphism), and can't have any fields or constructors.
Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.
Arguably, you can say the same thing about Android 4.4/5.0 "ART" runtime, or GWT which I work on. They use the Java "language", but the runtime behavior is completely different, and at least for GWT, we make no bones about this.
So, this is not an attack on asmjs, but I do think there is a distinction between "reusing the syntax" of a language, and creating expectations of new semantics. Languages carry with them implicit sets of runtime performance characteristics, even bugs, that developers tend to treat holistically.
Not many people care about what the specs say. They care about how it runs in the real world.
> It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago.
It's not readable, nicely-formatted JS, sure, but neither is the optimised, minified JS most sites served. It is, however, valid JavaScript. It uses open standards (ECMAScript, the various web APIs). It's already supported by all browsers.
> It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.
It's not "special behaviour". It's a performance optimisation. It still behaves exactly like JavaScript.
> If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.
I don't see why people would write Web apps by transpiling C code, the main advantage is for the existing codebases written in C. And other vendors don't necessarily need to implement asm.js with AOT compilation. asm.js-conformant code works well very with JIT compilers.
> Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.
No, it has identical execution semantics. It uses a static subset of JS, yes, but it's still JavaScript. If I remove the "use asm" pragma, the code still does exactly the same thing.
> Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.
Is that bad? Bear in mind that, without asm.js existing, this was the case anyway. asm.js wasn't created so that people could compile native code to run in the browser. It was created because people were already doing so, and by detecting the code patterns commonly used by compilers, they could make it run faster.
> Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.
Sure, you made a new standard. It's a backwards-compatible one that doesn't rupture the ecosystem, though.
I got 2,996 in Firefox and 1,277 in Chrome (2013 MacBook Air 13").
Interestingly, Chrome had much worse performance for float32 than float64... yet Firefox had slightly better performance. I guess the Chrome team implemented Math.fround yet none of the optimisations which make it useful!
http://kripken.github.io/Massive/