More play with Alchemy : Lookup table effects.

After the overwhelming response of posting the sources of 300.000 pixels with Alchemy and Pixelbender, I thought it would be nice to post some more from my session at FITC Amsterdam.

First let’s take a look at what people have done in response of the previous sources.

Yonatan Offek – Sierpinski Particles

Peter Nitsch – Alchemy Particles

David Lenaerts – Smoke, Milk and Ink

Dennis Ippel – Incredibly fast Plasma

Joa Ebert – Massive amounts of 3D particles without Alchemy and Pixelbender

All the work in that list is incredible, but for this post, I’m most interested in the last 2. Joa’s work on getting AS3 up to speed with my Alchemy demo (Joa’s demo is actually faster then the Alchemy version on my machine) is incredible. And it also proves the one thing I tried to convey in my blog post Adobe Alchemy, is it ActionScript Heresy ?.

Joa’s optimization relies mostly on a linked list implementation to iterate over the particles, and using the Flash 10 Vector type to allow for faster access to write to screen. Another speed improvement over the Alchemy version is not using Pixelbender, but having both rotation and projection done in the same loop as drawing to screen. All in all, his result on this is pretty awesome.

Again, writing highly optimized ActionScript should enable you to do the same speedwise as Alchemy compiled code. There’s at least one definitive advantage which Alchemy has in that case. The first advantage in Alchemy lies is the fast ByteArray access (which currently only Alchemy and Haxe can use).

The second advantage is why I think we should have a better AS3 compiler. It is the use of a more advanced compiler. This reduces the need to *highly* optimize your code, although I’d always recommend doing that in any case. My demo’s here are meant of examples on how to use Alchemy, rather then to get the last bit of performance out. That, we’ll leave to PapervisionX work.

Now, as I said, for this post we would be looking at two of the responses on my earlier Alchemy demo, the second one being Dennis Ippel’s Fast Plasma effects. Plasma effects and Lookup Table efffects aren’t too different. Ricardo Cabello did some experiments with them earlier, using Pixelbender. I worked on taking this type of effect and implementing it using Alchemy. Since that I had already done some experiments with them earlier, I thought it would be nice to release the sources, and see what you guys do with them. Maybe Joa feels like another shot of doing the same with ActionScript ?

Example

Source

Play around, let me know what you do with it, and make sure you check out Mr. Quilez his webpage, specifically, the article on Plane Deformations, where part of this code is derived from. If you want to optimize more, you *could* read Kebby’s article F***ing learn to code again.

One more observation  : the difference between running this on Firefox on a Mac and just running it in the FlashPlayer is huge, even bigger then normal. Could someone from Adobe finally explain this ?

This entry was posted in Examples, FITC, Flash. Bookmark the permalink.

