Bei XMpeg kommt die gewaltige Leistung eines Dual-Prozessor Systems erstmals zum Vorschein. Wo das K8W mit nur
einem Prozessor bestückt sich dem um 200 MHz schnelleren Athlon 64 FX-51 wie zu erwarten war geschlagen geben muss, bricht
es selbigem mit einem weiteren Prozessor ausgestattet gnadenlos das Genick. 25 Sekunden für das Umwandeln unseres Referenzvideos
sind konkurrenzlos und derzeit ausschließlich mit zwei (oder mehr) noch schnelleren Opteron Prozessoren zu schlagen.
Einen enormen Leistungseinbruch müssen wir beim Komprimieren mit WinACE 2.2 feststellen. Beim Test mit zwei
Prozessoren fällt die Leistung messbar ab und auch das Bestücken der zweiten CPU mit eigenem Arbeitsspeicher
verschlechtert das Ergebnis nochmals.
Erklären lässt sich dies wiederum durch bereits erwähntes Locking des Kernels. WinACE selber ist nicht in der
Lage, aus mehreren Prozessoren einen Vorteil zu ziehen. Mit anderen Worten, es ist nicht multithreaded geschrieben
und unterstützt nur einen Thread auf einem Prozessor gleichzeitig. Dieser Umstand macht es demnach logischerweise
auch auf einem Pentium 4 mit aktiviertem Hyperthreading langsamer, als mit deaktiviertem Hyperthreading.
Beim Einsatz zweier CPUs weist Windows (an dieser Stelle sei erwähnt, dass diese Erläuterung in selbem Maße auch
für den Linux-Kernel Gültigkeit findet) der Anwendung einen Prozessor zu und lagert den Betriebssystem-Overhead
komplett auf den zweiten, noch freien Prozessor, aus.
Somit kann sich der eine Prozessor zu 100% der Anwendung widmen und der zweite hält ihm sozusagen den Weg und
Rücken gleichzeitig frei. Leider führt dies in diesem Fall zu einem Leistungseinbruch, da die gesamte I/O (lesen
und schreiben auf- und von der Festplatte beispielsweise) von einem anderen Prozessor gehandhabt wird, als das
eigentliche Komprimieren der Datei. Das Ergebnis ist häufiges sperren des Arbeitsspeichers für einen der beiden
Prozessoren, was zu unnötigen Wartezyklen führt.
Der Seti@Home Benchmark wurde diesmal ein wenig verändert, um das Potenzial zweier Prozessoren zu zeigen. Wir
haben den Seti Client nicht nur einmal laufen lassen, sondern parallel zwei Instanzen gestartet. Da dies bei
den Referenz-Benchmarks nicht der Fall war, wurde das Ergebnis dieser einfach verdoppelt, um einen ungefähren
Vergleichswert zu erreichen.
Bei den Benchmarks auf dem K8W wurden die Ergebnisse der beiden laufenden Instanzen addiert und die Summe
durch die Anzahl der vorhandenen Prozessoren dividiert.
Und wie auch bei XMpeg lässt ein Dual-Opteron hier gewaltig seine Muskeln spielen und ist mit zwei Prozessoren
doppelt so schnell wie mit nur einem. Auch auf den um 200 MHz schnelleren Athlon64 FX-51 beträgt der Vorsprung
im besten Fall 76%. Windows (und auch Linux) merken selbständig, wenn ein Prozessor zu 100% belastet ist und
lagern den zweiten gestarteten Seti@Home Prozess automatisch auf den zweiten, noch freien Prozessor aus.
Erwähnenswert ist an dieser Stelle noch, dass sich die Ergebnisse der einzelnen Instanzen beim Einsatz zweier
CPUs mit nur zwei Speichermodulen um 300s unterschieden. Der Prozessor, der keinen direkten Zugriff auf den
Arbeitsspeicher hat, rechnet also messbar langsamer als der Prozessor mit direktem Speicherzugriff. Gibt man
dem zweiten Prozessor jedoch seinen eigenen Arbeitsspeicher, so sind die Ergebnisse wieder identisch.
Diesen Artikel bookmarken oder senden an ...