Transitive bouwt modulaire software-emulator

Het nieuwe bedrijf Transitive heeft een modulaire emulator gebouwd waarmee software voor de ene architectuur gedraaid kan worden op een andere architectuur. Het product maakt hierbij geen gebruik van een directe vertaling, maar van een universele tussentaal. Hierdoor is ondersteuning voor nieuwe platforms relatief eenvoudig toe te voegen. Op dit moment kan de 'universele' emulator - QuickTransit genaamd - software vertalen die geschreven is voor x86, MIPS, Power(PC) of bepaalde mainframes. De software zelf draait op IA-64-, x86(-64)- en Power(PC)-machines, waardoor er dus al een flink aantal combinaties van vertaling mogelijk is. Wired bericht dat het bedrijf tijdens de presentatie van het product Quake III voor Linux op een Apple PowerBook heeft laten draaien, maar ook dat men beweert Xbox-spellen op de Xbox 2 te kunnen laten werken.

De werking van de software lijkt op die van Intels IA32-EL: code wordt in blokken vertaald, en als een bepaald blok vaak wordt uitgevoerd steekt men extra moeite in het optimaliseren ervan. Het bedrijf claimt zo effectief 80% van de performance van de processor te kunnen gebruiken. Vanwege deze snelheid spreekt men zelf liever niet over een emulator - "omdat mensen dat woord associëren met traag" - en noemt de functie van het product: 'hardware virtualization'. Het programma gebruikt afhankelijk van de hoeveelheid lopende software die vertaald wordt tussen de 500KB en 30MB geheugen, en werkt volledig transparant. Er zouden al zes pc-fabrikanten zijn die interesse hebben getoond in het product, maar later dit jaar wordt de eerste naam pas bekendgemaakt.

Reacties (22)

Ik geloof er eigenlijk geen bal van dat veel zomaar met 80% cpu speed draait.

De PPC cpu architectuur is nogal verschillend van de X86 architectuur (niet voor niets heeft het zolang geduurd tot PearPC er was, en PearPC is behoorlijk traag). Een beetje compiler optimaliseerd ferm voor een bepaalde cpu. Dus de code die omgekat moet worden is nogal cpu specifiek. Ladingen overhead imho.

Daarbij komen dingen als alle bibliotheken met bijbehorende calls. Direct3D en QuartzExtrme bijvoorbeeld..

Verder worden er dus 'chuncks' van een binary direct vertaald. Werkt dat wel goed met dirty code: slinkse programmeer truuks die toegepast zijn om snelheid te winnen, maar erg platform specifiek zijn.. ?

Enne specieke OS calls. Zijn alle API's ook meegenomen? Die zijn wel closed source op windows.. Hebben ze alles lopen reverse engineeren ?

80% van de snelheid van de host-cpu is niet onrealistisch te noemen wanneer alleen cpu taken geemuleerd dienen te worden.

En ik weet niet op welke wijze deze emulator precies werkt. Of hij de blocken slechts vertaald naar native instructies. Ook als de blocken vaker gebruikt worden

Of dat hij een block als het niet vaak gebruik wordt gewoon vertaald en als hij een block vaker nodig heeft echt 'decompiled' en compiled. Dan vallen die ladingen overhead in het grooste gedeelte van de gevallen wel mee.

80% is echt enorm hoog voor een emulator(al lijkt de werking hiervan wel anders, de bestaande software lijkt te worden aangepast aan de architectuur in plaats van dat er heel de hardware wordt nagebootst, pin me hier overigens niet op vast). Maar naast de snelheid is ook belangrijk om te weten hoe compatible het programma is met de bestaande applicaties en games. Je kan wel 80% van de performance van een processor gebruiken, maar als 90% van de software er niet mee werkt...

Dit is indrukwekkend

Betekent dat dan dat mensen met een Mac nu gewoon Visual Studio .Net kunnen draaien op OSX, zonder die MS VirtualPC te hebben of blijft dit iets à la VM Ware ?

Uit dit berichtje blijkt dat voor mij iig een héél interessante applicatie. Dan had ik uiteindelijk toch een Powerbook kunnen kopen ^^

