Sechsradantrieb

Gemäß Intels Tick-Tock-Philosophie ist das Jahr 2010 ein Tick-Jahr: Eine neue Prozesstechnik für kleinere Strukturen wird eingeführt, aber die Prozessorarchitektur weitgehend beibehalten. Im kommenden Jahr (Tock) soll dann bei gleicher Prozesstechnik eine neue Mikroarchitektur herauskommen: Sandy Bridge.

Üblicherweise sind die Tick-Prozessoren netterweise sockelkompatibel zum Vorgänger. So kommt der neue Westmere-EP-Prozessor ebenso wie sein Vorgänger Nehalem-EP im LGA-1366-Layout. Und wenn die Board-Hersteller nichts falsch gemacht haben, sollte er problemlos nach einem BIOS-Update im alten System laufen. Wie das bei Apples Mac Pro und Xserve mit dem EFI bezüglich Upgrade alter Systeme aussieht, ist derzeit allerdings noch unklar.

Hat der Server noch thermische Reserven, so kann man gleich auf den Xeon X5680 mit 3,33 GHz hochrüsten, der dann 130 Watt TDP beansprucht. Anders als bei Workstations war bei Nehalem-EP-Servern zuvor mit dem Xeon X5570 bei 2,93 GHz (95 W TDP) Schluss. Neben den sechs Kernen und 12 MByte statt 8 MByte L3-Cache bringen die Westmere-Xeon-Prozessoren zudem ein paar kleinere Architekturverbesserungen mit. Hier sind insbesondere die AES-Krypto-Befehle für die SSE-Einheit zu nennen, die laut Intel die SSL-Transfers von Webservern um gut 50 Prozent beschleunigen können, wobei man dann aber schon SSDs einsetzen muss, damit der Performancegewinn nicht in Plattenwartezeiten untergeht. Verbesserungen gibt es ferner für die Virtualisierung und bei der Trusted Execution Technology (TXT), unter anderem um die Sicherheitsaspekte bei der Migration von VMs besser zu berücksichtigen. Diese TXT-Erweiterung erfordert aber den neuen C2-Step (20h) des Tylersburg-Chipsatzes (bei Windows unter Hardware-IDs des Chipsatzes im Gerätemanager zu finden). Doch auch der uns taufrisch zugeschickte Dell-Server R610 war noch mit der Chipsatzrevision B (13h) bestückt.

Empfehlungsschreiben

Die Benchmarkergebnisse, die Intel den neuen Sechskern-Prozessoren als Empfehlungsschreiben mit auf den Weg gibt, sind schon beeindruckend. Sieht man mal von dem in einer ganz anderen Liga spielenden Achtkerner IBM Power7 ab, so war bei den SPEC-CPU2006-Benchmarks für Zweisockelsysteme bisher bei rund 255 SPECint_rate_base2006 und 204 SPECfp_rate_base2006 Schluss – gehalten von der 3,3 GHz schnellen Workstation-Version des Nehalem-EP W5580. Konkurrent AMD liegt mit seinem Sechskerner Opteron 2439SE (Istanbul) gemäß den bei spec.org veröffentlichten Werten mit 169 beziehungsweise 133 Punkten weit dahinter. Und nun hängt der X5680 mit seinen sechs Kernen mit 355 SPECint_rate_base2006 und 248 SPECfp_rate_base2006 (veröffentlichte Werte von Fujitsu) die Latte erheblich höher. Da muss AMD schon vier Istanbul-Prozessoren bemühen, um in die gleiche Klasse zu kommen – genauso übrigens wie Intel mit dem bisherigen Sechskerner Dunnington.

Wir messen die CPU2006-Benchmarks aus gutem Grunde indes ein wenig anders als Intel, Fujitsu und die anderen Hersteller, nämlich auf kompatibler Codebasis, mit 64-Bit-Code und ohne Spezialbibliotheken, sodass unsere absoluten Werte ein gutes Stück unter den auf spec.org veröffentlichten liegen.

Die Steigerungsraten gegenüber dem Vorgänger liegen aber zumindest bei SPECfp in etwa im gleichen Bereich (22 Prozent plus bei gleichem Takt von 2,93 GHz und 36 Prozent plus mit 3,33 GHz). Bei SPECint fiel bei uns der Zuwachs mit 30 respektive 40 Prozent etwas geringer aus als bei Fujitsu – aber das ist immer noch recht ordentlich, wenn man bedenkt, dass die CPU2006-Benchmarks zum Teil sehr speicherintensiv sind.

