Linux-Magazin-Logo Die Zeitschrift für Linux-Professionals

AMD Opteron im 32- und 64-Bit-Test

Der Linux-Hammer

Mirko Dölle, Timo Hönig

Der AMD Opteron verspricht Leistung satt in doppelter Bandbreite. Was 64 Bit wirklich bringen und wie schnell 32-Bit-Software läuft, hat das Linux-Magazin in Zusammenarbeit mit Tom's Hardware gemessen.

Der Opteron macht seinem Codenamen Sledgehammer (Vorschlaghammer) alle Ehre und mischt die Serverszene gründlich auf. Wenige Monate nach Vorstellung der CPU gibt es bereits erste Dual-Prozessor-Server für weniger als 2000 Euro[1]. Es stellt sich allerdings die Frage, wer überhaupt von einem 64-Bit-Prozessor profitiert.

Die Beschränkung der 32-Bit-Prozessoren auf 4 GByte adressierbaren Speicherbereich ist bei Servern inzwischen ein ernster Engpass, denn schon Desktop-Rechner sind heute mit 256 MByte RAM ausgestattet und Workstations bringen es durchaus auf 1 GByte - Server benötigen entsprechend mehr RAM. Auch das Leistungspozenzial der 32-Bit-Prozessoren ist inzwischen fast ausgeschöpft, großartige Sprünge bei den Taktfrequenzen oder bedeutende Verkleinerungen der Chipstrukturen sind technisch nicht mehr zu verwirklichen.

Der Zug geht daher zwar eindeutig in Richtung 64-Bit-Prozessoren, aber gerade im Windows-Bereich gibt es noch sehr viele 32-Bit-Altlasten. Bei kommerzieller Software ist der Anwender wie immer darauf angewiesen, dass der Hersteller die Umstellung zeitnah erledigt. Damit ihre Kunden Soft- und Hardware nicht gleichzeitig wechseln müssen, haben Intel und AMD bei ihren 64-Bit-Prozessoren vorgesehen, dass 32-Bit-Programme weiterhin ausführbar sind.

Die Testsysteme

Gerade zu Beginn der Migrationsphase auf 64 Bit ist die 32-Bit-Performance der 64-Bit-CPUs besonders wichtig - im Windows-Lager besteht die Software derzeit fast ausschließlich aus 32-Bit-Programmen und 64-Bit-Intel-Versionen kommerzieller Linux-Programme sucht man ebenfalls meist vergeblich. Doch gerade bei 32-Bit-Programmen fiel Intels Itanium I in unserem Test vor gut zwei Jahren[2] durch: Der Itanium wurde von den damaligen Pentium- und Athlon-Systemen lässig überholt.

Grund: Der Itanium verwendet für den 32-Bit-Code eine Emulation, die offenbar nicht sehr effizient ist. Wie das beim Itanium-2 aussieht, ist unbekannt. Intel sah auch auf Nachfrage keine Möglichkeit, dem Linux-Magazin ein Itanium-2-Testsystem zur Verfügung zu stellen, und schickte dafür zwei Xeon-Systeme mit zwei und vier Prozessoren (2,8 GHz) ins Rennen.

Der Opteron kann 32- und 64-Bit-Code direkt nebeneinander ausführen. Deshalb wurden alle Benchmarks sowohl mit 32- als auch 64-Bit-Kernel gemessen.

Die beiden Opteron-Testsysteme kamen direkt von AMD. Der Dual-Opteron, den das Linux-Magazin bereits in[3] vorgestellt hat, war noch mit Vorserien-Prozessoren mit 1,3 GHz sowie 2 GByte RAM bestückt. Das Quad-Opteron-System enthielt Serien-Prozessoren mit 1,8 GHz Taktfrequenz und war mit 8 GByte RAM ausgestattet.

Weitere Testteilnehmer waren ein Pentium 4 mit Canterwood-Kern und PC800-RAMs auf Basis eines Asus-P4C800-Mainboards sowie ein Athlon XP 3000+ mit DDR-333-RAMs auf einem Asus-A7N8X-Mainboard.

Optimierte Compiler und Distributionen

Auf allen getesteten Systemen kam Suse Linux Enterprise 8 zum Einsatz, gerade in unternehmenskritischen Bereichen wird viel Wert auf zertifizierte Distributionen gelegt, nicht zuletzt um überhaupt Support für die Anwendungssoftware zu erhalten. So kommt es auch nicht in Frage, den Kernel mit einem optimierten Compiler neu zu übersetzen - die Zertifizierung wäre gebrochen.

Das betrifft im Test nur Intel, da Suse Linux Enterprise 8 für 32 Bit mit dem GCC und nicht mit Intels optimiertem ICC übersetzt wird. Die Tester verwendeten den ICC (Version 7.1) aber versuchsweise mal zum Übersetzen der Benchmark-Programme: Die Abweichungen von den mit GCC ermittelten Werten gehen im Toleranzbereich unter.

