I want to a step further now. But please keep in mind that I am definitly not a compiler expert or have deep knowledge of the Flash Player. Everything I write about is in my opinion common sense and comes from a long time of reverse engineering and autodidactic learning.

Alchemy

First of all I have to say that Alchemy is a great research project and I have full respect for Scott Peterson and his work. He did an awesome job and I am more than happy that Alchemy has now been released on labs because people begin to question now the Flash Player, ActionScript and the ASC (ActionScript Compiler).
So why is Alchemy faster than using plain ActionScript — or is that true at all? I do not want to disappoint anyone here but writing C/C++ code instead of ActionScript is not the right way. Alchemy will never be faster than your plain handoptimized ActionScript and it still has to prove for me that it is actually faster. All my comparisons between Alchemy and ActionScript showed that using ActionScript is in most cases faster.
But it makes sense to use Alchemy. An audio encoder for instance runs for a long time on its own without having to exchange data. Currently it is very slow to transfer data between Alchemy and ActionScript on every frame. This does not mean Alchemy is bad, but it will not work for your fast inverse square root algorithm.
So why can Alchemy be faster at all? There are a couple of reasons for that.

1. C/C++ can be compiled and optimized much better than ActionScript
2. The language offers you features you would dream about as an ActionScript programmer (operator overloading, method inlining, templates, etc.)
3. The LLVM does a really good job on optimizing its intermediate language
4. Alchemy comes with some new opcodes for the Flash Player that allow very fast ByteArray operations
5. Alchemy uses a modified ASC that supports inlining of Flash Player bytecodes.

So just to make one thing cristal clear: If the new opcodes would not exist, Alchemy would produce very poor results in terms of execution speed. But albeit that I have to disappoint you about the execution speed of Alchemy in general. Nicolas Cannasse wrote an interesting blog post about this issue and I completly agree. ActionScript does not support a lot of features which C/C++ offers — pointers for instance. All those features have to be wrapped and this means a significant speed loss.
But I do not want to start an Alchemy bashing here. I still think it is a really great technology and the main use case is not fast code execution. But it brings me to my next points: The ActionScript language and the ASC.

ActionScript

ActionScript has been designed several years ago and Adobe had always the incentive to be ECMA compilant. Being standards compilant reduces a certain level of innovation and recuded the power of the Flash Player in the last years. Right now, ActionScript 3 is not an ECMA compilant language. And I am not saying this because ECMA Script 4 has been dropped. ActionScript 3 added additional “features” even before that happened.
For a long time ActionScript 3 has been very close in terms of its ECMA compilance but I think it is now time for innovation. The ActionScript 3 language does not fulfill most of the professional needs.
Have you ever looked at haXe? I hope you did. haXe is definitly not perfect but I want give you a small excerpt of haXe language features which will make your mouth water:

• You are abel to use type parameters
• You are able to use function types like Event -> Void for an event listener instead of Function
• Enums instead of the public static const convulsion

Why am I talking about haXe at all? Java has most of those features implemented as well and several other languages too. But haXe can output a SWF so we can compare it to ActionScript. haXe is in a lot of ways superior to ActionScript and I did not talk about the compiler yet.
The quintessence is that ActionScript is not a feature rich language compared to mature ones. And even a single French genius can develop something better than a multi-million dollar company. What the hell is going on here?
The main problem of ActionScript is that you lose most of your types along the way and therefore the compiler can not produce a good output. E.g. everytime you put some object into an Array in ActionScript its type is lost unless you cast of course when reading again — and I hope you do that. This is a really big problem. This is the reason why Alchemy can produce “better ActionScript” than you. Not because you are stupid but because you do not have the tools in ActionScript to do that. And this is a shame for Adobe. So many great developers could produce such a great output but they are not allowed to.

ActionScript Compiler

One of the main problem in the whole Flash universe is the ActionScript compiler. This is a little bit harder to explain because it is a little bit more abstract. Some problems exist because of the ActionScript language nature. But some problems exist because of the compiler itself. Let me explain this with an example:

package {
public final class Example extends flash.display.Sprite {
public function Example() {
var a: int = 1+2;
var b: int = a;
var c: int = b+1;
}
}
}

This code will produce exactly this output for the constructor:

get_local0
pushscope
get_local0
constructsuper 0
pushbyte 1
pushbyte 2
add
convert_i
set_local1
get_local1
convert_i
set_local2
get_local2
pushbyte 1
add
convert_i
set_local3
returnvoid

The interesting part has been marked bold. Let me explain what is going on here:

