X86-ondersteuning Itanium in de ijskast gezet

De nieuwe Itanium, die komende zomer zou moeten verschijnen, zal niet meer over hardwarematige ondersteuning voor x86-instructies beschikken. Intels nieuwe serverchip, ook wel bekend onder de codenaam Montecito, is afhankelijk van software-emulatie. 'We kunnen de ruimte die deze feature nodig heeft wel beter gebruiken', weet Intel-woordvoerder Erica Fields, 'en emulatie biedt op de Itanium zowel betere prestaties als meer flexibiliteit.' De Itanium heeft volgens een onlangs opgedoken handleiding voortaan altijd een softwareschil nodig om met x86-software overweg te kunnen. Eerder werd ook de energiebesparende Foxton-technologie al uit het ontwerp verwijderd.

Volgens C|net betekent het afschaffen van x86-support een nieuwe stap achteruit voor het toch al geplaagde serverplatform. De grote investeringen die het bedrijfsleven had moeten doen om software geschikt te maken voor Intels 64bitters bleven uit, niet in het minst omdat AMD met een 64bits-chip kwam die de 32bits x86-software wél probleemloos aankon. Hoewel de Itaniums wel x86-code konden uitvoeren, bleven de prestaties achter bij de verwachtingen. Omdat 'toch niemand het gebruikte' heeft Intel de knoop nu dus maar doorgehakt, al meldt analist Gordon Haff 'dat natuurlijk ook niemand van de software-emulatie gebruik maakt'. De prestaties van de zogeheten IA 32-EL-emulatie zouden flink tegenvallen. De Itanium, waarvan jaarlijks enkele tienduizenden exemplaren worden verkocht, blijft daarmee veroordeeld tot serverracks en gespecialiseerde software.

Itanium-architectuur. De te verwijderen IA 32-logica in het midden is groen weergegeven

Reacties (37)

[jqv]

Ze zijn in een korte tijd heel veel overvallen door AMD.
64-bit met 32-bit x86-ondersteuning ----> geen direct werkend antwoord van Intel
dual-core van AMD zoals dat met de 64-bits kernen was bedoeld-----> een zwakke reactie van intel door dan maar 2 pentium 4's aan elkaar te plakken.

Nu kunnen ze het ook niet bol werken en gooien ze het slecht werkende deel er maar uit en melden dat het niet belangrijk genoeg is. Dus maken we een stukje code die deze mogelijkheid wel biedt.... Gewoon geld dus.

[drZymo]

Eerder ruimte. Als een feature niet gebruikt wordt, waarom zou je daaraan nog kostbare stukken silicium gaan verbruiken? Nu kunnen ze weer meer transistoren gebruiken voor andere doeleinden. Het verbruikt trouwens ook nog het een en ander aan stroom wat ze nu weer kunnen besteden in andere delen. Het is gewoon een logische keuze.

En ik denk niet dat deze beslissing enigzins iets te maken heeft met AMD zijn beleid. Deze processor valt in een marktsegment waar AMD nog helemaal buiten valt. Er is dus geen dreiging.

[Schapie]

Niet alleen de ruimte. Ik denk dat het gedeelte voor de X86 ondersteuning waarnschijnlijk ook wel vrij complex is. Door deze complexheid is er ook een grotere kans van falen van de chip. Op deze manier kunnen ze hun Yields denk ik ook meteen een stukje verbeteren. (Al is het maar 1% met dit soort chips kan dat aardig wat schelen.)

[TheGhostInc]

Intel en AMD werken niet op hetzelfde moment aan een nieuwe architectuur (Ati en nVidia wel bv.)

Toen Intel met de P4 kwam werd de P3 eruit gelopen door de Athlon XP. De P4 heeft niet lang daarna de kop overgepakt. Toen AMD met de Athlon64 kwam waren zij weer sneller. En nu is het dus wachten op de nieuwe architectuur van Intel.

Dit spel gaat al jaren zo, en geeft helemaal geen reden tot grove speculaties en AMD kan zichzelf echt niet rijk rekenen. Als Intel de belofte waar kan maken met de nieuwe processor, met 64bits, dual core en een hoge IPC. Dan staat AMD ineens weer onder druk. En dan ligt de bal weer bij AMD. Nu roepen dat Intel het niet trekt... de P4 heeft ook een tijd de vloer aangeveegd met de AthlonXP.