Bei AMD stellt sich das Problem eines separat optimierten Compilers nicht, die Dresdner Chipschmiede hat die Opteron-Optimierungen in den regulären GCC einfließen lassen. Suse wiederum baut den Enterprise Server 8 for 64 Bit mit den entsprechenden Opteron-Optimierungen. Selbst der im Laufe des Tests nachgelieferte Kernel mit Numa (Non-Uniform Memory Access) war für Suses Enterprise-Ausgabe zertifiziert.

Wie viel Einfluss die Opteron-Optimierung des 64-Bit-Kernels auf die Messwerte hat, lässt sich nicht sagen - bei sämtlichen 32-Bit-Tests wurde wie für alle anderen Maschinen auch der Originalkernel der Suse Enterprise Linux 8 for 32 Bit verwendet, der nicht auf Opterons optimiert ist.

Opteron-Interna

Der Opteron kommt ohne Northbridge aus, denn der Speichercontroller sitzt auf der CPU. Damit hat jeder Opteron seinen eigenen Speicherbereich. Zugriffe auf den Speicher laufen jedoch immer über die Cross Bar (XBAR, Abbildung 1). Sie steuert nicht nur die Zugriffe auf den Memory Controller, sondern bei ihr sind auch der Prozessorkern (über die System Request Queue) sowie die drei Hyper-Transportkanäle angebunden. Die Cross Bar ist also die zentrale Schaltstelle im Opteron.

Abbildung 1: Die Cross Bar im Opteron steuert den Datenfluss zwischen Memory Controller, Hyper Transport und Prozessorkern.

Nicht-lokaler Speicher

Über die Cross Bar läuft auch der Datenaustausch mit anderen Opterons in einem Multiprozessor-System: Jeder Prozessor hat maximal vier lokale Speichermodule (zwei DDR-333-Kanäle) und ist per Hyper Transport mit den unmittelbaren Nachbarn verbunden. In einem Vierprozessor-System bilden die Hyper-Transportkanäle also einen Ring. Liegen die benötigten Daten nicht im lokalen, sondern im entfernten Speicher, kommuniziert die lokale Cross Bar mit der des entfernten Prozessors und lässt sich die Daten schicken. Der entfernte Prozessor wird mit dem Transfer nicht belastet, die Cross Bar arbeitet die Anfrage eigenständig ab.

Beim Umweg über Hyper-Transportkanäle stehen 3,2 GByte/s pro Kanal und Richtung zur Verfügung. Ein Pentium 4 mit 533 MHz Frontside-Bus bringt es auf knapp 4 GByte/s - aber nur in einer Richtung, Hyper Transport beherrscht Vollduplex mit insgesamt 6,4 GByte/s. Intel setzt bei seinen Mehrprozessor-Xeon-Systemen hingegen auf einen Speicherbus, den sich alle Prozessoren teilen. Die Northbridge, die den gesamten Speicher verwaltet, kann somit immer nur eine CPU bedienen.

Gute Speicheranbindung

Die Unterschiede zwischen AMDs verteilter Speicherarchitektur Numa und Intels Speicherbussen zeigen sich erst bei mehreren Prozessoren. Im Ein- oder Zweiprozessor-Betrieb (Diagramm 1) lagen die Messwerte relativ dicht beieinander, der Pentium 4 hatte erwartungsgemäß die Nase vorn. Anders sieht es auf den Vierprozessor-Systemen aus. Gemessen wurden vier gleichzeitig gestartete »stream_d«[4] mit je 20 Millionen Array-Einträgen und 100 Durchläufen - was 457 MByte Speicher pro Prozess beansprucht.

Diagramm 1: Der Überflieger beim Speicher-Benchmark ist Intels Pentium 4 mit Canterwood-Kern und PC800-Speicher. Danach folgt der Opteron mit 64- und mit 32-Bit-Code.

Wie in Diagramm 2 gut zu erkennen steht den vier Streamprozessen auf dem Opteron insgesamt eine deutlich höhere Speicherbandbreite zur Verfügung als den vier Prozessen auf dem Xeon-System. Wie viel Speicherbandbreite letztlich eine spezielle Anwendung nutzen könnte, hängt einmal von der Parallelisierbarkeit der einzelnen Prozesse und von der Verteilung der Daten im Speicher ab - im ungünstigsten Fall etwa befinden sich beim Opteron die Daten im Speicher einer anderen CPU.

Diagramm 2: Bei vier Prozessoren und vier parallel laufenden Speicher-Benchmarks kann der Opteron mit seiner verteilten Speicherarchitektur deutlich punkten. Die Xeon-Prozessoren müssen sich den Speicherbus untereinander teilen.

D-Bench-Hammer

Alle Benchmarks liefen auf dem Opteron im 64-Bit-Modus schneller als im 32-Bit-Modus - doch selbst mit halber Busbreite schlägt der Prozessor immer noch die anwesende Konkurrenz. Besonders gut kam der Vierfach-Opteron mit dem D-Bench ([5], Diagramm 3) zurecht, bei dem Zugriffe von SMB-Clients auf ein Samba-Share emuliert werden, die Transferrate lag stets zwischen 1,2 und 1,3 GByte/s und blieb bis zur Maximalbelastung mit 256 Clients stabil.

