Virtual Memory API
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.
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 !
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.
...which brings me to question, will it work in FP9 if you remove Vector-related stuff?
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?
Wow! Thats quite impressive! Haxe rocks!
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+
Soon, adobe will send assassins after you ! ;)
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 ;)
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
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)
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
Hmm. Link didn't make it through? Trying again:
http://www.peterelst.com/blog/2008/10/05/more-information-on-flacc/