Echter de Itanium, maar ook Xscale projecten staan redelijk los van de concurrentie met AMD. De Itanium is bedoelt als specifieke server processor en niet als desktopprocessor. natuurlijk merkt de Itanium de Opteron wel, maar de Xeon is een nog grotere concurrent.

Intel overvallen door AMD, misschien. Maar Intel heeft wel elke keer geantwoord, misschien matig, maar toch. Wat gaat AMD antwoorden op Intel's nieuwe processor is veel interessanter.

[Verwijderd]

64-bit met 32-bit x86-ondersteuning ----> geen direct werkend antwoord van Intel

Dit was een keuze Intel wil(de) dat iedereen voor zware geheugenvretende taken de Itanium ging gebruiken. 64bit x86 zorgt ervoor dat men die switch niet altijd hoeft te maken. Toen bleek dat er behoefte was aan 64bit op een x86 (al was het maar voor marketingsdoeleinden) heeft Intel snel de techniek ingebouwd. Hierdoor verloor de Itanium dan weer wel een deel van zijn aantrekkingskracht

dual-core van AMD zoals dat met de 64-bits kernen was bedoeld-----> een zwakke reactie van intel door dan maar 2 pentium 4's aan elkaar te plakken.

Allereerst presteert de methode van Intel niet echt minder dan die van AMD. Daarnaast was Intel toen al bezig met de conroe core. De Dual Core P4s zijn inderdaad een Quick & Dirty oplossing maar over een half jaar verdwijnen die weer van het toneel. In de tussentijd kunnen ze wel gewoon de concurrentiestrijd met de X2 aan gaan en voorkomen ze dus dat AMD qua performance uitloopt.

Nu kunnen ze het ook niet bol werken en gooien ze het slecht werkende deel er maar uit en melden dat het niet belangrijk genoeg is

De X86 hardware wordt door de meeste Itaniumgebruikers niet gebruikt. Die kopen bewust een Itanium om daar native itanium software op te draaien. Daarnaast is de Itanium zelf krachtig genoeg om een X86 chip te kunnen emuleren. Niet op de snelheden van een snelle Xeon of Opteron maar waarschijnlijk niet veel trager dan de ingebouwde hardware. Als het (vrijwel) geen performancewinst geeft én vrijwel nooit gebruikt wordt mag het er wat mij betreft gewoon uit.

[Verwijderd]

'en emulatie biedt zowel betere prestaties als meer flexibiliteit.'

Dit klint heel ongeloofwaardig, emulatie door software is in principe altijd trager dan wanneer de x86-instructies door hardware worden uitgevoerd. Als Erica Fields gelijk heeft met deze bewering dan zou Intel zich moeten schamen.

[ShadowLord]

Ware het niet dat de x86 hardware in de Itanium dermate langzaam was (om maar zoveel mogelijk ruimte te besparen) dat deze praktisch onbruikbaar bleek.

De software emulator draait native IA64, wat veel sneller uitgevoerd wordt. Daarom kun je op de Itanium sneller x86 emulatie draaien dan native x86. het betrefd wel een JIT compiler, wta inhiud dat de 1e keer dat je een programma draait deze vrij langzaam is. Maar alle volgende keren 'valt het mee'.

Zie ook: http://en.wikipedia.org/wiki/IA64#IA-32_support

[mjtdevries]

"if it sounds too good to be true......"

Als die emulatie zo supergeweldig is, waarom heeft Intel dan uberhaupt in eerste instantie hardware gebruikt? Je denkt blijkbaar dat ze bij Intel niet goed bij hun hoofd zijn?

[Verwijderd]

De emulatie houd gedeeltelijk in, dat de software code opnieuw op microcode nivo wordt gehercompileerd en dan beter gebruik kan maken van de IA-64 architectuur.

Het kan dus in sommige situaties een beter resultaat opleveren, echter in de praktijk zal het vaker op een vertraging uitkomen t.o.v. software die al van te voren is geoptimaliseerd.

[Verwijderd]

Of het nu in de chip of in de software gebeurt, als in het in de software gebeurt loopt dat programma tenminste nog op de IA64.

[memphis]

