Feeds

Adobe adopts Alchemy for Microsoft .NET mindshare

Feel the burn

The essential guide to IT transformation

Adobe MAX Europe Adobe Systems has provided more details on a research project that converts and compiles C and C++ to ActionScript and brings raw speed to the Flash virtual machine.

Alchemy enables re-use of existing C libraries within the Flash runtime. Examples shown here at MAX Europe include OpenSSL encryption code, code to generate image files in PNG format, and code to preview PDF documents in Flash. Part of the rationale is that there is more open-source code in C or C++ than in any other language.

It turns out that code re-use is not the only reason to take an interest in Alchemy. The other reason is performance, since Alchemy code generally runs substantially faster than manually written ActionScript, up to around 30 per cent of the speed of native code.

This means you might also use Alchemy to optimize Flash applications, and Adobe Flash Player engineer Jim Corbett said he expects this kind of usage to be common. But why is Alchemy code faster? And why has Adobe not optimized the ActionScript runtime to run normal code equally well?

The answer is Alchemy code runs in a different way. ActionScript 3.0 is a modern garbage-collected language similar in many respects to Java or C#. This imposes a performance overhead, and Scott Petersen, who developed Alchemy, found his early experiments impossibly slow as a result.

Adobe solved this by adding a special per-application byte array in the Flash 10 player. This becomes the memory available to Alchemy code. "All the code does is jump around a byte array," according to chief scientist Mark Anders. The consequence is that the code runs up to 25 times faster, but the developer has to manage memory just as with native C programming.

That said, errors like buffer overruns or memory leaks, while they may crash the Alchemy application, should not have wider consequences. "All the security stuff works exactly as it does in ActionScript today," said Corbett.

There are other reasons why Alchemy code runs faster. The project uses the Low-Level Virtual Machine (LLVM) compiler, an open source project that compiles C and C++ to optimized intermediate code. Alchemy then compiles this intermediate code to ActionScript, which is not human-readable. "The LLVM tools optimize a lot better than the ActionScript tools," Corbett said.

Alchemy opens up a number of intriguing possibilities. One is support for other dynamic languages within Flash, using existing open source interpreter code.

"We've been working on Ruby and Lua and even Java," Corbett told MAX. It is also ideal for number-crunching algorithms and will be eyed with interest by game developers.

It glitters, but it 'ain't gold

Unfortunately, there are some snags. One is that all applications that use Alchemy include the compiled version of the C standard library, which adds around 140K to the download size. It is possible that Adobe will create a signed version of this library, enabling it to be installed in a local cache where it would be shared. However, apparently all Alchemy code is poorly optimized for size as yet.

Another problem is that while Alchemy code itself is fast, marshalling objects across the boundary between normal ActionScript and Alchemy code is slow and difficult to code, though there is a wrapper library called GlueGen that simplifies this to some extent. It is not suitable for applications that make a lot of these transitions. Debugging is currently primitive. Adobe will not say when Alchemy will be ready for production use or even if it will ever make it out of the Adobe Labs research area - though given the high level of interest that seems likely.

This is also a project that may help Adobe in its battle with Microsoft for developer mindshare. Silverlight's .NET runtime executes non-visual code faster than ActionScript in some tests, but probably not as fast as Alchemy, and if Adobe delivers the ability to execute other dynamic languages via an Alchemy interpreter, that could be an answer to Microsoft's Dynamic Language Runtime for .NET. ®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
China: You, Microsoft. Office-Windows 'compatibility'. You have 20 days to explain
Told to cough up more details as antitrust probe goes deeper
BBC: We're going to slip CODING into kids' TV
Pureed-carrot-in-ice cream C++ surprise
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
Scratched PC-dispatch patch patched, hatched in batch rematch
Windows security update fixed after triggering blue screens (and screams) of death
This is how I set about making a fortune with my own startup
Would you leave your well-paid job to chase your dream?
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Advanced data protection for your virtualized environments
Find a natural fit for optimizing protection for the often resource-constrained data protection process found in virtual environments.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.