Home

Computer

Hardware

Site Map

Der Itanium Prozessor

In meiner losen Reihe von „Fehlschlägen“ von Intel, also Prozessoren, die von Intel entwickelt wurden, aber die Erwartungen nicht erfüllten kommt mit diesem Artikel der krönende Abschluss. Bisher erschienen schon:

• Der Intel 8085 (1976) – ein Nachfolger des Intel 8080, dem zum Verhängnis wurde, das zeitgleich der noch bessere Z80 erschien.

• Der iAPX 432 (1981) – eine objektorientierte 32 Bit Architektur, die jedoch in realen Benchmark quälend langsam war.

• Der I860 (1989), ein von Intel als „Cray on a Chip“ beworbener RISC Prozessor mit auf dem Papier beeindruckender Performance. Leider erreichte er diese Geschwindigkeit in realen Programmen nicht und noch bedeutender: Er war auf Maschinensprachenebene inkompatibel zu jedem eingeführten Prozessor.

• Und nun eben im Jahre 2001 der Itanium mit einer VLIW Architektur, der nicht die Erwartungen Intels erfüllte.

Das Design

Ich beschreibe zuerst das Basisdesign des ersten Itanium-Prozessors, Codename „Merced“. Es folgen dann bei den folgenden Exemplaren nur noch die Änderungen relativ zu Merced. Hinweis: Die Links führen zu Grundlagenartikeln von mir, in der die Konzepte genauer erklärt sind.

Die x86-Linie, die im Jahre 2022, als ich diesen Artikel schreibe, noch immer aktuell ist, ist eine klassische CISC-Architektur. Sie hat in den Jahrzehnten sich gravierend verändert, ist aber im Befehlssatz noch immer eine reine CISC-Architektur, durch Befehlserweiterungen ist sie sogar noch mehr eine CISC Architektur als der Urahn 8086. Die meisten seit den achtziger Jahren neu erschienenen Architekturen sind dagegen RISC Architekturen. Motorola gab die erfolgreiche Konkurrenzlinie der MC 68k Architektur, sogar für die neue RISC Architektur Power PC auf. Intern übersetzen die Intel Prozessoren seit dem Pentium sogar den CISC-Code in mehrere einfachere RISC-Operationen.

Der Itanium war Intels letzter Versuch eine neue vom x86 abweichende Architektur zu etablieren. Das Basisdesign stammt aber nicht von Intel, sondern Hewlett Packard. Hewlett Packard war zu dem Zeitpunkt Hersteller von Workstations und Servern. Hewlett Packard hatte 1986 die firmeneigene PA-RISC Serie eingeführt, die langsam in die Jahre gekommen war, und deren Leistung nur mit großem Aufwand gesteigert werden konnte. HP arbeitete an einem Nachfolgedesign, einem „Post-RISC“ Prozessor. Zentrales Element der Architektur war eine VLIW-Architektur.

VLIW steht für „Very Long Instruction Word“. Bei einem konventionellen Mikroprozessor lädt dieser zuerst den Opcode eines Befehls und dann festzustellen wie lange er ist und wie viele Daten folgen. Dann lädt er diese und führt den Befehl aus. Dieses klassische Konzept wurde schon durch frühere Erweiterungen aufgeweicht. Der Intel 80286 führte die Pipeline ein, bei der gleichzeitig mehrere Befehle in verschiedenen Stadien abarbeitet werden. Der Pentium war der erste superskalare Prozessor, das heißt, die einzelnen Funktionseinheiten in einem Prozessor waren nicht einmal vorhanden, sondern mehrmals. Sie können so mehrere Befehle parallel ausführen, da jeder Befehl eine Funktionseinheit zumindest für einen Takt, meist mehrere blockiert. Der Itanium hatte nicht weniger als neun dieser Funktionseinheiten.

VLIW war ein Lösungsansatz die Auslastung der Einheiten zu erhöhen. Die grundlegende Idee ist, das nicht ein Befehl auf einmal geholt wird, sondern mehrere die zusammen ein VLIW bilden. Das entlastet zum einen mal das Bus- und Cachesystem das so größere Einheiten auf einmal vom Speicher holen muss und bei gleicher Cacheline-Anzahl einen größeren Cache unterstützen kann. Die zweite Idee des Designs war, das im VLIW einige Bits vorhanden sind, die angeben wie die Befehle voneinander abhängen. Das Grundproblem der parallelen Abarbeitung einer super-skalaren Architektur ist, das Code Abhängigkeiten hat. Wenn eine Rechnung ein Ergebnis benötigt, das im Befehl vorher ermittelt wird, dann kann dieser Befehl nicht ausgeführt werden, bis der vorherige abgearbeitet ist. Wenn ein bedingter Sprung durchgeführt werden muss, muss man erst die Bedingung auswerten, um den Sprung durchzuführen (oder eben nicht).

