Vivisecting Media

Imeem.com: Stream it now…

Hi, my name is James and I am a Google Reader addict. My old boss jokes that I spend 90% of my time in front of reader, he is probably not that far off. Before the holidays I was reading a post on Listening Post talking about Imeem’s Music Blog 2007 playlists. So here is the deal, Imeem is a community music site that allows you to listen to streamed music via a Flash player interface. You can build playlists, rate music, comment music, etc. What is amazing about Imeem is that there is a ton of music that you can listen to.

The 2007 playlist is just an example of how much content is currently available. What Imeem has done is taken Music Blog’s 2007 playlist, you know the ones where the blog picks their top 10, 15, 20, 100 songs. The issue is that most of these blogs just post the titles and you can not hear how it sounds. With Imeem’s library they have created playlists that allow for you to listen to the music. I am really impressed with what they have done so far and I plan to dig a lot deeper into the community aspect to see how the music uploading works and how the review system is tied together.

Update to Part 3 and Part 4 of Flash Internals…

Rick Reitmaier, Senior Computer Scientist at Adobe, took a few minutes of his time to review my writeup on the JIT engine within the Flash/Tamarin VM. Rick was part of the team that helped design and build the AVM+. I got to know Rick back when I worked on the Flex Builder team and I would like to thank him for his input. I am providing his comments in this post and linking back to the sections he was referring to. I have indented my writing and all first person references from here on out are the comments directly from Rick.

Rick’s comments to Part Three: The ActionScript Virtual Machine

“AVM+ is due to the radically different design, there was no way it could be backward compatible”

Also regarding file size increase, I’d say you’ll want to look at the file size of fp8 and fp9 and see that its not too bad; ‘dramatically’ in my mind means orders of magnitude.

Strictly speaking we are somewhat compliant with a draft of the ECMAScript spec, the spec has not been finalized as you correctly point out in a later paragraph.

Rick’s Comments on Part Four: Just-in-time (JIT) compilation

“Typically, the AS3 byte code is handed one by one to the VM which then leverages the specific platforms interpreter (aka Flash Player) to compile the passed data to the proper machine code. Byte Code is optimized for performance, but you still have to compile each one at a time as they are passed into the interpreter. This becomes a performance bottleneck if your code makes a call to a previously referred Byte Code (ala function). If this is the case (and it happens ALL the time) the same Byte Code has to be e-complied when it is queued up. Not exactly fast nor efficient.”

while(1) {
switch(ip) {
    case PUSH:
    // code that pushes something on the stack


case POP:
// code that pops something from the stack


}
ip = ip + 1;  // move on to next bytecode.
}

Also regarding MIR. Our unit of compilation is a method. So, the bytecodes for an entire method are transformed into MIR and its easier to think of MIR as just a slightly more verbose version of the bytecode, not as some fundamentally different data structure.

Thank you again Rick for you candid and insightful update!

Blocked from my own blog…

Its been awhile since my last post. Work has been keeping me on my toes and for the last month I have been spending all my time developing Functional and Technical Specifications. All that writing was getting to me and the thought of writing more on the blog pushed me over. Well, I am finally back to coding again so I am going to try and get back into the blog. That’s when I found out about the little Bad Behavior update.

I tried to log into my blog to start writing and I was informed that my IP was blacklisted for spam / malware. That really, really worried me since I am on OS X. After reading the full page it said I should have a blacklist reason and if I don’t to check the Bad Behavior site. I didn’t have a blacklist reason and after reading about the new update it was clear that it was on their end not mine. All I had to do was update my version of Bad Behavior and it was all good. Woot… I was scared there for a moment. BB is a great tool so I easily forgave the mistake and all is well.

Flash Internals: Just-in-time (JIT) compilation (part four)

During the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

Read Part One: Motto’s and Percentages. Read Part Two: Byte Code, Control Tags, Renderers… oh my! Read Part Three: The ActionScript Virtual Machine

Update: Rick Reitmaier (Sr. Scientist at Adobe) has provided some feedback on this article.

A Word Of Caution