1. Put value 1 on the stack
2. Put value 2 on the stack
3. Add the two values which are on the stack together using floating point calculus
4. Convert this floating point value to an integer
5. Set this value to local register one which is a
6. Put the value of local register one on the stack
7. Convert this floating point value to an integer
8. Set the value to local register two which is b
9. Put the value of local register two on the stack
10. Put value 1 on the stack
11. Add the two values which are on the stack together using floating point calculus
12. Convert this floating point value to an integer
13. Set this value to local register three which is c

Basically this is an example for the worst output a compiler could produce. First of all b is not needed at all in our code. We hold just the value a in b. a holds a constant value 3. Why do we have to add this stuff together at runtime everytime if it is constant? For c we add the constant value 1 to the constant value 3 which has been stored in a. The compiler should know at this point three things: a is constant, b is not needed, c is constant. The compiler could just set c to the integer value of 4. This is also what I would expect for a SmallWebFormat.
But to make it even more interesting: c is not used at all. So why does the constructor contain any bytecode at all besides calling the super constructor? And to make it a little bit more absurd: Try doing the same in PixelBender and use Tinic’s disassembler. You will see that you will not find any of your local variables in the PixelBender bytecode — which is correct. And the answer why the PixelBender compiler is smarter than the ASC is quite easy: Adobe uses the LLVM for PixelBender as well. Remember the LLVM is what Alchemy is using. This means basically that PixelBender has a better compiler than we have for ActionScript. This is sad and insane but true.
With the haXe compiler you will get nearly the same output as the ASC with certain differences. All the variables are integer values and therefore haXe uses integer calculus. And the last addition does not involve b at all. haXe will not ignore that a, b and c are not used at all. But as I said: haXe is definitly not perfect — but it is by far better.

I have asked for certain features a lot in the past and implemented them for myself. I asked Adobe to support the __asm keyword even before Alchemy and they refused it. Of course I am a little bit disappointed about that because now they use it for Alchemy and they see it makes sense. Basically having a __asm keyword allows you to get around the nonsense which the ASC produces at least for performance critical loops. This is why I started writing AS3C but it is basically a stupid idea to try optimizing on a byte code level but it integrated very well into my daily workflow.
The Flash Player could work much faster if we could access certain things with ActionScript. The lookup of a class can be stored in a local variable for instance which gives a significat speed boost. haXe already allows you to do that via var m = Math. Why do we have to wait for such things so long?

Thoughts

Now after writing about Alchemy, ActionScript and the ASC I think that you get the idea. What we need is a compiler that works. And once the new Alchemy opcodes are supported in the ASC it will be much more fun to write your lightning fast ActionScript code instead of converting C libraries. We need a mature language which allows us to work in professional large-scale environments and which allows the compiler to produce a good output.
Libraries which are a community-darling could become even better, easier to use and faster in execution speed which would result in better user experiences.
I would like to see a faster and more innovative development of ActionScript and the ASC. But then there are the politics and all the bussiness stuff so we will have to wait probably for ages until we get what we need. Right now we can use alternatives such as haXe. And the good thing is that other companies do not sleep as well. I would love to write C# instead of ActionScript but Silverlight just sucks. Maybe someone could write a C#->LLVM->ActionScript->SWF compiler toolkit?

Share This

I will also put some more sets and other tracks there if I find the time. The site will update randomly.

• Tones

Share This

I think John has choosen a perfect location. I am excited to meet new people and to be a part of a fantastic speaker line-up. More information available at http://www.flashonthebeach.com/.

Share This

Now I do not really know why there is no MIDI support on the Mac because the implementation is fairly simple. OS X comes with a lot of easy-to-use system libraries. One of those libraries is CoreMIDI. Now the only thing you have to do is wire everything together. Use SPI to talk over JNI with CoreMIDI and you are set.

I am not a Java programmer and not a Mac user at all. But I think I learned some common things during the last days.

• Synergy is awesome. A good friend told me about it half a year ago and now I finally tried it. One mouse and keyboard to control four screens which are connected to my Laptop and Macbook is pure luxury — but for free! Synergy is open-source and absolutely superior to a VNC solution.
• JNI is not hard to handle. It was not my first time using it but when it comes to threading you have to keep in mind that references to Java objects have to be marked global and everything from the call to your JNI method becomes invalid. Keeping a reference to the JVM and attaching the thread to it works very well.
• The Ant Jar task has a bug. Defining a service using the <service/> tag does not work because the folder in the jar will be named “service” and not “services“.

