# Understanding Avik Chaudhuri's post about future ActionScript (4?)

**URL:** <https://forum.kirupa.com/t/understanding-avik-chaudhuris-post-about-future-actionscript-4/326886>\
**Category:** flash\
**Created:** [January 19, 2012, 6:15am UTC](https://forum.kirupa.com/t/understanding-avik-chaudhuris-post-about-future-actionscript-4/326886 "2012-01-19T06:15:09Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![krilnon](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/krilnon/32/34_2.png) [@krilnon](https://forum.kirupa.com/u/krilnon)\
**Post date:** [January 19, 2012, 6:15am UTC](https://forum.kirupa.com/t/understanding-avik-chaudhuris-post-about-future-actionscript-4/326886/1 "2012-01-19T06:15:09Z")

</div>

Let’s discuss this Adobe employee’s post about future versions of ActionScript:

[The V8 Myth: Why JavaScript is not a Worthy Competitor](http://blogs.adobe.com/avikchaudhuri/2012/01/17/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](http://www.cs.umd.edu/~avik/) that they are working on it: “(3) optimizing code by eliminating dynamic checks wherever they are subsumed by static checks.”

> [@Avik Chaudhuri](#):
>
> The funny thing is, AS has had optional types for a long time. We can exploit that advantage better than we currently do.
> 
> […]
> 
> There is a lot of low-hanging fruit to be had by optimizing the VM, to start with. This does not even include advantages that language improvements promise bring in.
> 
> […]
> 
> ActionScript has a mix of static and dynamic typing that is very well-suited for writing games: write the game logic in a high-level scripting language, and all the performance-sensitive number crunching in statically typed code. We are working on further language features that routinely appear in modern languages and that will make the suitability even more obvious.

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](http://www.kirupa.com/forum/showthread.php?370154-Swiffy-anyone) “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.

> [@Avik Chaudhuri](#):
>
> While JavaScript keeps improving, do not expect ActionScript to remain stagnant. And there is no reason why AAA games cannot be written in a (admittedly much advanced) future version of ActionScript. Languages keep evolving, and we are already seeing C++ ports of AAA games through Alchemy

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:

> [@Wikipedia](#):
>
> An ahead-of-time (AOT) compiler is a compiler that implements ahead-of-time compilation. This refers to the act of compiling an intermediate language, such as [ActionScript bytecode], into a system-dependent binary.

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.