Let’s discuss this Adobe employee’s post about future versions of ActionScript:
The V8 Myth: Why JavaScript is not a Worthy Competitor
As I understand it, he is saying that Falcon (a new version of the AS compiler) will finally include many of the compile-time optimizations that people have been asking for since 2006. Especially, there are a lot of silly, type-related conversions and checks/guards that appear in the bytecode for type annotated ActionScript code, even though you’d expect that they could be enforced statically. Indeed, Avik says that they are working on it: “(3) optimizing code by eliminating dynamic checks wherever they are subsumed by static checks.”
The remarks he made on the speed comparisons he makes between JavaScript and AS3 were a little hard for me to decipher at first, due to the way they’re running benchmarks that originated in JS, and because it’s not immediately clear whether the results are comparing JS to the current version of the ActionScript compiler or a future one.
After reading through the post and the comments a few times, it seems that he’s using Falcon and the public / release version of AVM2 that’s in Flash Player today. This is an important distinction, because there are two separate things being improved upon in the version of AS / the compiler he’s using: 1) type-inference and 2) Falcon’s optimizations.
The type inference portion by itself is essentially taking untyped ActionScript and inferring types to use during compilation (for optimization). For example, it could probably tell you that var s = 'hi' was a string (and do the same for more complicated code).
The part that I found a little misleading without reading closely is that ActionScript with type annotations today is still often slower than JavaScript. This caused some outrage in the comments and from JS+Mozilla people, since, as senocular will tell you “JS is faster. We know it.” I don’t think Avik intended to be misleading; he may have just been so familiar with his own work that he didn’t phrase it properly.
So, while the type inference portion effectively annotates existing AS, you still need the Falcon improvements to see the performance benefits that are being touted in the post. It also means that you may not need to write your own annotations in ActionScript all the time to see those future performance benefits, but you’ll probably have to recompile your code.
So it sounds like language changes are pretty certain, and it also sounds like they are almost entirely focused on games (and preserving backwards compatibility) rather than Flash’s traditional multimedia or web application uses. That last part shouldn’t be too surprising given recent events, but it is weird in the context of comparing JS to AS, since people are still focusing on making web apps and multimedia stuff in JS.
[hr][/hr]
One thing that initially bugged me about the article was his use of the term AOT (ahead of time) when talking about compilation. The common definition of an [w]AOT compiler[/w], is something like this:
This is not what Avik is talking about in his post. There is in fact an AOT compiler for ActionScript bytecode, which is used to compile ActionScript to native code for mobile platforms like iOS. Again, that is not what he is talking about. He’s using AOT as a more general term describing code analysis and optimization that occurs in the ActionScript compiler before it is turned into bytecode.
I think his use of the term that way is fair, but it is not what people usually mean when they talk about AOT. AOT was introduced as a term to distinguish between JIT compiled code and code that compiles to bytecode, but that is compiled to machine code before the code is distributed to different platforms. It’s much like traditional compilation except that there is typically some architectural reason for having the intermediate bytecode step; in the case of Flash Player it’s because SWFs that target the web need to be in platform-independent bytecode to run on multiple CPU architectures, but that’s not the case on iOS AIR apps because you know that you need ARM instructions, and bytecode interpreters are very often not allowed in approved iOS apps.
So, he’s only talking about AOT in the sense that the optimizations happen at compile time instead of at runtime (like JIT). They would occur before the “AOT compilation” step. It may seem like a trivial detail, but imagine being in my shoes as I read the article for the first time and wondered why he was comparing the performance of platform dependent code to JavaScript.
[hr][/hr]
I’m interested in hearing everybody else’s thoughts about the article, too! I’m sure people have something to say about JavaScript speed, or their thoughts on what AS4 should be.
