Auf zum Atom! Teil 2

mj

Technische Administration, Dinosaurier, ,
Mitglied seit
17.10.2000
Beiträge
19.529
Renomée
272
Standort
Austin, TX
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=2730&w=o" border=1></center>

Vor zwei Wochen berichteten wir über Intels Atom-Prozessor und testeten diesen auf Herz und Nieren. In den Kommentaren wurden dann auch schnell Wünsche nach weiteren Tests und Benchmarks laut, aus diesem Grund gibt's heute ein Update des Artikels mit neuen, hauptsächlich Leser-inspirierten Benchmarks.

<b>Anwendungsbenchmarks:</b>
Einer der größten Kritikpunkte des ursprünglichen Artikels war die Praxisferne der durchgeführten Benchmarks. Zugegeben: die wenigsten werden einen Atom-Prozessor zum Encodieren von Videos nutzen, das tatsächliche Ergebnis kann jedoch vom Standpunkt des Vergleichs durchaus interessant sein. Ganz oben auf der Wunschliste standen bei vielen verstärkt Anwendungsbenchmarks, daher entschieden wir uns für den PCMark05 von Futuremark, da dieser diverse Tests durchführt und eine sehr detaillierte Ergebnisauswertung ermöglicht.

Zusätzlich zu diesem synthetischen Benchmark wählten wir mit Paint.NET noch einen sehr anwendungsnahen Test aus. Der <a href="http://paintdotnet.forumer.com/viewtopic.php?f=16&t=21669" target="b">kostenlos erhältliche Pdnbench</a> greift darauf zurück, öffnet, speichert und schließt diverse Dateien und führt ebenfalls unterschiedlichste Operationen auf diesen Dateien durch - vergrößern, verkleinern, transformieren, Filter anwenden, etc.

<b>Videodekodierung</b>
Auch sehr laut waren die Rufe nach den Fähigkeiten bei der Videodekodierung, insbesondere also der Wiedergabe hochauflösender HD-Videos. Um also zu testen, wie sich der Atom hier schlägt, haben wir vier unterschiedliche Videos ausgesucht und neben der CPU-Auslastung bei der Wiedergabe auch die tatsächlich dargestellten Bilder pro Sekunde ermittelt. Als Videos kamen zum Einsatz:
<ul><li>PAL (720x576), 25fps, H.264</li><li>HD 720p (1280x720), 24fps, H.264</li><li>HD 1080p (1920x1080), 25fps, H.264</li><li>HD 1080p (1920x1080), 29fps, WMV3</li></ul>
Die ermittelte CPU-Last spiegelt dabei einen Mittelwert wider, der bei der Wiedergabe der Videos mit Hilfe von Perfmon ermittelt wurde.

[BREAK=Fortsetzung: Einleitung II]
<b>SETI@home SMT-Bench</b>
Im ersten Teil des Artikels haben wir zwar einen SETI@home Benchmark durchgeführt, jedoch trotz des Vorhandenseins von SMT nur eine Instanz laufen lassen. Der Grund hierfür war die theoretisch Überlegung, dass die doppelte Ausführung bei SMP zwar durchaus Sinn macht und doppelter WU-Durchsatz machbar ist, dies bei SMT jedoch sehr schnell ins Gegenteil umschlagen kann.

Dieses auf den ersten Blick unlogische Verhalten ist auf die Arbeitsweise eines SMT-Mikroprozessors zurückzuführen. Anders als bei SMP stehen bei SMT keine zusätzlichen Befehlseinheiten zur Verfügung, sondern lediglich die notwendige Logik, um dem Betriebssystem einen zweiten Mikroprozessor vorzutäuschen und dadurch eine bessere Auslastung der Befehlseinheiten zu erreichen. Tritt der Fall auf, dass zwei nebenläufige Threads die gleiche Befehlseinheit benötigen, beispielsweise die ALU, dann muss ein Thread zwangsweise warten, bis die benötigte Befehlseinheit wieder frei geworden ist. Ein out-of-order-Prozessor sortiert an dieser Stelle die Befehle des wartenden Threads um, so dass andere Befehle ausgeführt werden, die nicht auf die ALU zurückgreifen müssen - beispielsweise Speicher- oder FPU-Operationen. Jetzt ist der Atom aber bekanntermaßen ein in-order-Prozessor und eine Umsortierung der Befehlsreihenfolge ist dieser Art der Architektur fremd. Daher steht der zweite Thread solange still, bis die benötigte Befehlseinheit wieder frei geworden ist.

Zum besseren Verständnis greifen wir nochmal auf die Grafik aus dem ersten Teil des Artikels zurück:

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2731"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2731&w=l" border="1" alt="Atom"></a></center>
Von Interesse ist für uns diesmal nur der untere Teil der Grafik. Nehmen wir an, die beiden nebenläufigen Threads sind zwei unterschiedliche WUs des BOINC-Clients. Der Zeitpunkt t=1 zeigt sehr schön, warum dies bei einem in-order SMT-Prozessor zu Problemen führen kann: Statt aus dem zweiten Thread die blaue Operation auszuführen, was bei einer out-of-order-Architektur problemlos möglich wäre, muss der zweite Thread pausieren, bis die ALU (rot) wieder frei ist.