One of the topics that keeps coming up when people talk about the new Flash Player is that is provides Just In Time (JIT) compilation. So what does this mean and how does it work? That, my friends, is the big one. What I am about to do is take a single paragraph of notes, taken from a single slide at the presentation and try to decipher what was said into something semi-understandable (at least to me). I make no promises, but since the presentation I have done a bit of research on this topic and I feel like I am starting to make sense of it all. If you have questions or see issues with my analysis, please feel free to post comments (I want to try them out!) . Okay, here we go…

What Is This JIT?!

The concept of JIT’ing code is to take byte code, compile it into the supported machine language for the proper chipset and enable reuse. Wha? Yeah, that is what I thought when I first read into it. Before I jump whole hog into this, let me take a split second to go over (or refresh) your knowledge on machine code.

Machine code is the compiled code that can be run directly by the CPU. When we compile an application using a language like C++ we are take our code and compile it down to a set of machine code instructions that can be passed to the CPU. The benefits of compiling an application is that it is in the machine code form when it gets delivered to the user. This complied version is built only for the specific OS/hardware match you are delivering it to and it runs very, very fast. The downside is that if you want to take your app from OS X to Linux you need to recompile your application for the new OS/hardware and then give the Linux user that version (this example ignores any OS specific code of course).

This is where interpreted languages come in to play. The benefit of interpreted languages is that you can take your code raw (uncompilable) and in-essence compile it line by line in real time. This means that you only have to write and compile your code once. From there you can run your code on any OS/Hardware that has a supported interpreter. This is where the Java slogan Compile Once, Run Anywhere starts to shine.

The Flash Player is really just an interpreter, but instead of line by line compiling by the interpreter we pre-compile the code into Byte Codes and then pass these Byte Codes to the interpreter. Typically, the AS3 byte code is handed one by one to the VM which then leverages the specific platforms interpreter (aka Flash Player) to compile the passed data to the proper machine code. Byte Code is optimized for performance, but you still have to compile each one at a time as they are passed into the interpreter. This becomes a performance bottleneck if your code makes a call to a previously referred Byte Code (ala function). If this is the case (and it happens ALL the time) the same Byte Code has to be re-complied when it is queued up. Not exactly fast nor efficient.

So now we get to just-in-time. JIT is the idea that we take the commonly used Byte Codes, compile them once and then store the compiled version in memory. When the Byte Code is required again the complied code is pulled from memory and handed to the CPU, allowing the Player to skip the compile step and therefore massively increasing the applications execution speed.

The Flash Player 9’s JIT engine is a two pass system. The first pass uses the Macromedia Intermediate Representation (MIR) process to generate a map-like data structure of the code. The MIR map is sorta like a flow chart that diagrams the code. This MIR allows for the JIT engine to then analyze and begin optimizing the code before the second pass creates the machine code. Once the MIR is generated there are few types of optimizations that also are applied during the first pass of the JIT engine:

• Early Binding From what I can determine this means that the JIT itself types the values of the references at the start of th JIT vs. late binding the types when the value is actually in hand. This is a tough one to verify since so little is out there as of now but a comment by Edwin Smith (inventor of Tamarin) kind of led me to this conclusion. One thing to note, is for this optimization to occur you need to type your AS3 code. You will constantly hear people say that typing your code increases performance, and it makes a lot more sense due to early binding.
• Constant Folding This is the process of finding values that never change, such as constants, integer values and calculations that only occur once. The JIT engine then replaces the calculated values in the MIR vs. having references to the method or instance. A little more info on constant folding.
• Copy and Constant Propagation This ties into Constant Folding by providing the service that looks up the constant and replacing the calculated values, but it doesn’t stop there. This process also looks to simplify conditional branches by determining the outcome and if it always returns in a specific way. If so then it is replaced with the result versus leaving in the conditional calculation. Here are examples of how constant propagation works.
• Common Sub-Expression Elimination (CSE) This is the process that finds calculations that are used in multiple places and determines if it makes sense to replace the calculation with a variable that holds the calculated value. By doing this it can greatly simplify how much data has to be calculated. Here are a few examples how how Common Sub-Expression Elimination can optimize calculations.