Die x86 Architektur verwendet ausgeklügelte Verfahren, um möglichst viele Befehle parallel auszuführen. So zieht es Befehle vor: „out-of-order-Execution“, versucht das Ergebnis eines Sprunges vorherzusagen „Branch perdiction“. Doch diese Verfahren machen auch den Prozessor komplex. Er benötigt so mehr Transistoren und ist teurer zu fertigen. Die Idee beim Itanium war, dass der Compiler der das Quellprogramm hat und damit viel besser weiß, was parallel ausgeführt werden kann, in einigen Statusbits dem Prozessor mitteilt welche Befehle in einem VLIW wie voneinander abhängen. Notfalls, wenn eine parallele Ausführung nicht möglich ist, muss man in dem VLIW Befehle weglassen, d.H. mit dem Befehl NOP (No Operation) füllen. Intel nannte diese Technologie EPIC (Explicitly Parallel Instruction Computing). Der grundlegende Vorteil von EPIC ist, das die CPU damit viel weniger komplex ist, so kann auf die out-of-order-Execution verzichtet werden. (Das Gegenteil:: in-order-Execution beherrscht jede CPU, selbst die einfachste, denn das ist der Normalfall).

Das Design wurde von Hewlett Packard ab 1994 entwickelt, die einen sauberen VLIW Prozessor, ohne „Altlasten“, also Unterstützung veralteter Architekturen schufen. Er sollte die PA-RISC Serie ersetzen. Als Intel dazukam, wurde das Design jedoch verändert. Intel hatte aus den Fehlern beim i860 gelernt, der zwar ein sehr leistungsfähiger RISC-Prozessor war, aber einen neuen Befehlssatz hatte, mit dem Code für schon vorhandene Plattformen – bei Intel die x86-Linie - nichts anfangen konnte. Intel wollte einen zusätzlichen Modus, in dem der Itanium auch den x86 Code ausführen konnte, damit Benutzern es möglich ist ihre Software zu migrieren. Apple war hier ein Vorbild. Die Firma hatte etwa zur gleichen Zeit die MC 68k Linie durch den Power PC ersetzt und eine Emulationsschicht erlaubte die Ausführung der alten Programme, obwohl der PowerPC anders als der Itanium nicht die Befehle der Plattform verstand, die er ablösen sollte. Das brachte HP dazu eine ähnliche Erweiterung einzubauen mit denen der Itanium auch die Befehle der PA-RISC Architektur abarbeiten konnte. Anders als die „IA32“ Erweiterung von Intel steckte diese aber nicht im Prozessor, also als Hardware, sondern war eine Emulationsschicht für das Betriebssystem HP-UX.

Bei EPIC wurden drei Befehle von je 41 Bit Länge zu einem 128 Bit langen VLIW zusammengefasst. Die verbleibenden 5 Bits (3 x 41 = 123, nicht 128) enthalten Information über den Typ der Befehle und ihre Abhängigkeit. Mit 5 Bits sind 32 Kombinationen möglich, davon wurden bei der ersten Version des Itaniums 24 benutzt. Es gab fünf verschiedene Befehlstypen: M (Memory), I (Integer), F (FPU), B (Branch) oder LI (64 Bit Immediate). Für je eine Kombination dieser Typen gab es eines der 24 Templates z. B. für MFI oder MMI.

• M: Memory

• I: Integer

• F: Floating Point

• B: Branch oder Branch Hint

• H: Branch Hint

• LI: Long Immediate

Es war Aufgabe des Compilers, die Befehle so zu gruppieren, das sie parallel ausgeführt werden konnten. Ging dies nicht, so musste er unbelegte Felder im VLIW Dreier Bündel mit NOP (No Operation) ausfüllen. Erkannte der Prozessor einen Konflikt, griffen z. B. zwei Befehle desselben Bündels auf dasselbe Register zu so erzeugte er eine Exzerption, die vom Betriebssystem behandelt werden musste.

Jede einzelne Instruktion hatte wie bei RISC üblich, einen festen Aufbau. Es gab 14 Bits für die Opcodes – damit hätte man theoretisch 16.384 Befehle definieren können, was dann nicht „RISC“ ist. Es folgten maximal die Register, die aber je nach Operation nicht alle benötigt wurden. Als Drei-Adresss-Architektur landete das Ergebnis einer Operation von zwei Registern (Operanden) in einem dritten Register. Wie man an dem Format sieht, war die Architektur darauf ausgelegt Register-zu-Register Operationen auszuführen. Andere Architekturen definierten noch ein zweites Befehlsformat für Ladeoperationen, bei denen man anstatt der Register 2+3 einen Wert (oder zumindest einen Teil eines Wertes ablegen konnte).

Die Architektur des Itaniums war eine 64 Bit Architektur, genannt IA64. Es gab damals noch keine 64 Bit Prozessoren der x86 Linie, die ersten Athlons sollten erst im Frühjahr 2004 erscheinen. Eine 64 Bit Konstante sprengte aber die 41 Bits, die für einen Befehl zur Verfügung standen, sodass dann ein Befehl im Bündel wegfiel. Der Itanium hatte eine Dreiadress-Architektur, das heißt das Ergebnis überschrieb nicht wie bei x86 einen der Operanden.

