Artikel over de werking van Intels IA-32 Execution Layer

Op Real World Technologies is een nieuw artikel van Paul DeMone verschenen waarin de werking van Intels IA-32 Execution Layer uit de doeken wordt gedaan. Dit stukje software, dat sinds vorige week te downloaden is, zorgt ervoor dat x86-applicaties op een Itanium-processor niet langer dramatisch langzaam zijn, maar met de snelheid van een even hoog geklokte Xeon-processor door de pipeline vliegen. Deze performanceboost wordt bereikt door x86-instructies te vertalen naar IA-64, in plaats van ze naar de geïntegreerde x86-hardware te sturen. Het concept lijkt veel op hetgeen wat DEC in 1995 deed met FX!32, de software die x86-programma's liet draaien op Windows NT voor de Alpha.

FX!32 werd in Windows NT verankerd aan de systeemaanroep CreateProcess, waarmee een nieuw programma gestart wordt. Op het moment dat deze routine een poging tot het uitvoeren van x86-code herkende greep het in. Er was een simpele tabel waarin voor iedere x86-instructie een serie van gemiddeld zo'n 45 Alpha-instructies stond die netto hetzelfde resultaat opleverden. Op zich nog geen heel erg efficiënt systeem, maar de grote truc was dat er tijdens het draaien informatie werd verzameld over het gedrag van het programma, en FX!32 op de achtergrond begon met het schrijven en optimaliseren van Alpha-code met dezelfde functionaliteit. Naar mate een stuk x86-software dus vaker werd gebruikt hoefde er steeds minder on-the-fly vertaald te worden, waardoor de emulatie wel tien keer sneller kon gaan dan de eerste keer. Het was zelfs een tijdje zo dat een Alpha met FX!32 veruit het snelste platform was om x86-software op te draaien.

De IA-32 Execution Layer werkt grotendeels volgens dezelfde principes, alleen wordt er geen permanente database van voor-vertaalde code bijgehouden. Wanneer een programma gestart wordt begint in eerste instantie "cold code translation", waarbij gebruikt gemaakt wordt van tabellen en templates om groepjes van vier of vijf instructies te vertalen. Zodra de emulator merkt dat een bepaald groepje wel erg vaak langkomt zal worden besloten om dat stuk te gaan optimaliseren. Deze "hot code translation" kost twintig keer zoveel tijd als de standaard vertaling, maar omdat een processor in de praktijk vaak meer dan negentig procent van de tijd bezig is in minder dan tien procent van de code, betaalt deze investering zichzelf ruimschoots terug. Tijdens SPEC CPU 2000, een benchmark die uit 26 applicaties bestaat, spendeert de processor 95% van de tijd aan het draaien van "hot code" en slechts 3% aan het vertalen. De 1,5GHz Itanium 2 scoort 105%, 99% en 133% ten opzichte van een 1,6GHz Xeon in respectievelijk SPECint 2000, SPECfp 2000 en SysMark 2002. Deze resultaten zijn zeker drie keer zo goed als voorheen mogelijk was, en de conclusie is dan ook dat Intel zich voortaan de kosten en moeite van native x86-hardware kan besparen.

Reacties (32)

[Verwijderd]

Ja wachten even, dit werkt dus enkel en alleen voor windows 2003 en niet op oudere windows versies of Linux. Dus een native implementatie van x86 instructies zou dus toch nog steeds handig zijn!

[Beaves]

Natuurlijk zou dat beter/handiger zijn, maar dat is nou eenmaal een stuk lastiger.

Zo zal Intel dan een betere x86 CPU in de Itanium moeten stoppen, want de huidige voldoet dus niet. Dan moeten ze dus een P3 of een P4 core erbij stoppen (min een aantal zaken die misschien geleend kunnen worden van de Itanium core ) en dat zorgt er weer voor dat het aantal transistoren in de Itanium gaat stijgen.