I am definitly not an expert when it comes to this kind of stuff but I had my problems especially with the Ant bug and calling a Java method from a different thread. The result is very nice on the one hand because it works for all kinds of MIDI messages now but on the other hand I still have to ask myself why nobody included this feature for the OS X Java VM in the first place.

The good news is that we will have a very robust MIDI implementation which will work crossplatform without the need to install any additional libraries.

Share This

Last week I was on holidays — no laptop, no internet, no mobile. Just wanted to get fresh eyes, relax a little bit — you name it. Yes, that’s right: I missed the launch of the Flash Player 10.

Today I went into the office and I heard about the news. The released version Flash Player 10 has a completly different behaviour when it comes to dynamic audio. We have been developing with Flash Player 10 for a while and it has been working like a charm.
But without telling anyone Adobe has changed the behaviour of the sound API. I can partially understand the changes which means I do not understand why it worked in the first place but the main point is that it worked. I have also another solution in my mind to keep it the same way as it was before.

We implemented several techniques to ensure a stable audio output. There are still parts in the Flash Player implemented native which we could not circumvent or would take a ridicolous amount of time to get around. Imagine if you set the scale on a big DisplayObjectContainer. The Flash Player itself will take a lot of time to perform this task. Enough time to block the audio stream. Therefore we were pre-calculating the needed audio information. Since the Flash Player or ActionScript is not multi-threaded it was the only option to send the data before performing such an expensive task. This is now impossible. The whole work we did was worthless and the application feels less stable.

Now there is no way for us to fix this issue with the latest changes. The reason why I am so disappointed is because nobody told us. It was probably a small change for the Adobe engineers but it has such a big impact nobody thought about that I ask myself how they deal with responsibility.

What can we do? We can wait. Get some feedback from the engineers and try to get the old version back. Of course we can arm up the MAKE SOME NOISE campaing but then what? Wait another year for Flash Player 11 and see how the API changes with the release? Without being notified?

Adobe, this was a real disappointment. I am not amused.

I am really happy that my work in the next couple of months will be focused on low-level API programming and server communication. I will not write that much ActionScript code — MIDI is about to make it into our tool and I have to write some nice stuff for you Mac folks without a proper Java VM ;)

Share This

PixelBender Outline is working with FDT only. Just grab the JAR file and place it into your Eclipse plugins folder (…/Eclipse/plugins/) to install it. After restarting Eclipse you can open the view using Window->Show View->Other->PixelBender->PixelBender Outline.

The outline is updated everytime you select a *.pbj file in the Flash Explorer.

• Download

Share This

AS3V is basically a tool that can check for syntactical correctness. It will do with your code what a compiler does but it keeps formatting metadata. That way it can generate an XML skeleton of your code and apply rules on the XML.

You can have a look at the first output AS3V produces here. The original source code is included in the comment at the top.

As you can see it will be possible to force coding standards for instance and to warn if code could be optimized. I hope that it will be possible to have a first version of a stable parser soon. ANTLR is still giving me a lot of trouble but it is the first time for me working with such a tool as well.

Share This

• http://www.joa-ebert.com/swfs/lectures/fotb08
• http://www.joa-ebert.com/files/swf/lectures/fotb08.swf

Share This

Here are the results for 1000 DisplayObjects with manipulation on their scaleX, scaleY, alpha, x, y and rotation properties. It is also very important that you take a look at the memory behaviour. A click starts the tweening.

• Hobnox
• GTween
• TweenLite

As you can see it makes a lot of sense to stay type-safe and to manage the memory you are using on your own.
I will talk about those concepts in my next session AudioTool’s Private Parts in Brighton and Boston. Since optimization on a code level is trivial the main performance boost is achieved by re-thinking algorithms, structures and concepts. I guess one of the most interesting topics will be the optimization of our cable solver which was running O(n^2) (really!), then O(n(n+1)/2) and could be minimized to a rare O(n(n-4)/2) worst-case.

Share This

If you know PixelBender, than you know that you can not create loops. What you could do is unroll all constant loops with a fixed length. If you know simple convolution filters like a blur, you know that you need an xy-loop and you know it should not be possible with PixelBender at all. Let me prove you wrong and have a look at dynamic loop unrolling with PixelBender (be careful with high values!).

I built a library to assemble and disassemble PixelBender kernels at runtime. I wrapped it also in a high level API so basically you can create a new Kernel by doing var kernel: Kernel = new Kernel();. Then when you need your shader as a ByteArray you simple call kernel.compile(). There are still some glitches here and there but I hope that I can release the source code pretty soon.

Share This