Adobe Releases C/C++ To Flash Compiler 216
SnT2k writes "Adobe recently released the beta version of Alchemy which compiles C/C++ code into AS3 bytecode (which runs on AVM2) that can run on the Flash or Flex platform and boasts increased performance for computationally-intensive tasks (but still slower than native C/C++). It was demonstrated last year during the Chicago MAX 2007 to run Quake. A few months later it has been demonstrated to run a Python interpreter and Nintendo Emulator. One interesting tidbit is that the thing is built upon the open source LLVM Compiler Infrastructure."
Still no contact info, so I'll post here... (Score:5, Interesting)
I've been interested in this idea since the presentation at the LLVM dev meeting. I'd be interested in extending clang to use the native ActionScript object model for Objective-C objects, and adding a GNUstep back end to use the native flash drawing primitives so that we can easily port Cocoa apps to run in a browser. Unfortunately, there was no contact information listed anywhere on the presentation or on this site, so I haven't been able to get in touch with anyone at Adobe Labs about this.
Oh oh Adobe... (Score:2, Interesting)
NES emulator? (Score:3, Interesting)
Where I can find info on the NES emulator in Flash? That link didn't have any info that I could find.
I had started such a project a while back, but never quite finished due to poor performance.
It has been said (Score:5, Interesting)
This seems to further cement flash as a worthy application environment, especially given the perceived problem in flash appeared to be its inefficiency.
Looking forward to better flash games... (Or perhaps not if im not wanting to procrastinate).
Re:Quake. Quake for fucks sake! (Score:4, Interesting)
Re:Still no contact info, so I'll post here... (Score:1, Interesting)
Actually yes. It's pretty yummy.
Increased performance (Score:5, Interesting)
Increased performance over what exactly? Is there some other 'slower' bytecode that the VM runs? The summary fails to mention this. I don't see how compiling C++ to the AS3 bytecode would be any faster than compiling some Flash language to AS3 bytecode, or writing AS3 bytecode directly. I assume it is the AS3 bytecode itself that is faster, in which case the 'compiling C++' part is irrelevant to the increased performance.
This is not where Adobes priorities should be! (Score:5, Interesting)
The Flash VM is slow beyond belief when getting into large data-structures, event its native array parsing is incredibly slow.
Object instantiation is slower than molasses. We were averaging about 7 seconds to instantiate about 500 fairly complex objects that in most any other language, compiled or interpreted would have easily been created in a thousandth of that time.
The Flash VM's garbage collection is perfectly incapable of doing anything that involves long application run-times and leaks memory all over the place, even inside its native low-level components. It got to the point that even doing any proactive cleanup in our code was totally fruitless and I am sorry to add that a lot of the proactive steps we were taking have been left by the wayside because it is utterly hopeless to release all the memory you have taken back to the system.
Loading an SWF inside another SWF and then disposing of it will not stop the loaded SWF's playback and it does not release it from memory. Instead of Adobe fixing this obvious bug they just added a different method in Flash 10 called "unload and stop" or something like that. This requires anyone who wants to fix this issue to go back and refactor their code!
There are also numerous inconsistencies between applications that run in Flash and those that run in AIR, even though the code base is the same and the idea is that you do not have to change any obvious code to make it work in one platform or another.
Even flashes most basic function, doing vector drawings and animations fails horribly under load. We have had to hack and jury-rig numerous fixes in to compensate for Flash's seemingly random graphical glitches.
If Adobe wants to be taken seriously as a application platform developer, especially one that is used on the desktop they need to get their shit together because right now it feels like a childs toy or half-assed attempt to enter a new market.
Unfortunately the project, the client, and the management have chosen this path for us and we are stuck with it so I really hope that Adobe gets it together because its been a royal pain doing this sort of work on their platform.
I don't want to be off topic but... (Score:2, Interesting)
Anyway, compiling C/C++ into the Actionscript VM might start (or reinvigorate) a trend of broader programing language support for VM's. The specific platform that came to mind was Android. One of the main complaints I've been hearing is that developers are contained by Android's own (some say retarded) implementation of Java. I think it would be awesome to see something like a C/C++ compiler for other VM platforms, making it easier for developers to port their applications to a wider range of devices.
Re:Increased performance (Score:5, Interesting)
The point is that the LLVM project can do far more optimization before being compiled to bytecode than Adobe's ActionScript compiler is doing, and as a result it runs faster.
Yes... Adobe's ActionScript compiler sucks at generating bytecode for their own VM, and even they admit it.
Re:Virtualize Everything (Score:1, Interesting)
In an ironic twist, I'm learning compiler theory from one of the professors who worked on it.
Re:Still no contact info, so I'll post here... (Score:5, Interesting)
I don't know first hand, but apparently horse meat is supposed to be very tasty. "The F-Word" (Gordan Ramsay cooking show in the UK) did an episode where they prepared horse meat, talked about the history of horses and talked to a farmer that raises them for their meat etc. It was really interesting.
In one part they were handing out samples near a horse-race track (they do that with lots of "exotic" foods. Go out into public and get people to try it and give their reactions etc.) and got asked by the police to leave. Not relevant but I thought it was funny.
-1 OT
Re:Virtualize Everything (Score:3, Interesting)
OK, sorry to be so hard on you. It turns out that there are copious buttloads of languages that use some sort of bytecode under the hood. The thing that really makes it stick in your mind with Java is just that it's the format that you're expected to distribute your programs in. Contrast that with Python: The reference implementation (CPython) is also a bytecode interpreter. I'm not sure, it may be possible to distribute a python program in bytecode, but I've neither seen nor heard of anyone doing it. Other interpreted languages are currently moving towards a bytecode-based implementation (Ruby is moving to YARV, Perl to Parrot...) and some implementations are even attempting to be self-hosting yet fast.
Google the term "PyPy", for example. It's a daring implementation of Python written in a strict subset of Python called RPython. It plans to use the LLVM infrastructure to eventually become competitive with the performance of the CPython interpreter. Pretty cool stuff!
Re:This is not where Adobes priorities should be! (Score:5, Interesting)
Yes, many times, and no I do not think my code is ever perfect, or even near perfect, but the proof is in the pudding, you can make very simple test cases and see very obvious drawbacks using just their code/UI components.
One of the problems with working with Flex is that sometimes you have to do things that seem incredibly retarded to get things done. Look at the extensive use of the callLater method in a lot of the Flex SDK code. This method basically says "ok things aren't done, so do it later." Not only does this seem to just patch a problem with not correctly sequencing your methods to fire when they are able to, but it creates huge memory leaks and is horribly hard to debug as you rarely can see past the point of the callLater in the stack.
This reminds me of another problem, in the fact that you can not catch run-time errors at the "root/base" level of the Flash/Flex/AIR application, and even better, if you do not have a debug version of Flash player (and forget it in AIR) then it just completely ignores the error and continues on as if nothing has happened. This then causes Flash to start chucking random errors and glitches that might get caught in your own try-catch blocks much, much later, and you will find that code that works perfectly under every imaginable situation is now glitching with really no known cause. Debugging can be quite the nightmare in Flash.
Comment removed (Score:4, Interesting)
A good Javascript isn't all that slow (Score:5, Interesting)
Here are some basic timings I made just to give a rough feel for the relative speeds (don't read too much into them). The first entry provides the timings for C, which is obviously compiled, purely as a basis for comparison with the scripting languages. Note that the times for C are in milliseconds, while the rest are in seconds, lower is better:
Execution times for recursive F/P factorial(n) to
Langs @ 2008 Times: n=1 n=170 difference
C 0.000 ms 0.090 ms 0.090 ms
Lua 0.001 s 0.005 s 0.004 s
Parrot-opt/iterative 0.013 s 0.018 s 0.005 s
Parrot/iterative 0.014 s 0.019 s 0.005 s
V8-Javascript 0.007 s 0.013 s 0.006 s
Ocaml 0.022 s 0.029 s 0.007 s
Python 0.013 s 0.027 s 0.014 s
Parrot-opt/recursive 0.013 s 0.029 s 0.016 s
Mozilla-Javascript 0.001 s 0.018 s 0.017 s
Perl 0.002 s 0.021 s 0.019 s
Nickle 0.031 s 0.065 s 0.034 s
Parrot/recursive 0.014 s 0.056 s 0.042 s
Ruby 0.041 s 0.095 s 0.054 s
Lua_on_Parrot 0.303 s 1.314 s 1.011 s
Although every scripting language is still at least some 50 times slower than compiled C, interpreters and language VMs in general have been improving steadily over recent years, and Javascript in particular is getting a lot of attention now, with more optimizations in the pipeline from all the major players.
The gap will shrink, guaranteed.
[Sorry about the Code posting mode, it's not very easy on the eyes
Re:This is not where Adobes priorities should be! (Score:3, Interesting)
I will say the exact opposite. We made a large enterprise application for a UK health insurer. All interface and logic was flash (not even Flex) with custom-built components. It was a lot better than the alternatives (the initial plan was to use ASPX for the interface). It was nice and fast too (the bottlenecks were on the server). By my last count there were over 200K lines of AS code.
I also made a chess game [flashchess3.com] in AS3. It's not Deep Blue but after optimizations it's fast enough to have fun with (and strong enough to beat you if you're not careful).
Some of the parent poster's comments are valid, but I could bitch and moan the same about PHP, Java or .NET.
Broken unicode input for years (Score:2, Interesting)
Re:Still no contact info, so I'll post here... (Score:3, Interesting)
In one part they were handing out samples near a horse-race track (they do that with lots of "exotic" foods. Go out into public and get people to try it and give their reactions etc.) and got asked by the police to leave.
Probably more due to his poor choice of venue, than because of the meat.
In some countries (such as Luxembourg), horse meat is a very normal thing to eat, with some restaurant's even specializing in it. Nobody thinks anything bad about it.
Germany is fun too: here, some restaurants put up fake signs "we serve horse meat", but that's only to keep the gypsies away...
Re:This is not where Adobes priorities should be! (Score:3, Interesting)
Designflow -- Very Cool (Score:5, Interesting)
More details here: http://www.llvm.org/devmtg/2008-08/ [llvm.org] (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)
While scrolling down looking for the Adobe talk, I found this:
Designflow: using LLVM to compile to Hardware - This project uses LLVM to compile code to a mixed hardware and software implementation. This detects pieces of programs that may be efficiently compiled to VHDL and synthesized them onto an FPGA. The rest of the program is compiled to PowerPC code and uses to drive the FPGA. The system automatically handles data migration and other handshaking between the two systems.
Waaaayyyy more interesting than LLVM for flash. This is cool!!!
Re:A good Javascript isn't all that slow (Score:3, Interesting)
You might be interested in my project Clue [sf.net], which is fairly similar to the Adobe project --- it compiles ANSI C into dynamic programming languages. The current released version does Lua, Javascript and Perl5; the version in SVN also does C and has a half-finished Common Lisp backend as well (code generator is done, but the contributor didn't include a libc).
I'm seeing speeds of about 1/5 of native with LuaJIT. Javascript via V8 is a bit slower. Unaccelerated SpiderMonkey produces about 1/100, and Perl5 is appalling 1/500 of native. Unfortunately, most dynamic languages don't support GOTO, which given Clue's fairly naive code generation spoils performance. (The Javascript backend has to emit a big switch statement in a loop for every function to handle control flowing from one basic block to another.) The Lua back end does nasty bytecode patching tricks to make GOTO work, which I've had to take out of the SVN version because it was just too horrible. Eventually I need to implement some sort of basic block graph reforming system to try and reduce the number of GOTOs in the generated code, but it's a lot harder than it looks.
However, unlike Adobe, all this is running on stock, unmodified VMs --- instead of implementing lots of specialised VM opcodes to make things like byte memory accesses work, I'm bending the ANSI C standard as far as it'll go to make it fit the dynamic world rather better. It's all standards-compliant, but the coding environment is odd: sizeof(char) == sizeof(int) == sizeof(double) == 1; sizeof(void*) == 2. So if nothing else, it'll make a decent testing environment.
Any volunteers to do Parrot, Ruby, Python etc back ends? Better still, any compiler theory gurus who are interested in the basic block reforming code? Nah, thought not...