Dynamic Cross-Processor Binary Translation

GFD writes: "EETimes has a story about software that dynamically translates the binary of a program targeted for one processor (say x86) to another (say MIPS). Like Transmeta they have incorporated optimization routines and claim that they have improved execution times between one RISC architecture and another by 25%. This may break the hammer lock that established architectures have on the market and open the door for a renaissance in computer architecture."

Comments

Dynamic Recompilation

[Anonymous Coward]

This sounds an awful lot like the dynamic recompilation of MIPS to x86 done in many emulators (such as UltraHLE, Nemu, Daedalus and PJ64).

I've been working on the dynarec for Daedalus for about 2 years now, and currently a 500MHz PIII is just about fast enough to emulate a 90MHz R4300 (part of this speed is attributable to scanning the ROM for parts of the OS and emulating these functions at a higher-level). Of course, optimisations are always being made.

After reading the article, I'd be very interested to see if they can consistently achieve the 25% or so speedups that they claim (even between RISC architectures).

For those interested, the source for Daedalus is released under the GPL.

Re:HP Dynamo project

[woggo]

whoops! that's supposed to say

Dynamo dynamically optimizes binaries; an equivalent in the Java world is IBM's Jalapeno VM. Unfortunately, the Dynamo approach is only feasible on the HP architecture, and it is only feasible on HP-PA because the PA-RISC chip has an absurdly large i-cache (greater than 1 mb). Look at HP's Dynamo site for more information, but IIRC the problem is dynamo's extremely aggressive branch prediction.

damn slashcode...

Re:-yawn-

[lostguy]

ahem. Ignorance does not equal proof.

To quote:

The performance results of Dynamo were startling. For example, Dynamo 1.0 could take a native PA-8000 SpecInt95 benchmark binary, created by the production HP PA-8000 C compiler using various optimization levels, and sometimes speed it up more than 20% over the original binary running standalone on the PA-8000 machine.

That's binary translation from/to the same machine.

This is basically run-time instruction block reorganization and optimization, which can definitely improve a given binary on a given machine, over compile-time optimizations. Admittedly, a native binary, run through this kind of profile-based optimizer, will probably be faster than a translated-then-optimized binary, but neither you or I can state that with any authority.

Humorous context...

[Durinia]

...the subject program in the form of what Transitive calls "directed acyclic graphs."

Wow! What innovative technology! I wonder when they will patent this so-called "directed acyclic graphs". And they picked such a cool name! It sounds so mathematical!

Okay, enough laughing at the expense of clueless reporters...

HP Dynamo project

[dmoen]

This sort of technology has been around a long time. HP's Dynamo project has been running since 1995. When Dynamo is run on an HP PA-RISC and is used to emulate HP PA-RISC instructions, speedups of up to 20% are seen. That's pretty astonishing: you would think that emulating a processor on that processor would be slower, not faster.

Doug Moen.

Solutions in search of a problem

[Chairboy]

While this is fascinating sounding technology, it sounds more like a solution in search of a problem. There are already software solutions for emulation (SoftPC, VMWare, etc). There are already cross platform language solutions (Java, etc) and so on. Despite this, the market for massively cross platform applications has not really developed. It isn't as if a 25% performance increase is whats holding back the 'rennaissance' the author speaks of.

Re:All Roads Lead to Open Source

[egomaniac]

I realize that Slashdotters love to trumpet the Open Source horn, but this comment is absurd. "Open Source" != "runs on all platforms".

The amount of work necessary to get a complicated X app running on many different flavors or Unix is certainly non-trivial, and that's just *one* family of operating systems. And it either requires distributing umpteen different binaries or requiring endusers to actually compile the whole damned program. All well and good for people whose lives are Unix, but do you *seriously* expect Joe Computer User to have to compile all his applications just to use a computer? ("how hard is it to type 'gmake all'?" I hear from the audience... as if you'd expect your grandma to do it, and you've *never once* had that result in forty-six different errors that you had to fix by modifying the makefile. make is not the answer)

The problem of having a program run on multiple platforms is not "caused by closed standards in the first place" as you state. It is caused simply by having multiple standards -- closed or open makes no difference. SomeRandomOpenSourceOS (TM) running on SomeRandomOpenSourceProcessor (TM) would have just as much trouble running Unix programs as Windows does. This is a great solution to a real problem; don't knock it just because you have a hardon for Linux.