Hoeft niet...
Alles via Windows Api's laten lopen is ook niet zaligmakend voor de snelheid. Alles moet door de Kernel heen, als je bovenop de kernel je emulatie hebt kan dat wel eens sneller werken.

[Verwijderd]

Uhh, dit heeft weinig met API's te maken, dit is een laagje lager...de reden waarom het sneller is is omdat ze nu de chip kunnen uitrusten met bijvoorbeeld meer execution hardware, of betere control logic of wat dan ook.

[Verwijderd]

hmph. dus BLIJFT emulatie trager! Slechts door het opvoeren van de hardware zal het "emuleren sneller velopen"...

[Verwijderd]

Dat is hier niet het geval, want in Service Pack 2 voor Windows XP voor Itanium zat een nieuwe x86-emulator die gebruik maakt van dynamische recompilatie, om de x86-performance flink te verbeteren. Deze software-oplossing was dus al een stuk sneller dan de ingebouwde hardware-emulator. Misschien dat Intel mede daarom heeft besloten om de hardware te verwijderen.
Het emuleren van x86 is gewoon dermate lastig dat je het niet efficient kunt krijgen met 1:1 vertaling. Ook niet met hardware (mede daarom hebben moderne x86s dus gigantisch complexe instructiedecoders, RISC-backends, en enorm lange pipelines met out-of-order execution etc etc. Dat kun je niet 'even' allemaal in een Itanium stoppen, wordt veel te duur).

[TheOneLLama]

Ze hebben het toch niet over IA64 emuleren op de Itanium? Het gaat hier tussen emuleren van x86 op de Itanium vs. gebruik maken van de huidige x86 support in de hardware, die momenteel in ruwe termen te vergelijken is met het met plakband vastmaken van een 386 op de de IA64 core.

[Verwijderd]

Ze hebben groot gelijk. Itaniums worden toch vooral in servers gebruikt, en daar heb je meestal de mogelijkheid om alle software speciaal voor de Itanium te laten compileren. Kant-en-klaar Itanium server software installaties zijn er inmiddels ook al.

Desktop systemen kan je natuurlijk ook prima (her)compileren naar 100% Itanium code, maar er zijn maar weinig mensen die dat doen. In de commerciele desktop wereld is dit zelfs onmogelijk.

[Wouter Tinus]

De prestaties van de zogeheten IA 32-EL-emulatie zouden flink tegenvallen.

Onzin. De hardwarematige x86-ondersteuning van de Itanium-processors is altijd al om te huilen geweest. Van 486-niveau op originele Merced tot Pentium II-niveau op de huidige Itanium 2 Madison. IA32-EL is letterlijk vele malen sneller, daarmee wordt het niveau van een (vroege - denk aan 1,5/1,7GHz) Pentium 4 gehaald. Waarom Cnet het een "stap achteruit" noemt mag joost weten, maar het is FUD van de bovenste plank. Bovenal spreekt het artikel zichzelf nogal tegen. Eerst beweren dat het een stap terug is en vervolgens dat toch niemand het gebruikt. Tja.

IMO heeft Intel een goede keuze gemaakt door die belachelijke trage x86-core (die inderdaad niemand gebruikt) uit de Itanium te slopen en de ruimte in te zetten voor iets wat wél nuttig gebruikt kan worden. Op de plaats van de x86-core is in Montecito 1MB L2 instructiecache geplaatst, wat (o.a.) erg gunstig zal zijn om de prestaties van IA32-EL te verbeteren. De paar uitzonderingen die per se x86-code op een Itanium willen draaien zullen er met IA32-EL alleen maar op vooruit gaan.

[Faust]

voor gespecialiseerde taken zijn er vele betere en goedkopere alternatieven. Beter als in: krachtig.

Tot nu toe heb ik bij geen enkele test op tweakers gezien dat de itanium ook maar in 1 ding het snelst was. Kijk het maar na.

Waarom kopen bedrijven dan toch zo'n 'troep'? Moeten ze? zoals bij dell? Of zijn ze gewoon heel erg goedkoop? Wat me onlogisch lijkt want iedereen klaagt over de hitte en het stroomverbruik.

[MrMr]