Der Adressraum des Itaniums war 44 Bits (16 TByte) physikalisch und 54 Bits virtuell groß. Das nutzte zwar nicht die vollen 64 Bits aus, man sollte aber bedenken, das als der Merced 2001 erschien, ein typischer PC 1 GByte Speicher hatte. 16 Terabyte waren das 16.000-fache dessen. Von den 44 Bit dienten drei Bits dazu, einen von acht Räumen zu selektieren. So konnte man zwischen Adressraum 0 (Kernel) und 7 (Usermode) verschiedene Schichten einziehen, die man zum einen für abgestufte Sicherheitskonzepte (Treiber) wie auch für Puffer nutzen konnte. Virtuellen Speicher unterstützte er, wie andere Prozessoren auch, über das Mappen von Seiten die für den logischen Speicher standen, wobei der Itanium jede Seitengröße zwischen 4 KByte und 256 MByte unterstützte. Üblich waren bei anderen Architekturen meist nur zwei Seitengrößen einem 4 KByte und einmal einigen Megabyte (typisch 1-4).

Intern hatte der Itanium 128 Allzweckregister. Das war ein großer Unterschied zur x86-Architektur bei der es nur acht Register waren und diese Register teilweise Spezialaufgaben hatten. Mehr noch: durch die Zwei-Adress-Architektur landeten alle Ergebnisse im Akkumulator, was zusätzliche Kopierbefehle nötig machte. Es gab jeweils drei Registersätze für Ganzzahlen, Fließkommazahlen und Adressen. Die Register für Ganzzahlen und Adressen waren 64 Bittig, die für Fließkommazahlen dagegen 82 Bit breit. Das wundert etwas, den der internationale Standard für Fließkommazahlen kennt kein 80 Bit Gleitkommaformat, sodass andere Prozessoren nur mit 64 Bit langen Fließkommazahlen arbeiten. Intel führte dieses Format aber schon 1982 im Intel 8087 Coprozessor ein und hat es bis heute beibehalten. Da allerdings die Architektur sonst mit 64 Bit arbeitet, belegt eine 82 Bit Fließkommazahl im Speicher 128 Bit, ein ganzes VLIW und der Itanium unterstützt daher auch ein Gleitkommaformat von 128 Bit Breite, muss diese Zahlen aber in zwei Etappen verarbeiten. Das Format wurde übrigens 2008 dann auch standardisiert. Allerdings beherrschte die FPU nicht Division, Wurzel, Sinus, Tangens, Exponentialfunktion oder Logarithmus. Diese Funktionen mussten per Softwarebibliothek bereitgestellt werden. Das hatte seine Gründe. Ein guter Algorithmus in einer Softwarebibliothek erreicht eine gute Auslastung der FPU bei Feldern durch Pipelining, während damals eine Fließkommaoperation die bei anderen Prozessoren durch Microcode erfolgte, welcher die FPU während der Operation komplett blockierte. Die FPU-Register konnten auch für MMX/3DNow!-artige Ganzzahloperationen mit 8, 16 oder 32 Bit Integerzahlen und für zwei gleichzeitige Single Precision Fließkommaoperationen (32 Bit) gleichzeitig genutzt werden. Zudem hatte der Itanium den MAC Befehl der gleichzeitig eine Multiplikation und Addition ausführte, so wie ein Jahrzehnt später Intel bei AVX mit dem FMA Befehl.

Die 128 Register waren deutlich mehr, als andere Architekturen hatten und so wurden sie in zwei Teile aufgeteilt. Die ersten 32 Register waren „statisch“ und immer verfügbar um wichtige Werte in den Register zu halten. Die anderen 96 Register wurden dynamisch für das Übergeben von Werten an Unterprogrammen genutzt. Die x86 Architektur nutzte dazu den Stack, der aber nicht im Prozessor, sondern im Speicher ist und damit zwangsläufig langsamer. Das erinnert etwas an die SPARC Architektur die Register-Windows eingeführt hat.

Die große Zahl an Registern erlaubt es auch Register zu „mappen“. Verarbeitet man Daten in einer Schleife, so kann man den nächsten Schleifendurchlauf schon durchführen, wenn die erste Schleife noch gar nicht durchgelaufen ist, dann werden einfach weitere unbenutzte Register „gemappt“.

Dazu gab es noch 128 Applikations-, 8 Sprung-, 8 CPUID- und diverse Performance-Monitor-Register für die (mindestens vier) Performance-Counter.