Diagramm 3: AMDs Vierfach-Opteron kommt mit dem D-Bench erfreulich gut zurecht und versorgt selbst 100 Clients noch mit 1,3 GByte/s. Der Vierfach-Xeon hingegen bricht bei dieser Last auf unter 10 MByte/s ein, während die anderen Systeme immerhin 30 bis 40 MByte/s liefern.

Im 32-Bit-Modus erreichte der Quad-Opteron deutlich geringere Transferraten, schlägt aber immer noch haushoch alle Konkurrenten. Dem Vierfach-Xeon lag der D-Bench dagegen schwer im Magen, bei 100 Clients brach die Transferrate pro Client auf unter 10 MByte/s ein.

Gute Werte beim T-Bench

Beim T-Bench[5], der Netzwerk- und Socket-I/O von Samba nachbildet, sind die Unterschiede deutlich geringer, aber trotzdem deutlich (Diagramm 4). Der Vierfach-Xeon bringt in etwa die gleiche Transferrate wie der Dual-Opteron bei 32 Bit, der Dual-Xeon liegt etwas darunter. Auch beim T-Bench ist zu sehen, dass der Opteron bei 64 Bit deutlich schneller als bei 32 Bit ist.

Diagramm 4: Auch beim T-Bench liegt der Opteron deutlich vorn, mit rund 300 MByte/s kann der Vierfach-Xeon aber noch mithalten. Die Wellenform der Messkurven tritt nur bei Mehrprozessor-Systemen auf, Ursache ist die Verteilung der einzelnen Prozesse auf die Prozessoren.

Die Wellenbewegung der Messwerte in Diagramm 4 ist durch unterschiedlich gute Verteilung der Prozesse auf die Prozessoren zu erklären, auf den beiden Systemen mit nur einem Prozessor gibt es diese Schwankungen nicht.

SCSI-Probleme

Der SCSI-Raid-Controller GDT-8523RZ von ICP Vortex bereitete mit dem 64-Bit-Kernel Probleme: Es kam zu reproduzierbaren Kernelpanics. Beim 32-Bit-Kernel spielten Controller und das Kernelmodul »gdth.o« problemlos zusammen.

Als Referenz-Plattensystem kam das IDE-SCSI-Raid Axus 16012 von ICO [1] zum Einsatz, bestückt mit 16 200-GByte-Festplatten von Maxtor. Das Raid-System trimmten die Tester auf maximalen Datendurchsatz, indem sie alle 16 Festplatten zunächst zu einem Raid-0 zusammenfassten, um dann nur ein 20-GByte-Slice über alle 16 Festplatten zu so verteilen, dass pro Festplatte nur etwa 5 GByte benutzt wurden.

Die Laufwerksgröße von 20 GByte resultiert daraus, dass Bonnie++[6] etwas mehr als das Doppelte des RAM an Daten schreibt und liest - die beiden Vierfach-Prozessor-Server waren mit je 8 GByte RAM bestückt. Das SCSI-Laufwerk wurde anschließend partitioniert und mit Ext 2 formatiert.

Diesen Test verlor der Xeon durchaus knapp: 65 MByte/s beim Schreiben und 79 MByte/s beim Lesen sind zwar gute Werte, der Opteron schrieb jedoch 80 MByte/s und las 73 MByte/s bei 64 Bit. Bei 32 Bit musste sich der Opteron dagegen dem Xeon geschlagen geben, er erreichte Schreibraten von 67 MByte/s und Leseraten von 59 MByte/s.

Fazit

AMD hat mit dem Opteron erfolgreich den Grundstein für die Migration auf 64 Bit gelegt. Mit 32-Bit-Binaries lässt sich der Prozessor zwar nicht ausschöpfen, bringt aber etwa 60 bis 70 Prozent der Leistung, die er bei 64 Bit hat. Auch den Vergleich mit der 32-Bit-Konkurrenz braucht der Opteron nicht zu scheuen. Durch die leistungsfähige Speicheranbindung empfiehlt sich der Opteron besonders für RAM-intensive Anwendungen, beim File-I/O bleibt er hingegen hinter Intels Xeon zurück.

Mit dem Athlon 64 und Athlon 64 FX, beides abgespeckte Opterons, möchte AMD künftig auch den Desktop auf 64 Bit bringen - und Intels Desktop-Prozessoren in Rente schicken.

Infos

[1] ICO Innovative Computer GmbH: [http://www.ico.de]

[2] Oliver Kluge, Mirko Dölle, "Inside Intel": Linux-Magazin 10/01, S. 24

[3] Mirko Dölle, "Hammer hart": Linux-Magazin 06/03, S. 65

[4] Stream Speicher-Benchmark: [http://www.cs.virginia.edu/stream]

[5] Samba-Benchmarks D-Bench/T-Bench 2.0: [http://samba.org/ftp/tridge/dbench]

[6] Festplatten-Benchmark Bonnie++ 1.01d: [http://www.coker.com.au/bonnie+]