19 Responses to More play with Alchemy : Lookup table effects.

  1. Another pixel bender + alchemy experiment : http://www.frankula.com/blog/?p=8

  2. Joa Ebert says:

    Ha, I love that article from Kebby. He is also a great DSP programmer by the way :o )

    I will have a look at the sources. It is always interesting to see how far we can push ActionScript. But what makes me sad again is that we have to optimize everything manually by using a different compilers (haXe, Alchemy) or writing cryptic code.

    There are a lot of modern compiler techniques and the ASC does not implement them. The LLVM is such a great example. Someone should really write an ActionScript frontend.

  3. hdachev says:

    We do need a better compiler. That’s me calling for some community awareness:
    http://blog.controul.com/2009/03/the-logical-consequences-that-never-happened/

  4. @Joa

    Unfortunately the LLVM is designed to compile code in a way that it would be nearly impossible to generate ABC correctly (mostly because of its *dynamism*). That is why Scott had to add additional opcodes to FPL 10 to achive some goals.

    A better approach might be to port some existing optimizations to the AS compiler; in the latest version there have been some improvements, but the compiler is still extremely slow and sometimes does not produces optimal code

    Well, do not forget Haxe … it is largely better as a compiler and as a language then AS. And there is still a lot of room for improvements there without big companies that take weird decisions based on the market and not on the users

  5. Joa Ebert says:

    Gabriele: I know a little bit about those problems with the LLVM architecture but could you not just do exactly what Scott has done?

    I mean parse the class, use the LLVM for the method body and compile that with the modified ASC?

    I have not looked at the ASC sources for two months now. Did they really improve something?

  6. What Scott did was creating an LLVM backend that produces AS code, that is then compiled using a *special* compiler that is able to compile also direct assembly instructions. Unfortunately those assembly instructions works only on the domainMemory, so they cannot be used to access AS objects that reside on the heap for instance.
    Creating an front end for AS won’t be easy because of the structure of the ABC bytecode ( that is largely different from the standard static code generated by any LLVM backend) and because of the dynamic nature of AS.
    It is not easy to explain, but what have been (easilly) done for C/C++ cannot be done so easilly for AS. For instance AS (as u already know) uses a lot of global tables in its bytecode, that makes inlining assembly and generating assembly instructions quite hard.
    With the current AS VM, methods code cannot be compiled into optimized bytecode (well … something can be done but probably it is easier to improve the VM)

    There are a lot of key points where the AS VM might be improved:

    - adding additional instructions to replace common patterns;
    - improving the JIT, maybe using a Trace based JIT;
    - remove extremely slow operations like runtime type checking (that sometimes can be avoided);
    - remove generic objects (like Array) and replace them with faster types (Vector is a decent solution – but far from something like static arrays that will perform extremely fast for some operations);
    - obviously find a way to improve function calls – the speed of getPixel32 is ridiculous;
    - provide a way to inline code: as long as function call requires a lot of time to setup, inlining can be a big improvment;

    There are some many fields where AS VM can be improved, I don’t see right now a big need for a better compiler (well maybe faster to compile).
    Now that their new politic is to provide low level APIs and then give higher level wrappers written in AS, I’m pretty sure that one of their goal is to improve execution speed.

    The new ASC is a bit better then the previous one, and generates faster code even if Haxe is still – sometimes, if well used – better.

    • UnitZeroOne says:

      Gabriele,

      I think my main standpoint on this still is, that if there’s things which are now native to the player, but can’t by utilized by the target language, we ARE being left behind. Yes, HaXe can do it. Yes Alchemy can do it. But all in all, AS3 should have some form of access too (this is vmem).

      As for the asc.jar that comes with Alchemy : apparently it would be possible for us to have some form of __asm tag for the asc.
      That being said; writing pure bytecode for more then just the most inner of inner loops doesn’t have my preference. All in all I do feel that a lot of times I am changing core architectures to better accomodate the quirks of the compiler / vm, which doesn’t seem right.

      As for your suggestions; couldn’t agree more. Especially inlining has been high on my wishlist for so long, but I am also kind of curious where AS will be going with ES4 out of the window ? Being able to inline functions shouldn’t be the hardest thing to implement. As for the runtime type checking : maybe they can add ultra-strict mode, disabling non-type-safe objects ? But that would most likely also disable all dynamic objects, including mc etc. Function calls are slow indeed, and this is why I am saying that a lot of time architecture needs to be changed to accomodate the vm / compiler. Which seems to be the wrong way around in most cases.

      I think alchemy is the proof for a better as3 compiler though. When you are saying new asc, are you talking gumbo ?

  7. Pingback: The Two Sides of the Brain. » So Much to do So Little Time

  8. Nicolas says:

    Hi Ralph, one easy solution is to forget about ASC issues and switch to haXe… But of course, I’m biased ;-)

  9. Kevin Newman says:

    It’ll be interesting to see how Adobe responds to the need for more performance out of AS3 vs. the need to make it easier for those who just want to hack something to get it working (Javascript style).

    I think the language can do both, with the right additional keywords, and perhaps some more compiler settings. Why not have lightening fast static method calls for types that don’t need ES4 cruft (is anyone doing prototype inheritance at this point in AS3), but still have more dynamic access to timelines “scripts” which really should behave like scripts in that case (and maybe not fail to execute quite as easily).

    AS3 seems to be standing in a place between the dynamic convenience of Javascript, and the strict performance of C, and can’t seem to decide which way to go. I hope it goes both ways. I want the fancy new Javascript (well, ES4 like) features for when I want to script something (including an easier time checking if a property exists, and possibly even a different way to deal with errors – that doesn’t halt future code on the timeline, maybe some runtime duck typing too), and the balls out performance benefits of C when I need it (maybe even static structural typing?). Can we have it both ways – or should AS3 become C, and we’ll just use a Javascript-like language (compiled to ABC or whatever) for the timeline (with an API to access the AS3 classes)?

    (that’s all stream of thought, hopefully it makes sense)

  10. Joa Ebert says:

    Gabriele: The ASC in the trunk looks pretty much the same. I stopped checking out branches and tags. So in that case I do not know about it (yet :) ).

    I still do not see the problems with using the LLVM although. It seems like you are thinking about something. I mean the use of SSA in the LLVM is not a problem at all. But maybe we are talking about two completely different aspects.

    So far the good news is that the MIR has been replaced with Nanojit — we just have to wait a little bit.

    IMHO inlining methods is completely overrated. This is a job for the VM and works very well for Java or .NET languages since the JIT decides at runtime what to inline. But of course we need a JIT that is smart enough to do that for ActionScript.

    More important than inlining is the (real) support of templates/generics like Vector. and method overloading. If I could prioritize any of those features I would go for

    1) Method overloading
    2) Template types
    3) Operator overloading
    4) More VM optimizations

    C# has so many fabulous syntactical features. Working with ActionScript/Java feels like stone age when switching back.

    By the way Ralph: I tried to implement your effect and I could not get up to the same speed. I it think it could be possible but that would require much more work. Anyways, it is no surprise. If everything runs in Alchemy and you do not have to thunk out: it is faster.
    But if Nicolas would create a haXe version, using the Alchemy opcodes, his version would probably be faster — which would not surprise me as well.

  11. Joa Ebert says:

    Oh, I completly forgot: The most important feature would be threading of course :)

  12. @Ralph

    Yes, I’m talking about the Gumbo one. Not sure if the improvements they did works for all the cases, but the compiler seems to have been improved.

  13. Obviously threading support is the most important stuff ever! Not sure if it can be implemented easilly in the current VM, but the MUST add something soon!

    About the rest, it is always a matter of personal taste: for instance operator overloading is not as important for me as it is to you, but probably more important might be to move AS to a real strongly typed language, so they can start working on all the optimizations/features that now cannot be added because of dynamic types. +1 for generics too ;)

    About LLVM well, it is a long story and and we might continue talking about that for days … the most important thing is that Adobe should do something to improve the language. Silverlight 3.0 is approaching with many new features … and they’ll have C# 4.0 that REALLY rocks ..

  14. Yagiz says:

    Some experiment about showing 500.000, 400.000 and 300.000 particles: http://www.yagizgurgul.com/blog/2009/04/24/500000-particle/

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

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

  17. AlexG says:

    I also do visual experiments but without Alchemy
    http://alexgblog.com/?p=356

  18. Pingback: More alchemy stuff & a surprise AS3 implementation « sudpaw

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.