Adobe Alchemy, is it ActionScript heresy ?

Take your time, this is a lengthy post. Before I jump in the matter, I want to go back a bit.

The magic of C64 Assembler

One of my first experiences with computer programming was on the C64. My dad bought my uncles C64…… Of course we played games at first, but at some point I started to look at all the books that my uncle had gaven with it. One of the first books I opened up and started playing with was called “Basic for Beginners”. I remember thinking, wow, so this is how you make games ? I started playing with existing programs and later on began writing my own, such brilliant programs as “My cassette collection” and “Adding Numbers”. But what I really wanted was to write my own games.

How come my C64 basic programs where always so slow ? Surely, there must be something I was doing wrong. With nobody around to teach me, or tell me anything about this machine, I dived in the pile of books that came with the computer once again. Two books took my interest. “C64 Programmers Reference Guide” and a home printed & binded book that had written on it “C64 Kernel listing”. I had two problems with these, being 1, my ability to read english and understanding the magic listings this book had. It took me a long, long time to grasp what these books where saying, but these 2 books, together with a dutch book on C64 programming, I slowly learned how to do 6510 assembly language for the C64.

This was the realm of pure magic. All of a sudden things went a lot faster. Moving a sprite along the screen could be done fast and smooth. But things where a lot more complicated. 6510 (or actually 6502, for the purists) asm, although especially now a days, quite simple, isn’t exactly humanly readable, nor was it clear to me how to structure full programs or games. I learned how to do a lot of tricks, like getting more then the 8 hardware supported sprites on screen at the same time (something then called multiplexing), playing sound while still having being able to do other things at the same time, getting sine waving color bars on screen and screen border, but I never managed to build a full game. What I learned about that was that interpreted basic was a lot slower then assembler and if you wanted to get real speed you’d have to target the platforms native code. Assembler wasn’t magic, it was just a better way to target the platform.

Back to current day.
I’ve been working with Flash for almost 9 years now. I dare to say I know quite a lot of Flash as a platform, and have been doing many projects and experimentation with it. Last year at MAX, when FlaCC or now, Alchemy was shown it looked like pure magic! Sure, I understood the basic principles, but running Quake in the Flash VM was nothing short of magic. Running Quake within the Flash VM using a port of the C code was quite an achievement, but the speed was more incredible. This was nothing short of pure magic, like turning lead into gold!

It’s an ironic name Adobe chose for FlaCC. Let’s look at the word and dabble into the occult. There’s a clear distinction between alchemy and science. Alchemy is most known for trying to create noble metals from otherwise less-valuable materials. Even Sir. Isaac Newton spent a lot of time in the field, surprisingly, even more time then he spent working on subjects such as optics and physics, for which he is most known. In a way, Alchemy is the forerunner for what now is chemistry. From the occult to exact sciences. So, with that name, is Adobe suggesting Alchemy is pure magic ? Turning lead into gold ?

Is it witchcraft ?
After the initial amazement I had with seeing Quake run within Flash, I started to question some things and started asking around with people who might know more of this witchcraft. Was this really Flash Player 9 running this ? From multiple sources I heard it was a slightly modified version of the Flash Player 9. Something to do with reserving a block of memory. Later on, after finding Scott Petersen his LLVM session on this subject, this was confirmed. In this session, Scott also shows an emulator running on top of the Flash VM. Having some experience in the FC64 (a commodore 64 emulator for flash) project, again, the speed was pure magic.

What I ended up finding most interesting about Alchemy, wasn’t the ability to take C code and compile it to Flash (although that’s an incredible achievement on itself), but the pure raw speed it seemed to harness. And with that, I also got a bit disappointed in Flash. It boils down to this.

The first magic bullet in Flash speed came in the form of the ActionScript Virtual Machine 2. With JIT compilation of ActionScriptByte code the platform just became a whole lot faster. With the coming of the AVM2, lot’s of things have changed. For me personally, one of the displays of the game changer was Papervision3D, in which I got involved quite early on. John Grden’s early demo using Papervision3D running on AS3 was an incredible testament to the speed of the AVM2. Now, that demo was built using ActionScript 3 as the language to be compiled down to ABC. ActionScript 3 is the language which was intended to run on top of this platform and one might thus derive that the language and it’s compiler is most optimized for the AVM2. So logically, one might asses that the best way to write code for the AVM2 is using ActionScript.