Once the MIR is completed and optimized, the second pass begins. During this pass the native machine code for the OS/Hardware is generated and the instruction selection algorithm is run upon the MIR to generate the most optimal instruction set. The goal of the instruction selection algorithm is to generate the least amount of code possible but at the same time covering all the required functionality. By limiting the code this requires less processing time for the CPU. Next up is the Register Allocation where the JIT attempts to manage the CPU registers (or slots) in the most optimal way. Lee mentioned that the JIT uses a linear scan algorithm to find the stalest register and uses that for the next slot. This algorithm greatly decreases the processing time for by providing a much simpler calculation versus the typical computational heavy Register Allocation process.

Finally (and this is in no real order) Dead Code Elimination (DCE) is applied. This is the process of hunting down unreachable or un-executable code and removing it from the instruction set. This helps reduce the overall size of the instruction set and making it perform quicker by reducing the amount of data. If you feel like it, read up on the theory of DCE.

Wrap this JIT up, dar’nab it!

Once this is all completed you have a nice set of clean machine code to run. As you can tell this is not a trivial process and to apply this to everything could potentially take more time then just compiling the byte code directly in the classic interpreter fashion. Yet when done correctly you can see a massive performance increase for your code. Oh, and one little thing Lee mention… this is the first JIT with a dynamic enabled language.

So there you go, a semi-in-depth look at the world of JIT in Flash Player 9. This has actually been a ton of fun to write since I had to look up 90% of this on the web before I attempted to get my thoughts down. I finally feel like I understand the concepts behind JIT and hopefully you do too after reading this!

Trying out Disqus for comments…

A while back I was having an email kvetch session with Jack Herrington about Flex String formating and during the thread he asked if I read Uncov. At the time I did not, now I am an avid fan (also the blog pics are redonkulus). Uncov is pretty much a blog dedicated to the world of Web 2.0 and when appropriate points out that the Emperor is butt ass naked. Usually, the pointing out is more the norm then not, but today’s Uncov post talked highly about a new Web 2.0 service called Disqus.

Disqus is a conversation / comment service for your blog that is all Web 2.0′d out using JS vodoo. Okay, its not really vodoo but my Ajax Kung Fu sucks compared to the people I work with so its all black magic to me. Black Magic that uses $ a lot… I mean ALOT. What the fuck, is it some Web 2.0 comment, like “my code is ChaChing!! Money baby!!!” Anyhoo, I took a look at the service and I am trying it out. Install was stupid simple and now I have threaded comments that can link back to a main forum page. They provide a slick admin system and they also have spam filtering. Oooh… new toys. So for the eight of you that read this blog, try it out if you have sum’thn to say.

Flash Internals: The ActionScript Virtual Machine (part three)

During the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

Read Part One: Motto’s and Percentages. Read Part Two: Byte Code, Control Tags, Renderers… oh my!

Size Was King

Prior to Flash Player 9, one of the complaints from the Flash development community was the overall performance of the ActionScript language. Performance not only for animation but also for manipulation of large data sets. This issue was most apparent with Flex 1 and 1.5, which were developed on ActionScript 2. The challenge the Player team was facing with ActionScript was that the ActionScript Virtual Machine (AVM) had reached its performance limit.

Until Flash Player 9, size was always the most important factor for the development team. These were the days when modems still ruled the earth and ATM to the door was a fantasy dream utopia. To help facilitate adoption, the Flash Player had to be small and compact so that users wouldn’t flinch when it was time to install or upgrade. During my stint at the company, I remember hearing of huge battles for just adding 10k to the player size.

With Flash Player 9, the landscape had changed a lot. High Speed Internet was more of a reality and therefore size became less of the driving factor and more of an desirable goal. Performance was now the new king. At the time, Macromedia decided to start the process from moving the Flash Player from a plugin and into the realm of a platform. In our planning meetings we started to talk about the Flash Platform and what it could achieve. To make this a reality the player had to speed up and handle large data sets with grace and ease. With this goal; in stepped AVM+.

My Two AVMs

AVM+ was the new ActionScript Virtual Machine. It was designed from the ground up for screaming performance. The goal was an overall 10x performance increase, which was a really serious task for the Player team. Not only was AVM+ about speed but it also opened the doors for new features such as Just In Time (JIT) compiling, cleaning up the existing and often confusing API set, updating the ActionScript language to a first class citizen and finally exposing granular control over how content is accessed and managed.