Daher müssten rein theoretisch zwei parallele Instanzen von SETI@home insgesamt langsamer laufen, als wenn beide hintereinander ausgeführt werden. Um diese Behauptung zu belegen (oder zu widerlegen), haben wir zwei SETI@home Instanzen parallel laufen lassen und die Zeit gemessen, die zur Berechnung beider WUs nötig war. Zusätzlich haben wir die Zeit gemessen, die zur Berechnung beider WUs hintereinander nötig war.

[BREAK=Benchmarks: Paint.NET & PCMark05]
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2804"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2804&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Im Anwendungsbenchmark Paint.NET schlägt sich der Atom sehr gut und profitiert mit 54% auch stark von SMT.

Der Web Page Rendering Benchmark lädt vier unterschiedliche Webseiten von der Festplatte und berechnet die zum Rendern der Seiten benötigte Zeit. Die Zusammensetzung der Seiten ist wie folgt:
<ul><li>130KB große typische Unternehmens-Startseite</li><li>Eine Seite mit sieben unterschiedlichen großen Fotos (insgesamt 2,9MB)</li><li>310KB große Webseite mit reinem Text</li><li>Eine dynamische Startseite eines Forums</li></ul>
Der Test läuft 20 Sekunden lang, gemessen wird wie viele Webseiten in dieser Zeitspanne dargestellt werden können.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2827"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2827&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Da der Test leider nicht auf einen frei wählbaren Browser zurückgreift, sondern ist fest an den Internet Explorer gebunden ist, sind die Ergebnisse mit Vorsicht zu genießen. Primär zeigt das Ergebnis eines: Der Internet Explorer profitiert kaum von SMP/SMT. Die maximale CPU-Last steigt während des Web Page Rendering Benchmarks auf gerade mal 58%. Andere Browser können zu einem anderem Ergebnis führen. Die hier ermittelten Werte sind also lediglich zum relativen Vergleich geeignet, nicht jedoch als absolute Leistungswerte.

Der Text Edit genannte Benchmark greift auf die mit Windows mitgelieferte Textverarbeitung Wordpad zu und führt mehrere unterschliedlich komplexe Suchen & Ersetzen Operationen auf einer 85KB großen Textdatei durch.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2830"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2830&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Sowohl mit aktiviertem, als auch mit deaktiviertem SMT, schlägt sich der Atom hervorragend und lässt den K8 weit zurück. So groß ist hier der Unterschied zwischen K8 und Atom, dass wir zum ersten und einzigen Mal von unserem Vorhaben Abstand nehmen, die Ergebnisse des K8 vollständig unkommentiert zu lassen.

[BREAK=Fortsetzung Benchmarks: PCMark05]
Der Audio-Benchmark führt eine Kompression einer unkomprimierten Audio-Datei in das Ogg Vorbis Format durch, bei der Dekompression wird eine solche Datei dekomprimiert. Gemessen wird dabei der Durchsatz des Kompressions- / Dekompressions-Algorithmus in Kilobyte pro Sekunde.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2828"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2828&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2829"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2829&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Da die Ergebnisse für sich sprechen, lassen wir sie an dieser Stelle unkommentiert.

Der Image Decompression Benchmark testet die Fähigkeit des Computers Bilder zu dekomprimieren. Dabei greift das Programm auf vier unterschiedlich große und unterschiedlich stark komprimierte JPEG-Dateien zurück:
<ul><li>130KB mit Kompressionsfaktor 8</li><li>900KB mit Kompressionsfaktor 4</li><li>900KB mit Kompressionsfaktor 10</li><li>1,1MB mit Kompressionsfaktor 12</li></ul>
Der Test läuft für 20 Sekunden, ermittelt werden Megapixel pro Sekunde.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2831"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2831&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>

[BREAK=Fortsetzung Benchmarks: PCMark05]
Die File Compression und Decompression Benchmarks greifen auf die kostenlose zlib-Bibliothek zu, um unterschiedlich große Dateien zu komprimieren und zu dekomprimieren:
<ul><li>3MB große ausführbare Datei</li><li>2MB großes Textdokument</li><li>10MB große Videodatei</li><li>3,5MB große Audiodatei</li></ul>
Neben der reinen Kompressions- / Dekompressionsleistung ermöglicht zlib einen tiefen Blick in die subjektiv empfundene Geschwindigkeit einer CPU, denn die Bibliothek kommt in vielerlei Software zum Einsatz, wo man sie gar nicht vermuten würde. So nutzen diverse Bestandteile von Microsoft Office die Bibliothek, ebenso wie Norton Antivirus, OpenOffice, oder der E-Mail Client The Bat! Die Leistung hat also direkt Auswirkung darauf, wie flüssig der Anwender eine Anwendung empfindet. Zwar handelt es sich dabei um einen rein subjektiven Wert, dieser kann jedoch bei Anwendern mehr bewegen, als die reinen Zahlen vermuten lassen.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2832"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2832&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2833"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2833&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>