Op tweakers.net staat veel, maar niet veel voor dit soort cpu's. De Itanium is in 2004 en 2005 vrij constant een van de snelste cpu's voor floating point volgens spec.org.
Alleen de nieuwe P5 machines zijn sneller dan de 1600MHz Itanium in de 64 cores fprate 2000, een 8-core opteron systeem (Sun Fire V40z) scoort maar zo'n 140 tegen 220 voor een oude 8-core Itanum machine en 266 voor de nieuwste P5 eServers.
Ik ben geen speciale fan van Intel, maar de Itanium-2 is niet geflopt omdat het een slechte cpu is...
(wat ze allemaal wel fout gedaan hebben laat ik maar in het midden)

[drZymo]

Reactie op ELiA.net (verkeerd geklikt ).

De Itanium valt helemaal buiten het intresse gebied van de gemiddelde bezoeker op t.net, dus het is logisch dat je niet de juiste testen tegen komt hier. De Itanium is een krachtige processor speciaal voor zware berekening. Denk maar aan moleculaire simulaties die in de bio industrie gebruikt worden. Het is niet een processor zoals een Xeon of Opteron die bedoeld zijn voor de server markt.

Het is gewoon een prima processor, en wat ik van de architectuur gezien heb heeft bij mij heel wat respect opgewekt. Het is goed doordacht, de instructieset kan nog jaren mee, en hij is vanaf het begin af aan ontworpen voor parallelle berekeningen. Dat mensen zeggen dat hij zo geflopt is komt omdat hij niet zo vaak in de spotlights staat. Ik hoop in ieder geval dat we nog lang kunnen genieten van de Itanium want ik denk nog steeds dat hij een grote invloed kan hebben in de toekomst.

[demisoft]

De itanium is zeker in bepaalde takken veel beter als b.v xeon of opteron. Denk b.v aan zeer zware multi-processor berekeningen.

[trogdor]

Daar zal je dan die nieuwe SUN processor voor willen gaan gebruiken.

[Verwijderd]

Nee, misschien een Power, maar die sun bak is juist zeer traag als het om floating point gaat

[dabla]

Daarin heb je een punt, probleem is dat dergelijke toepassingen die rekeninghouden met multi-processoren/cores zeldzaam zijn. Erger nog, dan zie je bv dat een "simpele" pentium 4 dezelfde code veel sneller uitvoerd dan een mega dure state-of-the-art sun server.

Nu dat de multicore processoren ook hun weg hebben gevonden in de gewone desktops (en consoles), denk ik dat dit echter wel zal verbeteren, er zullen alleen enkele jaren overheen moeten gaan vooraleer men zo ver is...

[Nas T]

het is dus een heel gespecialiseerde chip. Ik weet echt niet of het ontbreken van hardwarematige ondersteuning van x86 nou wel zo gek is. De tijd zal het leren.

[Frogmen]

Zou Intel niet gewoon van Apple geleerd hebben zorg dat je met software emulatie oude software kan blijven gebruiken maar hou er geen rekening mee in nieuwe hardware. Als microsoft hierin was meegegaan zou Windows misschien nu al veel verder ontwikkelt zijn.

[martijnvanegdom]

'een emulatie biedt zowel betere prestaties als meer flexibiliteit.'

Klinkt mij een beetje marketing in de oren.. Emulatie is per defintie langzamer dan hardwarematig het uitvoeren.

Op onze huidige x86 cpu's zijn echt zo traag..

mm.. toch sneller leren typen..

[TinusH777]

Dat ligt er aan: als ze een JIT compiler gebruiken, die X86 machine code vertaald naar RISC code, dan zal het eindresultaat best wel goed kunnen zijn.
Dit lijkt op de JAVA/.NET aanpak, met het verschil dat deze JIT compiler geen 'managed code' opleverd. Daarom kan de snelheid van de vertaalde binaries goed zijn.

[.oisyn]

Emulatie is per defintie langzamer

Onzin, goede emulatie op een heel snelle CPU kan echt wel sneller zijn dan een heel er slome hardware implementatie (en de x86-EL van de itanium kan echt niet meekomen met een hedendaagse athlon of pentium hoor, terwijl de itanium met native code dat wél kan).

Een ander voorbeeld: denk je dat de Z80 in de gameboy sneller is dan een Z80 emulator op een Athlon XP?

