Ive always wondered, how would this be better/faster than the flex compiler directly outputing AS bytecode or hand-coding the AS bytecode (if that were easy/possible).
The only reason I can think of is that Adobe's compiler does a lousy job and that Adobe would rather focus on the tools and frameworks component and let the guys good at compiler construction do the bytecode generation.
Is this it? or is there a much smarter reason that is eluding me (as it usually does)?
You're basically right. LLVM performs optimizations that mxmlc doesn't, and you don't lose those optimizations during the as3 compilation step because Alchemy ships with a modified as3 compiler that lets you inline opcodes (output by Adobe's LLVM backend).
You've actually always been able to optimize your AS to this degree, but you have to deal with the esoteric details of AVM2 bytecode, which, obviously, is not alot of fun.
Now, what are these operations that Alchemy does so well? Memory access and function calls. Alchemy compiled code utilizes new bytecodes added to FP10 for working with ByteArrays - which as you’ll remember are what make up the "RAM" in Alchemy. Function calls are faster because in ActionScript function calls require that their parameters be "boxed" and "unboxed" into and out of objects for each call. Alchemy code doesn’t have to do this.
Unfortunately it's slow as hell. Scott's presentation at MAX showed his Doom port running fluidly, so we know it can be done. With any luck we'll see optimization tips shared soon.
I played the first few levels without any performance issues - on Linux x86_64 with Flash 10.0.12.36-r1 in nspluginwrapper (I haven't gotten around to switching to the native alpha)
The only reason I can think of is that Adobe's compiler does a lousy job and that Adobe would rather focus on the tools and frameworks component and let the guys good at compiler construction do the bytecode generation.
Is this it? or is there a much smarter reason that is eluding me (as it usually does)?