You may think that you already know the answer the question posed in the headline, but some recent research by Mozilla might surprise you. 

Mozilla has a lot riding on the success of its mobile operating system Firefox OS. As all apps running under Firefox OS use JavaScript and, currently at least, there is no native code facility, it is important that JavaScript is fast. The latest idea is that any application that finds JavaScript too slow should use asm.js - a subset of JavaScript which can be optimized. 

Kannan Vijayan, over on the Mozilla blog, set out to find out how fast  asm.js was compared to Java running on the Dalivik VM and C++  compiled to native code, all running on Android of course. He took some of the components of the SunSpider benchmark:

• binary-trees - access and data manipulation
• 3D-morph - 3D graphics
• partial-sums - math
• fasta - strings
• spectral-norm - math
• nsieve - access and data manipulation
• nbody - access and data manipulation

Each was converted from JavaScript to Java and C++. The Java version was compiled to run under Android Dalvik. The C++ was complied to native ARM code and using emscripten to asm.js. Notice that the asm.js wasn't hand crafted for the test.  

The Java/Dalvik app was run as a standard app on a Nexus 4. The asm.js was run on Firefox Nightly and the native code was run as an NDK app. The programs were run for a number of iterations and the inverse running times were scaled so that the Dalvik program had a score of 1 in all cases. 

The results are interesting:

 The biggest shock is that the Java/Dalvik version does so poorly - remember the bigger the bar the smaller the run time. In the binary trees test the asm.js does better than C++ native code. Vijayan speculates that this is something to do with the way objects are allocated in C++ using malloc compared to asm.js's way of using a typed array as a memory pool.

This seems reasonable. You might say that any good C++ programmer wouldn't write the program so as to create and destroy objects, but notice that the asm.js program wasn't manually optimized either. The blog post puts forward reasons for the  huge advantages that native code and asm.js has over Java in the faster test and for all the behaviors in all the other tests.

The final conclusions drawn are that asm.js is competitive with native code and with Dalvik, which is good news for Firefox OS.

Of course, wherever there are benchmarks there are programmers ready to argue - and it has to be admitted that this is nowhere near a water tight case for asm.js. With some tweaks, no doubt the Dalvik code could be speeded up and the native code too. What is interesting is that asm.js has been generated not from JavaScript but from C++. It is also fairly early days for asm.js and it too could do better - this is an arms race not a finishing line. 

Talking of JavaScript where do you think it would come? 

The answer is:

At this point you might want to conclude that there isn't much point in using anything but good old JavaScript, which is clearly the equal of any of the others. This is, of course, the wrong conclusion. As Vijayan puts it 

The somewhat sad fact is that SunSpider scores have been “benchmarketed” beyond reason. All Javascript engines, including SpiderMonkey, use optimizations like transcendental math caches (a cache for operations such as sine, cosine, tangent, etc.) to improve their SunSpider scores.

Notice that this doesn't invalidate the results for Dalvik, asm.js and native code. Also notice that the asm.js and native code were generated from the same C++ source which makes the comparison much closer.