Posts Tagged 'alchemy'

How to make ASC2 alchemy SWC compatible with old compiler

Some time ago I tried to use latest Genome2D SWC with Code Orchestra livecoding tool and, like others, failed (at first). The reason was that COLT, being derived from old compiler, fails to parse SWC made with new compiler, if it uses memory opcodes. In theory, there should be no problem, since memory opcodes are already compiled into SWC’s library.swf and old compiler does not have to care about it. In practice, there is a problem in SWC’s catalog.xml:

<script name="" mod="9223372036854775806">
	<def id="avm2.intrinsics.iteration:hasnext"/>
	<def id="avm2.intrinsics.iteration:nextname"/>
	<def id="avm2.intrinsics.iteration:nextvalue"/>
	<def id="avm2.intrinsics.memory:lf32"/>
	<def id="avm2.intrinsics.memory:lf64"/>
	<def id="avm2.intrinsics.memory:li16"/>
	<def id="avm2.intrinsics.memory:li32"/>
	<def id="avm2.intrinsics.memory:li8"/>
	<def id="avm2.intrinsics.memory:sf32"/>
	<def id="avm2.intrinsics.memory:sf64"/>
	<def id="avm2.intrinsics.memory:si16"/>
	<def id="avm2.intrinsics.memory:si32"/>
	<def id="avm2.intrinsics.memory:si8"/>
	<def id="avm2.intrinsics.memory:sxi1"/>
	<def id="avm2.intrinsics.memory:sxi16"/>
	<def id="avm2.intrinsics.memory:sxi8"/>
	<dep id="Number" type="s"/>
	<dep id="int" type="s"/>

The solution is to remove any mentions of avm2.intrinsics.* from catalog.xml :) SWC continues to work without them for both ASC1 and ASC2. I asked Adobe people why does this garbage has to be there and break compatibility for no reason but got no reply, so I am posting this find as PSA – when some ASC2 SWC suddenly gives you headaches, you will know what to do.


Can AS3 and Alchemy be friends?

Ok, so many of us tried to use Alchemy opcodes in AS3 projects, years ago. But how many keep using it every day ever after? Not me. Why? Well, where do we start…

What is it good for?

Adobe introduced these opcodes to implement memory access operations required by LLVM, so that Alchemy could do its thing, and Flash Player could run C++ code. But for AS3 people these opcodes did not do anything magical. It was just another way to read numbers from or write to one ByteArray at a time that, coincidentally, worked faster than IDataInput/IDataOutput. So, if you were to do some number crunching, it might save you some milliseconds.

The problem I have with this is that now, when ASNext is abandoned and AS3 performance is being surpassed by JavaScript, many people tend to bring up these opcodes as valid solution to *all* our “make AS3 faster” pleas. Just how exactly fast numeric array IO is supposed to help with complex data types known as classes? Good question.

Placing your class fields in domain memory

In C++ you have pointers, but in AS3 you don’t, so placing your class data there will be ugly. But, if you will be able to access them normally (via dot syntax) and faster at the same time, why not try it? So I did: using legacy compiler and azoth, I did this simple test, and… got domain memory based loop running over 50 times slower than plain AS3. WTF?? Turns out domain memory is only fast if you set your ByteArray to use LITTLE_ENDIAN order (it’s the opposite by default). With LITTLE_ENDIAN memory opcodes were about 10 times faster, but this was still not enough to bridge the gap caused by having to use getters and setters now instead of plain variable fields.

Enter the ASC2

ASC2 has two features that make it interesting in this case. First, it can inline method calls. Second, it can emit memory opcodes without 3rd party tools. So, after people reported that this was indeed working for my cause, I opened my FB 4.7 trial and went on to try that myself. I was confused a lot by the fact that none of memory opcodes were present in playerglobal.swc, but it turns out you can ignore that – the code will compile and run any way. This time everything went better than expected – I had domain memory based loop finally running 30 to 50% times faster, although timings fluctuated a lot update: I bumped arrays length to get better numbers on desktop; for MBP/Chrome/11.6 they were on average 220 ms vs 110 ms, for Windows/standalone/11.6 – 250 ms vs 190 ms. Finally, for iPad3/ipa-test/AIR 3.7 they were 200 ms vs 275 ms (memory opcodes loop was slower).


People on twitter were fast to remind me that apparat had similar feature for quite some time. This way is probably the best way to use memory opcodes for people who cannot use ASC2. I wanted to include apparat-based test for this post, too, but it turns out I don’t have it installed here (nor do I have scala). It’s not that hard to install but, as lazy as I am, this is not something I am willing to do for the sake of this blog post. So you are going to have to trust in that it works, because clever people made it.

HOW TO: Integrate FlashDevelop with Azoth

  1. First, if you don’t know what a hell Azoth is and why would you need it in FD, read this post.
  2. Second, download Azoth zip.
  3. Find com subfolder inside zip’s as3class folder and extract it to C:\Program Files\FlashDevelop\Library\AS3\classes – now you can import Azoth’s fastmem class in any AS3 project.
  4. Make azoth folder in C:\Program Files\FlashDevelop\Tools.
  5. Find azoth.exe inside zip’s bin folder and extract it to azoth folder you have made at step 4.
  6. In the project that uses Azoth, go to project properties dialog, Build tab, and paste following into Post-Build Command Line field: “$(ToolsDir)\azoth\azoth.exe” “$(OutputDir)\$(OutputName)” “$(OutputDir)\$(OutputName)”

Update: FD response was incredibly fast – there’s now special FD extension available with AS3 project template.

Old stuff

December 2018
« Jan    

Oh, btw…