Posts tagged "JavaScript"

The V8 Myth: Why JavaScript is not a Worthy Competitor

Disclaimer: The following opinion is personal; it does not in any way reflect the opinion of Adobe.

UPDATE (01/18/2012): There have been some misunderstandings around the purpose of this post. The purpose is not to undermine JavaScript; it is to simply point out why ActionScript can do better given the compilation/execution model it inherently has.

UPDATE (01/18/2012): Some benchmark numbers posted below. More to come.

If you found yourself gaping in shocking disbelief at the premise in the title of this post, congratulations! You are the target audience for this post.

JavaScript programs are untyped, (relatively) small programs that are shipped/loaded as source code, and then compiled and run on the fly. In contrast, ActionScript programs are typed, (relatively) large programs that are compiled to byte code, shipped/loaded as byte code, and then run on the fly.

There is something inherently wrong in an argument that is based on the claim that JavaScript can do all its heavy-lifting work post-load time, and still do as good as, if not better than, a language that has the opportunity to do much of that heavy-lifting work pre-load time. What is wrong in such an argument is the reverence of, the dependence on, and the submission to, magic. Unfortunately, sooner or later, we all get to hear that Santa does not exist: the question is, can we grow up sooner?

Dynamic analysis is a great complement to static analysis: unfortunately, it is not a replacement. An ActionScript program that has been optimized to death by an AOT compiler can, almost trivially, beat a JavaScript program that is optimized on the fly by the JIT compiler. The only way out would be to let the JIT compiler work till death, but that is not an option! Checkmate.

So yes, you will hear about all the great things in V8 (JavaScript VM), including type inference. The fact is, there is no way a JIT compiler can afford to do the kind of modular analysis that an algorithm implemented in an AOT compiler can. To prove this unbelievably obnoxious claim, I compared the performance of the untyped JavaScript benchmarks in the Tamarin (ActionScript VM) performance suite, by passing them through, on the one hand, V8, and on the other hand, the type inference algorithm we recently prototyped in Falcon (ActionScript compiler), followed by Tamarin.

The ActionScript toolchain beat the JavaScript toolchain by around 3x.

(Note that a side-to-side comparison was never possible before we implemented type inference in Falcon; effectively, we regenerated the fully typed versions of the untyped JavaScript benchmarks automatically, and let the performance benefits enjoyed by typed ActionScript programs carry over to untyped ActionScript programs.)

So, let us stop worrying about JavaScript, and aim higher. As we focus on gaming, ActionScript programs will require significantly better optimizations for performance. ActionScript has just the right DNA mix for success, and it will become the 21st century language it could always be.

Sample numbers for Tamarin’s test/performance/jsbench benchmarks (running time in seconds for maximum datasizes in each case): 

  • SOR: 23.1 (V8), 4.6 (Falcon + type inference + AVM)
  • LUFact: 138.7 (V8),  23.3 (Falcon + type inference + AVM)
  • HeapSort: 10.0 (V8),  14.7 (Falcon + type inference + AVM)
  • FFT: 75.6 (V8),  31.1 (Falcon + type inference + AVM)
  • Crypt: 25.1 (V8),  7.4 (Falcon + type inference + AVM)