Beim Speicherzugriff kann der Westmere-EP trotz der gleichen Anzahl von Speicherkanälen und bei den gleichen DDR3-DIMMs (1333 MHz) nämlich noch ein bisschen zulegen – wohl begünstigt durch den größeren und schnelleren L3-Cache. Richtig auf die Threads verteilt, steigt die Performance des Stream-Triad (OMP-Version mit Intel icc 11.1 kompiliert) beim gleich schnell getakteten X5670 von 37,6 auf 41,5 GByte/s. Der X5680 schaffte sogar 42,6 GByte/s – allerdings erst nachdem das Problem auftretender ECC-Fehler durch einen Speicherwechsel behoben wurde. Offenbar haben die alten Speicher irgendwie mitbekommen, dass just in dieser Ausgabe ein Artikel über ECC-Speicher (siehe S. 182) eingeplant ist. Und so sank zuweilen die Performance auf einem der beiden Prozessoren um genau den angegebenen durchschnittlichen Korrekturverlust von 30 Prozent. Übrigens war das WHEA im BIOS des Asus-Boards eingeschaltet, dennoch tauchten die im BIOS-Eventlog eingetragenen ECC-Fehler nicht im Eventlog von Windows Server 2008 auf.

Für den Render-Benchmark Cinebench mussten wir auf die neue Version 11.529 wechseln, denn die alte 11er-Fassung läuft bei mehr als 16 logischen Kernen auf Grund. Die neue Version ist aber auch auf 64 logische Kerne limitiert. Der kommende Nehalem-EX wird diese Grenze in 8-Sockel-Systemen bald schon wieder sprengen. In der neuen Cinebench-Metrik steigt der Multiprozessorwert von 10,3 (X5570) auf 11,41 (X5640), 15,2 (X5670) und 17,4 (X5680), geht also fast linear mit Kernanzahl und Taktfrequenz nach oben.

Gleichungslöser

Ähnlich sieht es bei dem im High-Performance-Computing wichtigen Linpack-Benchmark, aus. Der bietet neben der rohen Gleitkommaperformance zusätzlich ein gutes Maß für den maximalen Energieverbrauch. Intels Linpack-Version ist allerdings ein sehr kapriziöses Geflecht aus Applikation, OpenMP und Math Kernel Library, wobei man mit Feintuning noch allerhand herausholen kann. Im Unterschied zu Intel schalten wir speziell für diesen einen Benchmark das Hyper-Threading nicht per BIOS ab – wer bootet denn einen Server extra für eine Applikation neu? –, sondern sorgen für eine möglichst optimale Verteilung der Threads auf die Cores bei aktivem Hyper-Threading. So kommt der Linpack unter Windows beim X5870 mit 132 GFlops nicht ganz auf den Wert, den Intel unter Linux gemessen hat (146 GFlops). Dafür liegt bei uns der Unterschied zum Vorgänger (70,5 GFlops) sogar noch ein gutes Stück über 60 Prozent.

Die Energieaufnahme im Leerlauf (C6) hat sich durch die Aufrüstung kaum messbar verändert. Mit zwei redundanten Netzteilen, zwei Festplatten und 8 DIMMs à 4 GByte kommt unser Testsystem mit dem Asus-Board vor- wie nachher auf 153 bis 155 Watt. Nach Speicherwechsel von Qimonda auf ATP stieg der Idle-Verbrauch auf etwa 162 Watt.

Intel spezifiziert den C6-Schlafzustand der X5570- und X5670-Prozessoren mit 10 Watt und des X5680 mit 12 Watt, also maximal insgesamt 4 Watt zusätzlich. Der Dell-Server R610, bestückt mit den Energiesparprozessoren L5640, ansonsten wie das Asus-System mit zwei redundanten Netzteilen, 24 GByte RAM und zwei Festplatten, begnügt sich im Leerlauf mit 120 Watt.

Unter Linpack-Volllast stieg die Energieaufnahme beim Nehalem-EP auf 354 Watt, beim gleichschnell getakteten Westmere-EP X5670 auf 374 Watt und beim X5680 auf rund 400 Watt. Je nach Umgebungstemperatur drehten zuweilen die Lüfter auf, sodass dann 40 Watt hinzukamen. Der L5640 im Dell R610 erreicht im Linpack 90,4 GFlops bei 265 Watt und ist mit 341 MFlops/Watt knapp der Effizienzsieger vor dem X5680 mit rund 330 MFlops/Watt. Der Nehalem-EP liegt in der Linpack-Effizienz lediglich bei etwa 200 MFlops/Watt.