[Verwijderd]

Op onze huidige x86 cpu's zijn echt zo traag..

Dat komt omdat x86 een hele beperkte architectuur is. Als je daar een complexere architectuur op wilt emuleren (meer registers, meer operands, meer bits etc), dan moet dat dus via allerlei omwegen, omdat je niet gewoon een instructie kunt vervangen door het x86-equivalent.
Andersom gaat het veel makkelijker. Een x86 emuleren op een PowerPC gaat best redelijk, en op een Itanium gaat dat ook best goed.
De meeste instructies kun je zo vervangen door equivalente native instructies, en dan wordt emuleren heel simpel, en best efficient.
In feite werken x86-processors intern ook al sinds ongeveer de Pentium Pro op deze manier. x86-instructies die vertaald worden naar RISC-instructies.

[Verwijderd]

Beperkt? x86 is een CISC architectuur, het heeft meer instructies, veel meer instructies. Het equivalent van alle x86 instructies vinden gaat best moeilijk zijn. De reden waarom het emuleren toch zo gemakkelijk gaat is om x86 mateloos achterhaald en dus onefficient is, en omdat intern in moderne x86 CPU's ook niets anders gebeurt.

[Verwijderd]

De reden waarom het emuleren toch zo gemakkelijk gaat is om x86 mateloos achterhaald en dus onefficient is

Dat zeg ik, beperkt.
Je hebt wel veel instructies, maar die instructies kunnen maar heel beperkte operaties doen. Bijvoorbeeld de inc en dec-instructies. Compleet overbodig, omdat je ook add en sub hebt, die overigens sneller zijn op moderne processors.
Bij RISC heb je minder instructies, maar doordat je meer operands hebt, en de instructies handiger zijn bedacht, kun je er meer mee. Maar zo'n handige RISC-instructie met 3 operands moet je dus wel vertalen naar een onhandige x86-instructie met 1 of 2 operands. Dat lukt dus niet, dus moet je meerdere instructies gebruiken. Andersom gaat het wel heel makkelijk.

[Database freak]

Itanium servers zijn zo duur dat je ze toch enkel voor zeer gespecializeerde taken inzet, waar ze dan wel weer heel snel in kunnen zijn.

[MadNeo]

Zou het niet gewoon zijn dat ze een slecht ontwerp hebben. er wordt namelijk over gesproken dat 64bit door emulatie wel sneller is dan het in de hardware te integreren.

Ze mogen wel eens een voorbeeld aan AMD nemen, hun 64bit chips gaan als warme broodjes over de toonbank.
Als INTEL de race een beetje wil bij kunnen houden zullen ze op z'n minst 64bit in hun spullen moeten stoppen, Door alleen de snelheid steeds hoger op proberen te voeren komen ze er echt niet meer..

[arjankoole]

Zou het niet gewoon zijn dat ze een slecht ontwerp hebben. er wordt namelijk over gesproken dat 64bit door emulatie wel sneller is dan het in de hardware te integreren.

klopt absoluut. De eerste serie Itaniums waren zo ongeloofelijk absurd traag dat ze er maar liefst een ongehoorde 8MB L2 cache in moesten gooien om het beest nog een beetje te laten lopen. Alles bij elkaar maakte het de Itanium (en uiteindelijk de Itanium2) zo duur dat ze zich compleet uit de markt voor 64-bit hebben geprijst. Zelfs als je het met andere dure merken als IBM, Sun vergelijkt. Daarnaast vrat de Itanium zoveel stroom dat je voor een beetje grote cluster al snel een eigen kerncentrale neer moest zetten. (lichtelijk overdreven natuurlijk, maar jullie snappen wel waar ik heen wil).

Toen kondigde AMD de opteron en het begin van de x86-64 familie aan. Google sprong gelijk op en kondigde aan dat ze op die CPU's gingen wachten, omdat het ze google-wide (wereldwijd dus) al snel 300.000 dollar per jaar aan energiekosten ging besparen... en nu zul je misschien puffen omdat op de jaaromzet van Google peanuts is, maar voor aandeel houders is het altijd goed om te laten zien... verkwist niet betekend indirect winst. (de masseurs, koks en andere 'features' op de google campus leveren ook meer geld op, direct en indirect, dan ze kosten).