Heresy I say! Heresy! Burn the witch!
Alchemy is proof that this is not the case. Here’s a bit of pure heresy in the Adobe church : Alchemy is a testament to the underachievement of the ActionScript compiler. Ouch. Surely, this can’t be the case, right ? Well, yes and no.

Let’s start with the “no” part. That reference of a modified player running Quake was partially true. This was an early demo of Flash 10, in a way. As Nicolas Canasse points out in this blog post about Alchemy virtual memory opcodes, it seems like Alchemy is cheating a bit. Cheating ? While, yes. This part of the API is not available from within ActionScript itself. So, the platform (AVM2) now has features which are not supported by the language which is native to it ? Wow. I find this a very significant move by Adobe. Moving to a more flexible compiler makes total sense, but is this the first symptom caused by the EcmaScript4 draft debacle ?

To achieve the speed as displayed by Alchemy, I have thus have to move to using C code, or HaXe to compile for the AVM ? This is odd, to say the least. Nicolas his work on HaXe is nothing less then brilliant. The features this compiler has are those which would greatly help the development of a 3D engine, such as Papervision3D. I’ve always had a great deal of interest of porting Papervision3D to HaXe, purely to be able to implement things like inlining easily, which will safe us function calls and thus speed up the process of rendering 3D to the screen. The downside to that is, that the code base would have to change to HaXe, and thus become incompatible with the compilers of Flash and Flex. We (Papervision3D) could provide with a SWC built with HaXe, but in a way, I’m still a bit weary of that.

Now we come to the yes part, of my earlier “yes and no”. Next to the virtual memory opcodes that are currently unsupported from within the AS3 language, Branden Hall states something very disturbing on his blog about Alchemy, “Understanding Adobe Alchemy“.

“In fact, because LLVM does a lot of optimizations, whereas Flash and Flex have no optimization step built into their compilers, Alchemy code manages to overcome a lot of it is overhead just on its own.”

Ok, that is down right disturbing. The AVM2 was built with ActionScript in mind and visa versa. But compiling C using LLVM with ActionScript as a target produces better faster ActionScript (that’s actionscript, not bytecode) then the actual compiler built for the platform does ? Ouch. Now, moving to C development for the ActionScript platform to utilize this “magically” acquired speed seems somewhat illogical to me ? Joa Ebert already showed us some work he had done on the compiler, allowing for inline bytecode to be used. Nicolas shows us he can harnass the new Virtual Memory Opcodes, and his work on HaXe also shows us that inlining is very, very nice.

I’d love someone from adobe shedding some light on this issue. I love the Flash Platform, I love the work all the people at Adobe do, but this leaves me somewhat confused on how to develop for the platform I hold so dearly. If we have to let go of ActionScript to harness the pure speed Alchemy proofs is possible, then tell us. What is the future of our beloved language and our compilers for it ?

This entry was posted in Flash, News, Papervision3D, Random Thoughts and tagged , , , , , , . Bookmark the permalink.

