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
&nbsp
 {      .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.