Da der Itanium nur „In-Order“ arbeitet war sehr wichtig, das der Fluss der Befehle in der CPU nicht aufgehalten wird, da er ja keine Befehle vorziehen kann. Besonders Sprünge halten dabei auf. Sehr viele Sprünge benötigt man oft, um einige Instruktionen zu überspringen. Der Itanium hatte dafür bedingte Anweisungen, die mit 64 Prädiktoren verknüpft waren. Jeder Prädiktor stand für eine Bedingung, an die die Ausführung eines Befehls verknüpft war. So konnte der Prozessor bei einer if c>b then a:=c else a:=b die Zuweisungen a:=b und a:=c (durch Register-Mapping) parallel ausführen und dann einfach ein Resultat verwerfen, wenn die Bedingung feststand. Das war schneller, als einen Sprung durchzuführen, bei dem die gesamte Pipeline neu gefüllt werden musste. Auch die 64 Prädiktoren waren in 16 statische und 48 dynamisch vergebene aufgeteilt.

Neu war auch, das der Itanium Daten spekulativ in Register laden konnte, nicht nur wie andere Prozessoren in den Cache.

HP baute in ihr Betriebssystem HP-UX eine Softwareemulation ein. Die Technik führt zur Laufzeit dynamische Optimierungen durch. Damit konnte HP offenbar recht erfolgreich binären PA-RISC-Code auf die IA-64-Architektur mappen. Die Emulation war schneller als die Hardwareemulation von IA32 im Prozessor, wahrscheinlich weil die beiden Befehlsformate so völlig unterschiedlich sind und wie erwähnt die Geschwindigkeit des Prozessors stark von der Gruppierung von abhängigen Befehlen abhängt und eine Softwareschicht kann diese eben umgruppieren, vorhandener Code ist unveränderlich.

Intel stattete hingegen den Itanium mit einer Hardwareemulation aus (genannt IA-32) samt einer kompletten PC-Virtualisierung (also inklusive der Zusatzbausteine wie Timer, DMA etc) aus - voll kompatibel zur x86 IA-32 samt aller Eigenheiten wie etwa A20-Gate.

Schon als der Merced erschien, wurde der interne Cache als zu klein angesehen. Da der Code aufgrund der Verarbeitung von 128 Bits größer als 32 Bit Code (eine Cacheline war z. B. 64 Byte lang, bei dem Pentium III waren es nur 32 Byte) waren beide interne Caches zu klein. Vor allem beim L2-Cahe fiel das auf. Der zeitgleich in derselben Technologie hergestellte Pentium III hatte einen 2,7-mal größeren Cache. Dafür hatte der Merced einen externen L3-Cache von 2 oder 4 MB Größe. Der L1-Cahce war nur ein Write-Through Cache, er pufferte also keine Schreibzugriffe ab. Das tat der L2-Cache. Der war aber ECC-Fehlergeschützt. Dieses Feature bremste vor allem 32 Bit Software aus, weil dann immer nur eine halbe Cacheline angesprochen wurde. Der externe L3-Cahce war meinem 128 Bit breiten Bus und vollem Prozessortakt angebunden, hatte aber eine große Latenz, der Speicher mit einem 64 Bit breiten Datenbus. Auch hier hätte man angesichts dessen das ein Befehlsbündel immer 128 Bit lang war sicher einen 128 Bit Bus verwenden können. Der Datenbus hatte eine Frequenz von 133 MHz.

Innerhalb des Prozessors waren die 64 Bit Ganzzahlregister mit einem 64 Bit breiten Bus angebunden, die Fließkommaregister mit einem 128 Byte breiten Bus und die Caches an den Decoder und Dispatcher mit 256 Bit Datenbus. Der Dispatcher konnte maximal zwei Bündel also sechs Befehle an die Funktionseinheiten verteilen. Davon gab es insgesamt neun Ports die drei Branch Units, um Verzweigungen vorherzusagen bzw. bedingte Zuweisungen zu machen, je zwei Memory und Integer-Units und zwei Fließkommaeinheiten. Die Fließkommaeinheiten hatten dann noch angeschlossen weitere Einheiten für SIMD-Instruktionen.

Die Pipeline des Merced war 10 Stufen lang. Das war zu der damaligen Zeit relativ kurz für einen CISC Prozessor, relativ lang für einen RISC Prozessor. Der Pentium II/III hatte eine 12.-stufige Pipleine, der Athlon XP eine 12-stufige Integer und 18-stufige FP-Pipeline. Je länger eine Pipeline ist, desto höher kann der Prozessortakt sein, da man die Gesamtausführungsdauer eines Befehls auf mehr Stufen verteilen kann. Andererseits muss der Inhalt der Popeline verworfen werden, wenn es einen Sprung gibt. Das bedeutet bei einer längeren Pipeline einen größeren Zeitverlust. Beim Merced mit seinen bedingten Ausführungsanweisungen sollte man weniger Sprünge erwarten und damit kann eine Pipeline länger sein.

Hier ein Vergleich des Merced und des Pentium III in denselben Technologie (180 nm Strukturbreite).

Geschichte

Nach den überwiegend positiven Ausführungen über die Architektur verwundert es etwas, warum der Prozessor kein Erfolg wurde. Doch die beste Architektur nützt nichts, wenn es Flaschenhälse und Probleme mit der Software gibt. Rechtzeitig zum Start veröffentlichte Microsoft eine Version von Windows XP für den Itanium und auch HP brachte eine angepasste Version seines Betriebssystems UNIX HP-UX heraus.

