Calendar

April 2014
Mo Tu We Th Fr Sa Su
<< >>
123456
78910111213
14151617181920
21222324252627
282930

Langs

Virtual Memory API

Posted on Nov 20 2008

Following my previous post about the new Alchemy-related opcodes in Flash Player 10, I was able thanks to people feedback to get the opcodes working in Haxe, and to wrap them with a new Haxe API that is called flash.Memory :

package flash;

class Memory  {

    static function select( mem : flash.utils.ByteArray ) : Void;

    static function getByte( address : Int ) : Int;
    static function getUI16( address : Int ) : Int;
    static function getI32( address : Int ) : Int;
    static function getFloat( address : Int ) : Float;
    static function getDouble( address : Int ) : Float;

    static function setByte( address : Int, value : Int ) : Void;
    static function setI16( address : Int, value : Int ) : Void;
    static function setI32( address : Int, value : Int ) : Void;
    static function setFloat( address : Int, value : Int ) : Void;
    static function setDouble( address : Int, value : Int ) : Void;

    static function signExtend1( value : Int ) : Int;
    static function signExtend8( value : Int ) : Int;
    static function signExtend16( value : Int ) : Int;

}

The general idea is that you allocate a byte array, of at least 1024 bytes, then you call select() to select it as the current virtual memory.

You can then get/set this memory using the Memory API, the address being a position offset inside your bytearray.

You also have three functions to sign-extend integer values. For instance signExtend8(250) is -6.

I did a quick speed test comparing the different ways of reading / writing memory, and here's the test bellow that will run that for you and give you the results. It creates a structure then read 10000 sequential elements from it, and repeat that 3000 times.

Results show that flash.Memory is 40% faster for reading and 30% faster for writing than using the Flash10 Vector class (for a single byte) - Tested on IE7 / FP10 NOT DEBUG VERSION. I also tested with double values and it performs very well too.

[bench_vmem.swf]

You can start using flash.Memory API right now by updating latest Haxe CVS, or you can wait for Haxe 2.02 to be released in a few days on http://haxe.org !

11 comments
  • Nov 21, 2008 at 01:08

    As usual, Nicolas is the fastest implementer of cool things. Now flash developers can become really jealous for the haX'ers :)

    BTW, Nicolas, it seems flash player detection on this page works a bit wrong. Now I see your test app in FP9 with no message I should upgrade the Flash Player.

  • Nov 21, 2008 at 01:42

    ...which brings me to question, will it work in FP9 if you remove Vector-related stuff?

  • Nov 21, 2008 at 02:10

    Also, it seems to follow that structured data arrays must be split into POD arrays in order to take advantage of this thing. I wonder if some higher level abstraction is possible to work around that?

  • Nov 21, 2008 at 09:58

    Wow! Thats quite impressive! Haxe rocks!

  • Nov 21, 2008 at 10:49

    Nicolas,

    thank you for your great work. I also had the opportunity to work with Alchemy but I was not that much interested in converting C code to Flash because it is way slower to use the converted code in comparison to hand-optimized code.

    In my opinion the best results of that project are the new opcodes and a new feature for the ASC that Alchemy is using which allows inline asm.

    I am happy that you implemented those new features so quick and it is again a shame for Adobe and their compiler :) How about adding inline asm to the Haxe compiler? I think it would be a good idea -- of course completly platform specific, but for Flash it would already make a lot of sense. Core classes and functions could be optimized specific for each platform and we would get even better results.

    a+

  • Nov 21, 2008 at 10:52

    Soon, adobe will send assassins after you ! ;)

  • Nov 21, 2008 at 13:15

    To makc : yes, the blog only checks for FP9 whatever the .swf version. You can try if you wish, but I highly doubt Alchemy opcodes are supported in FP9.

    To Joa : I agree with you with C-to-Flash.

    Inline ASM in Haxe would be indeed a geek feature but so far I was not that much able to get additional performances by writing ASM compared to what the Haxe compiler outputs. But maybe you can prove me wrong ;)

  • hosey
    Nov 21, 2008 at 20:35

    Nicolas, you should add some way of tracking test results. It would be interesting to see how different browsers perform.
    Ubuntu: FP 64 bit alpha
    readArray: 1967
    readByteArray: 363
    readVMem: 182
    readVector: 178

    writeArray: 967
    writeByteArray: 812
    writeVMem: 173
    vriteVector: 235

  • Nov 22, 2008 at 10:34

    Wow, nice opcodes! Just the sort of thing i need for that SCUMM interpreter of mine. :)

    (or i could just compile the c version in alchemy. that is seriously cool)

  • Nov 24, 2008 at 10:14

    Hi Nicolas!
    This is really neat. I actually saw a video where Scott Petersen explains this, but I didn't get it until now. It's the one linked at the bottom of this article that Peter wrote

    Worth checking out!

    J

  • Nov 24, 2008 at 10:15

    Hmm. Link didn't make it through? Trying again:
    http://www.peterelst.com/blog/2008/10/05/more-information-on-flacc/

Name : Email : Website : Message :