33 Responses to Adobe Alchemy, is it ActionScript heresy ?

  1. John Dowdell says:

    Hi Ralph, most of the Player folks are on holiday this week. I don’t know the internals, but am I understanding the core questions correctly?

    a) “Does Alchemy work faster than Flash/Flex?”
    b) “If so, is this a result of hidden APIs?”
    c) “Is there a meaningful difference between the compilers?”

    Are those the basic questions we need answers to, and can we wait to next week to get them?

    tx, jd/adobe

    • UnitZeroOne says:

      JD : Actually those are not really the questions which are remaining. Nor is the API hidden, the opcode’s are documented by Adobe. Where my question resides, as an aggregate of this post, are in the area of the compiler. How do you compile for the AVM2 in the best manner. Working on things like Papervision3D and some of the projects I have more covertly done, most of the time, my prime objective lies in getting speed.

      There’s a number of ways of getting to that speed. When Quake was demoed at last years max, it seemed like it was a magic bullet in speed. A quake port can’t be rendered easily using the Flash rasterizer. So my assumption there is that it was using the “normal” quake 1 software rasterizer, or at least a port of that. Same goes for the NES emulator…speed in rasterization is key, although the NES’s low resolution seems handleable. As it turns out, with the VMem Opcodes in FP10, you can target a reserved block of memory and read/write in that quite a bit faster then you can using either the vector or bytearray datatype. Perfect for a software rasterizer.

      Now where my 1 question resides is, why would I have to resort to compilers like Alchemy or HaXe to get this functionality, whilst Adobe ActionScript compiler doesn’t allow me to target that. Isn’t that odd ? Since the functionality is added to the player, why wouldn’t I be able to target it ? What is the reasoning behind it, if any ?

      Question number 2 is more or less a feature request for 2 things. Inlining functionality within the compiler, similar to HaXe and bytecode inlining similar to Joa’s work (allowing me to write pure ABC and using the inline function of the compiler then reuse that highly optimized bytecode, whilst retaining managable code).

      Question number 3 is; what is the status of ActionScript after the last nail on the coffin of ES4 has been added ? Where are we going with this ? With the clear amount of focus Adobe gave to Alchemy at MAX, is this the way of the future ? Targeting the VM with different types of languages; and if so, what’s the faith of ActionScript.

      Question number 4 would be ; why oh, why is it true that the (C->LLVM->ActionScript)->ABC->JIT pipeline is faster then ActionScript->ABC->JIT ? As Branden states on his blog about Alchemy, the LLVM compiled code is just better optimized. If this is true, when can we expect major optimisations to the AS3 compiler. Yes, I understand AS is a different beast then C, but still, with a speed diff at a suggested 10x (not my suggestion, Adobe’s), in some cases, where does the compiler fail, and how can we fix that.

      I would really hate and have to move to another language and compilation platform, like HaXe or C, just for the sake of optimally targetting performance withing the player. Yes, I can write C, yes I can write HaXe code. But why would I have too ? Although it’s amazing achievement to have C / C++ compile down to ABC bytecode, and this does expose a big amount of code to the Flash Platform, I could already port java / c code to Flash. The amazing speed at which things ran is what really stunned people. Being aware that this isn’t a magic bullet, and there is no actual magic, the optimisation can and should be moved to the AS3 compiler, imho.

  2. Josh Tynjala says:

    Excellent post, Ralph. I too found it odd to hear that the ActionScript compiler wasn’t as fast as Alchemy. At the same time, though, it’s not entirely surprising. ASC is only a few years old, and it hasn’t had much time to mature. As you said, the AVM2 speed boost was significant, and it kind of makes sense that such an increase would be considered good enough when they had so much to do to get FP9 out the door. That said, I hope that the compiler team takes serious note of the possible optimizations that Alchemy brings to the table because now is the perfect time to start making those sort of improvements.

    • UnitZeroOne says:

      Josh; thanks. I took a long time contemplating this post, because I genuinely deeply appreciate the amazing technology the Flash Player is. FP9 has been out for a while, and it’s not very dependent on what you compile with; the speed seems to come from the way the code is compiled, not from the AVM2 itself. As with the C64, it’s a matter of how you target the platform and exploit it’s benefits the best. I agree with you and hope the compiler team does take note of the fact that they are not optimally targeting the platform they write all their code for ;-)

  3. My thoughts lately have been taking a similar direction.

    Although from what I’ve understood the development teams at Adobe are quite compartmentalized so I’m sure at some point we will get an API to be able to use memory in the same way as Alchemy does. And if the way that Adobe’s development goes it will be ok but not quite perfect and then eventually there will be an even better solution.

    What I’m a bit confused about is that I watched an early presentation on Flacc and they were explaining that memory management essentially was just a ByteArray they were using to simulate RAM. Now it could be that I heard wrong because I was working and listening at the same time. But this is how I understood it. Maybe things changed from when I watched that presentation and last year when they demoed Flacc.

  4. jim says:

    Great post! Look forward to the Adobe player dev team’s reply.

  5. wonderwhy-er says:

    Felt the same when started to hear about FlaCC and seeing Quake running at acceptable FPS.

    I am working with Flash CS4 for less then a month for now but it seems to me that it was released in a hurry :(

    I didn’t pinpointed most of things that make me think so but first one is lack of Z sorting for movieclips as it makes impossibles to design 3D stuff(more complex then text and separate image effects) in Flash for those how don’t know how to program. And there are other things too…

    Also this case with changes in Sound API in the last moment… Seems they were done fast too… I presume that main deal with CS4 was bringing different Adobe products to something like a same platform with things like PixelBender. All things like compiler optimizations or new 3D and sound APIs were secondary and made in a way “Add as is or don’t add” or they were not a priority.

    Though as I said I am using Flash CS4 for 2-3 weeks so may be it is only first look opinion.

    Tough they did added up a lot of useful stuff which will be very useful and bring Flash RIA’s to a new level.

    • UnitZeroOne says:

      wonderwhy-er : Just to clarify, this wasn’t any type of bashing on my side based on either cs4 or Flash Player 10. I’m just seeing potential in the VM which can’t be utilized by ActionScript, due to the compiler. As for the Z Sorting, check out the work I did with Lee.

      It’s really one line of code, it would be hard to make it much more simple. I’d love to see real Z-buffering in flash, but that would cause other issues, like transparancy. A more system native form of 3D would be great, but I do understands Adobe’s reasoning to build this in the software rasterizer.

  6. duke dougal says:

    I feel that Actionscript is slow. I wrote a post about it here

    Adobe’s continual cry of “actionscript is 10 times faster!” is old, old news and I wish they would stop saying it.

    Javascript engines in the browser world are taking huge leaps forward but there is NO sign from Adobe that it feels anything more needs to be done to make Actionscript faster. Perhaps this is because “Actionscript is 10 TIMES FASTER!”. Maybe they think it doesn’t need to be any faster.

    This is exacerbated by the problem that some of the Flex components (like the datagrid and advanced datagrid) are frankly slow and crappy.

    Adobe does its development in the old school way – it develops new feature upon new feature but doesn’t go back and make what it has already built faster, better and more reliable. If it did, then it would be working hard on making actionscript and the datagrid and advanced datagrid less crappy and slow, bigridden, memory hogging and amateurish.

    Didn’t you hear? Actionscript is 10 TIMES FASTER!

    • UnitZeroOne says:

      Duke, I think the challenges in building an architecture for RIA’s like Flash poses different problems then what will be just raw performance. I wouldn’t say it’s amateurish; and with Adobe opensourcing the entire Flex SDK, I think there’s space for people creating their own, better components (as is done). But to get back on topic, and to answer your second post……the real question here is, how do we unlock the real potential of the Flash VM as Alchemy is able to do. That lies more in raw numbercrunching, better optimized code and faster memory access, imho.

  7. DD says:

    So to summarise, Flacc has revealed the top end performance potential of the Flash VM.

    Why can’t Actionscript generate code to exploit the potential performance of the Flash VM?

    When will Adobe release a compiler that generates Actionscript that is as fast as Flacc?

  8. wonderwhy-er says:

    UnitZeroOne: Yeah I seen it but it will not work in designer as far as I can say meaning that designing even 3D box primitive in Flash IDE is rather unfriendly task and doing it trough code seems an easier way. I was speaking about that. Runtime level sorter will not help designers and I find it strange they didn’t do this one step further.

    And I also was meaning that developers were not able to add that speed up before deadlines for CS4 as they were not able do make some other steps before it and left them for CS5/FP11 or something.

    Though as far as it goes for those optimizations then who knows may be they will come with IDE updates. May be trying to play with Alchemy writing same code on C and on AS3 and then pushing something like “Make some noise” was will speed up things a little.

  9. Thanks for the interesting post. I was wondering if you guys were looking at haXe with much interest. Even though I’ve not used it yet I keep wanting to move over to it. One of the things holding me back is that libraries like PV3D arn’t in it, and arn’t optimized using it, so I keep holding back.

    The fact that Flash IDE (CS4) has become even slower this release makes it more and more useless, I’ve even gone back to using CS3 for making libraries of images / movieclips etc and using these in externally loaded SWFs. It seems the step over to haXe isn’t really that far away now.

    I understand the problem of moving the whole project over to something like haXe, not just because of the rewrite of the code base, but because you’ll get a lot of people complaining they can’t get into deving it anymore, and others complaining they just can’t use the nightlies anymore. When working on the main PV3D project I’ve done ( – sorry for FB link) it was great to be able to easily download the SVN (for latest updated PV3D, rather than 1.5 SWC for example) and then make a few very small optimizations in the code myself (just getting the MovieClipMaterial to update every X frames), and compile straight from my Flash project. It would take a small bit of too-ing and fro-ing if it was in haXe and I wanted to use the actual code, but it would also encourage me to use the SWC, which would, when not working on the engine itself, let me compile the rest of my stuff super-fast.

    I really think that the move to FP10 would be the perfect chance for the change to haXe and SWC onyl for CS4 peeps. At least they can use SWCs now. I realise that even suggesting a massive change like this could easily cause another rift somewhat like Away3D, but it really could be worth it!

  10. Adriaan says:

    Hi Ralph, thanks for this post. I don’t truly understand most of it but your post and generous linking backstories was very informing. Thanks!

  11. Pingback: Alchemy, ActionScript and the ASC at - Blog of Joa Ebert

  12. Scott Petersen says:

    Hi, Ralph. Great post! Hopefully it goes without saying that Adobe is absolutely committed to moving AS3 forward on all fronts with performance being one of the most interesting. We’ve learned a lot from Alchemy’s ability to squeeze so much performance out of the Flash VM and are extremely interested in applying that knowledge to ActionScript. While we’re hopeful that Alchemy is going to do great things for the Flash community, Adobe’s commitment to AS3 is as strong as ever!

  13. mike chambers says:

    Alchemy is currently an experimental project. You can expect that lessons learned from the project (such as compiler improvements and optimizations) will eventually make their way into release tools (such as out compilers).

    mike chambers

  14. mike chambers says:


    Javascript engines in the browser world are taking huge leaps forward but there is NO sign from Adobe that it feels anything more needs to be done to make Actionscript faster.

    A lot of those improvements to JavaScript execution are being made possible by code and engineering time provided by Adobe. (for example, see the Tamarin and Trace monkey work that Adobe is doing with Mozilla).

    Furthermore, Alchemy shows that we are continually exploring ways to improve ActionScript performance. As the post mention, we have made some significant improvements to improve runtime execution speed, some if not all of which will eventually find their way into the release compilers.

    Both of these examples show that we are very serious about improving runtime performance on the web (both Flash player, and the web in general).

    mike chambers

  15. Nicolas says:

    Hi Ralf,

    Nice to see you posting about this.

    IMHO, I think that Adobe strategy is a bit difficult to maintain in the long term.

    They want to open the platform, and this creates a lot of expectations from people like us, and at the same time they want to keep full control over it – which reduces the amount of improvements by what they can afford to build and maintain.

    There are I think two possible choices for the future :

    - keep it as it, and somehow deal with community frustration. I’m pretty sure they can continue to run business this way, but more and more people will start doing their own things, independently from what Adobe is doing. It could be a danger is some open source technology becomes mainstream, leaving Flash and AS3 behind, and it happened somehow to Microsoft when the web emerged.

    - fully open source the flash player, and completely change the way technical decisions are made and implemented, by relying much more on the web community as a whole. That would mean relinquish partial control on the platform, and focus on improving the tools that they are selling, such as the Flash IDE.

    Clearly, even if AS3 and Flash9 has improved things, Flash is nowhere near mainstream in the web developers community, and I can’t see it becoming while it’s still a proprietary platform.

    Just an additional comment about haXe : you’re in the chicken-and-egg issue : should you wait haXe to increase it’s user base, or help it improving its user base by adopting haXe as a technology for PV3D ? I’ll not decide for you, but you should think about the pro and cons, and not see haXe as it is today but as it will be tomorrow ;)


  16. Tink says:

    Great post.

    “The downside to that is, that the code base would have to change to HaXe, and thus become incompatible with the compilers of Flash and Flex.”

    But Haxe will also spit out the code as AS 3.0 so if people want the slower version you could still offer it :) .

  17. Pingback: Programming News Week | JADBOX: Web Application Musings

  18. Pingback: L’AS3 est il obsolète? | iq¹²

  19. Pingback: Link: Adobe Alchemy, is it ActionScript heresy? | Psyked

  20. Pingback: Flash 10, Massive amounts of 3D particles with Alchemy (source included).

  21. Pingback: Flash 10 Massive Particles « nativecode.log

  22. Pingback: The logical consequences that never happened at controul

  23. Fragilem17 says:


    Would your recent post about beign able to compile haxe code into a SWC file change things.

    I mean, would it be possible to compile the papervision(x) core written in haxe down to a SWC and then beign able to use it in a flash AS3 project.

    this way the core papervision developers would need to switch to haxe but the big majority would not NEED to, to be able to use papervision.

  24. Pingback: 300000パーティクルを3Dで動かす (2) :: あおいそら

  25. Pingback: More play with Alchemy : Lookup table effects. | UnitZeroOne

  26. Pingback: More play with Alchemy : Lookup table effects. - unitzeroone(beta)

  27. Pingback: Flash 10, Massive amounts of 3D particles with Alchemy (source included). - unitzeroone(beta)

  28. Nikos says:

    I feel I’m in the inner circle just by reading this stuff :)

  29. Pingback: Adobe Alchemy 资料整理 « 国士无双

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.