One of the drawbacks with AVM+ is due to the radically different design, there was no way it could be backward compatible. This meant that if the Player only had AVM+ then the team would not be honoring their motto of “Don’t break the web.”. To resolve this, Flash Player 9 contains AVM-, or the original AVM from Flash Player 8 (plus some fixes). Having two AVMs does a few things that are not beneficial:

1. Dramatically increases the file size of the Flash Player.
2. Means that mixed code, such as SWFs that use AS3 and SWFs that use AS2 in the same application, are not able to directly talk to each other because the code is being run in different sandboxed AVMs

What did we get?

AVM+ created support for ActionScript 3, the first implementation of the ECMA 4 Spec. ECMA is the standard that JavaScript is based on and ECMA 4 is the basis for the new JavaScript 2. Right now there is a tremendous amount of fighting going on about ECMA 4, JS 2 and Browser support. The Ajax community is all aflutter right now but one of the benefits is that when JS 2 is finally approved and in the wild, AS3 developers will have a good leg up on the language and its structure.

At the release of Flash Player 9, ECMA 4 was still very much in draft form and meant that the Player team had to solve language issues without the guidence or approval of the ECMA board. The issue with this is that when the language format is finalized new syntax will need to be added to ActionScript. My guess is that AS4 is not that far away… mmm “let is the new var”.

As an old school Flash developer, one of the coolest additions to the AVM+ is the ability to directly access and manipulate the display list. In previous versions of Flash if we wanted to dynamically add content we need to either load it into a MovieClip using the old attachMovie(), or create an empty MovieClip to shove things into. Now that the display list is accessible developers can spawn new instances of objects and attach them directly to the display list. The display list is a tree based on a parent/child hierarchy that enables branches to be moved around while maintaing their structures. This is great for when you want to build a specific layout, pop it off of one part of the display list and then add it somewhere else. Again, this is a deep topic that I may write a whole article about.

Debugging an application has become a lot easier with AVM+ because a robust Exception handling system has been put into place. This is great for building apps because its now possible to catch the exception or see the full call stack when the exception is thrown. One of the challenges with exception handling is that if you don’t catch the error and your user is running a debug player then they will see the exception. Right now uncaught exceptions are a big problem with Flex apps.

AVM+ now supports Loading classes, which may not seem a big deal but it offers a lot of flexibility. In the previous players, when you loaded content the item that was loading the content was removed and replaced by the loaded content. Now a loader class can be used to pull in assets and then either displayed via the loader or the content can be referenced and used elsewhere. This also means that if the data is graphical (PNG, GIF, JPEG, Video, etc.) and coming from a crossdomain supported location you can use the bitmap clone() feature and then clone Bitmaps from a single loaded item and use it in multiple places. This is pretty powerful stuff if used correctly.

Finally, for this post at least, we come to the open source aspect of the AVM. Adobe did a very interesting, and personally brilliant, move. They open sourced the AVM+ to the Mozilla foundation. As I mentioned earlier, the AVM+ is for ActionScript 3 which is an ECMA 4 language, just the same as JavaScript 2. Mozilla is now using AVM+ aka “Tamarin” as their core VM for JavaScript 2. As Tamarin is updated by Mozilla, Adobe pulls in the new build of the VM and uses it in the Flash Player. If Adobe makes a fix to the VM, they submit it back to Mozilla. This helps keep the languages (ActionScript and JavaScript) in sync with the ECMA standard and opens the door so developers can truly see what is going on under the VM hood.

Enough for now… next time I will dig into the world of JIT and Garbage Collection.

Update: Read Part Four: Just-in-time (JIT) compilation

gMail + Thunderbird: How long will I last?

About a year ago I jumped feet first into the world of gMail and ported over all my Fake Science accounts so that they forwarded to gMail. Once I had the ability to send emails from gMail that looked like I was sending them from my many FS accounts life became a beautiful thing. The main driving force for me to port everthing to gMail was that I started consulting as a Flex Interactive Architect and I no longer found myself on just two machines (home/work). Email access for FS was crucial because I was handling all our Customer Service issues and that is always time sensative. Its also helpful when you find out your boxes are down or some other crap that stops your site from working a-okay.