Dat zorgt er weer voor dat de Itanium (die toch al een groot aantal transitoren heeft door de enorme berg cache) nog moeilijker te produceren valt door de lagere yields. De CPU wordt dan dus nog duurder met als gevolg dat de concurentie strijd met o.a. de Opteron helemaal lastig wordt.

Intel kan bijna niet anders dan het op deze manier op lossen, dat er nog geen non-Windows versie is zegt niets, intel steekt redelijk veel geld in Linux dus het is logisch dat ze daar ook een versie voor maken.

[Wouter Tinus]

Een versie voor Linux is onderweg en ik denk dat er ook wel een Windows 2000-versie komt als daar genoeg vraag naar is. De volgende generatie Itanium-core komt overigens pas in 2005 op de markt, dus het is ook weer niet zo dat iedereen die Itanium draait op een platform zonder EL nu in paniek moet raken .

[elteck]

Maar voor Linux is dat toch helemaal niet nodig? Daar draait toch inmiddels al een native 64 bit versie van? Dan is zo'n constructie toch alleen maar onnodige overhead.

Ik hoor iedereen roepen dat verwacht wordt dat yamhil compatible is met de Opteron 64 instructies. Echter ik zou juist verwacten dat die compatible is met de Itanium. Want uiteindelijk zijn de 64 bit prestaties van dit beestje best goed.

[Countess]

als je dat denkt heb je niet goed opgeled
yamhill gaat er juist om om 64bit te hebbem met het behoud van x86 compatabilitijd te hebben, zonder dan broncode persee herschreven hoefde te worden.
de itanium is IA64, een compleet ander systeem. (vandaar dat er dus een emulator/vertaler nodig is om x86 code te draaien)

yamhill is dus een x86 CPU met 64bit instructies.
itanium is een IA64 (non-x86 dus), 64bit's CPU die ook 32bit x86 instructies kan uitvoeren doormiddel van emulatie (net al waarschijnlijk elke andere non-x86 CPU dat kan met goede software).
itanium is niet gemaakt om x86 instructies te draaien, en het zit er alleen maar op vanwegen legatie compatabiltied
yamhill gaat dat wel zijn en kan deze dus ook op VOLLE snelhied draaien.

[Countess]

Uhm, het idee van Intel was juist dat het geen goed idee was om de IA32 instructies naar 64 bit te vertalen (zoals AMD doet)

AMD heeft helemaal geen IA CPU's (32 dan wel 64bit)
ik neem aan dat je hier eigenlijk x86-32 bedoeld.
de enige reden dat ze zeggen dat het geen goed idee is is omdat dat concuretie zou worden voor hun itanium. now dat die concurentie er is en AMD een grote slag lijkt te slaan, veranderen ze snel van praatje en gaan aan snel aan het werk aan een x86-64bit CPU. waar ze verder hun mond over houden om zoveel mogenlijk verwarring rond x86-64 te doen ontstaan tot ze hun eigen CPU lanceren (al dan niet compatible met x86-64 van AMD)

(voor de duidelijkheid
IA64 is het systeem dat de itanium gebruikt, en is een compleet ander systeem als de pentiums en de athlons die x86 gebruiken.
IA bestaat eigenlijk alleen in de 64bit vorm.
x86 is er nu in veel smaken van 8086 en 2-86 , tot 6-86 (samengevat als x86)
en nu dus x86-64)

.

ook in dat geval zal intel ervoor kiezen om een eigen implementatie te kiezen. Zij willen marktleider zijn en voorkomen dat andere gaan bepalen welke instrukties Intel processoren bevatten.

intel kan bijna geen eigen x86-64 instruties maken omdat microsoft heeft gezegt geen verdere versies voor windows te willen maken.
ze hebben de IA64 (voor itanium) windows gemaakt voor intel, exclusief voor server in principe.
en nu maken ze een x86-64 windows voor AMD
die bruikbaar zal zijn voor server en als desktop.
vanwegen support kosten en om te voorkomen dat ze consumenten verwarren willen ze zich niet wagen aan NOG een extra 64bit windows.
zoals jij al demonstreerde met het door elkaar halen van x86 en IA zal het voor de gemiddelde leek bijna onmogelijk worden om te weten welke hij moet hebben.
door maar 1 64bit windows voor de consumenten te maken houden ze het overzichtelijk en voor de consument duidelijk.

