Fujitsu claimt ontwikkeling snelste ARM-simulatieplatform
Fujitsu heeft nieuwe simulatiesoftware ontwikkeld waarmee multicore ARM-processors op een pc gesimuleerd kunnen worden. Hierdoor zouden ontwikkelaars sneller systemen kunnen ontwerpen die ARM-processors gebruiken.
De ARM-simulator van Fujitsu gebruikt een just-in-time-compiler voor het verwerken van ARM-instructies op een x86-processor. De simulaties zouden tot honderd maal sneller draaien dan bestaande ARM-simulatoren. Hierdoor kan een ontwikkelaar volgens Fujitsu op cycle-level-niveau een simulatie draaien, waardoor de ervaren snelheid overeen zou komen met de daadwerkelijke prestaties op een ARM-processor. De afwijking in de gesimuleerde kloksnelheid zou niet meer dan vijf procent bedragen, terwijl ook multicore-simulaties gedraaid kunnen worden.
Volgens Fujitsu kan zijn nieuwe simulator-software helpen bij het sneller ontwikkelen van systemen en software die gebruik maken van ARM-processors. Deze energiezuinige processors worden door een groot aantal fabrikanten gebruikt in onder andere tablets, navigatie-apparatuur, televisies en mobiele telefoons.
Reacties (25)
Heel goed nieuws, want de huidige android emulator is tergend traag..
Je hebt toch een Android x86 project? Dan knal je dat op de simulator. Voor een high level taal zou dit namelijk geen verschil moeten maken en aangezien je het toch in een soort van Java maakt lijkt me dat handiger.
Voor iOS is de emulator wel gewoon x86. (iOS is een afstammeling van OSX, en draait ook op x86). Een nadeel hiervan is dan weer dat het juist vaak sneller is dan het toestel zelf.
Maar uiteindelijk moet je natuurlijk ook altijd op het toestel zelf testen, een simulator / emulator is maar een hulpmiddel.
Voor iOS is de emulator wel gewoon x86. (iOS is een afstammeling van OSX, en draait ook op x86). Een nadeel hiervan is dan weer dat het juist vaak sneller is dan het toestel zelf.
Maar uiteindelijk moet je natuurlijk ook altijd op het toestel zelf testen, een simulator / emulator is maar een hulpmiddel.
IOS draait niet op x86 maar op ARM gezien de A5/A5x processoren voorzien zijn van een ARM V7 instructieset: http://en.wikipedia.org/wiki/Apple_A5
Dat het gebaseerd is op OSX klopt, maar net als vele *nix systemen kan je het compileren voor meer dan 1 processor 'platform'
Dat het gebaseerd is op OSX klopt, maar net als vele *nix systemen kan je het compileren voor meer dan 1 processor 'platform'
[Reactie gewijzigd door ultimasnake op dinsdag 13 maart 2012 21:32]
iOS zal echt wel draaien op x86, het wordt alleen niet zo verkocht (Apple verkoopt z'n OSsen überhaupt niet). Ze hebben bewezen dat ze OS X ook al sinds de eerste versie stiekem op x86 draaien. De structuur van de bibliotheken is hetzelfde op iOS en OS X, dus een emulator schrijven die op OS X draait zal niet heel moeilijk zijn, omdat de OS X kernel in principe prima overweg kan met de structuur van een iOS executable.
Dat was niet zo stiekem hoor, al voor osx uitgebracht was was al duidelijk dat er iig van de mach kernel een x86 versie bijgehouden werd door apple.
De iOS simulator voor developers is gewoon x86 iOS op de desktop.
en dan moeten er ook nog beter drivers komen om de grafische chip ook te emuleren.. dat kost ook nog veel inspanning voor goede drivers daarvoor te maken hoor.
Apart overigens. Eerst werd x86 op andere (arm/mips/alpha) geemuleerd, en nu is het juist andersom. grappig.
Apart overigens. Eerst werd x86 op andere (arm/mips/alpha) geemuleerd, en nu is het juist andersom. grappig.
Knap werk, mijns inziens. De meeste ARM-processors hebben (als ik het goed heb) een Von Neumann-architectuur, wat wil zeggen dat je data en instructies theoretisch gezien niet kan onderscheiden, en je vanuit je programma dynamisch de instructies kunt aanpassen ( = zelfaanpassende programma's).
Ik ben dan ook erg benieuwd hoe ze hiermee omgaan in het translatieproces. Ik kan me voorstellen dat dat behoorlijk lastig is voor bijvoorbeeld gecomprimeerde executables (bijvoorbeeld met UPX), en die genoemde 5% is wel een heel strakke marge!
Ik ben dan ook erg benieuwd hoe ze hiermee omgaan in het translatieproces. Ik kan me voorstellen dat dat behoorlijk lastig is voor bijvoorbeeld gecomprimeerde executables (bijvoorbeeld met UPX), en die genoemde 5% is wel een heel strakke marge!
Dat is wel redelijk goed op te lossen in software. Je kan bijvoorbeeld je getransleerde memory pages beschermen en als daar naar geschreven wordt via een page-fault handler daar op inspelen. Dit soort technieken worden ook in VMware gebruikt (of althans in oudere versies voordat de virtualisatie extensies gemeengoed werden), aangezien dit ook dynamic instruction translation gebruikte om bepaalde x86 instructies die niet goed virtualiseerbaar waren alsnog te kunnen ondersteunen.
[Reactie gewijzigd door Squee op dinsdag 13 maart 2012 20:55]
Dank voor de toelichting.
Men claimt echter een marge van 5% in de kloksnelheid te hebben, en het afhandelen van page faults (en daarmee eventueel opnieuw JIT-compilen) lijkt me redelijk processorintensief - als ze daadwerkelijk een oplossing hiervoor hebben (en dit niet gewoon in de cijfers weggemoffeld hebben) heb ik goede hoop voor andere virtualisatieomgevingen.
Men claimt echter een marge van 5% in de kloksnelheid te hebben, en het afhandelen van page faults (en daarmee eventueel opnieuw JIT-compilen) lijkt me redelijk processorintensief - als ze daadwerkelijk een oplossing hiervoor hebben (en dit niet gewoon in de cijfers weggemoffeld hebben) heb ik goede hoop voor andere virtualisatieomgevingen.
Nou ja, die 5% zal je ook niet hebben op dat soort self-modifying code wat je als voorbeeld aanhaalde. Maar wat het natuurlijk wel is dat er een grote lokaliteit zit in instructie data; bijvoorbeeld functies die vaak aangeroepen worden. Als die eenmaal getransleerd zijn dan hoeft dat niet keer op keer opnieuw te gebeuren. Vergeet ook niet dat de x86 gemiddeld op een 3x zo hoge clock lopen dan de ARM cores, dus ik denk dat ze daar een heleboel mee op kunnen vangen.
Het is zwaar verboden om instructies aan te passen en als je dat toch doet is niet gegarandeerd.
Dus hier hoeven ze niet mee om te gaan.
Als mijn geheugen me niet in de steek laat kunnen geheugen pagina's met instructies en die met data in principe onderscheiden worden en kan het hardwarematig verboden zijn om data instructies op instructie geheugen toe te passen.
Dus hier hoeven ze niet mee om te gaan.
Als mijn geheugen me niet in de steek laat kunnen geheugen pagina's met instructies en die met data in principe onderscheiden worden en kan het hardwarematig verboden zijn om data instructies op instructie geheugen toe te passen.
Tuurlijk is het wel toegelaten om instructies aan te passen! Een processor weet namelijk niet of een instructie nu komt van een net-ingeladen ('origineel') programma, of van een aangepast programma.
Het enige dat je moet doen is de cache leegmaken zodat je zeker bent dat de processor opnieuw de correcte (aangepaste) code uitvoert, en niet een eventuele oude versie die al in de cache stond...
Het enige dat je moet doen is de cache leegmaken zodat je zeker bent dat de processor opnieuw de correcte (aangepaste) code uitvoert, en niet een eventuele oude versie die al in de cache stond...
ARM-processoren hebben nog altijd instruction caches, dus als je self-modifying code wil gebruiken moet je toch altijd een cache clean interrupt uitvoeren (waar de VM dan op kan hooken en de nodige code her-JITten).
Kon het nergens terug vinden, maar kan dit principe ook werken voor andere architecturen? (zoals PowerPc, Itanium of MIPS)
Ik zie geen reden waarom een andere RISC-architectuur niet op deze manier gesimuleerd kan worden. CISC lijkt me weer wat lastiger, omdat bij non-compatible instructies het aantal instructies flink kan exploderen.
Hoe dan ook, JIT-compiling is inmiddels een veelgebruikte techniek. Deze wordt naast het in dit artikel genoemde doel ook gebruikt om bijvoorbeeld snel Javascript te draaien in je browser, en voor allerhande andere toepassingen.
Hoe dan ook, JIT-compiling is inmiddels een veelgebruikte techniek. Deze wordt naast het in dit artikel genoemde doel ook gebruikt om bijvoorbeeld snel Javascript te draaien in je browser, en voor allerhande andere toepassingen.
Moderne CISC implementaties hebben een HW translatie naar een interne RISC architectuur. x86 is daardoor een soort Esperanto geworden: de moedertaal van geen enkele chip, maar elke Intel & AMD verstaat het wel. Het gevolg is dat complexe CISC instructies overal langzaam zijn, en een software CISC interpreter heeft daar dus geen bijzonder nadeel.
Ja dat werkt inderdaad vrij goed, zo hadden de Transmeta CPUs indertijd een VLIW core terwijl ze wel x86 instructies ondersteunden. Dit werd ook door een JIT engine gedaan om de code van x86 on-the-fly naar de VLIW instructieset om te zetten.
Dit zal zeker ook werken voor een andere architectuur. Het is wel de vraag of het zinvol is, buiten het geval dat je geen beschikking hebt over de betreffende architectuur.Kon het nergens terug vinden, maar kan dit principe ook werken voor andere architecturen? (zoals PowerPc, Itanium of MIPS)
Hoe dan ook er zal een uitboeting op performance zijn. Zowel PowerPC/Power als Itanium doen niet onder voor een x86.
Ik vraag me eerlijk gezegd, buiten dat het een prestatie van Fujitsu is, af wat het nu van deze setup voor ARM is.
ARM wordt steeds sneller waardoor "emuleren" steeds minder zinvol is.
"Emuleren" heeft als nadeel dat je iets na doet, met een risico dat je iets niet helemaal juist nadoet. Een ARM SOC doet altijd een ARM SOC na.
Het nut is het ontsluiten van ARM voor miljoenen ontwikkelaars die op een x86 PC werken en niet de beschikking over een device met een ARM processor hebbe. Een emulatortje downloaden en installeren is toch wat anders dan naar de winkel rennen en een iPad 3 kopen.
Als veel ontwikkelaars hun applicatie aanpassen zodat deze ook op ARM draait dan wordt daarmee de ARM architectuur aantrekkelijke voor gebruikers... Meer gebruikers maakt het weer aantrekkelijker om je applicatie te porten en zo kan dat in een positieve spiraal uitmonden. Kassa!
Als veel ontwikkelaars hun applicatie aanpassen zodat deze ook op ARM draait dan wordt daarmee de ARM architectuur aantrekkelijke voor gebruikers... Meer gebruikers maakt het weer aantrekkelijker om je applicatie te porten en zo kan dat in een positieve spiraal uitmonden. Kassa!
# toch wat anders dan naar de winkel rennen en een iPad 3 kopen.
Dat nog niet eens maar meer dat je natuurlijk een stuk prettiger kan ontwikkelen met een fatsoenlijke desktop.
Dat nog niet eens maar meer dat je natuurlijk een stuk prettiger kan ontwikkelen met een fatsoenlijke desktop.
Voornaamste reden is dat je al met software ontwikkeling kan beginnen nog voordat de SOC klaar is.
Belangrijk hierbij is "Hierdoor kan een ontwikkelaar volgens Fujitsu op cycle-level-niveau een simulatie draaien, waardoor de ervaren snelheid overeen zou komen met de daadwerkelijke prestaties op een ARM-processor."
Dat wil zeggen dat je van te voren precies kan zien hoe snel iets gaat worden op de uiteindelijke SOC.
Ondanks dat het hier vaak wordt genoemd, is het niet bedoeld om ARM alleen maar te emuleren. Het gaat echt om simulatie tijdens de ontwikkeling van een SOC.
Belangrijk hierbij is "Hierdoor kan een ontwikkelaar volgens Fujitsu op cycle-level-niveau een simulatie draaien, waardoor de ervaren snelheid overeen zou komen met de daadwerkelijke prestaties op een ARM-processor."
Dat wil zeggen dat je van te voren precies kan zien hoe snel iets gaat worden op de uiteindelijke SOC.
Ondanks dat het hier vaak wordt genoemd, is het niet bedoeld om ARM alleen maar te emuleren. Het gaat echt om simulatie tijdens de ontwikkeling van een SOC.
Dit is dus wat Qemu ook doet?
Overigens, hoe lang zal het duren voordat Arm processoren te snel zijn of te veel cores hebben dat dat niet meer gaat (maw. dat de host processor te traag gaat zijn)?
Overigens, hoe lang zal het duren voordat Arm processoren te snel zijn of te veel cores hebben dat dat niet meer gaat (maw. dat de host processor te traag gaat zijn)?
Als je een oude host processor gebruikt nu al. Als je genoeg nieuwe snelle host processors gebruikt nooit.
Het zou me verbazen als de QEMU/ARM-implementatie een JITter gebruikt... Het is alleszins verschrikkelijk traag! :-)
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