Das geplante Releasedatum von 1997 war so nicht zu halten und verschob sich auf 2001. Als der Itanium dann erschien, fiel die erste Version Codename Merced schon hinter den Erwartungen zurück. Schon vorher erklärte Intel den „Merced“ als ein „Proof of Concept“.

Aufgrund der Verzögerung war der Takt, der 1997 noch hervorragend gewesen wäre, nun nicht einmal mehr Mittelmaß. Der maximale Takt betrug 800 MHz. Der Athlon erreichte damals 1.600 MHz und der Pentium III 1.400 MHz. Das war deutlich hinter den etablierten Architekturen. Immerhin hatte Intel aus dem Desaster des i860 gelernt, der ein sehr schneller und leistungsfähiger 64 Bit Riscprozessor war, aber für den es eben keine Software gab aus Crosscompilern von Intel die auf x86 Systemen liefen. Man hatte Microsoft mit ins Boot geholt. Es gab beim Start eine Windows XP Itanium Version. Später folgen Windows Server 2003 und 2008.

Verglichen wurde der Itanium in populären Zeitschriften immer mit schon existierenden Benchmarks für die x86 Linie. Verarbeitete der Prozessor seinen nativen IA64 Code so war er in Benchmarks in etwa genauso schnell wie ein gleich hoch getakteter Pentium III oder Athlon XP. Allerdings gab es diese schon mit höherer Taktfrequenz auf dem Markt und sie kosteten nur einen Bruchteil der 1.200 bis 4.000 Dollar die man nur für den Itanium bezahlen musste. Der Autor kaufte im selben Jahr einen Rechner mit Athlon 1.200 MHz Takt. Das ganze System kostete 1.799 DM, also so viel wie nur die kleinste Version des Merced und dafür erhielt man nur den Prozessor. Verarbeitete der Merced den Code der x86 Linie (IA32) so sank seine Performance auf die eines 100 MHz Pentiums.

Als Schwachpunkt entpuppten sich zum einen die zu kleinen Caches. So wurde für die nächste Generation , von Intel „Itanium 2“ bezeichnet, der L3-Cache in den Chip übernommen, aber auch die Erwartungen an EPIC erfüllten sich nicht. Die Compiler erzeugten nicht den Code, in dem die Befehle voneinander unabhängig gruppiert werden konnten. Das Compiler relativ wenig optimieren, ist bis heute so, wie man an selbst trivialen Benchmarks sehen kann. Versprochen wurde, dass wenn die compilierten Programme mit einem Profiler starteten, also einem Programm, das genau misst, wie der Code ausgeführt wird, die Compiler aus den gewonnenen Informationen die Befehle besser gruppieren könnte. Doch auch das erfüllte sich nicht oder es wurde schlichtweg nicht gemacht, zumindest fand ich bei der Recherche keinen Artikel, in denen ein solcher Profiler zum Einsatz kam.. Da Der Itanium kein Out-Of-Order Scheduling beherrscht bedeutet das einen deutlichen Geschwindigkeitsnachteil. Untersuchungen ergaben, dass er gegenüber einer Out-Of-Order Architektur rund 40 Prozent an Performance verliert.

Intel kündigte an, das die Erste Generation „Merced“ langsam sein würde, man aber an einer optimierten und schnelleren Architektur für den Nachfolger „McKinley“ arbeite, der dann auch im Takt zu den aktuellen Prozessoren aufschließen würde. Ab „McKinley“ nannte Intel den Prozessor „Itanium 2“.

Wichtigste Änderung für McKinley war das Integrieren des L3-Caches in das CPU-Die, um die miserable Performance, weil die Caches leerliefen zu steigern. Der L2-Cache wurde deutlich vergrößert und beschleunigt. Die Transitrosenzahl stieg durch das hinzunehmen des L3-Caches der ja selbst in der kleinsten Version 20-mal größer als der L2-Chace war, auf 225 Millionen Transistoren an. Der Takt selbst stieg nur leicht auf 1 GHz. Die Pipeline wurde gegenüber dem Vorgänger auf acht Takte verkürzt, was Sprünge beschleunigt. Der Datenbus zum Speicher beschleunigte sich auf 200 MHz.

Die dritte Generation „Madison“ bekam noch größere L3-Caches. Sie wurde bei gleichem Takt um 30 bis 50 Prozent, mit Berücksichtigung des höheren Taktes von 1,5 GHz um etwa 50 bis 60 Prozent schneller. Durch die Steigerung des Takts zum Speicher auf 200 MHz und den höheren Takt hatte Madison die sechsfache Bandbreite des Merced.

