Single vs. dual core Leistungsvergleich mobiler Intel-Systeme - Hochschule Bremen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
single vs. dual core
Leistungsvergleich mobiler Intel-Systeme
vorgelegt von
Frank Kuchta
Matrikel-Nr. 127685
Markus Rüger
Matrikel-Nr. 125575
Semester I7I
Im Fach Rechnerstrukturen – Labor bei
Herrn Prof. Dr. Thomas Risse
Hochschule Bremen – Fachbereich 4, Elektrotechnik & Informatik
Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Inhaltsverzeichnis
1. Motivation ............................................................................................................ 3
2. Ziel & Aufgabendefinition ..................................................................................... 3
3. Hardware - Architektur ......................................................................................... 4
3.1. Pentium M Serie (Banias - Architektur)......................................................... 5
3.2. Weiterentwicklung Codename: „Dothan“ ...................................................... 7
3.3. Dual-Core Prozessor “Yonah”....................................................................... 7
3.4. Intel Core 2 Duo / Intel Core-Mikroarchitektur .............................................. 9
4. Testumgebung................................................................................................... 10
4.1. Hardware .................................................................................................... 10
4.2. CPU-Z......................................................................................................... 12
5. Benchmarks....................................................................................................... 12
5.1. Vorbetrachtung ........................................................................................... 12
5.1.1. Software .............................................................................................. 12
5.1.2. Anwendertests..................................................................................... 13
5.2. Kompression............................................................................................... 13
5.3. Audio .......................................................................................................... 15
5.4. Video .......................................................................................................... 16
5.5. Grafik Rendering......................................................................................... 18
5.6. RSA Benchmark ......................................................................................... 19
5.7. Zwischenbetrachtung.................................................................................. 21
5.8. SyncAccess ................................................................................................ 21
5.9. DualSlow .................................................................................................... 24
6. Fazit ................................................................................................................... 29
7. Quellen .............................................................................................................. 31
8. Anhang .............................................................................................................. 35
8.1. Reports der verwendeten Systeme............................................................. 35
8.2. Single Core Systeme .................................................................................. 36
8.2.1. Dual Core Systeme ............................................................................. 38
Abbildungsverzeichnis
Abbildung 1: Banias-Kern [Banias] ............................................................................. 5
Abbildung 2: Dothan-Kern [Dothan] ............................................................................ 7
Abbildung 3: Yonah-Kern [Yonah]............................................................................... 8
Abbildung 4: Merom-Kern [Merom] ............................................................................. 9
Abbildung 5 Kompression Benchmark-Ergebnisse ................................................... 14
Abbildung 6: Screenshot von LAME ......................................................................... 15
Abbildung 7: Audio Benchmark-Ergebnisse.............................................................. 16
Abbildung 8: Video Benchmark-Ergebnisse.............................................................. 17
Abbildung 9: Cinebench Benchmark-Ergebnisse...................................................... 18
Abbildung 10: RSA Benchmark-Ergebnisse.............................................................. 20
Abbildung 11: SyncAccess Benchmark-Ergebnisse ................................................. 22
Abbildung 12: DualSlow-Benchmark, Datengröße bis 2000kByte ............................ 25
Abbildung 13: DualSlow: absolvierte Schleifendurchläufe / Zeit (1) .......................... 26
Abbildung 14: DualSlow: absolvierte Schleifendurchläufe / Zeit (2) .......................... 27
Abbildung 15: DualSlow-Benchmark, Datengröße bis 3000kByte ............................ 28
Abbildung 16: Preisübersicht aktueller Notebooks [Saturn] ...................................... 29
Abbildung 17: Preisübersicht Intel mobile Prozessoren [alternate] ........................... 30
Seite 2 von 39
Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
1. Motivation
Der PC-Markt hat in diesem Jahr eine Kehrtwende erlebt. Das Ende immer höherer
Taktfrequenzen scheint erreicht.
Die Erhöhung der Taktfrequenz erfordert eine höhere Betriebsspannung. Die
Leistungsaufnahme wächst jedoch mit dem Anstieg der
Spannung ungefähr quadratisch. Daher hat man sich dazu
entschieden, Entwicklungen in Richtung von Taktraten im
Bereich von 10 GHz nicht weiter zu verfolgen.
Der Chiphersteller Intel hat mit aufwendigen Marketing-
Maßnahmen die Zeiten des „Multi-Core“ Systems eingeläutet.
„Multiplizieren Sie Ihre Möglichkeiten und die Ihres
Computers“ [Zitat Intel 1] heißt es in einer Werbebotschaft auf
der Internet-Seite des Marktführers im PC Prozessor-Umfeld.
Im Endkunden –Bereich werden derzeit Dual-Core-Prozessoren beworben, die im
Gegensatz zu bisher üblichen Rechenwerken aus zwei Prozessor-Kernen bestehen.
Für den Business- bzw. Server-Bereich sind bereits Quad-Core-Prozessoren
verfügbar. Es ist geplant die Entwicklung nun zu immer mehr Kernen zu treiben, und
nicht wie bisher die Leistungssteigerung durch Erhöhung der Taktrate zu erreichen.
Dem Endkunden stellt sich die Frage, welche Vorteile sich für Ihn ergeben. Die
Hersteller werben bei Dual-Core-Systemen mit einer „doppelten Prozessorleistung
für mehr Multitasking“ [Zitat Intel 2]. Aber was steckt wirklich dahinter? Wie hoch sind
der Leistungsgewinn und der praktische Nutzen wirklich?
Diese konkreten Fragen von Anwendern wollen wir mit dieser Ausarbeitung auf den
Grund gehen.
2. Ziel & Aufgabendefinition
Um uns der Fragestellung der Anwender zu nähern, werden wir nachfolgend die
wesendlichen Änderungen in der Architektur von Single- und Dual-Core Prozessoren
erläutern. Wir werden einen Leistungsvergleich auf Anwendungsebene durchführen,
um direkt eine Aussage zum praktischen Nutzen eines Dual-Core-Systems geben zu
können.
Des Weiteren werden wir die Systeme auf technischer Ebene beleuchten, um ggf.
Probleme bzw. Schwachstellen auszumachen.
Ziel ist es, für die verschiedenen Fälle einen Beschleunigungsfaktor anzugeben.
Wir beschränken unsere Betrachtungen auf die derzeitigen Prozessoren der Firma
Intel, die für den mobilen Einsatzbereich konzipiert sind. Hier stehen uns geeignete
Geräte für Leistungsmessungen innerhalb des Semesterverbandes zur Verfügung.
Die Prozessoren im Desktop- bzw. Server-Bereich werden für andere Anforderungen
entwickelt und lassen sich deshalb nicht direkt mit den Mobil-Prozessoren
vergleichen.
Seite 3 von 39
Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Zudem stehen uns hierfür keine Geräte zur Leistungsmessung zur Verfügung.
Ebenso fehlen vergleichbare Geräte von anderen Herstellern, z.B. AMD.
3. Hardware - Architektur
Im wesendlichen gibt es fünf Architekturen der Firma Intel, die heutzutage in mobilen
Geräten zu finden sind. Die so genannte P6-Core-Architektur, auf der der Pentium III
basierte, stammt im Ursprung vom PentiumPro aus dem Jahre 1995 ab.
Mobile Pentium III Prozessoren basieren auf dieser Architektur.
Die Netburst – Architektur stellte den Nachfolger dar, sie wurde für den Pentium 4
entwickelt. Sie wurde im Jahre 2006 eingestellt, nachdem sich ein Ende bei der
Erhöhung der Taktfrequenz abzeichnete.
Es gibt drei mobile Varianten des Pentium 4. Da die Netburst – Architektur jedoch
sehr viel Energie benötigt, sind diese Prozessoren nicht sehr erfolgreich gewesen.
Die erste Serie von Prozessoren, die im Jahre 2003 konsequent für den mobilen
Anwendungsbereich entwickelt wurde, ist die Banias – Architektur. Diese finden wir
heute in den meisten Notebooks,die unter dem Label „Centrino“ oder Pentium M
verkauft werden.
„Yonah“ ist als vierte wichtige Architektur zu nennen. Dabei handelt es sich um den
ersten mobilen Dual-Core Prozessor der Firma Intel, der im Jahre 2006 erschienen
ist. Er basiert auf dem „Banias“ bzw. „Dothan“-Kern und wird deshalb auch noch
unter dieser Architektur aufgeführt. Vertrieben wird er unter dem Namen „Core
Solo“ wenn er nur über einen Kern verfügt bzw. als „Core Duo“ in der Dual-Core
Variante.
Im Herbst 2006 wurde die Intel Core-Mikroarchitektur vorgestellt. Hier wurden im
Bezug auf den Vorgänger „Yonah“ einige Änderungen durchgeführt, die zu einer
eigenen neuen Architektur führten. Der neu entstandene Mobil-Prozessor
„Merom“ trägt den Handelnamen „Core 2 Duo“. Zudem wurde die Entwicklung mit der
Desktop- und Server-Sparte wieder zusammengeführt.
Aufgrund der vielfältigen Prozessorlandschaft müssen wir unseren Focus eingrenzen.
Derzeit sind Notebooks mit den Prozessor-Kernen „Dothan“, „Yonah“ und
„Merom“ erhältlich.
Die Architekturen dieser Prozessoren werden wir genauer beleuchten.
Vorrab seien kurz einige allgemein gültigen Dinge erläutert:
Die typische Verlustleistung von Prozessoren wird als „Thermal Design Power“ (TDP)
bezeichnet und in Watt gemessen. Diese wird als Grundlage zur Berechnung der
Kühlung verwendet. Mit speziellen CPU-Testprogrammen simuliert der Chip-
Hersteller eine typische Verwendung seines Produktes. Dabei wird der TDP-Wert
ermittelt.
Seite 4 von 39
Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Jeder Hersteller tut dies nach seinen eigenen Vorgaben, die nicht öffentlich sind.
Daher geben die TDP-Werte nicht unbedingt Aufschluss über die tatsächlich
umgewandelte Leistung. Zudem spiegelt der TDP-Wert nicht die maximale
thermische Belastung wieder, da die CPU beim Test „typisch“ und nicht maximal
belastet wird.
3.1. Pentium M Serie (Banias - Architektur)
Bei der Banias – Architektur wurde die gesamte Entwicklung für eine Verwendung im
Mobilbereich ausgerichtet. Es galt also, den Stromverbrauch zu verringern, die
Leistungsfähigkeit zu steigern und den Ansprüchen für mobiles Arbeiten gerecht zu
werden.
Abbildung 1: Banias-Kern [Banias]
Dazu wurde unter anderem die Micro-Ops Fusion Technologie eingeführt. Bevor die
Micro-Ops in den Scheduler gelangen, wird analysiert, welche Operationen sich
zusammenfassen lassen. Somit wird der Scheduling-Aufwand reduziert. Erst vor den
parallelen Ausführungseinheiten werden Befehle wieder in einzelne Micro-Ops
zerlegt und auf die Einheiten aufgeteilt.
Dadurch muss der Scheduler weniger Einträge verwaltet, was die Performance
steigert und den Energiebedarf reduziert.
Zudem wurde ein spezieller Ablaufmanager integriert. Befehle, die sonst z.B. zu
Unterbrechungen führen würden, werden von dieser dedizierten Hardware
abgearbeitet. Dies sind z.B. die Stack-Operationen push, pop, call und ret. Dadurch
können die Ausführungseinheiten ohne Unterbrechung das eigentliche Programm
abarbeiten [Banias-Architektur].
Durch falsche Sprungvorhersagen kommt es häufig zu Stalls und
Befehlswiederholungen. Dies kostet Performance und erhöht den Stromverbrauch.
Seite 5 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Deshalb wurde die Banias-Architektur mit einer "Advanced Branch Prediction"
ausgestattet.
Dabei handelt es sich um drei Vorhersage-Einheiten, wobei der Prozessor selbst den
für den Anwendungsfall besten Predictor auswählt. Es gibt einen globalen, einen bi-
modalen sowie einen Schleifen Predictor.
Der bi-modale Predictor ist im wesendlichen eine Moore-Maschine mit vier
Zuständen. Dabei wird zwischen den Zuständen Strongly not taken, Weakly not
taken, Weakly taken und Strongly taken unterschieden. Dabei werden die letzten vier
Bits der Instruktion als Index genommen, um auf eine der Moore-Maschinen zu
verweisen.
Bei dem globalen Predictor handelt es sich um eine Index-Tabelle, die auf einzelne
bi-modale Predictoren verweist. Der Schleifen Predictor besteht aus zwei Index-
Tabellen und hat die Aufgabe, korrekte Vorhersagen für die Schleife als auch für den
Abbruch zu tätigen.
Ausführeinheiten bzw. Teile davon, die für eine Befehlsabarbeitung nicht benötigt
werden, können automatisch abgeschaltet werden. Das Ein- und Ausschalten
geschied innerhalb eines Taktzykluses. Durch diese Funktion wird Energie
eingespart.
Der Level-2 Cache des Banias ist 8-fach assoziativ und verfügt über eine Kapazität
von 1 MByte. Jede Cacheline ist in vier Bereiche unterteilt. Ein Quadrant Selector
kann gezielt jedes der insgesamt 32 Felder ansprechen. Felder, die nicht belegt sind,
werden in einen Energiesparmodus geschaltet.
Jeder Prozessor verfügt über Buffer-Schaltungen, die die Busspannungen für den
Prozessor konvertieren. Diese Schaltkreise haben einen sehr hohen Energiebedarf.
Bei der Banias - Architektur werden diese nur bei Bedarf mit Strom versorgt.
Die Banias - Architektur kann wie schon die Pentium-4-Prozessoren die SSE2
Befehle verarbeiten. Dabei handelt es sich um 144 neue zusätzliche Befehle, u.a.
sind nun 128 Bit breite Integer- und Floating-Point-Operationen möglich. Da jedoch
nur 64 Bit ALU’s vorhanden sind, müssen diese in zwei Schritten ausgeführt werden.
Der Front-Side-Bus wird mit 400 MHz getaktet. Zudem ist es möglich, die
Taktfrequenz und Core-Spannung dynamisch an die Prozessorleistung anzupassen.
Dies ermöglicht eine weitere Energieeinsparung.
Der Banias-Kern wurde mit einer Strukturbreite von 130nm gefertigt. Je nach Version
gab es Taktraten von 1.3 bis 1.7 GHz. Dabei hatte die 1,7 GHz Version eine
Leistungsaufnahme von 24,5 Watt TDP.
Vertrieben wurde der Banias-Prozessor unter den Handelsnamen Pentium M bzw.
Centrino, bis er vom Prozessor mit dem Codenamen Dothan abgelöst wurde.
Dieses Kapitel basiert überwiegend auf "Intel enthüllt den Banias" von Christian
Vilsbeck [Banias-Architektur] und "A Look at Centrino's Core" von Jon Hannibal
Stokes [A Look at Centrino].
Seite 6 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
3.2. Weiterentwicklung Codename: „Dothan“
Abbildung 2: Dothan-Kern [Dothan]
Der Dothan-Core ist der Nachfolger des Banias. Hier wurden einige Dinge geändert:
Die Strukturbreite wurde auf 90nm reduziert. Daher war es auch möglich, die Größe
des Level-2 Caches auf 2 MByte zu erhöhen und die Die-Größe nahezu
beizubehalten. Der L2-Cache ist 4-fach assoziativ. Die Prozessortaktrate wurde auf
bis zu 2 GHz erhöht. Die geringere Fertigungstechnik ermöglicht es unter anderem
auch, dass die Leistungsaufnahme bei 1,7 GHz auf 21 Watt TDP gegenüber dem
Banias mit 24 Watt TDP gesenkt werden konnte.
Es wurde ein so genannter Enhanced Data Prefetcher integriert. Dieser lädt
vorausschauend Daten in den L2-Cache, die demnächst benötigt werden.
Die Geschwindigkeit des Front-Side-Bus wurde auf 533 MHz erhöht. Daher
unterstützt der Dothan-Prozessor nun auch DDR2-Arbeitsspeicher.
Der Dothan-Prozessor wird unter den Handelsnamen Pentium M bzw. Centrino
vertrieben.
Dieses Kapitel basiert überwiegend auf "Intel Centrino im Detail" von Christian
Vilsbeck [Centrino Detail].
3.3. Dual-Core Prozessor “Yonah”
Der Dual-Core-Prozessor “Yonah” besteht im Wesentlichen aus zwei “Dothan”-
Kernen. Diese verfügen jedoch über einen gemeinsamen Level-2 Shared Cache, der
2 MByte groß ist.
Beide Kerne sind in der Lage bei Bedarf den ganzen Cache zu nutzen. Dies ist z.B.
sinnvoll, wenn Programme in nur einem Thread laufen. Die „Data Sharing“ Funktion
des Caches ermöglicht es, dass Daten, die von beiden Ausführeinheiten benötigt
werden, nur einmal gemeinsam im Cache abgelegt werden.
Seite 7 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 3: Yonah-Kern [Yonah]
Dass dieser Shared-Cache auch nachteilig sein kann, werden wir im späteren
Verlauf genauer aufzeigen.
Der Yonah-Kern wird in 65nm Technik gefertigt. Dies reduziert den Energiebedarf, da
die Leckströme verringert werden konnten und die Kernspannungen gesenkt wurden.
Für den Dual-Core Prozessor ist eine Leistungsaufnahme von 31 Watt TDP
angegeben.
Weitere Energiesparmaßen wurden integriert. So kann z.B. der Inhalt des Caches
komplett in den Arbeitspeicher geladen werden, wenn beide Kerne keine
Berechnungen durchführen. Die Versorgungsspannung des Caches kann dann
abgeschaltet werden. Diese Funktion nennt Intel „Enhanced Deeper Sleep“.
Die Abschaltung momentan nicht genutzter Bereiche des Caches im Betrieb
funktioniert genauso wie schon bei der Banias - Architektur. Der CPU Lüfter wird von
einem Baustein gesteuert, der die Prozessortemperatur stetig überwacht.
Die Decodierungseinheiten des Yonah-Kerns können nun direkt die 128-Bit langen
SSE2-Befehle verarbeiten. Die Micro-Ops Fusion funktioniert nun ebenfalls auch für
sie.
Der Yonah-Kern unterstützt die neuen Befehle der SSE3. Diese sind wesentlich für
komplexe Arithmetik, Wandlung von Gleitpunktzahlen in Ganzzahlen und Grafik-
Aufbereitung.
Die Abarbeitung von Divisionen von Integer-Daten wurde ebenso wie einige SSE2-
Befehle um ca. 30 Prozent beschleunigt. Wie dies erreicht wurde, ist jedoch nicht
bekannt. Darüber hinaus wurde beim Yonah die Geschwindigkeit bei Integer-
Divisionen deutlich erhöht, vorausgesetzt der Betrag von Dividend und Divisor liegen
nahe beieinander.
Die Geschwindigkeit des Front-Side-Bus wurde nochmals erhöht. Sie beträgt nun
667 MHz.
Vermarktet wird der Prozessor unter dem Handelsnamen Intel Core Duo.
Dieses Kapitel basiert überwiegend auf dem c't Artikel "Doppeltes Lottchen" von
Jürgen Rink [Doppeltes Lottchen], sowie dem Online-Artikel "Intels „Core Solo“ und
„Core Duo“, Ein Neuanfang?" von ComputerBase [ComputerBase].
Seite 8 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
3.4. Intel Core 2 Duo / Intel Core-Mikroarchitektur
Abbildung 4: Merom-Kern [Merom]
Im Herbst 2006 wurde die neue Intel Mikroarchitektur eingeführt. Dabei wurde die
Entwicklung der Bereiche Server, Workstation und Mobile wieder zusammengeführt.
Der mobile Prozessor trägt den Codenamen „Merom“.
Hier wurden einige neue Funktionen, aber auch bereits existierende Funktionalitäten
aus anderen Prozessorfamilien integriert. Intel stellt diese unter sehr fragwürdigen
bzw. teilweise unpassenden Namen dar.
„Wide Dynamic Excetution“ beschreibt im Wesentlichen das Ziel, immer mehr
Befehle pro Cycle zu verarbeiten. Dahinter verbergen sich drei Funktionen: Die
Micro-Ops Fusion ist bereits vom Banias bekannt. Dazu wurde eine Macro-Op
Fusion eingeführt. Die komplexe Decodereinheit ist in der Lage, zwei x86-Befehle in
einem Takt zu decodieren. Dabei muss es sich jedoch um einen Vergleich sowie um
einen Verzweigung handeln. Diese Kombination ist sehr häufig bei IF-THEN-ELSE
Anweisungen. Da beim Merom drei einfache Decodereinheiten sowie ein komplexer
Decoder vorhanden sind, ist der Prozessor unter idealen Bedingungen in der Lage,
fünf x86-Befehle pro Cycle zu verarbeiten.
Der Extended Stack Pointer bildet die dritte Funktion. Dabei handelt es sich um einen
dedizierten Baustein, der Stackpointer-Befehle bearbeitet. Diese wurden früher von
einer Integer-ALU bearbeitet. Laut Intel wurde der ESP, der bereits im Pentium M
zum Einsatz kam, beim Merom um 33% beschleunigt [K-Hardware].
Hinter der Bezeichnung „Smart Memory Access“ verbergen sich zwei
Funktionalitäten, die die Bereitstellung der benötigten Daten optimieren sollen. Bei
der Memory Disambiguation werden load & store Operationen neu sortiert, falls sie
nicht von einander abhängig sind. Dadurch können load-Operationen schneller
ausgeführt werden, weil nicht vorab gewartet werden muss, bis eine sonst
vorhergehende store-Operation abgeschlossen ist. Zusätzlich gibt es nun auch für
den L1-Data-Cache als auch für die Instruktionen Prefetcher-Einheiten.
Seite 9 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Hinter dem pompösen Namen „Advanced Digital Media Boost“ versteckt sich nichts
anderes als die Tatsache, dass der Merom-Kern nun über drei SSE
Ausführungseinheiten verfügt. Diese sind in der Lage, direkt drei 128 Bit SSE
Befehle in einem Takt zu verarbeiten.
Der L2-Data-Cache ist wie schon beim Yonah ein Shared-Cache. Er verfügt nun
jedoch über eine Kapazität von 4 MByte.
Die Entwicklung im Bereich der Energiesparmaßnahmen wurde fortgeführt. Die
Abschaltung nicht verwendeter Teile des Prozessors wurde verfeinert. So können
nun Bereiche des Datenpfades abgeschaltet werden, die nicht benötigt werden, z.B.
wenn die zu transferierenden Daten nicht die gesamte Bitbreite des Datenpfades
benötigen.
Der mobile Prozessor unterstützt nun erstmals die „Extended Memory 64
Technology“. Dabei handelt es sich um eine 64 Bit Erweiterung, die ursprünglich von
AMD entwickelt wurde. Dabei sind 16 Integer - General Purpose Register sowie 16
Register für SSE Befehlserweiterungen 64 bzw. 128 Bit breit.
Diese werden jedoch nur von Anwendungen genutzt, die in 64 Bit betrieben werden.
Bei 32 Bit Anwendungen werden nur wie bisher acht GP-Register verwendet. Zudem
werden nur 32 Bit angesprochen und die 32 High-Bits werden auf 0 gesetzt.
Als weitere neue Funktionalität ist zu nennen, dass der Prozessor nun mit der
Vanderpool - Technologie ausgestattet ist. Dabei handelt es sich um eine
Befehlssatzerweiterung zur Virtualisierungsunterstützung.
Der mobile Prozessor-Kern Merom wird unter dem Handelsnamen Core 2 Duo
vertrieben.
Dieses Kapitel basiert überwiegend auf dem c't Artikel "Vier ist besser als drei" von
Erich Bonnert und Andreas Stiller [Vier besser als drei], dem Online-Artikel
"Intel's Next Generation Microarchitecture Unveiled" von David Kanter [realworldtech]
sowie dem Online-Artikel "Intel Core 2 Duo" von Peter Gräber und Christian Hirsch
[hardtecs4u].
4. Testumgebung
Uns stehen aus der Studentenschaft verschiedene Notebooks zu Testzwecken zur
Verfügung. Für die Benchmarks verwenden wir frei erhältliche Software-Pakete,
sowie selbst programmierte Anwendungen.
4.1. Hardware
Für unsere Untersuchung stehen uns zwei Single-Core sowie zwei Dual-Core-
Systeme zur Verfügung. Die Single-Core Notebooks verfügen über einen „Dothan“-
Kern, „Yonah“ steckt in beiden Dual-Core-Geräten.
Es steht uns kein Dual-Core-System mit dem neuen „Merom“-Kern zur Verfügung.
Seite 10 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Ein Single-Core sowie ein Dual-Core Notebook arbeiten mit einer Taktrate von 1,6
GHz. Zudem führen wir unsere Tests auf einem 2,1 GHz Single-Core
„Dothan“ System mit 2,1 GHz Prozessor-Taktrate, sowie einem 2,0 GHz Dual-Core
„Yonah“ System aus.
Frank Kuchta vs. Markus Hanses
Intel Pentium M 725 Intel Core Duo T2300
Number of cores 1 2
Code Name Dothan Yonah
Technology 90 nm 65 nm
Core Speed 1616.9 MHz 1651.1 MHz
L1 Data cache 32 KBytes, 8-way set 2 x 32 KBytes, 8-way set
associative, 64-byte line size associative, 64-byte line size
L2 cache 2048 KBytes, 8-way set 2048 KBytes, 8-way set
associative, 64-byte line size associative, 64-byte line size
Instruction sets MMX, SSE, SSE2 MMX, SSE, SSE2, SSE3
Memory DDR - 1280 MBytes DDR2 - 2048 MBytes
168.4 MHz 264.2 MHz
Windows Version Microsoft Windows XP Home Microsoft Windows XP Home
Edition Service Pack 2 Edition Service Pack 2
Der Intel Pentium M verfügt nur über DDR Memory, der deutlich langsamer getaktet
ist.
Holger Wolf vs. Markus Rüger
Intel Pentium M 770 Intel Core Duo T2500
Number of cores 1 2
Code Name Dothan Yonah
Technology 90 nm 65 nm
Core Speed 2131.5 MHz 1999.4 MHz
L1 Data cache 32 KBytes, 8-way set 2 x 32 KBytes, 8-way set
associative, 64-byte line size associative, 64-byte line size
L2 cache 2048 KBytes, 8-way set 2048 KBytes, 8-way set
associative, 64-byte line size associative, 64-byte line size
Instruction sets MMX, SSE, SSE2 MMX, SSE, SSE2, SSE3
Memory DDR2 - 1024 MBytes DDR2 – 2048 MBytes
266.4 MHz 333.2 MHz
Windows Version Microsoft Windows XP Microsoft Windows XP
Professional Service Pack 2 Professional Service Pack 2
Der Arbeitsspeicher bzw. der Frontside-Bus des Dual-Core Systems wird mit einer
höheren Taktrate betrieben als der Pentium M. Dieser jedoch weist einen höheren
Prozessortakt als der Core Duo aus.
Die Chipsätze sind bei den verwendeten Systemen verschieden. Ebenso
unterscheiden sich die eingesetzten Festplatten. Deshalb führen wir die
Seite 11 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Testprogramme von einer USB-Festplatte aus, um überall annähernd gleiche
Festplattenbedingungen herzustellen.
Aufgrund der unterschiedlichen Hardware erwarten wir Auswirkungen auf unsere
Messergebnisse.
4.2. CPU-Z
Das Tool CPU-Z [CPU-Z] ist ein Freeware-Programm von Franck Delattre. Es gibt
detaillierte Information über die Hardware des Computers aus, z.B. die Daten des
Prozessors, der Caches, des Speichers, des Chipsatzes oder des Betriebsystems.
Wir verwenden CPU Z, um die Daten unserer Testgeräte auszulesen. Dies
ermöglicht es uns, die Ergebnisse unserer Tests besser deuten zu können. Die
ausführlichen Reports befinden sich im Anhang 8.1.
5. Benchmarks
Ein genereller Vergleich zwischen Single- und Dual-Core Prozessoren ist schwierig
und wenig aussagekräftig. Denn häufig haben sich durch die Weiterentwicklung auch
weitere Bausteine im Gesamtsystem geändert.
Zudem wird im Umfeld der ursprünglichen x86-Architektur inzwischen in
verschiedene Richtungen bezogen auf die Anwendungsgebiete (Mobile, Workstation,
Server, Home - Entertainment, Games) die Entwicklung voran getrieben.
Wir vergleichen daher Prozessoren miteinander, die für den mobilen Einsatz
entwickelt wurden. Die Anforderungen sind nach wie vor dieselben: energieeffizient
aber leistungsfähig für das mobile Arbeiten.
5.1. Vorbetrachtung
5.1.1. Software
Als Betriebsystem für unseren Test verwenden wir Windows XP Service Pack 2,
Home und Professionell Edition. Diese Versionen sind auf den uns vorliegenden
Systemen bereits installiert. Zudem verfügen wir nicht über ausreichend Erfahrung im
Linux/Unix-Umfeld um in der kurzen Zeit ähnliche Tests auf einem derartigen System
durchführen zu können.
Im Bereich der Notebooks verfügt Windows XP als Betriebsystem über den größten
Marktanteil. Bezogen auf unsere Zielsetzung, die Fragestellung der Anwender zu
beantworten, erscheint uns diese Wahl daher als richtig.
Windows XP unterstützt mehrere Prozessoren. Es ist jedoch nicht bekannt, wie diese
behandelt werden. In Normalfall verteilt Windows XP eigenständig verschiedene
Seite 12 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Threads auf die einzelnen Prozessoren. Nach welchen Regeln dies erfolgt, ist nicht
offen gelegt.
Der Benutzer hat allerdings die Möglichkeit, sich anzeigen zu lassen, welcher
Prozess aktuell auf welchem Core läuft. Dabei ist es möglich, nachträglich für einen
laufenden Prozess über den Task-Manager auszuwählen, welche CPU’s dieser
verwenden darf. Die c’t entwickelte zudem das Tool „Launch.exe“ [Doppeltes
Ottchen]. Mit diesem Programm kann der Benutzer vorab die Prozessoraffinität sowie
die Prioritätsklasse für ein Programm definieren.
5.1.2. Anwendertests
Computerzeitschriften führen in regelmäßigen Abständen Anwendertests durch, um
die aktuell verfügbare Hardware zu vergleichen. Dabei werden häufig Werkzeuge
eingesetzt, z.B. PCMark 05, SiSoft Sandra 2006 uvm.
Diese Programme führen Testroutinen aus, und vergeben am Ende Punkte, mit
deren Hilfe dann ein Ranking erfolgt. Was genau getestet wird, bzw. wie diese
Testroutinen aussehen, bleibt verborgen.
Wir haben uns daher entschlossen, Anwendertests durchzuführen, die auf einen
praktischen Nutzen schließen lassen. Die Computerzeitschrift c’t hat ähnliche
Testfälle verwendet, um den Beschleunigungsfaktor eines Dual-Core Systems
gegenüber einem Single-Core System zu ermitteln [Zweispänner].
Dabei kam heraus, dass Dual-Core Systeme ungefähr um den Faktor 1,8x schneller
sind, als vergleichbare Single-Core Systeme, vorausgesetzt die Anwendung
unterstützt zwei Threads optimal.
Wir testen das Verhalten bei der Kompression von Daten, Umwandeln eines Videos
sowie eines Musikstückes und das Rendern einer aufwendigen Grafik.
5.2. Kompression
Wir vergleichen das Komprimieren einer großen Video-Datei. Dazu verwenden wir
das Programm WinRAR der ROG GmbH, welches uns in der Shareware-Version zur
Verfügung steht [WinRAR]. Dies ist vor allem damit zu begründen, dass andere
Kompressionsprogramme wie z.B. Winzip 9.0 keine Threads unterstützen.
In den Release Notes von WinRAR finden wir drei interessante Aspekte:
WinRAR - Was ist neu in dieser Version?
Version 3.61
1. Es wurde ein Fehler im Textkompressionsalgorithmus für
Mehrprozessorsysteme korrigiert, der unter gewissen Umständen zu
fehlerhaften Archivdaten führen konnte.
Dieser Fehler trat nur in WinRAR 3.60 bei angeschaltetem Mehrprozessormodus
auf. Andere RAR-Versionen waren nicht betroffen.
[...]
Seite 13 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
1. Rechner mit mehreren Prozessoren , Dual-Core-Prozessor und
Hyperthreading werden durch einen optimierten Komprimierungsalgorithmus
besser unterstützt und komprimieren schneller. Die Multithreading-Fähigkeit
ist in den Standardeinstellungen aktiviert und kann dort auch abgestellt
werden. Der Schalter -mt ermöglicht Ihnen in der
Befehlszeilenversion, die gewünschte Anzahl der Threads festzulegen.
[…]
10. Beim Geschwindigkeits- und Hardwaretest kann die Option
"Multithreading" aktiviert werden. So ist ein Vergleich zwischen dem
herkömmlichen und dem für Mehrprozessorbetrieb optimierten
Komprimierungsalgorithmus möglich.
[…]
Als Testdatei wird eine ein ca. 42 MB große Video Datei genommen. Wir haben eine
Multimediadatei gewählt, um den Aufwand der Kompression möglichst hoch,
hingegen die Belastung der Festplatte niedrig zuhalten. Gemessen wird die Dauer
der Kompression in Sekunden. WinRAR bietet mit dem Konsolenkommando
„mt“ die Möglichkeit, die Anzahl der Threads, die verwendet werden sollen,
festzulegen.
Abbildung 5 Kompression Benchmark-Ergebnisse
Die Single Core Systeme zeigten sich unbeeindruckt davon, ob WinRAR mit 1, 2
oder beliebig vielen Threads betrieben wurde. Wohingegen die beiden Dual-Core
Systeme bei dem Vergleich zwischen einem Thread und beliebig vielen Threads
einen Beschleunigungsfaktor von ca. 1,4 aufzeigten. Wir wissen nicht, was jeder
einzelne Thread tut. Daher können wir nur Annahmen machen.
Seite 14 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Beim Komprimieren müssen die Aufgaben ständig neu verteilt werden und nach
Abschluss der Berechnung wieder zusammengeführt werden. Daher war unserer
Meinung nach kein höherer Beschleunigungsfaktor zu erwarten.
Randbemerkung:
Eines der beliebtesten Packer-Tools, das Programm WinZip, bietet selbst in der
neuesten Version leider noch keine Multi-Thread/Core Unterstützung, weshalb
unsere Wahl auf das Programm WinRAR viel.
Beschleunigungsfaktoren:
•
•
•
•
5.3. Audio
Für den Audio Kompressionstest wird das Tool LAME-MP3, in der derzeit neuesten
Version 3.97 verwendet [LAME]. Wegen der hohen Qualität wird der LAME
Quellcode häufig in Freeware-Programmen verwendet.
Abbildung 6: Screenshot von LAME
Es wird eine ca. 40 MB große WAV-Datei in eine MP3-Datei mit 128 kbit/s
umgewandelt. Gemessen wird die Zeit, die der Prozess von LAME auf der CPU
benötigt hat. Diese Zeit wird von dem Programm, wie in Abbildung 6 zusehen ist,
ausgewiesen.
Seite 15 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 7: Audio Benchmark-Ergebnisse
LAME MP3 konvertiert lediglich in einen Thread. Daher ergibt sich kein
bemerkenswerter Geschwindigkeitsvorteile aufgrund des Vorhandenseins von zwei
Kernen. Abbildung 7 zeigt die Ergebnisse im Detail. Wir verzichten hier darauf, die
Beschleunigungsfaktoren aufzuführen.
5.4. Video
VirtualDub ist ein kostenloser Video-Editor mit vielen Funktionen [VirtualDub]. Er ist
deshalb sehr weit verbreitet.
Wir wollen ein Video komprimieren und die Zeit messen. Unser Testvideo ist 5,3 MB
groß. Es ist bereits vorkomprimiert; unkomprimiert würde es ca. 900 MB groß sein.
Xvid ist ein Open-Source MPEG-4 Video Codec, der auf den Sourcen des
ursprünglichen DivX Codec basiert. Er ist sehr populär, und viele Videos verwenden
diesen Codec. Wir entschließen uns daher zunächst, unser Testvideo mit Xvid zu
komprimieren.
Seite 16 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 8: Video Benchmark-Ergebnisse
Die Ergebnisse überraschen uns. Alle Testsysteme benötigen zum Komprimieren im
Schnitt zwischen 38 und 30 Sekunden. Gerade hier hätten wir einen deutlichen
Vorteil der neuen Technologie erwartet. Zumal Video-Bearbeitung häufig als
praktischer Anwendungsfall für leistungsstarke Systeme genannt wird.
Der Blick in die Sourcen von Xvid verrät uns, dass dieser Codec in nur einem Thread
arbeitet. Somit ergeben sich hier nur sehr minimale Vorteile für ein Dual-Core-
System, nämlich die, dass andere Anwendungen sowie das Betriebsystem auf dem
zweiten Core arbeiten können und somit die Ausführung der Komprimierung nicht so
stark beeinflussen wie auf einem Single-Core-System.
Aufgrund dieses Ergebnisses führen wir einen zweiten Test durch, nun mit dem
Windows Media Video Codec 9. Diesen rufen wir ebenfalls mit VirtualDub auf.
Beschleunigungsfaktoren WMV Codec:
•
•
Der WMV Codec scheint die Komprimierung auf mehrere Threads aufzuteilen,
sodass beide Kerne ausgenutzt werden. Dadurch ergeben sich
Beschleunigungsfaktoren von 1,86 bzw. 1,76, was sich mit unseren Erwartungen
deckt.
Seite 17 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
5.5. Grafik Rendering
Die Firma Maxon, die die Grafiksoftware CINEMA 4D vertreibt, stellt einen speziellen
Benchmark kostenfrei zur Verfügung [CINEBENCH]. CINEBENCH 9.5 basiert dabei
auf der 3D Bearbeitungssoftware.
Die Engine von CINEMA 4D zeichnet sich dadurch aus, dass sie nach eigenen
Angaben mehrere Prozessoren bzw. Kerne optimal ausnutzt. Im Bereich Grafik-
Rendering wird dazu das gesamte Bild in zwei Teile aufgeteilt und diese werden
jeweils von einem Thread gerendert. Im Beispiel von Cinebench ist dabei der erste
Thread auf einem Dual-Core-System deutlich früher fertig, als der zweite. Deshalb
wird das verbleibende Teilstück des zweiten Threads wieder in zwei Teile zerlegt und
an separate Threads vergeben. Dass der erste Thread deutlich schneller mit seiner
Aufgabe fertig ist, hängt von verschiedenen Faktoren ab. Zum einen liegt auf dem
einen Prozessorkern das gesamte Betriebsystem, zum anderen verfügt die
verwendete Grafik über aufwendige Texturen im mittleren Bereich.
Abbildung 9: Cinebench Benchmark-Ergebnisse
Cinebench arbeitet genauso wie fast alle anderen erhältlichen Benchmark-Tools mit
einem eigenen Messwert. Dieser nennt sich „CB-CBL“. In der Dokumentation finden
wir dazu keine genauen Informationen. Es wird bloß angegeben, dass dieser Wert
multipliziert mit 10 ungefähr den Prozessortakt ergeben sollte. Da diese Angabe
keinesfalls stimmt, und uns dieser Wert nicht aussagekräftig genug erscheint,
entschließen wir uns dazu, hier die Zeit zu messen, bis die Grafik vollständig
gerendert ist.
Die Anwendung erkennt, ob es sich um ein Dual-Core System handelt. Entsprechend
ist es auch nur auf diesen möglich, die Grafik in zwei Threads zu rendern.
Die Testergebnisse sind nicht überraschend aber erstaunlich. So übertreffen die
Beschleunigungsfaktoren dieser Tests den Daumenwert von 1,8 doch teilweise
deutlich.
•
Seite 18 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
•
•
•
Gegenüber den Single-Core Systemen weisen die Dual-Core Maschinen eine
deutliche Beschleunigung auf. Zum einen natürlich durch die Aufteilung der Aufgabe
auf zwei Kerne, zum anderen aber auch durch eine bessere Anbindung des
Arbeitsspeichers. Die Effizienz der Aufteilung der Aufgabe alleine sieht man sehr
deutlich im Vergleich 1 Thread gegen 2 Threads auf den Dual-Core-Systemen mit
einem Beschleunigungsfaktor von 1,82 bzw. 1,83. Das Rendern einer Grafik eignet
sich also sehr gut, um es auf mehrere Berechnungseinheiten aufzuteilen.
5.6. RSA Benchmark
Die folgenden eigenen Programme sind alle in C#2005 implementiert [C#]. Der
Compiler erstellt ähnlich wie Java ein Bytecode, der in einer Runtime ausgeführt wird.
C# bietet zwei Einstellungen für Compiler-Optimierungen: keine, und volle
Optimierung mit SSE und SSE2. Für Zeitmessungen bietet C# eine Auflösung von
10ns, was deutlich genauer ist als bei Java.
Beim RSA Benchmark besteht die Aufgabe darin, einen gegeben Text zu
verschlüsseln bzw. zu entschlüsseln. Dabei messen wir die benötigte Zeit.
Der Programm wird mit festgelegten Parametern ausgeführt: Die Primzahlen p und q
sind dabei jeweils 128 Bit lang.
• p = 272841391209158082973553771691834107803
• q = 204529522774722087416736679430142573943
Mit p * q wird n bestimmt.
• n=
55804119537200356864262710503223737361364815547930284919191499
161941360777229
Der öffentlichen Schlüssel e ist ebenfalls 128 Bit lang. Der Wert ist random, jedoch
muss ggT(e, φ(n)) = 1 erfüllt werden.
• e = 299959329779933941214908800093326386487
Seite 19 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Der geheime Schlüssel d wird errechnet, so dass e*d = 1 mod φ(n)
• d=
52697171591031710974197215140234759556016669833013983138526341
286792399231215
Als Text zum Verschlüsseln und anschließenden Entschlüsseln wird das Dokument
Heath.pdf als Text-Datei (833kb) verwendet.
Getestet wird in einer 1- und 2-Thread-Variante. In der 2-Thread-Variante wird der zu
verschlüsselnde String in zwei gleiche Hälften geteilt und beide Threads werden mit
dem Verschlüsseln „beauftragt“. Die Größe der Hälften und die Blocklänge wurden
dabei so gewählt, dass kein Padding erforderlich war.
Da uns diese Aufgabe als geeignet für die Aufteilung auf zwei Threads erscheint,
erwarten wir einen Beschleunigungsfaktor im Bereich von 1,8.
Implementiert wurde der RSA-Benchmark in C# 2005, ohne Compiler Optimierung.
Abbildung 10: RSA Benchmark-Ergebnisse
Bereits bei 1-Thread Encoding zeigt sich ein großer Abstand zwischen den Single
Core und Dual Core Prozessoren. Bei den 1,6 GHz Prozessoren noch größer als bei
den 2,1GHz und 2,0 GHz Prozessoren. Im Vergleich zu den vorherigen Tests, wird
bei diesem Testfall deutlich intensiver auf den Speicher zugegriffen. Der Zugriff
erfolgt hierbei nicht linear, sodass wahrscheinlich vorhandene Mechanismen wie z.B.
intelligente Prefetcher nicht optimal arbeiten können. Zudem verfügen die Single-
Core-Systeme über einen deutlich langsameren RAM.
Ein direkter Vergleich zwischen den Single-/ und Dual Core Systemen ist daher bei
diesen Tests nicht sinnvoll, wird aber zur Vollständigkeit aufgeführt.
•
Seite 20 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
•
•
•
Die Beschleunigungsfaktoren bei den Dual-Core-Systemen (das Verhältnis von 1-
zur 2-Thread-Variante), liegen im Bereich der zuvor prognostizierten Erwartungen
(1,6 – 1,8).
•
•
•
•
5.7. Zwischenbetrachtung
Wir haben nun vier Testfälle durchgeführt. Beide Notebooks mit Dual-Core-Prozessor
waren dabei immer schneller als die Rechner mit nur einem Kern.
Dabei ist uns aufgefallen, dass es im wesendlichen darauf ankommt, ob eine
Anwendung die zu erledigende Aufgabe aufteilt und an zwei Threads delegiert, oder
eben nicht. Kann man also sagen, dass eine Anwendung sobald sie Threads
verwendet auf einem Dual-Core System deutlich schneller ist als auf einem mit nur
einem Kern?
Wir wollen dieser Frage auf den Grund gehen und nachfolgend versuchen, mit
eigenen Programmen uns den möglichen Schwachstellen der Dual-Core-
Prozessoren zu nähern.
5.8. SyncAccess
Mit dem Programm SynAccess versuchen wir, den Vorteil des Dual-Cores, dass zwei
Threads zur selben Zeit laufen können, als Nachteil auszulegen.
Dabei nutzen wir einen klassischen Anwendungsfall: der gleichzeitige Zugriff von
zwei Anwendungen auf eine gemeinsame Ressource, bekannt als das Producer/
Consumer Problem aus der EBS-Vorlesung.
Seite 21 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Zwei Threads greifen jeweils in einer Schleife ständig auf die globale Variable
SharedMem zu. Mit dem Befehl lock (block)wird der Zugriff auf die Variable
SharedMem exklusiv für den bearbeitenden Thread reserviert und erst nach
Verlassen des Bereiches wieder für andere Threads freigegeben. Die
mathematischen Operationen sind zufällig gewählt und sollen eine beliebe
„zeitverbrauchende“ Aufgabe darstellen. Die Variable SharedMem wird nach
Abschluss der Messung ebenfalls ausgegeben, um eine automatische Compiler-
Optimierung der Schleife zu verhindern.
for (long i = 0; i < n; i++)
{
lock (block)
{
SharedMem *= 5;
SharedMem = Math.Pow(SharedMem, 63);
SharedMem /= 3;
SharedMem = SharedMem % 99999;
}
}
Dieses Programm wurde implementiert in C# 2005, ohne Compiler-Optimierung.
Gemessen wurde die Dauer, bis beide Threads ihre Aufgabe erledigt hatten.
Abbildung 11: SyncAccess Benchmark-Ergebnisse
Beschleunigungsfaktoren:
•
•
Seite 22 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Obwohl beide Kerne der Dual-Core-Systeme voll belegt wurden, benötigten die
Systeme bei diesem Benchmark länger als die Single-Core-Notebooks zur
Abarbeitung der Aufgaben.
Dies liegt in erster Linie daran, dass der blockierte Prozess im „busy waiting“ Modus
(zyklische Abfrage eine Variable) verweilt. So muss dieser ständig abfragen, ob die
Ressource frei ist. Ebenso muss bei Freigabe der Ressource ein notify an den
anderen Thread erfolgen. Sobald dies geschehen ist, greift sich der zweite Thread
die Ressource, und der erste Thread, der nun wieder die Schleife durchläuft, wird
blockiert.
Auf dem Single-Core-System läuft während eines Zeitscheiben-Zyklus nur ein
Thread. Dieser blockiert die gemeinsame Ressource und durchläuft die Schleife
mehrere Male. Entweder erfolgt nun der Prozesswechsel nach Freigabe der
Ressource oder gerade während sie blockiert ist. Im zweiten Fall würde der zweite
Thread einen Zyklus warten müssen, denn die Ressource ist dann ja belegt. Es lässt
sich nur spekulieren, wie das System dies handhabt. Die Ergebnisse zeigen jedoch
deutlich, dass dies in jedem Fall immer noch wesentlich besser funktioniert als auf
dem Dual-Core-System, wo beide Threads zeitgleich aktiv sind.
Seite 23 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
5.9. DualSlow
Wir wollen nun einen Fall konstruieren, bei dem wir die Schwächen des Shared-L2-
Caches aufzeigen möchten. Intel’s Marketing-Maschine verkauft den gemeinsam
genutzten Cache als Performance Vorteil.
Grundsätzlich verfügen alle unsere Testsysteme über einen L2-Cache mit einer
Kapazität von 2048 KBytes. Dieser ist 8-fach assoziativ, eine Cacheline ist 64Byte
lang.
"Prozessoren der IA-32 Architektur nutzen physikalisch indizierte Caches, das heißt,
Teile der physikalischen Adresse werden für die Set-Auswahl im Cache
herangezogen." Zitat Alexander von Bülow, "Optimale Cache-Nutzung für
Realzeitsoftware auf Multiprozessorsystemen", Abschnitt 3.3.2 Cache-Architekturen,
Seite 24 [Cache].
Frei nach der Hypothese, „Aufgaben auf Threads aufzuteilen“ schreiben wir ein
Programm mit zwei Threads. Dabei greift jeder Thread auf seine eigenes Daten-
Array zu. Es gibt also keine Abhängigkeit bzw. Blockade einer Ressource im
Programm. Der Shared-Cache als auch der Systembus und Arbeitsspeicher stellen
jedoch immer noch gemeinsame System-Ressourcen dar, um die beide Threads
konkurrieren.
Das Daten-Array ist 64Byte breit und variable lang.
int[,] Datenfeld1 = new int[DatenfeldGroesse, 16];
Wir wollen vermeiden, dass es zu Cache-Hits aufgrund von räumlicher Lokalität
kommt. Daher greifen wir alle 65 Byte auf ein Array-Feld zu, und schreiben diesen
Integer-Wert weitere 65 Byte weiter.
Wenn das gesamte Datenfeld durchlaufen wurde, wird der Vorgang n mal wiederholt,
um in den nächsten Durchläufen Cache Hits aufgrund von zeitlicher Lokalität zu
erreichen.
for (int j = 0; j < n; j++)
{
for (int i = 0; i < DatenfeldGroesse; i = i + 2)
{
Datenfeld1[i, 0] = Datenfeld1[i + 1, 0];
}
}
Der gesamte Test wird mit unterschiedlichen Längen des Datenfeldes wiederholt, um
die benötigte Zeit in Abhängigkeit der Datengröße pro Thread aufzeigen zu können.
Seite 24 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 12: DualSlow-Benchmark, Datenfeldgröße bis 2000kByte
In Abbildung 12 sieht man, dass beide Single-Core-Systeme (rot & blau) bei
ansteigender Datengröße eine lineare Steigung aufweisen.
Bis zu einer Datenfeldgröße von ca. 1000KByte pro Thread ist dies auch bei den
Dual-Core-Systemen (grün & lila) zu beobachten. Sie sind jedoch schneller als die
Systeme mit nur einem Kern.
Wenn wir eine Datengröße über 1000KByte pro Thread wählen, ist ein extremer
Anstieg bei der benötigten Zeit zu beobachten. Bei einer Datengröße von ca.
1700KByte pro Thread sind unsere Single-Core-Systeme ca. viermal schneller als
unsere Systeme mit zwei Kernen.
Um dieses Verhalten genauer untersuchen zu können, messen wir nach jedem
Schleifendurchlauf die Zeit. Wir erhalten also n Messwerte. Durch das Messen der
Zeit verändern wir unseren Testfälle. Diese Veränderung hatte jedoch keine
gravierende Auswirkung auf unser Testergebnis.
Wir wählen n = 20.000 Schleifendurchläufe für unsere Tests.
In Abbildung 13 werden die absolvierten Schleifendurchläufe in Abhängigkeit zu der
benötigten Zeit dargestellt. Dabei werden der 1. und der 2. Thread des 2,0 GHz Dual-
Core Systems rot bzw. grün dargestellt. Im Vergleich dazu der 1. und der 2. Thread
des 2,1 GHz Single-Core Systems in den Farben blau und lila.
Seite 25 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 13: DualSlow: absolvierte Schleifendurchläufe / Zeit (1)
Abbildung 14 zeigt den Zeitabschnitt bis 1 Sekunde nach Start. Dort ist sehr deutlich
zu sehen, dass das Single-Core-System die beiden Threads in Zeitscheiben á 50 ms
abarbeitet. Die Zeitauflösung beträgt 1ms.
Seite 26 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 14: DualSlow: absolvierte Schleifendurchläufe / Zeit (2)
Single Core:
Während eines Zeitscheiben-Zyklus steht dem laufenden Prozess die gesamte
Kapazität des L2-Caches alleine zur Verfügung. Bis zum nächsten Prozesswechsel
schafft der Prozess ca. 300 Schleifendurchläufe. Beim ersten Schleifedurchlauf
kommt es zu Cache-Misses. In diesem Zuge wird das gesamte Datenfeld nach und
nach in den Cache geladen. Bei allen weiteren Schleifendurchläufen erhalten wir nun
Cache-Hits aufgrund von zeitlicher Lokalität.
Dual Core:
Beide Threads laufen hier parallel. Somit verwenden gleichzeitig beide Prozesse den
Cache für ihre jeweiligen Daten. Da jeder Prozess ca. 1,7 MByte in den Cache lädt,
überschreiben sich die beiden Prozesse die Daten ständig gegenseitig.
Dadurch müssen in jedem neuen Schleifendurchlauf die Daten erneut aus dem RAM
gelesen werden. Ebenso muss für den Fall, dass modifizierte Daten aus dem Cache
verdrängt werden, ein Write-Back erfolgen. Dadurch ergibt sich eine extreme
Verzögerung.
Hier spielt das Single-Core-System den Vorteil aus, dass dem Prozess die gesamten
2 MByte Cache exklusiv während des Zeitscheiben-Zyklus zur Verfügung steht.
Übersteigt nun die Größe des Datenfeldes die 2 MByte-Marke, werden ebenfalls
Teile des Datenfeldes verdrängt, die später wieder benötigt werden. Dies ist in
Abbildung 15 dargestellt. In diesem Fall spielen die Dual-Core-Systeme nun wieder
Ihren Vorteil aus; sie verfügen über eine schnellere Anbindung des Arbeitsspeichers.
Seite 27 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Abbildung 15: DualSlow-Benchmark, Datengröße bis 3000kByte
Seite 28 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
6. Fazit
Wir haben in unseren Tests deutlich gesehen, dass die Effizienz eines Dual-Core
Systems deutlich davon abhängt, wie die verwendete Anwendung programmiert
wurde.
Die Software-Entwickler sind also aufgefordert, die Anwendungen, soweit möglich, zu
parallelisieren. Dass hier besonders bedachtsam vorgegangen werden muss,
konnten unsere letzten zwei Testfälle deutlich zeigen.
Viele Anwendungen sind leider derzeit nicht in mehreren Threads programmiert,
sodass sich hier kaum ein Geschwindigkeitsvorteil ergibt.
Dazu zählen z.B. Virenscanner, Grafik-Programme wie z.B. der „Wohnzimmer
Designer“ oder „Paint Shop“ sowie Google Earth und die meisten auf dem Markt
verfügbaren Spiele [Zweispänner].
„Word, Excel, OpenOffice und Co. treiben einen modernen Einzelprozessor
normalerweise nicht an die Grenze seiner Leistung, dennoch kommt hier ebenfalls
Multithreading zum Einsatz. Das klassische Office-Beispiel ist die im Hintergrund
laufende Rechtschreibkorrektur, diesen zusätzlichen Thread arbeitet jedoch auch ein
aktueller Einzelprozessor spielend mit ab, wenn gerade mal Zeit ist.“ Zitat von Nico
Nowarra, Joachim Sauer, Andrea Trinkwalder [Zweispänner] Abschnitt: Dualer Alltag
Grundsätzlich lässt sich auch sagen, dass der Aufbau von Internetseiten oder das
Versenden von E-Mail Nachrichten nicht von der Prozessorgeschwindigkeit oder dem
Vorhandensein eines Dual-Core Prozessors abhängen sondern viel mehr von der
Internetverbindung. Etwaige Marketing-Aussagen von Prozessor-Herstellern sollte
man also sehr kritisch begutachten.
Nichts desto trotz profitiert der Benutzer von einem Dual-Core-System. Werden z.B.
viele Dinge zur selben Zeit gemacht, wie z.B. das Abspielen eines Videos und
gleichzeitig das Durchführen eines Virenchecks im Hintergrund, so werden diese
Anwendungen auf die Kerne verteilt. Die Video-Applikation ist in diesem Fall in der
Lage, auf dem zweiten Kern zu arbeiten während auf dem ersten Kern das
Betriebsystem sowie der Virenscanner aktiv sind.
Abbildung 16: Preisübersicht aktueller Notebooks [Saturn]
Seite 29 von 39Frank Kuchta, Markus Rüger single vs. dual core RST-L WS06/07
Wie in Abbildung 16 zu sehen ist, betragen die Mehrkosten für ein Notebook mit
Dual-Core-Prozessor in diesem Beispiel von Saturn nur 27%. Dieser Vergleich hinkt
etwas, da man eigentlich die gesamte Ausstattung der Geräte betrachten müsste.
Jedoch zeigt es, dass die Preise derzeit deutlich gefallen sind, was auch darauf
zurück zu führen ist, dass bereits nach nur einem halben Jahr der Core 2 Duo den
Dual-Core der ersten Generation abgelöst hat.
Einsteiger haben dadurch die Möglichkeit, preislich reduzierte Pentium M bzw.
Centrino Geräte sowie Duo Core’s der ersten Generation zu erhalten. Für Leute, die
öfter mit mehreren Anwendungen zur selben Zeit arbeiten, ist es in jedem Fall
empfehlenswert, ein Dual-Core-System auszuwählen.
Abbildung 17: Preisübersicht Intel mobile Prozessoren [alternate]
Wir dürfen gespannt sein, was die Zukunft auf dem Notebookmarkt bringen wird.
Beim Pentium 4 hat man gesehen, dass die Erhöhung der Taktrate nur bedingt
geeignet ist. Die Bitbreite der Ausführungseinheiten wurde inzwischen auf 128 Bit
erhöht. Jedoch wird dies nur von sehr wenigen Befehlen genutzt. Auch eine
Erweiterung des Befehlssatzes um häufig genutzte Funktionen wie z.B. bei SSE
bringt nur bedingt eine Performance-Verbesserung, da viele Anwendungen diese
nicht unterstützen.
Die Einführung der Dual-Core Systeme hat einen deutlichen Leistungsgewinn unter
bestimmten Bedingungen verursacht. Eine weitere Verdoppelung wird in Zukunft nur
schwer möglich sein. Zum einen ist es nur begrenzt möglich, Aufgaben in beliebig
viele Teilaufgaben zu zerlegen, zum anderen muss man sich die Frage stellen, wie
viele Kerne in ein Notebook passen. Der Energiebedarf ist nach wie vor der
wichtigste Aspekt bei einem mobilen System. Immer größere Anstrengungen sind
nötig, um diesen zu reduzieren bzw. auf einem erträglichen Niveau zu halten.
Folglich ist die einzige Konsequenz auf lange Sicht, sich von der bisherigen
Architektur zu verabschieden und eine komplett neue Plattform zu entwickeln.
Seite 30 von 39Sie können auch lesen