Der File Encryption und Decryption Benchmark verschlüsselt und entschlüsselt unterschiedliche Dateitypen verschiedener Größe. Dabei kommt der AES-Algorithmus zum Einsatz, gemessen wird der Durchsatz in Megabyte pro Sekunde.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2834"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2834&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2835"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2835&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Sowohl bei Verschlüsselung als auch Entschlüsselung fällt das Ergebnis aus wie erwartet und spiegelt den bisherigen Eindruck wider.

[BREAK=Benchmarks: Videodekodierung]
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2805"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2805&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2806"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2806&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Das einzige nicht-HD-Video im Test stellt den Atom vor keinerlei Schwierigkeiten, selbst ohne SMT reicht die Leistung zur flüssigen Wiedergabe aus.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2807"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2807&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2808"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2808&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Das H.264 720p Video ist jedoch bereits zu viel des Guten, ohne SMT reicht die Leistung des Atom zur flüssigen Wiedergabe nicht mehr aus. Mit SMT reicht sie hingegen problemlos auch zur Wiedergabe schneller Sequenzen aus, die Framerate blieb trotz der hohen CPU-Last während des Testdurchlaufs konstant bei 24 Bildern pro Sekunde.

[BREAK=Fortsetzung Benchmarks: Videodekodierung]
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2809"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2809&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2810"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2810&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Beim H.264 1080p Video stößt der Atom, wie zu erwarten war, an seine Grenze. Trotz nur 81% Auslastung kommen lediglich neun Bilder pro Sekunde beim Anwender an. Ohne SMT sinken diese sogar auf nur noch sieben Bilder pro Sekunde.

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2811"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2811&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2812"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2812&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Ähnlich ist die Situation beim WMV3 1080p Video, auch hier wird die spezifizierte Bildrate nicht erreicht. Bei 56% Prozessorlast zaubert der Atom mit SMT immer noch mehr oder weniger flüssige 20 Bilder pro Sekunde auf den Bildschirm. Lediglich bei sehr schnellen und aufwändigen Sequenzen ist die niedrige Framerate bemerkbar, die, bei einer CPU-Last von 70%, nochmals um weitere 2-5 Bilder pro Sekunde sinkt. Langsame Sequenzen scheinen hingegen durchgehend flüssig.

[BREAK=Benchmarks: BOINC/SETI@home]
Der letzte Test ist der bereits in der Einleitung gründlich erläuterte SETI@home Durchlauf mit zwei WUs; einmal nebenläufig und einmal hintereinander berechnet. Gemessen wird jeweils die Zeit pro WU:

<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2836"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2836&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=2837"><img src="http://www.planet3dnow.de/photoplog/file.php?n=2837&w=l" border="0" alt="Update: Auf zum Atom!"></a></center>
Das Ergebnis entspricht den theoretischen Überlegungen: Werden beide WUs parallel berechnet, benötigt die langsamere WU über vier Stunden. In den 201 Minuten, die die erste WU zur Fertigstellung benötigt, schafft die zweite WU gerade mal 24%. Wir haben den Durchlauf zweimal durchgeführt, die Berechnungszeit der langsameren WU war dabei gleich, lediglich die Berechnungszeit der schnelleren WU ändert sich. Zudem kehrte sich dies beim zweiten Durchlauf um - die im ersten Durchlauf schnellere WU war beim zweiten Durchlauf die langsamere und umgekehrt.

Interpoliert bedeutet das Ergebnis: Laufen beide WUs parallel, stehen beide Ergebnisse nach 289 Minuten zur Verfügung. Laufen beide WUs nacheinander, stehen beide Ergebnisse bereits nach 271 Minuten zur Verfügung. Bei einem out-of-order-Prozessor, wie beispielsweise dem Pentium 4, sieht dies hingegen anders aus: Hier sorgt die Umsortierung der Befehle dafür, dass bei zwei nebenläufigen Berechnungen zwar die Zeit jeder einzelnen WU steigt, <a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=3628161#post3628161" target="b">die Gesamtzeit, die zur Berechnung von zwei WUs jedoch nötig ist niedriger ausfällt, als wenn man diese nacheinander berechnen würde</a>.

[BREAK=Fazit]
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=2730&w=o" border=1></center>

Im Prinzip haben die neuen Benchmarks den bisherigen Eindruck bestätigt. Ohne SMT macht dem Atom seine in-order-Architektur schwer zu schaffen und die Leistung fällt mehr als schlecht aus. Sobald der Mikroprozessor jedoch über beide virtuellen Kerne verfügen kann, reicht die Leistung für vielerlei Aufgaben mehr als aus und selbst die Wiedergabe von H.264-HD-Videos bis 720p ist flüssig möglich. Die dank SMT erreichte höhere Auslastung der Befehlseinheiten ist den Mehrenergiebedarf von geschätzten 20% (laut Intel) also durchaus wert.

<a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=344784">Artikel kommentieren...</a>
 
Zurück
Oben Unten