naast MS zullen ook vele anderen softwarebedrijven niet erg over intel te spreken zijn als ze hun eigen 64bit instruties maken.
ook zij zullen van 2 64bit versies van al hun programas moeten maken (en hebben dan in totaal dus 3 versies, met alle extra kosten en gevolgen vandien)
of ze zullen moeten stoppen met het ontwikkelen van 64bit software compatible met AMD.
dit zullen ze niet erg leuk vinden want velen hebben al veel geld en tijd geinversteerd in de ontwikkeling hiervan.
intel zou dus geen vrienden maken bij de mensen die ze nodig zouden hebben om hun x86-64 instruties tot een succes te maken.
kort om ze zouden weinig kans van slagen hebben, zelf met hun huidige markt aandeel.
hun hardware is niks zonder support van de software makers, en dat weten ze donders goed.

wat ze waarschijnlijk wel gaan doen is x86-64 pakken, en daar dan hun eigen instructies aan toe voegen(zie SSE1 t/m 3 en PNI bv). om zo toch meerwaarden aan hun CPUs toe te voegen, zonder software incompatible te zijn.

[Verwijderd]

Uhm, het idee van Intel was juist dat het geen goed idee was om de IA32 instructies naar 64 bit te vertalen (zoals AMD doet)

Tuurlijk kan Intel nu eieren voor zijn geld kiezen maar ik denk niet dat intel de IA64 standaard van AMD gaat volgen. ook in dat geval zal intel ervoor kiezen om een eigen implementatie te kiezen. Zij willen marktleider zijn en voorkomen dat andere gaan bepalen welke instrukties Intel processoren bevatten.

Door de AMD instrukties te volgen krijgt AMD meer kans. Door hun eigen instructieset te maken krijgt AMD een probleem. (Veel paketten wel beschikbaar voor Intel 64 maar niet voor AMD 64)

[SG]

Als X86 slaat op de hele 86 reekt van 8086 tot 80486, Pentium tot P4
Slaat IA32 alleen op de 32bit x86 versies.
Aangezien 8086 8bits is en 80286 16bits daar is geen IA voor.

[serkoon]

De 8086 is ook al 16 bits hoor

(En de 8088 ook, maar die heeft maar 8-bits externe bussen ipv 16 bits zoals de 8086)

[Countess]

SG: IA heeft helemaal niks te maken met x86
IA is een techniek die intel heeft ontwikkeld als alternatief voor (en ze hoopte vervanging van) x86.

dat hebben ze echter alleen gedaan voor in 64bit
dus noemen ze het IA64

en voor de duidelijkheid de term x86 heeft totaal geen enkele referentie in zich naar de hoeveelheid bits die gebruikt worden. zoals serkoon al zei kan het zijn vanaf 8 dan wel 16 tot nu 64bit

deze IA32 layer is gemaakt om X86-32 programas de draaien op een IA64 processor.
de naam IA32 vind ik daarom nogal slecht gekozen.
net alsof IA64 echt de vervanger van x86 is.
al was dat wel intels bedoeling eigenlijk.

[elteck]

Maar denk nu eens andersom. Stel Intel brengt een P4 op de markt, met een 64 bit modus, waarin deze als IA64 werkt?
(Overgens bij de Opteron kun je ook niet in een programma 64 en de oude 32 bit instructies door elkaar gebruiken)
Dan hebben ze een proc. die compatible is met de IA64 maar geoptimizeerd voor x86 code in plaats van andersom.
Zo'n processor kan ze helpen om de kwakkelende IA64 alsnog op de rails te zetten.

