Trotz Optimierungen wie Out-of-Order-Execution und Sprungvorhersage gerät die 20-stufige Pipeline von Intels Pentium 4 immer wieder ins Stocken. Sie muss beispielsweise auf Daten aus dem Speicher, noch nicht vollendete Rechenergebnisse oder den Ausgang einer Fallunterscheidung warten. Bislang waren die Transistoren einzelner Pipeline-Stufen deshalb rund 35 Prozent der Zeit zum Warten verurteilt.
Die von Intel Hyper-Threading (HT) getaufte Aufteilung der CPU in zwei logische Prozessoren soll diese brachliegende Rechenpower nutzbar machen. Im Normalfall bearbeitet die CPU dabei zwei Aufgaben (Threads) in zwei virtuellen CPUs gleichzeitig. Gerät die Pipeline eines Threads ins Stocken, wird in der Wartezeit intensiver am zweiten gearbeitet. Insgesamt ist die physikalische CPU dadurch besser ausgelastet, die Rechenleistung steigt.
Doch in der Praxis ergeben sich aus diesem Ansatz zahlreiche Probleme. Abgesehen von niedrig priorisierten Nebenaufgaben, wie der Druckaufbereitung, nutzen die meisten Desktop-Anwendungen nur einen Haupt-Thread. Diese Programme werden durch Hyper-Threading keineswegs schneller. Wenn das Betriebssystem nicht optimal auf Hyper-Threading abgestimmt ist, steht ihnen im Extremfall nur eine halbe CPU zur Verfügung. Doch selbst Multithreaded-Programme kann Hyper-Threading massiv ausbremsen.
Der folgende Artikel beschreibt einige Fallstricke, die vom Betriebssystem und vom Programmierer umschifft werden müssen. Neben zahlreichen Benchmark-Ergebnissen erläutern wir die Besonderheiten beim Testen von HT-Anwendungen. Die technischen Details zu Hyper-Threading und die CPU-Interna lesen Sie in unserem Artikel Hyper-Threading im Detail.
Betriebssysteme: Aus für Windows Me
Hyper-Threading benötigt ein multiprozessorfähiges Betriebssystem. Die größten Unterschiede liegen dabei im Scheduler, der den Prozessoren die jeweiligen Threads zuordnet. Von den Microsoft-Betriebssystemen unterstützt nur die NT-Schiene mit Windows NT, 2000, XP und .Net mehrere CPUs. Wenn nächstes Jahr der Pentium-4-Nachfolger Prescott mit seiner Hyper-Threading-Unterstützung Einzug in die Desktop-PCs erhält, bedeutet dies das endgültige Aus für die Windows 98/Me-Linie.
Für die Betriebssysteme bedeutet die Verwaltung mehrerer CPUs jedoch einen erhöhten Aufwand, der das System bremst. Zum Vergleich haben wir unser Testsystem mit einem Xeon 2,2 GHz ohne Hyper-Threading mit Windows XP einmal mit Single- und einmal mit Multiprozessor-Kernel konfiguriert.
Während Applikations-Benchmarks nur einen geringen Effekt zeigen, fallen einige Low-Level-Benchmarks mit dem Multiprozessor-Kernel um mehr als zehn Prozent ab. Um von Intels neuer Technologie zu profitieren, müssen zumindest diese Einbußen wettgemacht werden.
Anforderungen an den Scheduler
Während für den Programmierer kaum ein Unterschied zwischen einem HT-System und einem echten Dual-System besteht, muss ein optimierter Task-Scheduler eines Betriebssystems beide Varianten unterschiedlich behandeln. Solange nur ein einziger Thread auf einem HT-System läuft, sollte der Scheduler das Hyper-Threading ausschalten. Dazu führt er auf der logischen CPU im Leerlauf den privilegierten Halt-Befehl aus und deaktiviert sie damit. Dann stehen dem aktiven Thread auf der anderen "CPU-Hälfte" alle CPU-Ressourcen voll zur Verfügung.
Kommt nun ein weiterer, niedriger priorisierter Thread hinzu, kann der Scheduler diesen auf einem "echten" SMP-System der zweiten CPU zuordnen. Der höher priorisierte erste Thread auf der ersten CPU wird dadurch nicht gebremst.
Bei Hyper-Threading würde ein nicht optimierter SMP-Scheduler die zweite logische CPU nun aktivieren und dieser den niedrig priorisierten Thread zuweisen. Da innerhalb der physikalischen HT-CPU aber keine Priorisierung der beiden logischen CPUs stattfindet, bremst der unwichtige Job so den wichtigen aus. Sinnvoller ist es in diesem Fall, den niedrig priorisierten Job ganz zurückzustellen oder ihm nur gelegentlich eine kurze Zeitscheibe auf der zweiten logischen CPU zu geben.
Probleme mit Software-Lizenzen
Noch komplexer wird es für den Scheduler, wenn er mehrere physikalische CPUs mit Hyper-Threading bedient. Hier muss er zunächst dafür sorgen, dass jede physikalische CPU mit Arbeit versorgt ist. Erst wenn alle CPUs belegt sind, darf er den Multitask-Mode innerhalb der CPUs aktivieren und einer physikalischen CPU zwei Threads zuordnen.
Laut Intel haben Microsofts Windows XP und .NET einen entsprechend optimierten Scheduler. Windows 2000 soll ebenfalls schon weit gehend für Hyper-Threading optimiert sein. Die Unterstützung von Windows NT nennt Intel "sub-optimal", Updates sind dafür nicht mehr geplant.
Eine Hürde muss Hyper-Threading auch bei der Lizenzierung des Betriebssystems und von Software überwinden. Die Software sieht die doppelte Anzahl von CPUs, und die Preise von multiprozessorfähigen Anwendungen steigen meist mit der Anzahl der unterstützten Prozessoren. Zumindest Microsoft hat inzwischen bekannt gegeben, sich ab Windows 2000 und bei neueren Serverapplikationen nur die physikalischen CPUs zahlen zu lassen.
Der aktuelle Linux-Kernel 2.4.18 unterstützt Hyper-Threading ebenfalls vollständig. Ältere Versionen sollte man auf jeden Fall mit dem Ingo-Scheduler patchen, um brauchbare Ergebnisse zu erhalten.
Fallstricke beim Programmieren
Um von Hyper-Threading zu profitieren, muss eine Applikation multithreaded programmiert sein. Ein häufiges Problem dabei stellt die Synchronisation einzelner Threads dar. Im einfachsten Fall geschieht dies über ein gemeinsames Flag, eine so genannte Sperrvariable. Doch dabei muss man auf HT-Systemen besonders aufpassen.
Wartet ein Thread auf ein bestimmtes Ereignis eines anderen Threads, kann er a la "Loop until Sperrvariable true" eine Warteschleife durchlaufen. Auf einem SMP-System belastet dieses einfache Verfahren zwar eine CPU zu 100 Prozent mit Warten, der aktive Thread kann jedoch auf dem zweiten physikalischen Prozessor mit voller Performance weiterlaufen. Bei einer HT-CPU belegt diese kurze Warteschleife aber fast alle Ressourcen des physikalischen Prozessors. Der zweite Thread, auf den der erste ja wartet, läuft dadurch nur noch sehr langsam ab.
Deshalb sollte man in derartigen Schleifen zumindest den neuen Pentium-4-Befehl PAUSE integrieren. Er hält die Befehlsausführung für einige Takte an, ohne am Prozessorstatus etwas zu ändern. Dadurch kann der Thread auf der anderen logischen CPU für ein paar Takte mit voller Geschwindigkeit weiterlaufen. Auf älteren Intel-CPUs und AMD-Prozessoren wird die PAUSE-Instruktion als NOP (No Operation) interpretiert.
Besser ist es jedoch, auf eine derartige, handgestrickte Synchronisation der Threads ganz zu verzichten und die dafür optimierten Objekte des Betriebssystems zu nutzen. Microsoft stellt dafür beispielsweise die Objekte Mutex, Semaphore, Event und Critical Section zur Verfügung.
Probleme durch die Cacheline
Zwei weitere Fallstricke beim Programmieren für HT-Prozessoren sind im Cache-Management der Intel-CPU begründet. Die kleinste Speichereinheit, die die CPU beim Cache verwaltet, ist eine Cacheline. Beim Pentium 4 beträgt deren Größe 64 Byte für den L1- und 128 Byte für den L2-Cache.
Benutzen zwei Threads verschiedene globale Variablen oder Variablen des übergeordneten Threads, können diese mitunter in einer Cacheline liegen. Solange mehrere logische CPUs nur lesend auf die verschiedenen Variablen innerhalb einer Cacheline zugreifen, entsteht kein Problem. Hier ist die Paarung sogar von Vorteil, da die Daten beim ersten Zugriff des zweiten Threads bereits im schnellen Cache liegen.
Sobald aber ein Thread eine der Variablen ändert, beansprucht er die komplette Cacheline zeitweise exklusiv. Dadurch blockiert er den Zugriff auf alle anderen Variablen in dieser Line für eine relativ lange Zeit und bringt die zweite logische CPU damit zum Stoppen.
Programmtechnisch sollte man daher Variablen, die sich häufig ändern, als lokale Variablen deklarieren oder mit einer lokalen Kopie arbeiten. Ist dies nicht möglich, kann man die Variable künstlich etwa durch ein Array auf eine Größe von 128 Byte aufblähen und mit _decspec (align 128)) auf den Anfang einer Cacheline legen. Dadurch belegt sie die Line exklusiv und kann nicht mit anderen Variablen kollidieren.
Eigentor Cache-Trashing
Gerade wenn sich eine Aufgabe gut parallelisieren lässt, bietet sich eine Thread-basierte Lösung an. Voneinander unabhängige Daten werden dabei auf mehrere identische Threads aufgeteilt. Bei Multiprozessor-Systemen erhält man dadurch eine deutlich höhere Performance.
Speziell im Zusammenspiel der Microsoft-Entwicklungsumgebung mit Intels Hyper-Threading ergibt sich aber ein spezielles Problem. Intels Pentium 4 und Xeon können Variablen von verschiedenen physikalischen Adressen nicht beliebig in ihrem Cache ablegen. Sie speichern Daten in dieselbe Cacheline, wenn die unteren 16 Bit der Adresse identisch sind.
Microsoft gibt aber jedem neuen Thread einen um 1 MByte verschobenen Stackpointer. Erzeugt man also zwei Threads mit identischem Code, sind die unteren 20 Bit der Adressen aller lokalen Variablen und Funktionsparameter identisch. Diese Daten müssen somit in die gleiche Cacheline und verdrängen sich bei jedem Zugriff gegenseitig aus dem Cache. Dieser Effekt kann beispielsweise für Laufvariablen einer Schleife dramatische Folgen haben.
Der Effekt ist im Diagramm gut zu erkennen. Zum Einsatz kommt dabei ein multithreaded programmierter Dhrystone, der viel mit lokalen Variablen arbeitet. Ohne einen Workaround fällt die Gesamtleistung mit Hyper-Threading beim Einsatz von zwei Threads um 12 Prozent ab. Behebt man dieses Problem, steigt sie dagegen um 13 Prozent. Auf einem Prozessor ohne HT fällt die Leistung ebenfalls minimal, da die Threadwechsel Zeit kosten und jeder Thread nach dem Wechsel erst einmal erneut den Cache füllen muss.
Lösen lässt sich das Problem des Cache-Trashing, indem man den Stackpointer von Hand bei jedem Erzeugen eines neuen Threads um das Vielfache einer Cachelinesize verschiebt. Der Codeabschnitt im Bild "Fix in C++" zeigt eine entsprechende Lösung für Intel C++-Compiler.
Diese Lösung hilft herzlich wenig bei Programmen, die nicht im Sourcecode vorhanden sind. Deshalb hat Intel bereits angekündigt, das Problem beim Prescott durch eine Designänderung in der CPU zu lösen.
Compiler-Abhängigkeit
Intel gibt an, dass seine Compiler besonders gut optimierten Code für den Pentium 4 erzeugen. Um dies zu prüfen, haben wir einen Dhrystone-Benchmark mit Microsofts C++ 6.0-, Intels C++ 5.0- und Intels C++ 6.0-Compiler übersetzt. Allerdings läuft der Stackfix auf der vorangehenden Seite nicht mit dem Microsoft-Compiler. Übersetzt man den Benchmark mit Microsoft C++ 6.0, stürzt der Test ab. Deshalb geben wir bei den Intel-Compilern die Werte einmal mit und einmal ohne den Fix gegen das Cache-Trashing an.
Bei allen Tests kommt die Compiler-Option "Optimierungen: Geschwindigkeit erhöhen" aus Microsofts Visual Studio 6.0 zum Einsatz. Innerhalb der Intel-Compiler hat damit die Version 6.0 meist mit ein paar Prozent die Nase vorn. Verglichen mit Microsofts Compiler läuft der damit erzeugte Code bei einem Thread sogar um 19 Prozent schneller. Bei mehreren Threads wächst der Unterschied weiter an. Ohne den Fix beträgt er bei vier Threads 42 Prozent (1301 zu 1854 kDhrystone/s).
Allerdings bringt die bessere Code-Optimierung des Intel-Compilers auch einen Nachteil mit sich: Die Compilations-Zeiten sind im Vergleich zum Microsoft-Compiler um den Faktor drei länger. Gerade bei großen Projekten werden die Turnaround-Zeiten damit unerträglich lang.
Benchmark-Vorbetrachtungen
Alle Tests fanden auf einer Dell Precision Workstation 530 mit zwei Xeon-2,2-GHz-Prozessoren und 1-GByte-PC800-RDRAM statt. Bei diesem Rechner lassen sich im BIOS sowohl die zweite CPU als auch das Hyper-Threading abschalten.
Bei den folgenden Benchmark-Diagrammen haben wir die Werte einmal mit einer physikalischen CPU und einmal mit beiden physikalischen CPUs mit und ohne Hyper-Threading angegeben. Der Vergleich mit der Dual-Nicht-HT-Konfiguration zeigt dabei, ob und wie ein Benchmark mit einer zweiten "echten" CPU skaliert.
Die Low-Level-Benchmarks erfolgen mit dem von tecCHANNEL eigens entwickelten tecThread. Dieser Benchmark kann die verschiedenen Testroutinen parallel in mehreren Threads ablaufen lassen. Angegeben ist dabei die Summenleistung aller Threads. tecThread wurde mit Intels C++-6.0-Compiler übersetzt. Er befindet sich derzeit in der Evaluierungsphase und ist daher noch nicht als Download erhältlich.
Jede der Testroutinen von tecThread belastet eine andere Funktionsgruppe innerhalb der CPU. Die teils in die Jahre gekommenen Tests wie Dhrystone und Whetstone eignen sich wenig, um die Systemleistung eines PCs zu ermitteln. Für den punktuellen Vergleich einzelner Funktionsgruppen sind sie jedoch bestens geeignet. Ihr Verhalten im Cache und ihre Zugriffsmuster sind bekannt und eingehend analysiert.
Die MMX- und SSE-Tests bestehen aus Codefragmenten, die diese Einheiten sehr stark belegen. Zusätzliche Threads finden dadurch bei Hyper-Threading kaum freie Lücken in der Execution-Einheit der CPU. Bei Anwendungen, die parallel dazu andere Funktionseinheiten in weiteren Threads belegen, fallen die Gewinne deutlich höher aus. Dies wird auch bei den weiter hinten aufgeführten Benchmarks unter Last sichtbar.
Dhrystone Multithread Benchmark
Der Dhrystone-Benchmark ermittelt die Integerleistung einer CPU. Er enthält zu 53 Prozent Integer- und String-Manipulationen, 32 Prozent Control-Statements und 15 Prozent Funktionsaufrufe. Seine Daten sind zum großen Teil lokal und liegen auf dem Stack. Deshalb reagiert er sehr empfindlich auf das eingangs erwähnte Cache-Trashing.
Der Dhrystone-Benchmark läuft zu einem großen Teil aus dem Cache und nutzt viele einfache Befehle. Deshalb ergeben sich selten Lücken in den einzelnen Stufen der Prozessor-Pipeline. Ohne Hyper-Threading ändert sich die Leistung beim Wechsel von einem auf zwei parallel arbeitende Threads kaum (2147 zu 2117 kDhry/s). Mehr Threads bringen aber auch keine Nachteile, selbst mit sechs Threads erreicht der Benchmark noch 96 Prozent seiner Leistung.
Auf einer HT-CPU ergibt sich mit zwei Threads immerhin eine Steigerung von 17 Prozent (2148 zu 2518 kDhry/s). Kein schlechter Wert, vor allem da die Implementation im Test nicht gut mit der Anzahl der CPUs skaliert. Beim Wechsel von einer auf zwei physikalische CPUs ergibt sich bei zwei Threads nur eine Steigerung von 61 Prozent.
Whetstone Multithread Benchmark
Der Whetstone-Benchmark nutzt zu rund 50 Prozent Floatingpoint-Operationen und transzendente Funktionen. Aber auch Integer-Arithmetik und der Zugriff auf Array-Elemente werden häufig verwendet. Im Gegensatz zum Dhrystone sind seine Variablen meist global. Da der Whetstone-Benchmark sehr viele kurze Schleifen enthält, läuft er zu einem hohen Prozentsatz aus dem Trace-Cache des Pentium 4.
Der Whetstone-Benchmark profitiert sehr stark von Hyper-Threading. Beim Wechsel von einem auf zwei Threads bei einer HT-CPU steigt die Leistung um 45 Prozent. Der Grund liegt in dem Mix aus Integer- und Floatingpoint-Operationen. Wartet ein Thread auf das Ergebnis einer mehrere Takte dauernden FP-Berechnung, kann der andere in dieser Zeit die Integer-Pipelines füllen. Somit sind alle Execution Units bei mehreren Threads immer gut gefüllt.
Die Implementierung skaliert bestens mit der Anzahl der CPUs. Eine zweite CPU bringt 100 Prozent mehr Leistung. Beeindruckend ist die Steigerung mit zwei HT-CPUs bei einem, zwei und vier Threads: 5,3 10,5 und 15,4 MWhetstone/s. Bei gemischten Integer- und Floatingpoint-Problemen zahlt sich Multithreading in Zusammenhang mit HT-CPUs demnach wirklich aus.
MMX Integer Multithread Benchmarks
Im MMX-Integer-Benchmark kommen nur 64-Bit-MMX-Befehle der ersten SIMD-Generation zum Einsatz. Das Codefragment zum Benchmark berechnet dabei eine Überlagerung von zwei Farbbildern mit 48 Bit Farbtiefe.
Bei diesem Alpha-Blending kommen in der Kernschleife nur MMX-Befehle vor. Die Farbwerte der Bildpunkte werden mit einem Gewichtsfaktor multipliziert und anschließend addiert. Jeder Thread arbeite mit 80 kByte großen Teilbildern, so dass er 240 kByte Daten verwendet (zwei Ausgangsbilder, ein Ergebnisbild).
Beim Wechsel von einem auf zwei Threads skaliert der Test auf einer Dual-CPU-Konfiguration bestens. Die Steigerung beträgt 94 Prozent (33 zu 64 kLoops/s). Sobald jedoch mehr Threads laufen als physikalische CPUs vorhanden sind, bricht die Leistung stark ein. Selbst auf einer HT-CPU bringen zwei Threads 28 Prozent weniger Leistung als ein einzelner Thread.
Hier dürfte das Problem auf eine ungünstige Cache-Belegung zurückzuführen sein. In einem solchen Fall ist entweder eine gründliche Analyse mit Intels Performance Analyzer VTune und ein anschließendes Umprogrammieren notwendig. Alternativ startet man nur so viele Threads, wie physikalische CPUs vorhanden sind - und verzichtet auf Hyper-Threading.
SSE Floatingpoint Multithread Benchmark
Der SSE-Floatingpoint-Test bildet eine Bewegung von Geometriedaten eines Spiels oder einer CAD-Anwendung ab. Die Weltkoordinaten von 16.000 Punkten liegen dabei als Floatingpoint-Werte mit einfacher Genauigkeit vor. Im Test werden erst alle Punkte um einen Winkel gedreht und anschließend verschoben. Jeweils vier Werte sind dabei in einen 128-Bit-Floatingpoint-Vektor gepackt, der mit einem SIMD-Befehl bearbeitet werden kann. Die Datengröße für jeden Thread beträgt 256 kByte.
Im Wesentlichen gleichen die Ergebnisse denen des MMX-Tests. Auf zwei CPUs skaliert der Test bestens mit zwei Threads (plus 96 Prozent). Laufen mehr Threads als physikalische CPUs, sinkt die Leistung bei zwei Threads je CPU leicht. Bei noch mehr Threads pro physikalischer CPU bricht sie drastisch ein.
Hyper-Threading bringt hier bei einem Thread je logischer CPU noch minimale Vorteile, um dann bei mehr Threads ebenso einzubrechen.
Messung mit Fremdlast
Das Aufteilen einer Aufgabe in mehrere parallele Threads ist nur ein Aspekt von Multithreading. Gerade auf Desktop-PCs laufen meist mehrere verschiedene Threads und Programme parallel ab. Dabei treten gänzlich unterschiedliche Datenzugriffsmuster und Belegungen von Prozessoreinheiten auf. Somit kommt es selten zur gegenseitigen Behinderung, und Hyper-Threading sollte deutliche Vorteile bringen.
Zur Messung unter diesen Bedingungen kann tecThread eine Teilaufgabe mit konstanter Last nachbilden und dann die verbleibende Leistung für eine andere Aufgabe ermitteln. Im Folgenden haben wir nur eine physikalische CPU benutzt und als Last-Thread 1 MDhrystone/s gewählt. Das entspricht rund 45 Prozent der maximalen Dhrystone-Leistung. Interessant ist bei diesen Messungen, wie schnell dann noch etwa ein Whetstone-Test auf einer normalen und auf einer HT-CPU abläuft.
Wie auch schon bei den Einzelmessungen profitiert der Whetstone-Benchmark deutlich von Hyper-Threading. Bei einer Standard-CPU fällt die Leistung erwartungsgemäß auf 54 Prozent der Spitzenleistung ab, da ja die Last bereits 45 Prozent der CPU belegt. Mit Hyper-Threading stehen dagegen noch 88 Prozent der Whetstone-Leistung zur Verfügung. Der parallel laufende Dhrystone bremst den Whetstone-Test damit nur minimal aus.
MMX und SSE unter Last
Auch die Problemkandidaten der vorangehenden Messungen gewinnen deutlich an Leistung, wenn sie auf einer HT-CPU gemeinsam mit einer anderen Aufgabe ablaufen.
Ohne Hyper-Threading sinkt die MMX-Leistung erwartungsgemäß auf 54 Prozent, wenn ein gleichzeitig laufender Dhrystone-Thread 45 Prozent der CPU-Leistung belegt. Mit HT liefert der MMX-Benchmark immerhin noch 69 Prozent seiner Leistung ohne Last.
Das Bild wiederholt sich beim SSE-Floatingpoint-Benchmark: 54 Prozent der Spitzenleistung ohne HT stehen 67 Prozent mit HT gegenüber. Bei unterschiedlichen Aufgaben bringt Hyper-Threading demnach deutliche Vorteile gegenüber klassischen CPUs.
SYSmark 2002
Im täglichen Einsatz ist die Performance bei Standardanwendungen am wichtigsten. Dazu gehören nicht nur Programme wie Word und Excel, sondern auch MPEG-Encoder, 3D-, Video- und Sound-Software. Die Leistungsfähigkeit der Prozessoren überprüfen wir deshalb auch mit dem Benchmark-Paket SYSmark2002, das ein Mix aus den genannten Programmen ist.
SYSmark2002 soll auch das parallele Arbeiten mit mehreren Programmen gleichzeitig simulieren. So arbeitet beispielsweise im Vordergrund eine Office-Applikation, während im Hintergrund der Virenscanner auf die Suche geht. Der Tester hat so jedoch leider keinen Überblick, welches Programm einer CPU nun besonders zu schaffen macht. Aus welchen Einzelwerten sich die beiden Ergebnisse für Office Productivity und Internet Content Creation errechnen, bleibt deshalb das Geheimnis der BAPCo.
Beim Test enttäuscht Hyper-Threading. Während SYSmark 2002 beim Wechsel von einer auf zwei CPUs zumindest 16 Prozent schneller wird, fällt die Leistung beim Aktivieren von Hyper-Threading sogar ab.
Raytracing Lightwave 3D
Das 3D-Programm Lightwave 3D 7 von NewTek ist für den Pentium 4 optimiert. Laut NewTek betrifft das speziell den SSE2-Befehlssatz. Lightwave 3D ist Thread-basiert, wobei die Anzahl der Threads vom Benutzer vorgegeben wird
Bei einer Standard-CPU fällt die Leistung von Lightwave mit der Anzahl der Threads leicht ab. Mit HT ergibt sich bei einer physikalischen CPU ein Gewinn von immerhin 15 Prozent. Eine zweite physikalische CPU bringt dagegen 88 Prozent Steigerung.
Raytracing: Cinebench 2000
Cinema 4D XL von Maxon ist ein professionelles 3D-Modelling- und Animationswerkzeug. Eigens für Performance-Tests entwickelte Maxon den Cinebench 2000. Er basiert auf Cinema 4D XL und führt Shading- und Raytracing-Tests durch. Die verwendete Version des Benchmarks unterstützt noch nicht den SSE2-Befehlssatz.
Beim Raytracing-Leistungstest fordert Cinebench 2000 besonders die FPU des Prozessors. Der Benchmark verwendet eine Szene, die stark von Anti-Aliasing, Schatten, Transparenzen und Spiegelungen Gebrauch macht.
Bei einer CPU bringt HT eine Mehrleistung von 10 Prozent. Eine zweite CPU steigert die Geschwindigkeit dagegen um 70 Prozent. In der Dual-CPU-Konfiguration beschleunigt HT die Ausführung nochmals um 17 Prozent.
Fazit
Hyper-Threading gibt es derzeit nur für Xeon-Server und -Workstations. Doch demnächst wird der Pentium 4 damit aufgemöbelt und Hyper-Threading in Standard-PCs wandern. Für Intel wird die Rechnung auf jeden Fall aufgehen: Der "zweite" Prozessor kostet nur rund fünf Prozent mehr Chipfläche, die Herstellungskosten fallen deshalb nur marginal höher aus. Der Anwender erhält dafür - bei entsprechenden Anwendungen - 10 bis 20 Prozent mehr Leistung.
Will man diese Steigerung über die Taktfrequenz erreichen, sind 15 bis 30 Prozent höhere Frequenzen nötig - entsprechend dem zwei- bis dreifachen höheren CPU-Preis. Interessant wird daher, wie teuer sich Intel dieses Feature bezahlen lassen wird und ob es in Zukunft weiterhin einen preiswerten "Pentium-4-Celeron" ohne Hyper-Threading geben wird.
Allerdings profitieren nicht alle Anwendungen von Hyper-Threading. Doch Programmierer sehen nun endlich einen Sinn in Thread-basierten Desktop-Anwendungen und einer Thread-Optimierung. Aktuell können sie auf Xeon-Systemen ausgiebig Hyper-Threading testen und dafür entwickeln. Und kommt Hyper-Threading im Mainstream-PC, haben sie passende Argumente für ein Update der Software parat. (ala)
Testkonfiguration
Komponente | Daten |
|---|---|
| |
Computer | Dell Workstation 530 MT |
CPU | 2x Intel Xeon 2,2 GHz, 512 kByte L2-Cache |
Chipset | Intel i860 |
Mainboard-Version | A00 |
BIOS-Version | A05 |
Speicher | 4x 256 MByte PC800-RDRAM mit ECC |
Grafikkarte | NVIDIA Quadro2 EX, 32 MByte |
Controller | Dell PERC3 SCSI RAID, 64 MByte Cache |
Festplatten | 2x Fujitsu MAM3184MP, 18,4 GByte, 1500 rpm, Ultra 160, im RAID-0-Verband |
Netzwerk | 3Com 3C920v3 Fast EtherLink XL 10/100 PCI |
CD-ROM | LG CDR-8482B |
DVD-Brenner | Philips DVD+RW-D01 |
Sound | AC'97 Vollduplex-Audio integriert |
Sonstiges | 2x Firewire- (IEEE1394) Schnittstelle |
Betriebssystem | Windows XP Professional 1-2 CPUs |