Verder stel ik me toch nog een vraagje... Die tussentaal, maakt dat nu zoveel verschil uit ? Nu gaat het van PowerPC > Tussentaal > x86 bijvoorbeeld. Dat heb je toch een nadeel tov PearPC waar het van PPC > x86 gaat . Of zit ik er zover naast ?

Verder stel ik me toch nog een vraagje... Die tussentaal, maakt dat nu zoveel verschil uit ? Nu gaat het van PowerPC > Tussentaal > x86 bijvoorbeeld. Dat heb je toch een nadeel tov PearPC waar het van PPC > x86 gaat . Of zit ik er zover naast ?

Performance technisch gezien heb je misschien wel gelijk, want iedere vertaalslag is er ééntje. maar ik denk dat de reden anders is.

De tussentaal is namelijk het portable gedeelte, een soort virtuele processor zoals de JavaVM. In principe zou Java hiervoor gebruikt kunnen worden.

Het enige wat ze hoeven te doen is nu processor translatie modules te schrijven. Twee soorten, te weten platform<->tussentaal en tussentaal<->emulatie. Hierdoor kunnen ze zeer éénvoudig porten naar andere systemen. Bijvoorbeeld:

MIPS als toepassing
x86 als toepassing
PPC als toepassing

Ze hebben hiervoor 3 modules nodig. Willen ze een andere processor doen, dan gewoon een module erbij.

Daarnaast kunnen ze hun eigen tussentaal op verschillende platformen draaien. Bijvoorbeeld:

MIPS
x86
PPC

Nu hoeven ze alleen maar, bijvoorbeeld een AS/400 module te schrijven en dan loopt alles op AS/400. Wanneer je naar MS Virtual PC kijkt of VMWare dan zou dit veel complexer zijn omdat ze dan meerdere vertalingen moeten schrijven. Voor VMWare zou je bijvoorbeeld krijgen:

VMWare voor Mac, x86 ondersteuning
VMWare voor MIPS, x86 ondersteuning
VMWare voor AS/400, x86 ondersteuning
VMWare voor Mac, MIPS ondersteuning
VMWare voor x86, MIPS ondersteuning
VMWare voor AS/400, MIPS ondersteuning
etc. etc.

Bij Transitive heb je gewoon Transitive voor Mac, AS/400, MIPS, i86 met losse modules.

De disassembly en assembly stappen zijn dan nog het makkelijkste aspect. De pijn komt pas als je de andere hardware specifieke zaken (disk drives, video kaarten enzo) tussen verschillende platforms moet gaan ondersteunen. Het OS en de verschillende runtime omgevingen bieden daar enige abstractie voor, maar het blijft een zeer lastig problem. Het belangrijkste gevolg is dat een dergelijke tool veel platformafhankelijker wordt (OS en/of overige hardware).

Ik denk dat ze bedoelen dat een applicatie geschreven voor een X86 processor werkt op je Apple.

Visual Studio zal gok ik niet snel werken aangezien het appje nogal afhankelijk is van windows.

Betekent dat dan dat mensen met een Mac nu gewoon Visual Studio .Net kunnen draaien op OSX, zonder die MS VirtualPC te hebben of blijft dit iets à la VM Ware ?

Het kan ook de andere kant op gaan werken. Dus Mac software op een x86 bak. Hoef je niet meer perse zo'n dure G5 aan te schaffen.

De huidige emulatoren werken veelal met JIT engines die met name de processor(s) heel efficient kunnen emuleren. Maar wat ze hier doen is het JIT principe uitbreiden met nog een extra optimalisatieslag door in brokken code te werken.
Maar wat ik me afvraag is hoeveel rendement ze uiteindelijk met die optimalisaties halen. Want als je sterk geoptimaliseerde code hebt die door een hele goeie compiler gebakken is dan zal elke interpretatie/vertaling minder snel zijn.
Maar 80% die ze hier beweren vind ik al heel netjes.
Dan zou je met een 3Ghz x86 een 2Ghz PPC moeten kunnen emuleren.

Eigenlijk lijkt het me wel logisch om als computers ongeveer dezelfde hardware gebruiken je dit meeneemt bij de emulatie en gebruikt om je emulatie te versnellen. En ik denk dat ze hier te triviaal melden dat ze hier gebruik van maken. Ik denk dat 3D accelleratie een zeer grote invloed heeft op de performance. Zeker bij Quake III.