Ik kan me namelijk niet voorstellen dat Intel, AMD gaat bevoordelen boven hun eigen Itanium.

[Countess]

dit is zogoed als niet te doen.
omdat de 2 argitecturen zo verschillend zijn zijn ze niet in 1 core te verwerken zonder eigenlijk gewoon 2 cores aan elkaar te plakken, 1 x86 en 1 IA64.
de kosten zouden erg hoog zijn, het oppervlak van de core enorm, en de yields daardoor erg laag.
daarnaast op welke snelheid zou je de core dan laten draaien? IA64 is voorlopig nog helemaal niet geschikt voor veel ghz-en, terwijl intels x86 implimentaties er om schreewen om hoger geclocked te worden.
zo'n core zou bijna niet anders dan laag geklock kunnen zijn, en dat zou zijn 32bit prestaties zeker niet ten goede komen, hij zou zelfs gelijk zijn aan de prestaties van een normale itanium met deze IA32 'emulator'
nee dit idee zie ik helemaal al geen hail in.

(Overgens bij de Opteron kun je ook niet in een programma 64 en de oude 32 bit instructies door elkaar gebruiken)

er is geen een CPU waarbij dat wel kan.
maar de opteron is wel de enige die op een 64bit OS native en hardwarematig 32bit code can draaien op snelheiden dicht bij hoe snel een 64bit varriant zou zijn. (afhankelijk van hoeveel het programa in questie voordeel heeft bij 64bit natuurlijk)

en waarom zouden ze niet AMD's argitectuur gebruiken? AMD heeft er milljoen en milljoenen in gestoken om het te ontwikkelen, en nu bieden ze het gratis aan! het is een open standaart!
niets staat VIA, trancemeta en eventuwele andere CPU bakker in de weg om achter AMD aan te gaan.
intel zou dan alleen staan, wat ze opzich wel zouden kunnen hebben gezien hun marktaandeel.
maar omdat de legacie compatabilatie van AMD en andere zo veel beter zou zijn zouden ze die snel verleisen denk ik.
nee met een IA64 compatible desktop prossesor gaan ze AMD niet in de weg zitten.
als ze voor een eigen x86-64 zouden kiezen met legacie support, hebben ze wat meer kans van slagen. maar dan alleen als ze MS toch zover kunnen krijgen om ook een versie van windows voor hun te maken.
en daarna alle software bedrijven... hoe veel zin die daar in hebben blijft maar de vraag natuurlijk.
en dan moeten ze daar eerst een hoop geld in stopen om dat te ontwikkelen.
en duswaarom zouden ze, AMD heeft dat toch al gedaan? en geeft het nu gratis weg!

[eggieman]

Wat niet wordt gezegd is dat hier een vergelijk is gemaakt met een voor huidige begrippen erg langzame Xeon.
Een Xeon 1.6 Ghz is een oudje en als het beste resultaat neemt, 133%, dan kom je nog maar op een Xeon 2.1Ghz.
Een Xeon is ontworpen voor een hoge klokfreq en een laag aantal instucties per kloktik. De Itanium daar in tegen juist voor een hoge insturcties per klok en dus een lagere klok.
Hij is dan misschien wel veel sneller geworden. Maar dat zegt alleen maar iets over zijn vorige snelheid, hij wordt er nog steeds door elke processor van nu uitgelopen