Die Energieeffizienz wird aber üblicherweise mit dem SPECPower-Benchmark gemessen, der nicht nur auf Volllast schaut, sondern der verschiedene Laststufen eines Servers mit Hilfe des SPECjbb2005-Benchmarks simuliert. Die Performance hängt dabei stark von der benutzten Java-VM und deren Konfiguration ab. Wir benutzten die JRockit-Version R27.5.0 der Firma Oracle. Die SPECjbb2005-Performance legte vom X5570 zum X5680 von 496 257 auf 666 865, also um 34 Prozent zu, der maximale Stromverbrauch in der beschriebenen Ausstattung aber nur um weniger als 10 Prozent auf 385 Watt. Der SPECpower_ssj2008-Effizienzwert stieg somit von 940 auf 1203 ssj_ops/Watt. Geringfügig besser ist noch der kleinere Bruder mit 2,93 GHz. Beide hängen in dieser Disziplin den energiesparenden Prozessor L5640 im Dell R610 ab, der nur auf 1036 ssj_ops/Watt kam.

Mehr Infos

Linpack- und SPEC-CPU2006-Spezialitäten

Der Linpack-Benchmark ist die Lösung einer Linearen Gleichung mit vielen Tausend Unbekannten. Und weil diese Aufgabe ein Klassiker ist, gibt es dafür in jeder besseren Mathematik-Bibliothek hochoptimierte Routinen, so insbesondere auch in Intels Math Kernel Library MKL. Bei näherer Betrachtung zeigt sich, dass diese recht eigensinnig ist. Gibt man mit der OpenMP-Umgebungsvariablen OMP_NUM_THREADS die Zahl der Threads vor, so weigert sich das Programm zum Teil, den Auftrag auch umzusetzen. Bei Intels vorletzter Linpack-Version mit OMP-Bibliothek vom 24. Juni 2009 meldet es zudem zum Beispiel 24 Threads, arbeitet tatsächlich aber nur mit maximal 12. Das korrekte Mapping der Threads auf die Kerne kann man sich mit KMP_AFFINITY=verbose genau anzeigen lassen. Die neuere Fassung vom 11. August 2009 macht das zwar besser, doch auch hier ist die Zuordnung nicht eindeutig, denn die MKL variiert die Zahl der Threads nach eigenem Gusto und überschreibt die Settings von OMP und KMP.

Außerdem hat Intel in der aufrufenden Batchdatei die Verteilstrategie „Compact“ gewählt, die man nur nehmen sollte, wenn man Hyper-Threading per BIOS abschaltet. Ansonsten ist „Scatter“ die klar bessere Verteilung: 132 zu 60 GFlops sprechen eine klare Sprache. Will man selber mit Threads experimentieren, sollte man die Eigenmächtigkeit der MKL mit MKL_DYNAMIC=false abschalten. Allerdings kann es dann passieren, dass die MKL aus Trotz nur mit einem einzigen Thread arbeiten will.

Die CPU2006-Benchmark-Suite der SPEC wird bei uns mit der Zielsetzung gefahren, einen möglichst fairen Vergleich zwischen den Systemen zu ermöglichen und nicht wie bei den Herstellern üblich, mit allen gerade noch erlaubten Tricks, das eigene System brillieren zu lassen. Daher treiben wir die Optimierung nicht auf die Spitze, belassen es auf einer kompatiblen SSE3-optimierten Codebasis und verzichten auf Spezialbibliotheken wie SmartHeap. Das führt zuweilen zu Problemen, wenn wie aktuell bei den Intel-11.1-Compilern der SSE3-optimierte Code nicht korrekt läuft (Absturz bei cactusADM). Also bleibt es für SPECfp bis auf Weiteres bei den älteren 11.0-Compilern.

Zudem halten wir es nicht für zeitgemäß, auf den großen Serversystemen 32-Bit-Software auszustoppen, nur weil die Ergebnisse etwas besser sind. Die 64-Bit-Version hat jedoch das Problem, dass ein einziger Benchmark, 432.mcf, mit rund 2 GByte pro Thread reichlich viel Speicher benötigt, was bei den aktuellen Multikern-Systemen oft nicht machbar ist oder das System verlangsamt. Hier nutzen wir nun einen tragfähigen Kompromiss. Das Zauberflag „auto_ilp32“ veranlasst den Compiler, zu überprüfen, ob er sich auf 32-bittige Adressen innerhalb eines 64-Bit-Programms beschränken kann. Das ist nicht immer eindeutig, mitunter irrt er sich, was zu „unvorhersehbarem Verhalten“ führen kann – aber bei den SPEC-Benchmarks klappt’s und 432.mcf begnügt sich dann mit nur noch 1 GByte pro Thread.

(as)