De meeste JIT compilers werken ook in "brokken" met code hoor.
Ik vraag me overigens af of dit product een echte JIT compiler is.

Goede kans dat het een "mixed-mode" runtime is, een deel van de code wordt dan wel degelijk "ge-emuleerd", oftwel instructie per instructie vertaald. Dit gaat trager, maar vergt minder voorbereidingstijd (men hoeft niks te compilen of optimizen). Men name voor stukken code die maar 1 keer worden uitgevoerd (bijv opstarten) is dit efficienter.

Andere delen, die vaker worden uitgevoerd worden wel gecompiled (of misschien pas na een paar keer te zijn ge-emuleerd). Hoe vaker een deel gebruikt wordt, hoe meer men kan proberen te optimizen.

Dit zou een flinke opsteker zijn voor Microsoft die op dit moment worsteld met de backwards compatibility van de Xbox 2. Deze zou door een andere hardware structuur niet in staat zijn om normale xbox games af te kunnen spelen.

Dat zou een behoorlijke licentiedeal zijn voor Transitive want dan zet je gemakkelijk miljoenen producten af.

ik wil me niet uitspreken over het product, aangezien ik het nog niet gezien en getest heb,
maar ik denk niet dat MS een licentie afsluit zonder dat ze zeker zijn dat alle(of toch de populaire games) vlekkeloos werken.(jaja...makkelijke prooi voor MS bashers )

Hoe werkt dit?

Je hebt verschillende Operating-Systemen en verschillende processoren. Daarnaast heb je specifieke programma's voor specifieke OSen, die weer op specifieke processors draaien.

Draait het programma als een zelfstandig OS en kun je dan een willekeurige applicatie (bv Winzip voor Windows XP) draaien op een Mac, zonder dat je Windows XP en OSX nodig hebt?

nee, want alleen Linux/Unix wordt ondersteund:

Operating system call mapping from any Unix/Linux-like operating system or any mainframe operating system to any Unix/Linux-like operating system is supported

Voor microsoft is alleen interessant andere OSén op windows te laten draaien, als de software van de andere OSén op windows draait wie heeft die andere OSén dan nog nodig.

Als dit product betaalbaar is zou het een zeer mooie oplossing zijn om behoorlijk platform onafhankelijk te worden en zo alle software overal op te kunnen gaan draaien. Bijv DirectX9 installeren op mn linuxbak/toekomstige powerbook zodat ik windows spellen erop kan draaien Maar ik denk dat MS er een stokje voor zal proberen te steken.

Ff op de site gekeken. Ik merk dat die virtualisatie software alleen geschikt is voor unix/linux programma's te draaien op een ander unix/linux OS dan het voor gecompileerd is en geen win32.

[qoute]QuickTransit for x86. Allows application binaries compiled for a MIPS®, POWER™, PowerPC™ or mainframe processor to run on an x86-based computer. Application binaries compiled for other processors will be supported soon. Operating system call mapping from any Unix/Linux-like operating system or any mainframe operating system to any Unix/Linux-like operating system is supported.[/quote]

Fijn! Eindelijk Doom 3 op mn MSX \o\ /o/

Ik weet dat Amiga hier zo'n vijf jaar geleden erg hard mee bezig was. Die hadden een vertaalprogrammatje dat zo klein was dat het in de cache van de processor paste zodat er nauwelijks performanceverlies optrad. Ze beweerden ook dat de meeste programma's zelfs sneller zouden lopen omdat de vertaalde instructies precies op de processor aansloten, en niet zoals nu 'bijna' omdat software ook compatible moet zijn met andere soortgelijke processoren (denk bijvoorbeeld aan MMX en AMD Now!).

Je programmeerde toen voor een algemeen (virtueel) platform Amiga, met bijbehorende assembly code. Voor elk fysiek platform zou er dan een vertaalmodule komen:
amiga->intel p3
amiga->ppc
amiga->alpha
etc.

Idem voor videokaarten, input/output, etc.

Was veelbelovend, heb het ook werkende gezien, jammer dat er nooit meer iets van vernomen is.