Die vierte Generation „Montecito“ hatte nun zwei Kerne. Zusätzlich gab es nun einen weiteren gemeinsamen L3-Cache für beide Kerne von 20 bis 32 MByte Größe, was die Transistorzahl auf 1,7 Milliarden katapultierte – 68-mal mehr als „Merced“. Bei Montecito flog nun die IA-32 Emulationseinheit aus dem Prozessor, dafür kam eine Schiebeeinheit. Der Scheduler konnte nun auch drei Befehlsbündel anstatt zweier gleichzeitig bearbeiten. Trotz zweier Kerne wurde der Stromverbrauch um 20 Prozent gesenkt. Erneut wurde an den Caches gearbeitet. War vorher der L1-Cahce aufgeteilt in Daten und Codecache so wurde dies nun der L1-Cache. Der Codecache blieb bei 256 KB, der Datencache wurde auf 1 MByte vergrößert.

Montecito konnte bei Benchmarks mit einem guten Compiler mit damals aktuellen IA32 Prozessoren von Intel (Xeon) und AMD (Opteron) mithalten oder sogar überflügeln, musste sich aber IBMs PowerPC 5+ geschlagen geben. Sein Nachfolger Montvale hatte vor allem eine Anbindung an den Bus bekommen die auch die Xeon Serverprozessoren bekamen.

Inzwischen hatte Intel die Bezeichnung erneut geändert. Geplant für 2009 war die nächste Evolution „Tukwilla“. Schon beim Montecito sprach Intel aber nicht mehr vom „Itanium 2“, sondern Itanium 9000, entsprechend war Montvale de Itanium 9100.

Tukwilla als erster „Itanium 3“ (auch wenn dies nicht mehr so hieß, sondern Itanium 9300) setzte den Pfad fort, den man bei Montvale begonnen hatte, man lies den Prozessorkern unverändert und wandte bei Caches und Bus Technologien an die auch in der x86 Linie eingesetzt wurde, hier war es der Quickpath zur Verbindung der Cores. Tukwila hat nun bis zu vier Kerne, unterstützte DDR3-Speicher. Tukwila verdoppelte über SMT die Zahl der verarbeitbaren Threads (Symmetrisches Multithreading, SMT) . SMT gaukelt dem Betriebssystem mehr Kerne vor als es gibt. Der Code der nicht vorhandenen Kerne wird an die ungenutzten Funktionseinheiten verteilt. SMT kann je nach Prozessordesign etwa 10 bis 30 Prozent mehr Performance erbringen.

Ansonsten änderte sich nicht viel, nur der Herstellungsprozess wurde auf 65 nm verkleinert. Neu war auch die von der x86 Serie schon bekannte Möglichkeit des Turbo-Boost, also der Erhöhung der Taktfrequenz einzelner Kerne, wenn die anderen nicht ausgelastet sind. Der physikalische Speicher hatte nun 50 anstatt 44 Bits zur Adressierung.

Der Nachfolger Poulson (Itanium 9500) kam erst zwei Jahre später 2012, da Intel den 45 nm Prozess übersprang und den Prozessor gleich im 32 nm Prozess fertigte, Die Zahl der Kerne wurde nun auf maximal acht verdoppelt, ebenso die Caches. Die L1-Caches wurden deutlich vergrößert, die L2-Caches nun gemeinsam genutzt. Das Hyperthreading (SMT) wurde verbessert. Auch wurde erstmals seit Montecito der Maximaltakt deutlich auf 2,53 GHz gesteigert.

Zwischendurch prozessierten HP und Intel wegen des Itaniums gegeneinander. Die Vereinbarung die schließlich gezogen wurde, war das Intel bis 2017 Itaniumprozessoren für HP herstellen würde. HP bezahlte dafür 440 Millionen Dollar für den Zeitraum 2010 bis 2014 und weitere 250 Millionen Dollar bis 2017. Danach gat Intel die Architektur wohl aufgegeben, denn der letzte Itanium „Kittson“ (Itanium 9700) erschien erst 2017 und er beinhaltete keine Architekturänderungen, sondern war nur eine etwas schnellere Ausführung des Poulson. Mit der Veröffentlichung gab Intel bekannt, dass dies der letzte Itanium Prozessor sein würde. 2019 wurde, dann angekündigt das die Produktion auslaufen würde und Kunden Bestellungen bis zu einer Frist abgeben müssten, die letzten Prozessoren wurden dann im Sommer 2020 ausgeliefert.

Der Itanium hatte seinen höchsten Marktanteil 2008 bei den Servern mit etwa 26 Prozent. Danach sank er. Die meisten Server – geschätzt 80 Prozent – verkaufte HP. Nach 2008 stiegen die Firmen, die bisher den Itanium anboten nach und nach aus, auch weil andere Plattformen preislich attraktiver waren. 2015 war nur noch HP Hersteller von Itanium Servern. Kleine Notiz am Rande: Als Sun (heute Oracle) 2011 nach schlechten Verkäufen die Produktion von Itanium-Systemen einstellte, klagte dagegen Hewlett-Packard und gewann in letzter Instanz am 1.10.2021. Zu dem Zeitpunkt produzierte keine Firma mehr Itanium-Systeme, auch nicht HP. Oracle musste 3 Milliarden Dollar an HP zahlen. Immerhin gibt es seitens HP noch Support bis zum 31.12.2025.