Recently, the internet has been all abuzz about gMail’s new IMAP integration. It was conceptually interesting to me but I had yet to commit to trying it out. Today, I decided to experiment with the system and see if I prefer using Thunderbird as my mail client or gMail’s web interface. There actually is another reason I have jumped onto the bandwagon: gTalk.

One of the issues that I have had with gTalk is that its a Jabber client and a company I work for has a very strict firewall which blocks all the Jabber ports. That meant the only way I could communicate with my friends who use gTalk (mainly my girlfriend) I had to use the web client. It was never ideal because I always ended up closing the gMail window/tab. Often I had to restart the browser because Firefox is a memory hog, or I was testing code, or I crashed the browser due to some bug in my code, or totally by mistake (which always pissed me off).

Over the last year I have gotten really good at not closing the window/tab but I still don’t like the workflow. Now that I am working at home four days a week the Jabber port issue went away and I finally got around to installing Adium. Since gTalk is now in its own IM client and I don’t have to use the web interface, I may as well hack at Thunderbird.

Thanks to this brilliant article over at Lifehacker on setting up Thunderbird it appears to be working great. One of the benefits I am looking forward to is the ability to have nested folder/labels. Yeah, I know I can run greasemonkey scripts to create a folder hierarchy for my labels but it never felt right for some reason. This parent child relationship is very important now that I have multiple clients. This allows me to create a logical organization structure so that it is much easier to track who is doing what, etc.

So far I like it… but its only day one. I will see if I learn to hate or love this set up in the coming weeks.

Flash Internals: Byte Code, Control Tags, Renderers… oh my! (part two)

During the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

Read Part One: Motto’s and Percentages.

Byte’ing the Hand That Feeds

When an application is compiled from a FLA or mxmlc the generated SWF file has two main components that control how the application behaves: Byte Code and Control Tags. The Byte Code is the generated ActionScript. Control Tags are currently only produced from Flash Authoring.

The generated Byte Codes are loaded into the Player via the SWF and are sent to the Flash Player ActionScript Virtual Machine (AVM) for processing. The AVM processes the Byte Codes and then manipulates the current Display List based on the commands within the code. The Display List is a tree based structure that represents an asset hierarchy within the SWF. These assets are MovieClips (Sprites / Components), Audio elements, Video elements, etc. The assets are added, updated and removed from display list by the AVM. In the following example, the code is compiled down into a Byte Code set that at run time informs the AVM to create a new Button and then add it to the display list.

var myButton:Button = new Button();
Application.application.addChild(myButton);

Control Tags skip the Byte Code and AVM step and directly access the Display List. Control Tags were briefly mentioned but from what I recall when I worked at Macromedia/Adobe, the timeline’s keyframes are compiled into Control Tags and when processed by the Player they update the stack according to how the keyframe interaction was defined.

Render Me This

There are two types of renderer’s in the Flash Player, immediate and retained. The vector engine that Flash is famous for is a retained renderer. The example that was used was that we request two boxes to be drawn in the same render pass (or frame): a red rectangle and a black rectangle. The black rectangle is 40px by 40px, is located at 10,10 on the stage and is requested first. The red rectangle is 200px by 200px, is located at 0,0 and is drawn second.

The retained renderer is a smart rendering system and sees that the black rectangle is covered by the red rectangle and therefore the rendering system skips drawing the black rectangle. This process helps memory usage and other system gains but it is a more time consuming process because all the drawing requests have to be made before the render pass is completed.

As I mentioned earlier, there are two renderer’s in the player. The second renderer is the Bitmap renderer which is an immediate render and happens off stage. This means that as data is requested to be drawn in the Bitmap renderer buffer, the update is done at the time of the request. This makes Bitmap rendering much, much faster and is one reason why changing animations and other assets to bitmaps can offer an increased performance gain. For more information about Bitmap Caching performance check out Guy Watson’s “Using Bitmap Caching in Flash”.

I was going to delve into the AVM deeper in this post, but looking at what I have to talk about I am going to save that for part three!

