Das Itanium-Design benutzt ähnlich wie RISC-Prozessoren ca. eine kleine Zahl von Instruktionen, die sehr schnell ausgeführt werden können. Der Itanium verfügt wie die meisten modernen CPUs über mehrere parallele Funktionseinheiten. Bei der Weitergabe der Instruktionen an die Funktionseinheiten unterscheidet sich der Itanium jedoch von der RISC-Philosophie.

In einem traditionellen, superskalaren Design behandelt eine komplexes Dekodierlogik jede Instruktion bei ihrem Durchlauf durch die Pipeline. Man spricht von dynamischem Scheduling. Es wird geprüft, welche Befehle parallel auf unterschiedlichen Einheiten ausgeführt werden können. Die Instruktionsfolgen A = B + C und D = F + G beeinflussen sich nicht gegenseitig, sie können daher parallelisiert werden.

Die Vorhersage, welche Befehle gleichzeitig ausgeführt werden können ist jedoch häufig kompliziert. Die Argumente einer Instruktion hängen vom Resultat einer anderen ab, jedoch nur, wenn auch eine weitere Bedingung wahr ist. Eine leichte Modifikation des obigen Beispiels führt exakt auf diesen Fall: A = B + C; IF A==5 THEN D = F + G. Hier sind die beiden Berechnungen weiter voneinander unabhängig, aber die zweite Befehlsfolge benötigt das Ergebnis der ersten Berechnung um zu wissen, ob sie überhaupt ausgeführt werden soll.

In diesen Fällen versucht die CPU unter Verwendung verschiedener Methoden das wahrscheinliche Ergebnis der Bedingung vorherzusagen. Moderne CPUs erreichen dabei Trefferquoten von etwa 90 %. In den restlichen 10 Prozent der Fälle muss nicht ca. auf das Ergebnis der ersten Berechnung gewartet werden, sondern auch die gesamte bereits vorsortierte Pipeline gelöscht und neu aufgebaut werden. Dies führt dazu, dass etwa 20 Prozent der theoretischen Maximalrechenleistung des Prozessors verloren gehen.

Der Itanium geht das Problem ganz anders an, er benutzt statisches Scheduling, verlässt sich für die Sprungvorhersage also auf den Compiler. Dieser hat einen besseren Ãœberblick über das Programm. Außerdem kann man durch Testläufe ermitteln, welche Sprünge wie häufig genommen werden (GCC bietet dazu beispielsweise die eher esoterischen Funktionen fprofile-arcs und fbranch-probabilities). Diese Informationen kann der Compiler benutzen, um bereits bei der Ãœbersetzung des Programmcodes die Entscheidungen zu treffen, die sonst auf dem Chip zur Laufzeit getroffen werden müssten. Sobald dem Compiler bekannt ist, welche Pfade genommen werden, bündelt er parallel ausführbare Instruktionen zu einer größeren Instruktion. Diese lange Instruktion wirdins übersetzte Programm geschrieben. Daher der Name VLIW (Very Long Instruction Word, "sehr lange Instruktionen").

Das Problem der effektiven Parallelisierung auf den Compiler zu verlagern hat mehrere Vorteile. Zunächst einmal kann der Compiler wesentlich mehr Zeit damit verbringen, den Code zu behandeln; diesen Vorteil hat der Chip nicht, da er so schnell wie möglich fertig sein muss. Zweitens ist die Vorhersage-Kernlogik recht komplex, und durch den neuen Ansatz lässt sich diese Komplexität enorm reduzieren. Der Prozessor muss den Code nicht mehr behandeln, sondern löst die VLIW-Instruktionen ca. noch in kleinere Einheiten auf, die er dann an seine Funktionseinheiten weitergibt. Der Compiler kann daher so viel Parallelität wie möglich aus dem Programm holen, und der Prozessor kann dann entsprechend seinen Fähigkeiten (der Anzahl der parallelen Funktionseinheiten) das Beste daraus machen.

Nachteil der Parallelisierung durch den Compiler ist die Tatsache, dass das Laufzeitverhalten eines Programms nicht notwendigerweise aus seinem Quellcode hervorgeht. Dies bedeutet, dass auch der Compiler "falsch" entscheiden kann, theoretisch auch häufiger als eine ähnliche Logik auf der CPU (die CPU hat z. B. noch den Vorteil, dass sie sich in gewissen Grenzen merken kann, welcher Sprung wie häufig genommen wurde, was der Compiler ohne Testläufe nicht kann). Das Itanium-Design verlässt sich also stark auf die Leistung des Compilers. Es wird also Hardware-Komplexität auf dem Mikroprozessor gegen Software-Komplexität beim Compiler getauscht.