Retrospektive

Heute gilt der Itanium als großer Fehlschlag, von dem sich Intel aber anders als bei den vorherigen Fehlern wie iAPX432 oder I860 die nur wenige Jahre lang produziert wurden, nicht trennen konnte. Intel kündigte erst Mitte 2019 das Produktionsende des Itaniums an, die letzten Exemplare wurden 2020 ausgeliefert, rund zwanzig Jahre nach Einführung. Die meisten Hardwarehersteller hatten sich schon Jahre oder Jahrzehnte vorher von der Architektur verabschiedet, selbst HP welche sie zusammen mit Intel entwickelten. Bei Tests ergab sich übrigens, das die Itaniums in HPs eigenen Systemen deutlich schneller waren als in anderen Systemen. Auch die hauseigene PA-RISC Emulation war viel weniger langsam als die des IA-32 Codes, obwohl es keine Hardware dafür im Prozessor gab. HP hatte offensichtlich die besseren Compiler für den Itanium. So verwundert es auch nicht das die Firma die meisten Systeme verkaufte. Die Langsamkeit spielt bei größeren Servern nicht die Rolle, sofern der Systempreis stimmt, und zumindest die kleineren Itanium-Versionen boten mit unter 1.000 Dollar pro Prozessor hier einen attraktiven Preis verglichen mit Konkurrenzen. Ein Server setzte dann eben mehr Prozessoren ein. Bei Workstations mt dagegen nru einem oder zwei Prozessoren war dies aber ein entscheidendes Argument gegen den Itanium. Der Marktanteil bildet den Verlust des Performancekampfes deutlich ab. Den höchsten Marktanteil hatte Intel als Montecito/Montvale aktuell waren. Von Merced bis Montecito schaffte Intel es den Takt zu verdoppeln, die Kernzahl ebenfalls und den Bustakt zu vervierfachen. Die Caches wurden um ein vielfaches größer und in den Prozessor integriert. Danach gab es nur noch eine Erhöhung des Taktes um 50 Prozent, der Busgeschwindigkeit um ebenfalls 50 Prozent und eine Verdopplung der Kernanzahl, obwohl zwischen Merced und Montecito nur fünf Jahre liegen, zwischen Montecito und Kittson aber elf Jahre.

Für den Fehlschlag gibt es mehrere Gründe. Einer der wichtigsten ist, das Intel auf EPIC setzte und damit darauf, das de Compiler die Befehle so anordnet das der Prozessor maximal ausgelastet ist. Das klappte aber niemals. Ohne Out-Of-Order Scheduling, das auch bei den nachfolgenden Generationen nie eingeführt wurde, blieb die Performance so gering. Wie sich der Compiler auswirkte, zeigte ein Test in der ct 6/2007 S.194-198: Der Microsoft-Compiler erzeugte dreimal langsameren Code auf einem Montecito als Intels Compiler, und der wurde von HP’s Compiler um weitere 40 Prozent überboten. Angesichts dessen sollte ein Käufer eines Itaniums wohl mehr Geld in den Compiler stecken als in den Prozessor selbst ….

Das Problem, das die Caches zu klein waren, um die 128 Bit langen VLIW schnell genug an den Prozessorkern zu liefern wurde angegangen. Aber hier übertrieb man es. Anstatt andere Schwachstellen anzugehen wurden die Caches immer größer. Die immer mehr Transistoren auf dem Chip machten ihn teuer. Im oben erwähnten Artikel der ct’ wurde als Vergleich im Fließkommabenchmark auch der Merced angeführt. Dessen SPECfp_rate_base2000 betrug 22,4 bei 800 MHz. Montecito schaffte bei 1,6 GHz maximal 123,4. Bezogen auf den Takt ist das eine Steigerung um den Faktor 3 (ei zwei Kernen), aber dafür musste Intel 68-mal mehr Transistoren auf dem Chip unterbringen. Das zeigt schon das Problem, denn mehr Transistoren bedeuten auch einen teureren Prozessor.

Ebenso blieb die Taktfrequenz immer hinter anderen Prozessoren zurück. Als „Montecito“ 2007 erschien, hatte er einen Takt von maximal 1,6 GHz, der Server-Prozessor Power PC von IBM dagegen 5 GHz. Nach Montecito wurden die folgenden Generationen des Itaniums von der Fachpresse abgeschrieben, der Autor hatte Probleme aussagekräftige Reviews zu finden.