[Edit 1 typo's]
* 786562 eggieman
[Edit 2]
[@ Wouter Tinus]

Ik ben het met je eens dat de Itanium een ander publiek heeft. Ik wilde alleen de verbeteringen in een juist perspectief zetten. Door ze te vergelijken met een Xeon 1.6Ghz lijken de percentages een stuk rooskleuriger dan dat ze werkelijk zijn.

[Wouter Tinus]

Als je een Itanium koopt om er x86-software op te draaien doe je iets niet goed, dus de x86-prestaties zullen altijd een bijzaak zijn (voor de meeste klanten is het zelfs totaal irrelevant). De toename van die prestaties met een factor drie dankzij de EL maakt echter het verschil tussen compatible en bruikbaar, en dat is nou juist waar het hier om gaat. Niet of het nou als een 2GHz of 3GHz Xeon presteert, maar of iemand op een Itanium workstation naast zijn IA-64 ontwerp-applicaties af en toe de x86-versie van Photoshop kan gebruiken zonder daarvoor een aparte tweede computer te kopen.

[Wouter Tinus]

Het zou op zich trouwens wel een leuke grap zijn als een toekomstige release van de IA-32 EL ook x86-64 code kon vertalen. Ik zie zo snel eigenlijk geen reden waarom het technisch niet mogelijk zou zijn, maar het management van Intel zal er natuurlijk op zijn minst enigzins huiverig tegenover staan.

[Verwijderd]

Het zou natuurlijk ook heel goed mogelijk zijn dat dit door de open source gemeenschap wordt gedaan. Het maken van een primitieve emulator stelt niks voor, het probleem zit 'm er in om het ding snel te laten werken.

[Vorlon]

Ja, en dat kan ook best snel zijn maar de Itanium en de Xeon zijn qua platform meer vergelijkbaar dan de Itanium en de Opteron. En dan bedoel ik vooral de bandbreedtes naar de rest van het systeem.

Zowieso zal er niet echt vraag naar zijn. Als bedrijven toch al de moeite doen om een 64bit versie van hun software te maken is een Itanium port niet bijster veel extra werk. Met een beetje geluk een tweede compile. (Optimistisch maargoed.)

[Countess]

Ja, en dat kan ook best snel zijn maar de Itanium en de Xeon zijn qua platform meer vergelijkbaar dan de Itanium en de Opteron. En dan bedoel ik vooral de bandbreedtes naar de rest van het systeem.

wat heeft dat er nou mee te maken?

daarnaast, de opteron hoeft niet meer zo veel bandbreedte te hebben naar de rest van het systeem. want geheugen verkeer hoeft er niet overheen
en voor de rest is de hypertranceport bus meer als groot genoeg.
(800mhz x 16bit = 1.6GB/s UP en nog eens 1.6GB/s down, ik zou niet weten waar je die vol mee zou willen krijgen)

[procede]

Waar heb jij leren rekenen

800Mhz*16bit = 800MHz*2byte = 1.6GB/sec

[Countess]

zie post tijd

bijgewerkt

[Verwijderd]

Hmmm minor setback voor AMD. Want het grootste voordeel dat de Opteron had ten opzichte van de andere 64 bitter de Itanium was dat de opteron beter met x86 om kon gaan. Nou weet ik dat de opteron een ander deel van de markt bestrijkt dan de Itanium, maar het feit dan de Itanium op deze manier efficienter om kan gaan met x86 dan voorheen, is toch weer een positief punt voor Intel.

[Countess]

effectiever maar nog steed maar half (if that) zo snel als de opteron dat kan, voor stukken minder geld.
ik denk niet dat het veel mensen over de schreef zal trekken.
als je een itanium koopt dan ga je daar geen x86-32 software op draaien behalve dat ene programatje wat nog niet is over gezet misschien.
heb je wel veel x86-32 bit software die je wilt draaien dan lijkt me de opteron een betere keuzen. (en als je daar de prijs bij pakt... lijkt me de opteron zogoed als altijd een betere keuzen eigenlijk)

AMD zelf zegt trouwens dat de opteron wel tegenlijk tegen de itanium concureert, en gelijk hebben ze, ik zie geen reden waarom hij niet tegen de itanium kan concureren.

[Verwijderd]

Hoewel AMD anders beweerd is de echte tegenstander van de Opteron natuurlijk de XEON.

De Itanium richt zich op een andere markt. Dat de Itanium relatief slecht presteert t.o.v. de Opteron is betrekkelijk irrelevant. Mensen die een Opteron overwegen kunnen net zo goed een Xeon kopen. Die is ook duurder dan een Opteron maar wel de directe concurrent van de Opteron. De 64 bits prestaties van de Opteron zijn op dit moment meestal niet relevant. Er is vrijwel geen 64 bits software beschikbaar voor de Opteron dus wordt die meestal gebruikt voor normale 32 bits intel software. En die werkt prima op de Xeon.

Dat de Itanium min of meer een flop is, is lastig voor Intel maar daar heeft AMD erg weinig mee te maken. Dit komt veel meer door de prestaties van suns, IBMs e.d.

[Countess]

Hoewel AMD anders beweerd is de echte tegenstander van de Opteron natuurlijk de XEON.

waarom?
er is ongeveer evenveel 64bit (windows) software beschikbaar voor de itanium als voor de opteron op dit moment, en de opteron bestaat nog maar net eigenlijk, de itanium al veel langer.
en de opteron kan ook nog gewoon alle linux programa draaien, zelfs op 64bit na alleen een hercompilatie (in tegenstelling tot herschrijven zoals nodig is voor de itanium)
en dat compileren kan je gewoon zelf doen, herschijven kunnen de meeste mensen niet, naast de tijd die je er dan mee kwijt bent.

hoewel de hoofd concurent van de opteron zeker de xeon is (gewoon omdat die stukken meer verkoch worden) heeft de itanium niet erg veel voordelen over de opteron, zeker niet als je ook het koste plaatje bekijkt.
en hoewel vroeger de x86 server CPU's en de non-x86 CPU's werden beschoud al zijnde bestemt voor verschillende markten heeft opteron dat compleet veranderd.
ik zou dus niet weten waarom de opteron niet tegen de itanium zou kunnen concureren.
eigenlijk is het alleen intel en consorten die beweren van niet.

[Vorlon]

Hmm, wat ik me nu afvraag is of Intel met die deal met Compaq ook de FX!32 software gekregen heeft uit de Digital nalatenschap.

Als dit zo zou zijn zou het wel verklaren waarom Intel niet gelijk dit softwarematig heeft aangepakt ipv eerst een basic ia32 cpu bij itanium in te stoppen. (Itanium project is veel eerder begonnen dan dat Intel de Alpha van Compaq heeft overgenomen.)

[blade181]

Intel heeft de alpha afdeling van Compaq een paar jaar geleden volledig opgekocht, het is nu een onderdeel van Intel zelf. Ze hebben niets te duchten van de patenten of Digital Nalatenschap of iets dergelijks. zie www.tweakers.net/nieuws/17366/

[SKiLLa]

Ik neem aan dat de rode delen in het plaatje de 'x86 Logic'-delen zijn ?

[Verwijderd]

@ Vorlon

<quote>Ja, en dat kan ook best snel zijn maar de Itanium en de Xeon zijn qua platform meer vergelijkbaar dan de Itanium en de Opteron. En dan bedoel ik vooral de bandbreedtes naar de rest van het systeem.</quote>

Als dat het geval is heeft de Opteron al gewonnen aangezien die een geheugen bandbreedte kan behalen van maarliefst 27 Gb p sec.
En de Xeon er maar 6.

[homers]

Je ziet dus dat DEC met zijn alpha omgeving zijn tijd ver vooruit was, niet alleen maar met IA-32 maar ook met clustering, en de manier waarop, maar ja in de techniek, wordt niet altijd gekozen voor de beste

[Countess]

er was een IA-32 voor de alpha.
alpha gebruikte weer een anders systeem als x86 of IA, ze hadden RISK.
maar ze hadden idd wel een emulator voor x86 software, al hete die geen IA-32.

[MacD]

Blam! Daar ging AMD's voordeel met hun 64-bits architectuur die ook 32 bit architectuur heeft.

Mooi stuk techniek, moet ik zeggen

[trogdor]

Wederom is het het oude DEC team wat ons kan verbazen, AMD-ontwerpen, Itanium ontwerpen, en nu dit coole stuk code.
Echt, ik heb respect voor deze mensen.