Update: Read Part Three: The ActionScript Virtual Machine
Read Part Four: Just-in-time (JIT) compilation

AS3 Performance: For Loops

A while back I was reading an article on Ajaxian (I can’t remember who wrote it) but it was talking about JavaScript performance tips. One of them was around writing blazing fast For loops and for some reason it really stuck in my head. The trick the author recommended was that when running a For loop don’t use a method in the loop test expression but use a scalar value. The idea is that if you are making a method call, such as length(), in the test expression this takes more processing time to calculate the method then just applying the scalar value.

If you followed me, bravo, if not… here is an example that will make a lot more sense. Let’s say that you want to loop over an Array. The typical For loop looks like this (note: the syntax highlighter is ignoring the < and replacing it with the HTML character):

var myArray:Array = new Array();
... // populate the array
for(var i:uint; i < myArray.length; i++)
{
	... // do something
}

Pretty standard stuff. The issue with this method is that every time we enter the loop we call myArray.length to validate if we should run the code or end the loop. This means that a get method is being called to validate the Array length and then return it. By adding one line of code we can remove this call and see better performance:

var myArray:Array = new Array();
... // populate the array
var len:int = myArray.length;
for(var i:uint = 0; i < len; i++)
{
	... // do something
}

I wrote a test Flex app that demos both versions and using 100,000 loops (yeah, super brute force I know). I saw a significate performance increase. The first method took 24ms the second method took 13ms. So the next thing I did was change the Array to an ArrayCollection because this is more of a typical use case. More and more applications are pulling in large data sets and every ms counts. With an ArrayCollection the first method took 577 ms vs. 424 ms.

Its amazing to me that an extra line of code can help this much but at the same time it makes a lot of sense. I have uploaded the MXML file so that you all can play with it… so enjoy!

Speedtest.mxml [download]

Flash Player Internals: Motto’s and Percentages (part one)

During the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

You break it you buy it

First off, Jim and Lee dropped the Flash Player motto on us: “No breaking the web”. This is a really important concept for developers as they evolve apps over time. As a lot of oldschool Flash devs know there are a lot of hacks we used to take advantage of. Accessing objects via hidden flags so we can get to the data that we really need. The issue is that some of these hacks were bugs in the player that we used to our advantage. What happens when the Flash Player team finds and then fixes the bug we built upon?

For example, we built our SWF in Flash 6 and used a hack to make our application work. In Flash 7 they fix the bug/hack. This would mean that if our SWF was run in Flash Player 7 the app would break… and this violates the Flash Player teams motto.

So, what they have done is made a kind of progressive fallback sandbox. If it worked in Flash Player 6 and your movie was made for Flash Player 6 then your SWF will be run in the FP6 version of the sandbox and your hack will work. If the developer wants to leverage the fix in Flash Player 7, then the SWF needs to be recompiled for that version.

This ability goes all the way back to the first Flash version. I am making the assumption this is based on major releases and not dot releases. I also assume that this is only for hacks that are not considered a security risk. I really wish I had a chance to ask about that… but my brain was full by the time the session was done.

How deep is deep?

One of the questions clients almost always ask is: “How deep is the Flash Player x.x penetration?”. If you go to the Adobe website you will see that Flash Player 9 has 93.3% of the mature market (as of Sept. 2007). Okay, but the trick is what about the .x? Does 9.0.47 really have 93.3%? When “Moviestar” (the newest player dot release code name) rolls out when will it have the full share of the pie? Jim and Lee dropped some great estimation numbers on us. These are based on the percentage of adoption from the release date of the new dot release (or player too).

@3 months = 30 – 40% @6 months = 55 – 65 @9 months = 80 – 85% @12 months = 90+%

What it gets down to is that if you need the newest dot release you need to consider the penetration estimates just like you would with a new full version update. For a great breakdown of how this works check out Emmy Huang’s blog about the topic (where I re-poached the values since I couldn’t type fast enough to get them all).

Okay, so that’s post one and I just scratched the surface… next up will be Byte Code, Control Tags, AVMs… oh my!

Update: Read Part Two: Byte Code, Control Tags, Renderers… oh my! Read Part Three: The ActionScript Virtual Machine Read Part Four: Just-in-time (JIT) compilation