Die Steigerung in der Leistung war über einen Zeitraum von 20 Jahren bescheiden. Datei darf man nicht vergessen das andere Plattformen nicht stehen blieben. Die Takte von x86 Prozessoren stiegen schnell auf 3 GHz, dann langsamer. Mit dem Sprung auf Zweikernprozessoren schaltete man in der Taktfrequenz wieder etwas zurück, doch immer blieb der Itanium im Takt hinter anderen Prozessoren. Ebenso war schon von Anfang an die 64 Bit Fähigkeit nur ein Alleinstellungsmerkmal in der Intel/AMD Welt. Nachdem 2004/5 Amd und intel die heutige 64 Bit Architektur in die x86 Linie eingebaut hatten, war auch dieser Vorteil weg. Kleines Detail am Rande. Intel hatte zuerst eine eigene Erweiterung eingebaut, die sich an dem Itanium-Befehlsatz orientierte, während AMD mit AMD64 einfach nur die bisher vorhandenen Register auf 64 Bit erweiterte. Nachdem der Markt diese einfachere Lösung besser annahm, übernahm sie auch Intel. AMD dürfte im Austausch dafür AVX in ihre Prozessoren einbauen.

Relativ spät machte man den Sprung beim Itanium auf mehrere Kerne, auch das hatten Intel und AMD bei der x86 Linie zwei Jahre früher hinbekommen und sie bauten immer mehr Kerne in ihre Prozessoren ein. Dabei waren diese Chips als Massenprodukt sehr viel billiger.

Was den Autor persönlich verwundert ist, das man den eigentlichen CPU-Kern nie groß änderte, stattdessen sehr viel an den Caches arbeitete, wodurch auch die Transistorenzahl so enorm anstieg. Schaut man sich die Entwicklung der x86 Reihe im gleichen Zeitraum an, so warf Intel die grundlegende Basisarchitektur zweimal komplett über Bord (Vom Pentium III zum Pentium 4 mit seiner Netburst-Technologie und dann erneut zur bis heute geltenden Core-Mikroarchitektur. Diese Architekturen wurden auch intern immer weiter erweitert. Die Core Mikroarchitektur hatte als sie herauskam z. B. Fünf Ports, welche die Funktionseinheiten mit Daten versorgten, bei „Alder Lake“ (Core 12xxxx) sind es inzwischen 12 Ports also das 2,4-fache. So verwundert es nicht, dass Rechner mit diesen Architekturen an den Itaniums in der Performance vorbeizogen.

Intel hat geschätzt 10 Milliarden Dollar in die Entwicklung des Itaniums gesteckt. Das einzige was davon blieb und in anderen Plattformen übernommen wurde war die Erfindung des UEFI-Bios.

Links:

https://ark.intel.com/content/www/us/en/ark/products/34655/intel-itanium-processor-9152m-24m-cache-1-66-ghz-667-mhz-fsb.html

https://www.heise.de/select/ct/archiv/2001/13/seite-148

https://www.heise.de/select/ct/archiv/2007/6/seite-194

https://www.heise.de/select/ct/archiv/2010/9/seite-158

https://www.heise.de/select/ct/archiv/2014/12/seite-176

https://en.wikipedia.org/wiki/Itanium

https://www.heise.de/newsticker/meldung/Adieu-Intel-Itanium-3713706.html

Artikel erstellt: 4.3.2022

Zum Thema Computer ist auch von mir ein Buch erschienen. "Computergeschichte(n)" beinhaltet, das was der Titel aussagt: einzelne Episoden aus der Frühzeit des PC. Es sind Episoden aus den Lebensläufen von Ed Roberts, Bill Gates, Steve Jobs, Stephen Wozniak, Gary Kildall, Adam Osborne, Jack Tramiel und Chuck Peddle und wie sie den PC schufen.

Das Buch wird abgerundet durch eine kurze Erklärung der Computertechnik vor dem PC, sowie einer Zusammenfassung was danach geschah, als die Claims abgesteckt waren. Ich habe versucht ein Buch zu schreiben, dass sie dahingehend von anderen Büchern abhebt, dass es nicht nur Geschichte erzählt sondern auch erklärt warum bestimmte Produkte erfolgreich waren, also auf die Technik eingeht.

Die 2014 erschienene zweite Auflage wurde aktualisiert und leicht erweitert. Die umfangreichste Änderung ist ein 60 Seiten starkes Kapitel über Seymour Cray und die von ihm entworfenen Supercomputer. Bedingt durch Preissenkungen bei Neuauflagen ist es mit 19,90 Euro trotz gestiegenem Umfang um 5 Euro billiger als die erste Auflage. Es ist auch als e-Book für 10,99 Euro erschienen.

Mehr über das Buch auf dieser eigenen Seite.

Hier geht's zur Gesamtübersicht meiner Bücher mit direkten Links zum BOD-Buchshop. Die Bücher sind aber auch direkt im Buchhandel bestellbar (da ich über sehr spezielle Themen schreibe, wird man sie wohl kaum in der Auslage finden) und sie sind natürlich in den gängigen Online-Plattformen wie Amazon, Libri, Buecher.de erhältlich.

Sitemap

Kontakt

Impressum / Datenschutz

Neues

Hier werben / advertisment here

Buchshop

Bücher vom Autor