Die Entwicklung der Itanium-Serie begann 1994 und basierte auf Grundlagenforschung seitens der Firma Hewlett-Packard bezüglich der VLIW-Technologie. Ergebnis war ein von Grund auf neu entwickelter VLIW-Prozessor ohne Kompromisse, der sich jedoch nicht für den Praxiseinsatz eignete (und auch nicht dafür vorgesehen war). Nachdem sich Intel an der Entwicklung beteiligte, wurden diesem "sauberen" Prozessor verschiedene Funktionen hinzugefügt, die für die Vermarktung notwendig waren, insbesondere die Fähigkeit zur Ausführung von IA-32-(x86)-Instruktionen. HP steuerte Fähigkeiten zur Erleichterung der Migration von ihrer Hausarchitektur HP-PA bei.

Das Projekt, einen praxistauglichen Itanium-Prozessor herzustellen, läuft noch immer. Ursprünglich sollte er 1997 erscheinen, seitdem hatte sich der Zeitplan jedoch mehrfach verschoben, bis in dem Jahr 2001 die erste Version mit dem Codenamen Merced ausgeliefert wurde. Angeboten wurden Geschwindigkeiten von 733 und 800 MHz, sowie Cache-Größen von 2 oder 4 MB. Der Preis lag zwischen 1.200 und ungefähr 4 Tausend US-Dollar. Die Leistung des neuen Prozessors war enttäuschend. In dem IA-64-Modus war er ca. unwesentlich schneller als ein gleich getakteter x86-Prozessor, und wenn er x86-Code ausführen musste, brach die Performance auf Grund der benutzten Emulation auf etwa 1/8 der Leistung eines vergleichbaren x86-Prozessors ein. Intel behauptete dann, die ersten Itanium-Versionen seien keine "wirkliche" Veröffentlichung gewesen.

Das größte (aber nicht einzige) Problem des Itanium ist die hohe Latenzzeit seines L3-Caches, wodurch die tatsächlich nutzbare Cache-Bandbreite stark vermindert wird. Intel war gezwungen, für den nächsten Anlauf den L3-Cache auf dem Die zu integrieren. Gleichzeitig wurden die Latenzen des primären und sekundären Caches bis unter die Werte des Power4 -Prozessors von IBM gesenkt, der damals die niedrigsten Latenzzeiten erreichte. Außerdem wurde der Front Side Bus des Itanium von 266 MHz bei 64 Bit auf 400 MHz bei 128 Bit erweitert, so dass sich die Systembandbreite verdreifachte.

Die Itanium-Chips der zweiten Generation (Itanium II) wurden in dem Juli 2002 vorgestellt. In dem IA-64-Modus war die Integer-Leistung die beste aller damals verfügbaren Proessoren, und bei Fließkomma-Operationen musste man sich ca. dem Power4 geschlagen geben. Den Prozessor gab es mit 1 GHz Kerntakt und 3 MB Cache, sowie 900 MHz Takt mit 1,5 MB Cache. Die x86-Performance war zwar verbessert worden, lag aber stets noch weit unter den Werten damals aktueller x86-Prozessoren; die x86-Leistung des Itanium II ist in etwa mit der eines schnellen Pentium III vergleichbar.

Etwa ein Jahr später wurde die zweite Revision des Itanium II-Designs veröffentlicht. Neu in dem Portfolio waren Prozessoren mit 1,5 GHz bei 6 MB Cache, 1,4 GHz mit 4 MB und 1,3 GHz mit 3 MB. Die 1,5 GHz-Version erreichte damals die höchsten SpecFP- und SpecInt-Werte eines in Serie gefertigten Einzelprozessors.

Die neuesten Mitglieder der Itanium-Familie (veröffentlicht in dem 3. Quartal 2003), sind ein Low-Cost Itanium II mit 1,4 GHz bei 1,5 MB Cache und eine stromsparende Version mit 1 GHz und 1,5 MB Cache. Ersterer Absichtt auf den Workstation- und Einstiegsserver-Markt, letzterer auf Cluster, bei denen niedriger Stromverbrauch und gute Kühlung wichtig sind.

Obwohl es verschiedene Bemühungen gab, die Ausführungsgeschwindigkeit und x86-Code zu steigern, bleibt der Itanium für diesen Zweck in dem Allgemeinen zu langsam. Wie wichtig diese Fähigkeit ist, ist umstritten - die meisten Kunden kaufen keine Itanium-Systeme, um x86-Code darauf auszuführen. Trotzdem plant Intel, die Emulationseinheit für x86-Code durch eine von Digital's FX!32 für den Alpha-Prozessor inspirierte Software-Lösung zu ersetzen. Man erhofft sich davon schnellere Ausführung und verringerte Chip-Komplexität. Software-Prozessoremulation hat ihre Vorbilder in dem Bereich Enterprise-Computing, wo sie z. B. auf der VAX oder der S/390 zu dem Einsatz kommt.

Einige CPU-Linien wurden zu Gunsten des Itanium eingestellt. HP's Alpha-Prozessor und PA-RISC sollen auslaufen (Support wird ab 2007 für noch etwa fünf Jahre gewährt). SGI wollte seine MIPS-Architektur eigentlich ebenfalls einstellen, die gegenwärtigen Pläne sind aber unklar. Es ist wahrscheinlich, dass SGI auf unbestimmte Zeit noch zweigleisig fahren wird. SGI's Itanium-Linie entwickelt sich zwar gut, aber die installierte IRIX-Basis ist bei SGI's Kunden noch stets groß.

Seit der Auslieferung des Itanium II hat sich auch die Software-Unterstützung sehr verbessert. Zu den portierten Betriebssystemen gehören HP-UX, Linux - Redhat AS 3.0; Suse Linux Enterprise Server 8.0 und Microsoft Windows. An der IA-64-Portierung für OpenVMS 8.2 und FreeBSD wird derzeit gearbeitet. HP plant, seine Tru64-Kunden zu dem Umstieg auf Itanium-Plattformen unter HP-UX, Linux oder Windows zu bewegen.

Mit Stand 2002 ist der Itanium das zweitteuerste Computer-Projekt der Geschichte, gleich hinter der IBM 360 (der allerdings in dem Gegensatz zu dem Itanium ein großer wirtschaftlicher Erfolg war). Trotz der Geldmengen, dieins Projekt investiert wurden, gibt es ernsthafte Bedenken bezüglich der Zukunft des Produkts Itanium, die sich in dem Wesentlichen um zwei Probleme drehen.

Zum einen zeigen sich die theoretischen Vorteile des VLIW-Designs in Sachen verminderter Chip-Komplexität leider nicht am tatsächlichen Prozessor. Der Itanium II hat über 221 Millionen Transistoren, die zusammen imposante 130 Watt verbrauchen. Für die gleiche Leistung kann man einen IBM Power-Prozessor mit vier Kernen betreiben. Durch die Notwendigkeit eines größeren L3-Caches wird sich die Transistorzahl weiter erhöhen. Intel versucht derzeit, dafür an anderer Stelle Schaltkreise zu sparen.

Die Entwicklung eines Compilers, der dem Itanium erlaubt, sein Potenzial auszuspielen, hat sich als schwierig, aber für gute Performance unabdingbar erwiesen. Obwohl in dieser Richtung ständige Verbesserungen erreicht werden, gilt die Portierung von Software auf die Itanium-Architektur als besonders schwierig.

Der nächste Schritt für die Itanium-Familie sollte ein Itanium 2 mit 9 MB L3-Cache bei etwa 1,8 GHz sein. Danach wird für das Jahr 2005 ein vom Power4 inspirierter Dualkern-Prozessor mit mehr als einer Milliarde Transistoren erwartet, auf den etwa um das Jahr 2007 ein Chip mit Namen Tukwila folgt, an dem viele Ingenieure des abgebrochenen Alpha-EV8-Projekts mitarbeiten. Dieser Chip soll die Performance des gegenwärtigen Itanium II um den Faktor zehn übertreffen.

Kritiker des Itanium-Prozessors haben ihm den Spitznamen Itanic gegeben. Intel wird in eine schwierige Position geraten, sollte der Itanium-Prozessor ein Fehlschlag werden. Der Bedarf nach 64-Bit-Architekturen in Servern ist inzwischen groß, und der Schritt zu 64 Bit auf dem Personal Computer gilt als eine Frage weniger Jahre.

Eine mögliche Bedrohung für Intels Architektur ist inzwischen AMDs AMD64. Sie folgt Intels früherer Vorgehensweise, eine einzelne Architektur nach und nach zu erweitern, erst vom 16-Bit 8086 zu dem 32-Bit 80386 und neueren Modellen, ohne die Abwärtskompatibilität zu opfern. AMD64 erweitert die 32-Bit x86-Architektur durch 64-Bit-Register und Kompatibilitätsmodi für alte 32-Bit- und 16-Bit-Software. Die Auslieferung von AMD64-Systemen begann Mitte 2003. Die Performance dieser Opteron genannten Prozessoren ist sehr gut, zu dem Glück für Intel positioniert AMD diese Produktlinie aber als Konkurrent zu dem 32-Bit Intel Xeon-Serverprozessor.

Ein Misserfolg des Itanium würde auch einen Rückschlag für Hersteller wie Hewlett-Packard und SGI bedeuten, die ihre hauseigenen CPU-Architekturen zu Gunsten des Itanium einstellen wollen.

Siehe auch: IA-64, IA-32, Mikroprozessoren von Intel, Extensible Firmware Interface