Slashdot Mirror
Universal Emulators Return
webmilhouse writes "Wired has an article about Transitive Corporation that claims their software "allows any software application binary to run on any processor/operating system" without any performance hit. That would allow any program written for Windows to run on Linux or Mac, and vice-versa, which Wired likened to digital alchemy. The Transitive software is supposed to be released today. What do you think, vaporware or miracle?"
In demonstrations to press and analysts, the company has shown a graphically demanding game -- a Linux version of Quake III -- running on an Apple PowerBook.
I'm sorry, but that's just not impressing me. Not to mention that there's already a native Mac OS 9/X port of Quake III, but it's not even the most system-dependent code that I can think of.
When I can run Office 2003 natively inside Linux then we can talk.
Okay, but for a product that really is this good, why is the newest news on their site dated March 2003? (There's an article in 04, but it has nothing to do with what they're releasing)
They're talking about recompiling sections of critical code, like java's HotSpot. It'll be interesting to see how fast it ends up - the startup time is a pain in java, but it's pretty decent after that. I can't find a source for the "no performance hit" bit. It looks real, and quite impressive, but not exactly what the summary indicates ;-)
Free Java games for your phone: Tontie, Sokoban
Yeah, obviously!
QuickTransit fully supports accelerated 3-D graphics and about 80 percent computational performance on the main processor. It requires no user intervention: It kicks in automatically when a non-native application is launched.
It sounds like it is software that translates one machine language to another? Pretty sweet idea!
It will still have some java-ish problems with each different form of hardware needing a unique version to translate. And then updating each of those versions as each change in the operating systems occur, etc.
Davak
There is NO F-IN way that BIG BUSINESS would have EVER let this even GET to the starting gate, much less be this close to release.
.02.
Think of it....
This would put a date-of-expiration on MS's BILLIONS.
I predict:
1 - Windows will team up with hardware vendors (Dell, HP, IBM) and give them incentives to make this NOT work
2 - Office prices will skyrocket (don't know how that's possible, but it will to prevent this) UNLESS you have a valid Windows license
There are so many GREAT things that can happen with this, but I predict that too many politicians and big-business big wigs are wise to what this will do and will NEVER let this happen.
Just my
Just take Alan Turing's original Turing Machine. It can be proven that certain algorithms, like a binary search, will take an algorithmically longer time on a Turing's machine than on your standard x86 processor.
Binary search is logarithmic time on a normal processor, but it is at least quadratic time on Turing's machine.
Therefore, I have found a counterexample to their claim.
PS: Turing's machine used an infinite tape and that tape could only be moved 1 space per cycle. Most of the time spent in the binary search will be moving the tape around.
very true :)
take a look at what they're demonstrating, too. Linux Quake 3 on a Powerbook... and Linux GIMP on a Windows machine. These aren't really things that can't be done already today.... but that may be just that the article doesn't go into a lot of depth. Show me Windows Quake 3 running on a Powerbook, now that would be something a little more impressive.
It will be interesting to see the software in any case, and see whether it really does live up to the promise. Because if it does, they're right, it's comp sci's equivalent of turning base metal into gold.
-- james
what about api calls which are native to windows, or even directx applications, I don't think that they will be able to "emulate" all this without a performance hit (or at all for that matter).
Or are they just talking about the processors and their native instructions?
Time is the only precious thing I've got left; Don't waste it
...they'll soon be sued away by the likes of Microsoft and Apple, both of whom have an established interest in maintaining the status quo.
It sounds like a virtual machine they've created for each host operating system and "virtualized" operating system. While possible - see WINE and the lately not heard from David project - this would require quite a bit of work. Hell, trying to emulate Linux in this way would be a hoot. Which window manager do you want to emulate today?
I think it is mostly vapor. Enderle, the famed SCO analyst, has his hands in it and I immediately distrust anything he works with and endorses.
(I just found out that my sister's ex-boyfriend's brother is one of the major financers of the Phantom. How's that for being close to slime?)
My reality check bounced.
In demonstrations to press and analysts, the company has shown a graphically demanding game -- a Linux version of Quake III -- running on an Apple PowerBook
Does this company realize that proper existing ports of each of those particular pieces of software exist in some kind of native form for those architectures? I've used GIMP in Windows w/ no problems. Also, as mentioned previosuly, Quake III already exists for the Mac as well. What good are they doing by using software that already exists in ports? I want to see a copy of some DirectX game running on a Mac/Linux w/o a performance hit. This company so far has not proven anything by using the two comparisons cited in the article.
The "pretty darn impressive" examples given are GIMP under Windows and Quake 3 on Mac. Both of those have completely native versions available. I smell something not quite honest about these demos.
there is mention only of unices. Operating System Mapper. Dynamite supports operating system mapping between any two Unix/Linux-like operating systems, as well as mapping between mainframe and any Unix/Linux-like operating systems. Don't see "Windows" mentioned in there. I assume it would be a lot easier to run a Linux version of Quake 3 on BSD-based Mac OS X than to convert stuff to/from a rather more different OS such as Windows.
The summary should almost be modded flamebait for making such an obviously impossible statement like that.
So what's really up here? TFA says they demonstrated running a Linux Quake III on a OS X powerbook.
(And they quote Rob Enderle praising this technology.. this is the guy who thinks SCO will win, which speaks loads for his credibility.)
Now, I haven't seen the source for Quake III, but I'm pretty certain it uses OpenGL, which the Mac has. OS X is also POSIX-compliant. So, most of the API calls done by Quake can already be done natively on OS X.
So what I guess they're doing here is translating API calls (like Wine) while emulating the processor core (like a real emulator).
That isn't anything new. For instance, I've written similar code for an Atari emulator, which can emulate an Atari hard-disc filesystem as a local directory through translating OS calls.
(Note: And that was far from the first time it'd been done either.)
So many times with a product like this they will boast something amazing, but then in the small print you find something to the effect of "for this product to function as described, you must meet the following requirements....". Such requirements always seem to be very obscure or hard to meet, leading to a product which does not do exactly what it says it does.
A somewhat related example is Unreal Tournament 2003 for Linux. It works, but only if you have a GeForce. Granted, that's not an outlandish requirement since nVidia cards work well on Linux anyway, but you get the idea.
-illumina+us "I put on my robe and wizard hat..."
When reading that part of the article, I do recall that DEC once touted an alpha "feature" where pages of memory could be marked as foreign, and when faulted, could be ran through a translator that turned x86 code into alpha code, and then cached the result on disk for future loads. This allowed the Alpha port of NT to run some (maybe many) x86 native apps, with a bit of initial overhead, at near native speed. Of course it also required hardware support in the Alpha MMU to accomplish this. \
You don't need to translate OS calls if you license the other operating system and run it behind the scenes. OS2 provided flawless Win16 emulation by this method.
-m
I think you're the only one who has interpreted their claims that way. I don't think Wired would bother writing up a company that claimed it could run Office on a C64.
Support the First Amendment. Read at -1
The website says "...supports operating system mapping between any two Unix/Linux-like operating systems, as well as mapping between mainframe and any Unix/Linux-like operating systems...". This would suggest that there is no mapping between windows and unix...
It simply doesn't matter. If the program works, Microsoft will simply buy it and bury it. If it doesn't work, then who cares!?
If someone says he and his monkey have nothing to hide, they almost certainly do.
Since TFA is a worthless content-devoid POS, and since the transitive website is /.ed, here is
a useful link on HOW they claim to do it. It
sounds plausible, at least.
http://66.102.7.104/search?q=cache:KjTa-qAM7LQJ:ww w.transitive.com/technology.htm+site:www.transitiv e.com+-qwerty&hl=en
If their claims were really as true as they say, they would have been brave and they would have chosen Doom III or something like that. Quake III on a Mac-- not so very impressive.
Needing a license to use the software because your CPU makes a copy of the program in the RAM makes no sense at all. Especially since most software cannot even fit entirely into RAM. If I am not mistaken licenses cleary state that you are licensed to install this program on one machine at a time only. If you choose to install it on another machine you must remove the copy from the aforementioned machine. It says nothing about the program being processed in the computer's memory. The license is for you to install it onto your harddrive and execute it for your purposes. Most licenses also allow you to make backups of your software for your own personal use.
The reason you need a license for the software is because that software is copyrighted and in order to use or display copyrighted material you need to have a license for it. Music and video that you purchase at the store has an implied EULA type agreement too. Just because you don't see it doesn't mean you are not bound by it.
-illumina+us "I put on my robe and wizard hat..."
So dos that mean I have to now fear the latest Windows virus on my MacOSX box? Sounds like another reason to hate Microsoft.
Remember when the Alphas first came out? DEC had a re-compiler that took your old VAX VMS binaries and translated them to run under Alpha VMS. Same OS, different machine architecture. It actually worked quite well. They also had a re-compiler that took Sparc-SunOS4 binaries (I think, it wasn't Solaris 2.X was it?) and generated Alpha-DEC-OSF/1 binaries. I don't think they actually sold that, but it made the rounds in universities. It was good enough to run WordPerfect for SunOS on an Alpha.
I gots two words for ya: "register starvation"
Why not fork?
/obvious
What would be truly impressive would be running, say, Wolfenstein3d Mac on an x86 box, with reasonable speed. That would be far more difficult.
Thanks to Basilisk II, I think I'm on level 20 on the Mac version of Wolfenstein 3D while I play it on my x86. The JIT compiler seems to work right in the Windows version, so I get a decent speed (about 30-40 fps) in the game. It crashes every once in a while, but the Linux version seems to be better behaved, although much slower since the JIT compiler doesn't behave well with the assembly that draws the walls in the game.
It would be cool if it didn't suck.
I'm aware that VirtualPC is an emulator, I meant that demoing Windows on a Mac is something that can be accomplished without writing a line of code. If this is truely not vaporware, I'd want to see an interactive demo of something that hadn't yet been accomplished such as Mac on Windows (though I see, from another poster, that too has been nearly accomplished).
It says specifically "QuickTransit fully supports accelerated 3-D graphics and about 80 percent computational performance on the main processor" - that's 80% performance. Later, it says "The power user might notice the difference, but the other 95 percent won't notice.""
This means that there IS a performance hit, just that they don't expect the average user to notice (probably rightly so).
picpix image polls. create - share - vote. fun!
Don't those applications that they were running( Quake3, Gimp) have native ports.
I'm not saying its vaporware, but I could see someone trying to show off the software using the native ports instead of the "hardware virtualization"
It would obviously be more impressive/credible if they tried it on programs sans native ports.
A couple of friends of mine work for transative. I know there are a lot of smart guys there (top of class masters, phds, lecturers). My mates have been very secretive when i've been asking them what there up to for more than a year now and have said it will be a big thing when it comes out. I also know getting binaries to run on different systems is their speciality. So i know the company isn't vapour and neither are their employees (or their swanky city centre flats). I believe the program isn't complete vapour either, but how well it lives up to it's claim of any binary on any machine...i don't know.
There was a translation solution in place back in the early 90's: Apple was working with a company called Echo Logic (probably not in existence today; please don't /. the logical URL!), a spin-off of Bell Labs, that could convert 68K binaries to PowerPC as an approach to migration to PowerPC.
I worked with them for a while to see if we could port our application (which would have required tons of work to re-compile for PowerPC); the technology was impressive, but aspects of our code gave it fits (trap patching, and dispatch tables that were effective self-modifying code).
The EL technology identified code blocks in the binary, built an intermediate representation of all the effects of each code block, and translated it back to binaries in the target architecture. Theoretically feasible, but computationally very expensive. In some test cases, the translated code was in fact more efficient from the original, because the software was able to detect unused output of a code block, and re-code the block to eliminate the unused "side-effects."
Ten+ years later, maybe somebody has more of the gnarly problems worked out. But I would bet there are issues that can't be solved with technology; i.e., the binary software on the "source" system. Presumably you can find and translate the system binaries to build a translated app, but wouldn't this constitute "reverse engineering" that most software licenses prohibit?
Yep, none of this is new tech. In fact, it's pretty old tech at this point. Emulators/translators and everything in between have been the subject of experimentation for decades.
Actually, I expect to see someone sit down and write this for Parrot sometime soon. Especially of interest would be an S/390 emulator written in Parrot.
Parrot, for those who don't know, is a VM that targets very high level languages, but it's flexible enough and has a sufficiently strong JIT compiler that a hardware emulator extension to Parrot could easily produce code that would perform as well as the described product.
The cool part about writing such an emulator for Parrot is that you get access to the resulting emulated code from a number of high-level languages, so you could port over your S/390 airline application written in TPF and call its routines from a Java, Perl, Scheme or Ruby program, jumping into and out of hardware emulation as you go. While high-level languages would only have gross access to data as opaque objects, the hardware emulator could provide the ported code with everything that it expects.
"Emulation" is a sophisticated art at this point, and it's going to get very interesting over the next few years.
I really wish this RISC/CISC myth would just die. Just about every desktop processor nowadays is a RISC/CISC hybrid, including the Pentium 4 and PowerPC 970.
I'll wager that if I took something like "Quicken" or "Microsoft Office Professional" for Windows and tried to run it on a Mac running QuickTransit that it certainly wouldn't work. I doubt if iMovie would run on a QuickTransit-enabled PC. THAT, my friends is the "computer-alchemy" goal. Of course, I would LOVE to be proven wrong on this!
Now, if they are talking about "any program written for Windows [that adheres to QuickTransit Requirements] to run on Linux..." then they may be accurate, but again, this really isn't "universal emulation".
My mom always said, "Jim, you're 1 in a million." Given the current population, there are 7000 of me. God help us all!
Lessee, the Universal Turing Machine required exponential slowdown to emulate absolutely anything. Emulating CISC on RISC is going to take a linear slowdown (expanding some operation into the X fundamental operations). Heck, if this emulator even looks at the program it's emulating, it has to read program P of size N; it can't run itself in constant time C and then run the program it's emulating as if it were native. Unless the miracle is that in constant time C this emulator transforms your system into one native for the program.
:)
I'd like to test this program by emulating a program written for a Cray. Love to have my p.o.s. top-of-the-line-for-1998 transformed into a Cray.
Yes, we understand these tags always apply: fud, dupe, typo, slashdotted, topic name
What are you trying to say? That a horse is not a horse if you look at it from the ass end? That's silly! If the code was written for a CISC processor and you run it on a RISC processor, it HAS TO take extra clock cycles to tranlate the complex instructions back to reduced instructions. It cannot happen magically and software actually takes clock cycles to run so the emulation has to provide a performance hit in itself. It's simply self delusional to accept anyones claim in this area as truthful. It is a claim that you can get more energy out than you put in. It cannot happen. You cannot make hamburger from steak without putting energy into the crank to turn the grinder. Yes it's still all beef, but it takes extra effort to change it from one packaging to the next. (Silly Goose!, or is it Silly Goose Meat!)
I wonder if it would be any easier to make a binary-to-binary translator on the same architecture? The idea would be to translate legacy i386/i586 binaries to take advantage of the latest CPU extensions.
Any complicated self modifying code could be left the same if the program could at least spot it reliably. It might even be possible to translate to 64-bit at the cost of a few "x &= 0xFFF..." instructions around shift operations.
After reading the article, I personally see the whole issue as much ado about nothing. The quotes provided in the article leave me with the impression that those who were involved with the article had little experience with emulators or were quoted out of context. I think this is obvious given remarks like "One of the key breakthroughs is an 'intermediate representation'..." that imply revolutionary thinking when in fact the ideas are not new.
I'm sure their product does whatever they designed it to do, but the article alludes to platform migration and operating system virtualization. This screams out to me that the emulated programs are going to be very well behaved out of necessity, and most hardware interfaces will not be accessable except through API calls. Additionally, desktop PC software and operating environments tend to be much more 'regular' than embedded systems like game consoles. It is much easier to describe the behavior of user-mode code on a platform with a generic memory space and API set than it is to describe the behavior of an embedded multiprocessor system with control registers, DMA, custom graphics and audio subsystems and banked memory.
I also have to question the allegation that "no one has successfully developed an emulator for multiple processors and operating systems." Dynamic recompilation is not new. Intermediate representations are not new. Surely there exist some emulators which are capable of emitting multiple native instruction encodings in the backend. If none exist, I doubt it is because they are not capable of doing so.
Describing a processor architecture and providing an API mapping is not a trivial task by any means. The Transitive tool doesn't just 'simply work,' its requires a massive undertaking to prepare the behavior descriptions that I imagine would be in some ways more difficult than writing an ad-hoc single-platform emulator. I think that calling their tool a "hardware virtualizer" is probably a good idea, but not because its faster than an "emulator," but more because its likely nowhere near as powerful as a system emulator.
Finally, I would also beware the performance claims. Dynamic recompilation is certainly the way to go for ultimate performance, but when you generalize architectures, you often lose the ability to take advantage of native features. Also related to processor capabilities, the overhead incurred by emulation is highly correlated to the disparity between the host platform and the emulated platform. Transmeta processors suffer about 20% overhead and thats using a flexible VLIW architecture designed with x86 emulation in mind and using a dynamic recompiler that supports *only* x86. Thats a huge performance penalty, even if programs are running as fast as needed. Given the generalized emulation approach, I think its clear that the feasibility of such an approach is going to depend heavily on the host platform being more powerful/flexible than the emulated platform.
FWIW, I am the author of Nuance, the Nuon emulator. Nuance currently performs all of the same feats listed in the article including block translation, optimization and 'OS' virtualization (native implementation of the Nuon BIOS). I'm currently working on emitting native code using a custom x86 run-time assembler and backpatch mechanism.
although there's a slightly more optimistic version later on:
from here.
It's the first statement which got the most oxygen at the time, understandably. But just because they have a current port doesn't mean it makes commercial sense to release it for a large company. The Linux version is in the same boat with regards to a commercial release...
deus does not exist but if he does