Milliardengrab: Warum Intels Itanium gescheitert ist

Parallel zu den RISC- und CISC-CPUs entwickelte HP seit 1989 an einem Konzept, das sich Explicitly Parallel Instruction Computing (EPIC) nannte. 1994 beteiligte sich Intel an dieser Entwicklung. Daraus sollte später der Itanium entstehen. EPIC basiert auf der Very-Long-Instruction-Word-Architektur (VLIW). Ein VLIW-Prozessor kann mehrere Befehle gleichzeitig ausführen. Allerdings muss der Compiler die Befehle gruppieren. Beim Itanium sind das drei Befehle pro Gruppe.

Die Überlegung ist ähnlich zu denen der RISC-Idee. Ein Compiler soll den Programmcode so gestalten, dass die CPU keine Techniken wie Out-Of-Order-Execution benötigt, um parallele Ausführung zu erreichen. HP nannte seine Architektur EPIC, weil neben VLIW weitere Techniken einflossen, etwa Sprungvorhersage und spekulative Ausführung, die später auch in RISC- und CISC-Prozessoren Einzug hielten.

Als im Jahr 2001 nach mehrjähriger Verzögerung endlich der erste Itanium auf den Markt kam, war allerdings klar, dass EPIC-CPUs keine zukunftsweisende High-Performance-Architektur aufweisen. Als Intel 1999 den Namen Itanium ankündigte, kursierte im Internet innerhalb von wenigen Stunden der Name "Itanic" als Anspielung auf Titanic.

Tatsächlich erwies sich der Itanium nicht als sonderlich skalierbar. Entwickler von RISC- und CISC-CPU mit dynamischen Scheduling-Techniken, zum Beispiel Out-of-Order-Execution und Hyperthreading, können bei Neuentwicklungen beliebig viele funktionale Einheiten wie Rechenwerke hinzufügen. Da der Befehlssatz frei von Reihenfolgebeschränkungen ist, kann die CPU immer versuchen, die funktionalen Einheiten bestmöglich auszulasten.

Bei den Dreiergruppen des Itanium müssen pro Instruction Word immer drei Wege zu funktionalen Einheiten frei sein. Realistisch lässt sich das nur erreichen, wenn man jede Einheit, etwa ALUs und FPUs. in durch drei teilbarer Anzahl implementiert.

Hinzu kommen Probleme, dass trotz der 128 General Purpose Register oft Fälle auftreten, bei denen nicht alle drei Befehle eines Instruction Word genutzt werden können. Dazu folgendes Beispiel aus der Itanium-Version des ZDNet-Tools MKLINK:

 {      .mmb                                               //R-Addr: 0X090
        ld8      r29=[r30]                                 //40 r       cc:18
        nop.m    0
        nop.b    0;;
 } // 00090 20 00 00 00 00 00 02 00 00 00 10 18 3c 00 e8 19
 
 {      .mmi                                                //R-Addr: 0X0a0
        ld8     r26=[r29], 8;;                              //40.       cc:0
        ld8     gp=[r29]                                    //40.       cc:1
        mov     b6=r26                                      //40.       cc:1
 } // 000a0 07 00 09 a0 c0 20 30 74 00 10 14 18 3a 20 d0 0a
 
 {      .mmb                                                //R-Addr: 0X0b0
        nop.m    0
        nop.m    0
        br.call.dptk.many b0=b6;;                           //40.       cc:1
 } // 000b0 12 80 00 68 00 00 02 00 00 00 00 01 00 00 00 19

Man erkennt, dass das erste Instruction Word zwei NOPs enthält. Es wird also nur ein Befehl statt drei ausgeführt. Das liegt daran, dass im zweiten Instruction Word mit dem Register r29 gearbeitet wird, dessen Inhalt im ersten bestimmt wird. Da das dritte Instruction Word einen bedingten Sprung enthält, stehen keine weiteren unabhängigen Befehle zur Verfügung, die im ersten Instruction Word noch ausgeführt werden könnten. Das Ende vom Lied ist, dass vier von neun Befehlen, also 44 Prozent, NOPs sind.

Ein RISC- oder CISC-Prozessor könnte geeignete Scheduling-Maßnahmen durchführen, um die CPU nicht leer laufen zu lassen. Ein VLIW-Prozessor ist an die Reihenfolge gebunden, die der Compiler vorgibt und hier in einem ungünstigen Verhältnis von NOP- und Nutzbefehlen vorgeben muss.

Themenseiten: Intel, Plattform, Servers, Software, Storage, Storage & Server

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

1 Kommentar zu Milliardengrab: Warum Intels Itanium gescheitert ist

Kommentar hinzufügen
  • Am 7. Juli 2009 um 20:22 von Davidoff

    WindowsNT 3.1 und 16MB RAM
    Wie Sie auf "Microsoft sah sich allerdings genötigt, das Chicago-Projekt ins Leben zu rufen, das in Windows 95 mündete, um damals übliche Rechner mit bis zu 4 MByte Hauptspeicher zu unterstützen" ist mir schleierhaft, denn "Windows NT 3.1 benötigt mindestens 16 MByte" ist schlichtweg falsch, auch der Nach-Nachfolger WindowsNT 3.51 lief noch prima mit 8MB RAM. Und selbst das gute alte WindowsNT 4 begnügt sich in der Workstation-Variante mit lediglich 12MB, nur die Server-Version brauchte tatsächlich 16MB RAM. WindowsNT 4 kam aber erst Ende 1996 und damit geraume Zeit nach Windows95 raus.

    Der wahre Grund für Windows95 lag zum Einen in der damals noch hohen Verbreitung von DOS-Programmen (vor Allem Spiele), welche unter der DOS-Emulation von WindowsNT garnicht bzw. nur eingeschränkt funktionierten. Zudem erlaubte das die Aufspaltung des eigenen Portfolios in Consumer- (Windows95) und Business-Linie (WindowsNT).

    Davidoff

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *