Im Solution Center fand der große Test statt.

Ein Riese ist in Aufbruchstimmung. Am Ende der 32-Bit-Ära will Intel auch im 64-Bit-Zeitalter weiter an vorders-ter Front mitmischen. Der größte Prozessorhersteller gewährte dem Testlabor des Linux-Magazins Zugang zu seinem Solution Center, um den neuen Itanium-Prozessor unter die Lupe zu nehmen.

Noch ist der Itanium eine relativ junge Neuentwicklung, die ersten fertigen Maschinen werden von den Software-Entwicklern okkupiert, denn noch gibt es sie nicht, die neue Software für das 64-Bit-Zeitalter.

Itanium ist dennoch ein heißer Prozessor. Insbesondere wissenschaftliche Anwendungen laufen geradezu rasant, wie der Test ergeben hat. Ein paar Schwächen gibt es bei der Linux-Implementierung. Genaueres lesen Sie ab Seite 28. Es geht bei diesem Test aber nicht darum herauszufinden, ob Itanium jetzt x Prozent schneller als ein Xeon- oder sonstiger aktueller 32-Bit-Prozessor ist. Sobald die Softwarehersteller die ersten großen Datenbanken, Groupwareserver und andere dicke Pakete freigegeben haben, wird das Linux-Magazin auch den Praxiseinsatz des Itanium analysieren.

Doch auch die Untersuchung der Details mit den so genannten Low-Level-Benchmarks ist spannend und aufschlussreich. Denn wenn die Datenströme von der Festplatte oder aus dem Netz nicht mit voller Geschwindigkeit kommen, dann kann die Datenbank noch so gut sein, ihre Geschwindigkeit wird sie nicht entfalten können. Zudem liefern Detail-Benchmarks wertvolle Hinweise, um spätere Messwerte von großen Programmen besser bewerten zu können. Ab Seite 28 lesen Sie im Detail, wie wir gemessen haben.

Kraftvoller Hertzschlag

Itanium beteiligt sich (noch) nicht an den Gigahertz-Rennen, wie sie derzeit Pentium III, 4 und Athlon durchmachen. Der Itanium, den das Testlabor getestet hat, wird mit einer Core-Frequenz von 800 MHz getaktet. Das ist jedoch kein Nachteil, denn Itanium führt mehrere Befehle pro Takt aus (sechs!) und kann auch Daten aus dem Hauptspeicher double pumped lesen, also mit doppelter Datenrate. 2,1 GByte pro Sekunde gibt Intel als Transferrate für den Systembus an. Die CPU-Leistung wird mit 3,2 Gigaflops bei doppelter und erweiterter Fließkommagenauigkeit und mit 6,4 Gigaflops pro Sekunde bei einfacher Genauigkeit vom Hersteller spezifiziert.

Im Solution Center fand der große Test statt.

Speicher ohne Ende

Hauptspeicher von 2 GByte ist jetzt Standardausstattung. Auch im Inneren wird großzügig mit Speicher umgegangen. Die zwei zusätzlichen Chips, die auf dem Foto des geöffneten Prozessors zu sehen sind, sind 4 MByte Level-3- Cache, der vierfach assoziativ arbeitet. Auf dem eigentlichen Prozessor befinden sich die anderen Caches.

Der Second-Level-Cache misst 96 KByte und arbeitet sechsfach assoziativ. Der schnellste Speicher, L1, ist zweigeteilt. Der Instruktionscache L1I ist 16 KByte groß, der Datencache L1D ebenfalls. Die Teilung in zwei dedizierte Caches bringt einen deutlichen Performancegewinn. L1I-, L1D- und L2-Cache sind 256 Bit breit angeschlossen, L3 mit 128 Bit. Die Fließkomma-Rechenwerke hängen nicht am L1-, sondern am L2-Cache. Somit können Integer- und Floating-Point-Register gleichzeitig geladen werden. Die FUs können zudem in Integer-Einheiten umgewandelt werden.

Die vielen Caches fordern ihren Tribut: So gesellen sich 295 Millionen Transistoren für Cache zu den 25,4 Millionen, die die Arbeit in der CPU machen.

Der interne Aufbau des Itanium im Detail.

Bruch mit der Vergangenheit

Itanium ist keine Weiterentwicklung der X86-Reihe, sondern von Grund auf neu entwickelt. Konsequenterweise bricht der Prozessor auch mit einer Reihe von althergebrachten Konventionen, was zum Teil ganz erhebliche Folgen für Software-Entwickler hat. Die gute Nachricht: Der Real Mode ist abgeschafft. 32 Bit ist also der kleinste gemeinsame Nenner. Intel betont dabei auch stets, dass die Abwärtskompatibilität zur IA32-Architektur nur für die Erleichterung des Übergangs gedacht ist, Performance sei hier nicht zu erwarten – dafür gibt’s ja IA64.

Die Zeiten sind also endgültig vorbei, als ein Prozess den ganzen Rechner okkupieren und darin frei schalten und walten konnte. Sicherheit war ein zentraler Gedanke, als Itanium entworfen wurde.

Labormitarbeiter Mirko Dölle am Itanium.

Intels Itanium im Test des Competence Center. Gut zu sehen ist die Verkabelung des Raid-Systems.

Paradigmenwechsel

Doch Itanium bricht noch mit einer Reihe anderer Gewohnheiten. Seit den Anfängen der Mikroprozessoren haben die CPUs eine Reihe von Paradigmenwechseln erlebt. Während die einen immer komplexere Befehle bekamen, die immer mächtiger wurden, speckten die anderen immer immer weiter ab. Die mächtigen Befehle der CISC-Prozessoren haben den Nachteil, dass sie viele Transistoren benötigen. Pro- zessoren mit weniger Befehlen versuchen, diese wenigen Befehle so schnell wie irgend möglich abzuarbeiten. Komplexe Aufgaben werden daher zwar mit vielen Befehlen be-arbeitet, die laufen aber schnell ab.

Der Hintergedanke der RISC-Idee ist, dass die weniger mächtigen Befehle auch mit weniger Transistoren konstruiert werden können. Bekommt man dann durch die Weiterentwicklung der Fertigungstechnik (Verkleinerung der Strukturgrößen) mehr Transistoren zur Verfügung, kann man die befehlsverarbeitenden Schaltungen mehrfach verbauen.

Wenn ein Prozessor so konstruiert ist, dass seine logischen Komponenten in nachfolgenden Generationen mehrfach verbaubar sind und damit die Geschwindigkeit erhöht werden kann, ohne den Code zu verändern, spricht man von einer superskalaren Architektur.

Doch es ist nicht so leicht, einfach zwei Addierer zu verbauen und zu erwarten, die Geschwindigkeit der Addition dadurch zu verdoppeln. Die Befehle, aus denen Programme bestehen, stehen ja einer nach dem anderen hintereinander. Und hier beginnt der Itanium, neue Wege zu beschreiten.

Der Itanium-Prozessor (rechts, unter dem Kühlkörper) und sein eigenes, privates Netzteil (DC/DC-Regler, links).

Superskalarität

Bisherige Prozessoren versuchen mit vielen Tricks herauszufinden, welche Befehle man gleichzeitig auf den vorhandenen Ausführungseinheiten abarbeiten kann. Außerdem kann man versuchen, Befehle in einer anderen als der vorgegeben Reihenfolge zu verarbeiten (Out of order execution), wenn das Vorteile bei der Auslastung bringt.

Das geht natürlich nur mit Befehlen, die nicht die Ergebnisse anderer Befehle weiterverarbeiten, denn dann müsste einer auf den anderen warten. Daher werden nur voneinander unabhängige Befehle auf die verschiedenen Ausführungseinheiten verteilt oder umsortiert. Da dies bei bisherigen Prozessoren von einer komplexen Logik im Inneren der CPU erledigt wurde, mussten sich die Compiler-Programmierer dafür nur am Rande interessieren.

Mit Itanium wird das nun anders. Itanium kann mit seinen 128 Bit breiten Instruktionsanweisungen (weshalb sich die Befehle auch aus jeweils drei Teilen zusammensetzen, explizite Parallelität) zum einen gleichzeitig drei Befehlsströme verarbeiten, zum anderen aber viel intelligenter die Auslastung der vielen doppelt und dreifach vorhandenen Rechen-, Speicher- und Verzweigungseinheiten ausreizen. Die intelligente Logik bisheriger Prozessoren hat nämlich den Nachteil, dass sie nur den kleinen Ausschnitt des Programms analysieren kann, der gerade in der Pipeline steht, und das ist bei heutigen Programmgrößen ein winzig kleiner Ausschnitt. Außerdem versteht der Prozessor nicht die höhere Aufgabe, den Sinn der vielen Befehle, mit denen er gefüttert wird.

Der Compiler, mit dem das Programm einmal in die Maschinensprache übersetzt wurde, kennt jedoch den Sinn der Befehle. Deshalb verlagert Itanium die Entscheidung über die Verteilung der Befehle von der CPU in den Compiler.

Der Trick mit den Prädikaten

Itanium lässt sich dann vom Compiler erklären, wie der Code verteilt werden soll. Der Compiler weiß genau, wie oft die Verzweigung am Ende einer großen Schleife auszuführen ist und wann die Befehle danach wichtig werden. Er schreibt nun Hinweise in den Befehlsstrom. Der Prozessor wer- tet diese Hinweise (Prädikate) aus und steuert so die Verteilung wie angewiesen. Die Folge sind erheblich besser ausgelastete Rechenwerke und damit noch mehr Performance.

Doch Itanium kann noch mehr: Zum ersten Mal unterhalten sich Prozessor und Compiler. Itanium kann nämlich dem Compiler Informationen zukommen lassen. Die CPU kann protokollieren, wie effektiv die Ausführung eines Befehlsstroms die Einheiten auslastet und ob Caches gut genutzt werden. Wenn der Compiler sich dieses Protokoll bei der CPU abholt, kann er seine Verbesserungen weiter optimieren und noch die letzten Engpässe beseitigen.

Ein Blick ins Innere des Testrechners. Zu erkennen sind die zwei Speicherbänke mit je 1 GByte RAM sowie unten die 64-Bit-PCI-Slots.

Data Poisoning

Ein interessantes Sicherheitsfeature ist das Vergiften von Daten. Itanium verwendet im Hauptspeicher ECC-gesicherte Speicher. Fehler, die nur ein einzelnes Bit betreffen, können damit verlustlos im laufenden Betrieb korrigiert werden. Sind jedoch zwei Bits gekippt, ist das nicht mehr möglich. Bisherige Architekturen haben in einem solchen Fall eine Exception ausgelöst, die praktisch alle Betriebssysteme mit einem kompletten Abbruch und erforderlichem Reboot quittieren.

Mit Data Poisoning sind sowohl Panics als auch Blue Screens deutlich seltener. Finden die ECC-Prüffunktionen 2-Bit-Fehler auf dem Systembus, werden die entsprechenden Daten von einer speziellen Logik vergiftet. Mit diesen vergifteten Daten wird dann normal weitergearbeitet. Was nun geschieht, beschreibt ein Intel-Entwickler mit diesen blumigen Worten: “Processes consuming poisoned data are terminated; the rest of the system remains intact.”

Natürlich muss hier das Betriebssystem mitspielen, damit es bei 2-Bit-Fehlern nicht bootet, sondern nur gezielt einzelne Prozesse abschießt, die auf vergiftete Daten zugegriffen haben. Der Vorteil liegt auf der Hand: Ein großer Datenbankserver geht nicht gleich zwangsweise vom Netz, wenn es zum Fehler kommt – mit unbekannten Folgen für alle Anwender. Nur ein Prozess muss neu aufgesetzt werden und höchsten dieser verliert Daten.

1 GByte Hauptspeicher. Die Chips für die Speicherverwaltung sind extra gekühlt, für die Energieversorgung gibt es eigene Regler und Pufferkondensatoren.

Error Promotion and Logging

Ein interessantes Feature des Itanium ist auch die Fähigkeit, aufgetretene Fehler zu promoten. Damit ist Folgendes gemeint: In einem Verbund von mehreren CPUs wird die Tatsache, dass etwas nicht so gelaufen ist, wie es sollte, den anderen Prozessoren mitgeteilt, damit sie gegebenenfalls ihre eigenen Schutzmaßnahmen ergreifen können.

Aufgetretene Fehler können auch protokolliert werden, um so dem Betriebssystem ausführliche Statusinformationen über das System zukommen zu lassen. Das ist insbesondere zusammen mit Error Promotion wichtig, damit korrigierbare Fehler korrigierbar bleiben, die Systemintegrität also erhalten bleibt. Hochverfügbarkeit ist das entsprechende Schlagwort – High Availability wird in der 64-Bit-Ära sicherlich ein Kernparadigma sein.

Register Renaming

Ein Problem beim Verteilen von Befehlen auf Ausführungseinheiten ist, dass die Logik mitunter falsche Abhängigkeiten meldet, etwa wenn Register nach dem Auslesen überschrieben werden. Da Register nicht gleichzeitig mit zwei Rechenwerken reden können, wird eine Abhängigkeit gemeldet, die keine ist. Itanium umgeht dies dadurch, dass er Register notfalls umbenennt. Der Schreibbefehl schreibt dann in ein anderes, virtuelles Register.

Das hat natürlich zur Folge, dass später auftauchende Lesevorgänge ebenfalls auf das virtuelle Register umgebogen werden müssen. Unter dem Strich bleibt aber trotzdem wieder ein Performancegewinn.

So haben wir getestet

Der Testrechner wird mit 800 MHz getaktet und verfügt über 2 GByte DDR-SDRAM. Für die I/O-Tests kommt ein zweikanaliges SCSI-Raid von Starline zum Einsatz. In der Konfiguration mit 512 MByte Cache werden je vier Platten zu einem Raid 0 zusammengefasst und über zwei Adaptec-SCSI-160-Controller (64 Bit PCI-66) mit dem Rechner verbunden. So ergibt sich eine nominelle Transferrate von 320 MByte/s bei einer Festplattenkapazität von 0,25 Terabyte. Das Testsystem läuft unter SuSE Linux 7.2 for IA64, zwei Entwickler von SuSE waren vor Ort und auch Intel schickte mehrere Ingenieure. Kompiliert wurden die im Sourcecode vorliegenden Benchmarks mit dem SuSE-IA-64-GCC und G77 (für Fortran) sowie Intels Itanium-optimierten GCC und EFC. Wegen Kompatibilitätsproblemen liefen nicht alle Benchmarks auf beiden Compilern. Zu Hilfe kamen ein zweiter Itanium mit Red Hat 7.0, außerdem ein Xeon (IA32) mit einem Cross- Compiler. Verglichen haben wir mit einem 1-GHz-Athlon-Rechner von Leo mit 512 MByte SDRAM und demselben Raid wie am Itanium. Bei allen Grafiken wurde der jeweilige Sieger zu 100 Prozent Balkenlänge hochskaliert. Eher aus Tradition wurden Dhry- und Whetstones getestet. Damit kann man CPUs zwar mit einer Anzahl älterer Prozessoren vergleichen, aber mit der Einschränkung, dass die Ergebnisse nur für die – nach heutigen Maßstäben – winzigen Messroutinen gültig sind. Dhry- und Whetstones verschwinden bei heutigen Prozessoren im First- oder Second-Level-Cache. Dennoch sind die Ergebnisse interessant. Die Dhrystone-Routine stammt aus dem ehemaligen Unix-Test der amerikanischen Byte, der von David Niemi weiterentwickelt wurde. Hier liegt Itanium mit gut 1400 kDhry hinter dem Athlon. 29 Jahre hat der in Fortran geschriebene Whetstone auf dem Buckel. Zum Einsatz kam Version 97, die nach C portiert wurde. Hier ist in allen Disziplinen – bis auf eine – Athlon schneller. Wenn es um Cosmops geht, bringt Itanium 30 Prozent mehr Power, aber bei Integers gibt Athlon Gas. Gesamt: 603 zu 373 MWIPS. Es sei an dieser Stelle noch einmal erwähnt, dass Dhry- und Whetstone kaum Rückschlüsse auf richtige Anwendungsprogramme zulassen. Ein viel modernerer und praxisnäherer Bench ist Stream. Dieser Test hantiert in Fortran mit so großen Daten, dass er alle Caches (sogar den riesigen L3 des Itanium) überflutet und so die Hauptspeicher-Transferrate misst. Hier gewinnt Itanium grandios: Er bringt mit über 1 GByte/s mehr als die doppelte Leistung des Athlon. Von Samba kommen D-Bench und T-Bench, die eine I/O-Last simulieren, wie sie bei massiven Netzwerktransfers auftreten. D-Bench simuliert die Plattenlast, T-Bench die Belastung der Sockets. Bei Ersterem ist der Durchsatz des Itanium anfangs niedriger als beim Athlon (49,5 zu 65,6 MByte/s bei 16 Clients), verliert aber kaum an Leistung, wenn die Anzahl der Clients wächst. Mit 128 Clients ist der Itanium um die Hälfte schneller als der Athlon. Bei Socket-I/O dagegen verlieren beide etwa die Hälfte der Leistung, wenn es an 128 Clients geht, aber Athlon ist konstant etwa 60 Prozent schneller als Itanium. E Ein sehr guter Benchmark für Platten-I/O ist Bonnie++. Mit ihm ließ sich klären, woher die rätselhafte Überlegenheit des Athlon bei Socket-I/O stammt. Zum einen zeigt sich, dass die Wahl des richtigen Compilers entscheidend ist, aber keiner ist in allen Disziplinen top. Sequentielles Schreiben (blockweise) beherrscht GCC besser als Intels ECC, aber der Athlon punktet noch mehr. 60 zu 33 zu 79 MByte/s – das ist auffällig. Zeichenweise sieht das anders aus: 8,3 zu 12,5 zu 11,3 MByte/s. Den größten Einbruch erlebt Itanium auf Linux aber beim zeichenweisen Lesen: 6,4 zu 4,6 zu 11,9 MByte/s. Anscheinend gibt es ein Linux-Problem, wenn die 64-Bit-CPU 8 Bit breite Daten handeln soll. Intel und SuSE prüfen gerade, an welcher Stelle hier der Performanceverlust eintritt, wahrscheinlich werden die Caches des Itanium wegen eines Bugs nicht oder nicht optimal eingesetzt. Nicht alles läuft glatt Der Open Source Database Bench fiel leider einer Inkompatibilität zum Opfer, stattdessen wurde der Benchmark von MySQL eingesetzt. Er wird als SuSE-Paket »mysql-bench« auf allen CDs mitgeliefert und muss nur zu MySQL installiert werden. Auch MySQL zeigt Schwächen auf: ATIS läuft gerade mal halb so schnell, Alter-table und Big-tables um die Hälfte langsamer. Das ist mit Sicherheit auf dieselbe Störung zurückzuführen, die byteweises I/O bremst, und ein Problem, das Intel und SuSE noch beheben werden. Von der amerikanischen Raumfahrtbehörde NASA kommen zwei sehr interessante Benchmarks, Arc2D und NPB. Ers-terer berechnet überschallschnelle Strömungen um doppelt konvexe Tragflächen, der andere simuliert eine mathematische Berechnung auf einem parallelen Supercomputer, der mit fünf Kernen und drei simulierten Anwendungen rechnet. Damit werden sowohl die Berechnung als auch die Transfers zwischen den Knoten simuliert, die bei komplexen Strömungsdynamik-Berechnungen von flüssigen Medien (CFD) auftreten. NPB lässt sich auch parallelisieren, so dass Multi-CPU-Systeme getestet werden können. Bei diesen beiden Benchmarks legt der Itanium richtig los: Die überschallschnellen Strömungen werden doppelt so schnell berechnet wie beim Athlon. Beim NPB wird Athlon regelrecht abgeledert. Bei der CG-Disziplin erreichte der Athlon 61,3, Itanium satte 250,4 Mops/s. Bei BT stand es 136,9 zu 628,0 Mops/s zum Nachteil des Athlon. Gerne hätten wir noch den Molecular Dynamics Bench verwendet, der in Fortran-77 Berechnungen anstellt, doch Kompatibilitätsprobleme verhindern derzeit einen Einsatz genau wie beim High Performance Linpack der Lawrence Livermore und Los Alamos National Labs. Fazit Zusammenfassend kann man dem Itanium Höchstleistungen bescheinigen, besonders wenn es um mathematische Berechnungen großer Datenmengen geht. Beim I/O scheint es noch ein Problem mit der Linux-Implementierung zu geben, an dem aber gearbeitet wird. Benchmark: Dhrystone/Whetstone Benchmark: Stream Benchmark: MySQL-Bench Benchmark: D-Bench Benchmark: T-Bench Benchmark: Bonnie++ Benchmark: Arc2D Benchmark NPB: Die mathematischen Details der einzelnen Disziplinen wurden von der Nasa nicht dokumentiert.