Wer profitiert von 64-Bit Computing?

Wer profitiert von 64-Bit Computing?
Tim Ollmann (153445), Volker Schepker (100870)
Inhaltsverzeichnis
1 Entwicklungsgeschichte
1.1 Die 16-Bit-Architektur . . . . . . .
1.1.1 Der Intel 80286er . . . . . .
1.1.2 Die Modi des 80286ers . . .
1.1.3 Adressierung beim 80286er1
1.2 Die 32-Bit-Architektur . . . . . . .
1.2.1 Der Intel i386er . . . . . . .
1.3 Die 64-Bit-Architektur . . . . . . .
1.4 AMD Athlon64 . . . . . . . . . . .
1.4.1 Der AMD Athlon64 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 32-Bit Befehle auf einer 64-Bit CPU
2
3
3
4
4
6
6
8
8
8
15
3 Benchmarken des AMD Athlon64
3.1 Einrichten des Testsystems . . . . . . .
3.1.1 Das Testsystem . . . . . . . . . .
3.1.2 Gentoo Linux 32 Bit . . . . . . .
3.1.3 Gentoo Linux 64 Bit . . . . . . .
3.1.4 Ablauf der Installation . . . . . .
3.2 Auswahl geeigneter Benchmarks . . . .
3.2.1 Cachebench . . . . . . . . . . . .
3.2.2 NBench . . . . . . . . . . . . . .
3.2.3 SQL-Bench . . . . . . . . . . . .
3.3 Auswertung der Benchmarkergebnisse .
3.3.1 Cachebench . . . . . . . . . . . .
3.3.2 NBench . . . . . . . . . . . . . .
3.3.3 SQL-Bench . . . . . . . . . . . .
3.4 Weitere Auswertung und Anmerkungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
16
17
17
19
19
21
24
25
25
30
36
36
4 Fazit
38
Abbildungsverzeichnis
38
Tabellenverzeichnis
39
Literaturverzeichnis
41
1
Kapitel 1
Entwicklungsgeschichte
Um sich ein Bild von dem aktuell im PC Bereich stattfindenden Umstieg von 32 auf 64 Bit zu
machen, wird ein kurzer Rückblick auf die Entwicklung der x86 kompatiblen Prozessoren geworfen.
Dabei liegt besonderes Augenmerk auf dem Intel 80286er, da er der letzte 16 Bit Prozessor war
und in einigen Bereichen große Ähnlichkeit zum 8086er bestand.
Der nächste zu betrachtende Prozessor wird der Intel i386er. Dieser war im PC Bereich der erste
32 Bit Prozessor. Es wird auf die Änderung in der Architektur sowie Speicheradressierung eingegangen. Was die Prozessorarchitektur betrifft, findet dann ein kleiner Zeitsprung zu den aktuellen
64 Bit Prozessoren statt. Dabei wird das Testobjekt, der AMD Athlon64, erläutert.
Bei der Betrachtung der Entwicklung der x86 Architektur fällt auf, dass aus Gründen der Abwärtskompatibilität eine neue Prozessorgeneration die Funktionen der vorherigen Generation implementiert und um neue Funktionen erweitert. Das bedeutet, dass auf einem Athlon64 immer
noch Programme ausgeführt werden können, welche ursprünglich für den 8086 geschrieben und
kompiliert wurden.
Um die Performanzvorteile eines 64-Bit Betriebssystems im Gegensatz zu einem 32-Bit System
auf einer x86 64-Architektur aufzuzeigen, wurden auf zwei eigens eingerichteten Betriebssystemen
verschiedene Benchmarks durchlaufen, deren Auswahl, Installation und Ausführung in den nachfolgenden Kapiteln näher beschrieben wird. Die Ergebnisse der Benchmarks werden im Anschluß
(so gut wie möglich) analysiert und erklärt.
2
1.1
1.1.1
Die 16-Bit-Architektur
Der Intel 80286er
Um sich ein Bild von einer herkömmlichen 16-Bit-Architektur zu verschaffen, erklären wir nachfolgend die versuchsinhaltsbezogenen Leistungsmerkmale anhand eines 286er der Firma Intel.
Technische Daten:
• Erscheinungsdatum: 1. Februar 1982
• Taktfrequenz: 4-16 MHz
• Adressbusbreite: 24 Bit
• Datenbusbreite: 16 Bit
• Befehlslänge: variabel, ein oder zwei Byte lang, danach keine, eine oder zwei Adressen oder
Immediates mit jeweils ein oder zwei Byte Länge
• Befehlswarteschlange: FIFO, 6 Bytes
• L1/L2 Cache: nicht vorhanden
Das folgende Bild zeigt die Prozessorarchitektur eines Intel 80286, an welchem kurz die Abarbeitung von Befehlen erklärt wird. Da die 80286 Architektur keinen Cache-Speicher besaß, wurden
zu verarbeitende Befehle direkt aus dem RAM geladen und in der Befehlswarteschlange zur weiteren Verarbeitung abgelegt. Nach der Dekodierung (und somit auch Generierung der benötigten
Steuersignale) erfolg nach erneuter Ablage in einer Warteschlange die Verarbeitung des Befehls.
Hierbei werden Steuersignale an die Steuerung gesandt, sowie Datenanteile (Immediates, ...) auf
den internen Datenbus gelegt. Zur Realisierung von Sprüngen ist ein Offset-Addierer (rot) implementiert, welcher mit Registerinhalten, aber auch mit Daten aus der ALU geladen werden kann.
Die Adresseinheit besteht aus 2 Datenpfaden, der obere spiegelt den Pfad des Offsets wider, der
untere ist die Basisadresse für jedes Segment. Der Teil Segmentbegrenzung wird nur im Protected
Mode verwendet.
Abbildung 1.1: Aufbau der 286er Architektur1
1 http://de.wikipedia.org/wiki/80286
3
1.1.2
Die Modi des 80286ers
Der 80286er unterstützt verschiedene Modi:
• Real Mode
• Protected Mode
• System Management Mode
Der Real Mode wird benutzt, um Abwärtskompatibilität zum 8086er zu erzeugen. In diesem Modus
haben Programme kompletten Zugriff auf den Speicher, d.h. ohne Kontrolle, ob es ihnen erlaubt
ist, diesen zu lesen oder hineinzuschreiben. Insgesamt steht im Real Mode 1MiB adressierbarer
Speicher zur Verfügung.
Im Protected Mode werden die Programme in verschiedenen Hierarchieebenen ausgeführt, eine
Ebene kann auf Programmcode und Daten von niedrigeren oder gleichen Ebenen zugreifen, aber
nicht auf eine höhere. Daraus ergibt sich eine Zugriffskontrolle, welche verhindert, dass Programme,
welche fehlerhaft programmiert werden, das ganze Betriebssystem zum Absturz bringen können.
Abbildung 1.2: Ringmodell des Protected Mode2
Der adressierbare Speicher erweitert sich im Protected Mode von ehemals 1MiB auf nun 16MiB,
da der Prozessor einen 24 Bit breiten Adressbus besitzt. Da aber die einzelnen Adressregister nur
16 Bit groß sind, muss ein spezielles Verfahren zum Zugriff auf den Speicher verwendet werden.
1.1.3
Adressierung beim 80286er3
Die Speicheradressierung im Real Mode geschieht folgendermaßen: Die zu ladende Adresse steht in
einem 16 Bit Segmentregister. Dieses wird mit 16 multipliziert (Schieben um 4 Bits nach links) und
dazu dann ein 16 Bit Offset addiert. Daraus entsteht eine 20 Bit Adresse, der Prozessor kann also
220 verschiedene Adressen, oder 1MiB Adressraum ansprechen. Um den kompletten Adressraum
von 16MiB über die um 8 Bit zu kleinen Segmentregister anzusprechen, ist folgende Vorgehensweise notwendig:
Zuerst einmal muss der Prozessor im Protected Mode betrieben werden, nur dann steht der erweiterte Speicherbereich zur Verfügung. Im Real Mode ist man auf 1 MiB festgelegt. In den Segmentregistern steht die Speicheradresse des Segmentdeskriptors, welcher die echte physikalische
Speicheradresse enthält. Zusätzlich dazu enthält der Segmentdeskriptor Informationen darüber,
ob das Segment gelesen oder geschrieben werden kann und zu welcher Hierarchieebene das Segment gehört. Die Adressenbildung mittels Offsetaddierung findet genauso wie beim 8086er statt.
2 http://www.fh-zwickau.de/doc/prmo/pmtutor/text/p
3 [14,
all1.htm
Kapitel 6.2.4, Direct Memory Access (DMA)]
4
Aufgrund der immer noch 16 Bit breiten Register bleibt die Größe eines anzusprechenden Segments
auf 64KiB beschränkt.
5
1.2
1.2.1
Die 32-Bit-Architektur
Der Intel i386er
Technische Daten:
• Erscheinungsdatum: 17. Oktober 1985 (i386DX4 ), 16. Juni 1988 (i386SX5 )
• Taktfrequenz: 16-33 MHz (i386DX) oder 16-25MHz (i386SX)
• Adressbusbreite: 32 Bit (i386DX) oder 24 Bit (i386SX)
• Datenbusbreite: 32 Bit (i386DX) oder 16 Bit (i386SX)
• Befehlslänge: 1-15 Byte
• Befehlswarteschlange: 16 Byte Code + 3 Byte dekodierte Befehle
• L1/L2 Cache: nicht vorhanden
• Register: Zwei zusätzliche Segmentregister, FS und GS
Architektur:6
Der Intel i386DX, später 80386 oder 386er genannt, war der erste für den PC erhältliche 32
Bit Prozessor. Die Erweiterung des Adressbusses auf 32 Bit ermöglichte, physikalisch bis zu 4GiB
RAM anzusprechen (i386SX: 16MiB).
Daher entschied sich Intel, 1988 den wesentlich günstigeren 80386SX zu veröffentlichen, welcher
sich gegenüber dem DX nur in der Anzahl der Adress- und Datenpins unterschied. Durch die
16 Datenpins mussten für jedes 32 Bit Immediate zwei Speicheroperationen ausgeführt werden.
Mit den 24 Adresspins (anstatt den 32 beim DX) konnten maximal 16MiB physikalischer RAM
angesprochen werden. Da aber die RAM Ausstattung Ende der 80er Jahre eh nur im einstelligen
Megabyte Bereich lag, war dies keine wirkliche Einschränkung. Zusätzlich wurde eine Erweiterung
des Protected Mode implementiert, der Enhanced Mode. In diesem war es unter anderem möglich,
mittels Paging virtuellen Speicher anzusprechen.
Da man im 286er ohne größere Probleme nur vom Real Mode in den Protected Mode wechseln
konnte und nicht wieder zurück, erhielt der 386er einen weiteren Modus, den Virtual 8086 Mode. In
diesem Modus konnte man innerhalb einer Protected Mode Umgebung Real Mode Programmcode
ausführen. Der direkte Zugriff auf die Hardware und den Speicher wird hier allerdings abgefangen
und kontrolliert. Daher werden direkte Hardwarezugriffe in diesem Modus langsamer ausgeführt
als im echten Real Mode.
4 Double-word
eXternal, 32 Bit
eXternal, 16 Bit
6 [14, Kapitel 6.2.4, Direct Memory Access (DMA)]
5 Single-word
6
Abbildung 1.3: Aufbau der 386er Architektur7
Die 386er Architektur ist schon wesentlich aufwändiger als die vom Vorgänger, 80286er. Dies
liegt zum Teil an den verschiedenen Erweiterungen, welche vom 80286er übernommen wurden
(Segmentation Unit), respektive neu im 386er implementiert wurden (Paging Unit). Die Segmentation Unit erfüllt die gleiche Aufgabe wie beim 80286er, die Paging Unit versetzt die CPU in die
Lage, virtuelle Adressen anzusprechen.
Der 386er ist ein CISC Prozessor. Zu erkennen ist dies unter anderem an den extrem unterschiedlichen Verfahren, um auf den Speicher zuzugreifen (indirekte Adressierung, Basisadressierung,
registerindirekte Adressierung) als auch an den deutlich unterschiedlich langen Befehlen. Diese
reichen von 1 Byte für Operationen wie z.B. NOP, PUSH/POP oder das Setzen einzelner Flags
bis hin zu 15 Bytes für komplexe Operationen zzgl. Immediates und Präfixes.
Der Umstieg von 16 auf 32 Bit war neben der Möglichkeit, sehr große Mengen Arbeitsspeicher
ansprechen zu können, dadurch geprägt, dass sehr viel Wert auf Abwärtskompatibilität gelegt
wurde. Somit entstand eher ein Prozessorupdate als eine komplette Neuentwicklung. Dies kann
auch vom Umstieg auf 64 Bit erwartet werden. Zusätzlich zu der enorm gewachsenen Menge an
adressierbarem Speicher wird auch dieser Prozessor abwärtskompatibel bis hinunter zum 8086
sein.
7 http://de.wikipedia.org/wiki/Bild:80386DX
arch.png
7
1.3
Die 64-Bit-Architektur
Als kurz nach der Jahrtausendwende der 32 Bit Adressraum für den verfügbaren Arbeitsspeicher
zu klein wurde (das Limit liegt bei 4GiB), entschied man sich, den Adressraum und die Architektur
der PC Prozessoren auf 64 Bit zu erweitern. Dies ermöglicht es, bei 64 Adressleitungen insgesamt
264 Byte = 16 EiB physikalischen Speicher zu adressieren. Im Folgenden wird der für den Versuch
verwendete AMD Athlon64 vorgestellt.
1.4
1.4.1
AMD Athlon64
Der AMD Athlon64
Technische Daten8 , 9 :
• Prozessorkern: Venice, Revision E6
• Erscheinungsdatum: April 2005 für Rev. E3 und Juli 2005 bei Rev. E6
• Taktfrequenz: 1800 - 2400 MHz
• Adressbusbreite: 40 Bit
• Datenbusbreite: 2x 64 Bit (Dualchannel)
• Befehlslänge: 1-17 Byte
• L1 Cache: 64 + 64 KiB (Daten + Instruktionen)
• L2 Cache: 512 KiB
• Register: Erweiterung sämtlicher Register von 32 auf 64 Bit
Der AMD Athlon64 wurde 2005 veröffentlicht und war der zweite 64 Bit Prozessor für den PC
(Intel war schon mit seinem Itanium am Markt). Er besitzt einen 40 Bit physikalischen Adressbus
und kann damit maximal 1 TiB Speicher adressieren. Damit werden die maximal möglichen 64
Bit nicht ausgenutzt, allerdings sind momentan (April 2008) verfügbare PCs mit Arbeitsspeicher
in der Größenordnung von zwei bis vier GiB ausgestattet. Bis zum Erreichen der 1 TiB Grenze
wird noch einige Zeit vergehen, die eingesparten 24 Adressleitungen sorgen für weniger komplexe
Hardware und somit für einen billigeren Prozessor. Virtuelle Adressen sind 48 Bit breit und damit
kann der Athlon64 maximal 256 TiB Speicher adressieren.
Bei der Vergrößerung der Register von 32 auf 64 Bit wurde auch die Anzahl der 128 Bit breiten
SSE Register von 8 auf 16 erhöht und zusätzlich acht 64 Bit breite Basisregister hinzugefügt (R8
bis R15). Von der Registerverbreiterung und der zusätzlichen Anzahl von Registern profitieren
Benutzer aber nur, wenn ein 64 Bit Betriebssystem geladen ist.
Für den 64 Bit Betrieb wurde der Long Mode eingeführt, welcher inkompatibel zu den Modi Real
Mode und Virtual 8086 Mode ist. Um den Long Mode zu aktivieren, ist ein 64 Bit Betriebssystem
notwendig, z.B. Linux, Windows XP 64 oder Windows Vista.
Der Long Mode selbst ist nochmal in zwei unterschiedliche Modi unterteilt:
• Compatibility Mode
• 64-Bit Mode
8 http://de.wikipedia.org/wiki/Athlon
64
9 http://www.amd.com/de-de/Processors/ProductInformation/0
30 118 9485 9487%5e9493,00.html
”
8
Im Compatibility Mode unterstützt der Prozessor die Ausführung von 32 Bit Code. Hierbei werden
die Prozessorregister zwar mit 64 Bit angesprochen, die obersten 32 Bit sind aber auf 0“ gesetzt.
”
Der 64-Bit Mode ist der einzige Modus, in dem 64 Bit Code zur Ausführung gebracht werden kann.
Aufgrund der größeren Immediates und dadurch längeren Befehle entstehen größere Binärdateien
als im 32 Bit Modus (etwa um den Faktor 3/2).
Um die 64 Bit breiten Register anzusprechen musste der Befehlssatz erweitert werden. Dafür wird
vor den jeweiligen Befehl ein zusätzliches Byte hinzugefügt, welches an Position 3 definiert, was
für ein Befehl ausgeführt wird10 (so gennantes REX Byte). Bei einer 0“ ist es ein normaler Befehl,
”
bei einer 1“ ein 64 Bit Befehl.
”
10 http://www.sandpile.org/aa64/opc
rex.htm
9
Abbildung 1.4: Aufbau der AMD64 Architektur[7, Seite 268, Abbildung 6]
In der Athlon64 Architektur ist zu erkennen, dass Befehle in drei verschiedenen Pfaden bearbeitet werden, die prinzipiell gleich aufgebaut sind. In einem gesonderten Pfad werden Fließkommaberechnungen durchgeführt. Zusätzlich dazu befindet sich der Level-2-Cache auf der CPU, sowie
ein Kreuzschienenverteiler (Cross Bar/XBAR), welche die Verbindung zum Memory Controller
für Speicherzugriffe sowie die HyperTransport Technology zur Kommunikation mit der Peripherie
(AGP, PCI, SouthBridge)11 und eventuell vorhandenen anderen CPUs bereitstellt. Der Speichercontroller ist im Prozessor integriert, was für wesentlich geringere Latenzzeiten sorgt.
Im Athlon64 werden Sprünge durch eine Kombination von der Branch Prediction Unit, dem Global
History Counter und eines Return Adress Stacks bewertet. Dies resultiert darin, dass eine korrekte
Sprungvorhersage nur eine Taktverzögerung um einen Takt zur Folge hat. Bei einer inkorrekten
Vorhersage dauert es mindestens 10 Takte, bis der Prozessor wieder Befehle verarbeiten kann.
Die Branch Prediction Unit im Athlon64 funktioniert folgendermaßen[14, Kapitel 5.4, SteuerHazards]: Bevor ein Sprung ausgeführt wurde, geht die Einheit davon aus, dass ein Sprung nicht
stattfindet. Sollte ein Sprung stattgefunden haben, wird angenommen, dass ein Sprung immer
ausgeführt wird, bis diese Erwartung wieder fehlschlägt. Danach wird die Branch Prediction Table benutzt, um Sprungvorhersagen zu treffen. Der Puffer für Sprungzieladressen (Target Array)
beträgt 2048 Einträge.
Der Global History Counter hat 16384 Einträge zu je zwei Bit, welche dazu benutzt werden, einen
bedingten Sprung vorherzusagen. Indiziert wird die Tabelle an Hand des Ergebnisses der letzten acht bedingten Sprünge und vier Bits der Sprungadresse. Diese Tabelle ermöglicht es, bis zu
acht Sprungvorhersagen zu speichern. Der Return Address Stack dient dazu, Vorhersagen über
die Rücksprungadresse von Unterprogrammen zu treffen. Hierzu werden insgesamt 12 Einträge
verwendet[7, Anhang A.6].
Die Branch Selectors speichern Sprungdaten aus vorhergehenden Sprüngen um die Sprungvorhersagen zu verbessern. Diese Vorhersagen werden unabhängig von der Sprungart (bedingter oder
11 http://techreport.com/articles.x/5683/1
10
unbedingter Sprung) getroffen. Dafür werden 16 Byte breite Zeilen mit Instruktionen gefüllt, an
Hand derer die Sprungvorhersagen getroffen werden. Es stehen insgesamt 4096 Zeilen zur Verfügung. In jeder Zeile steht zu jeweils zwei benachbarten Bytes ein Zwei-Bit Branch Selector zur
Verfügung, welcher eine Sprungvorhersage trifft. Dabei wurde der Athlon64 dahingehend erweitert, dass er pro Zeile drei Sprünge oder Returns vorhersagen kann. Sollte eine Zeile aus dem Level
1 Cache in den Level 2 Cache ausgelagert werden, wird die zugehörige Zeile des Branch Selectors
mit ausgelagert[13].
Die Fetch-Decode Unit holt die Befehle aus dem Befehlscache (Fetch 2 Transit), ordnet unabhängige Befehle in Gruppen an (Pick) und dekodiert sie teilweise (Decode 1 und 2) wobei die Reihenfolge
der Befehlsausführung durch die frühen Dekodiereinheiten nicht verändert wird. Dabei werden pro
dekodiertem Befehl drei Makrobefehle pro Takt von jedem Pfad generiert (Pack). Als Makrobefehle
bezeichnet man eine Menge von Befehlen, welche in ihrer Verarbeitungsreihenfolge nicht verändert
werden dürfen und somit als Funktionsblock ausgeführt werden müssen. Makrobefehle können nur
als komplette Befehlsfolge in der Ausführung verschoben werden, aber nicht einzelne Mikrobefehle.
Als Mikrobefehl werden daher die einzelnen Befehle bezeichnet, aus denen sich ein Makrobefehl
zusammensetzt. Die nächste Stufe der Befehlsabarbeitung ist die Instruction Control Unit, in der
die Befehle umsortiert werden um einen möglichst hohen Befehlsdurchsatz zu erzielen[7, Anhang
A.7].
Nach der Fetch Decode Einheit folgt die Instruction Control Unit (Decode) in der die erstellten
Makrooperationen dekodiert und in in einen Reorder Buffer geschrieben werden. Dieser Puffer besitzt 24 Zeilen zu je drei Makrooperationen. Die so maximal gespeicherten 72 Makrooperationen
werden dann sortiert und zu dem Integer Scheduler bzw. Floating Point Scheduler weitergeleitet[7,
Anhang A.8].
Hinter der Integer Control Unit befinden sich die Integer Scheduler und die Floating Point Scheduler. Der Integer Scheduler besteht aus drei Warteschlangen für Makrooperationen, welche jeweils
acht Einträge fassen. Jede Warteschlange teilt die Befehle je nach Bedarf in Integer- und Adressoperationen auf[7, Anhang A.11].
Nach dem Aufteilen befinden sich die Befehle in der Integer Execution Unit (Floating Point Befehle
werden weiter unten behandelt). Diese besteht aus drei parallelen Verarbeitungspfaden von denen
jeder einzelne aus einer ALU und einer Adress generation Unit (AGU) besteht. Mikrooperationen werden dann ausgeführt, wenn alle benötigten Operanden zur Verfügung stehen, unabhängige
Befehle können out-of-order ausgeführt werden. Zusätzlich dazu kann ein Integerpfad zwei Mikrooperationen von verschiedenen Makrooperationen ausführen, eine in der ALU, die andere in der
AGU. Nachdem alle Befehle einer Makrooperation abgearbeitet wurden wird ein Statussignal an
die Integer Control Unit gesendet. Bis auf Multiplikationen kann jede Integer Operation in jedem
Pfad ausgeführt werden. Multiplikationen werden in Pfad 0 und 1 ausgeführt. Dies wird dadurch
erreicht, dass Mikrooperationen, welche nicht an der Multiplikation beteiligt sind, in einem anderen Pfad oder zu einer anderen Zeit ausgeführt werden[7, Anhang A.12].
Parallel zu der Integer Execution Unit befindet sich die Verarbeitungseinheit für Floating-Point
Berechnungen, bestehend aus Floating-Point Scheduler und Floating-Point Execution Unit. Die
Floating-Point Logik des Athlon64 ist in der Lage, in jedem Takt jeweils drei beliebige der folgend
aufgeführten Makrooperationen zu bearbeiten:
• x87 floating-point
• 3DNow! Befehle
• MMX Befehle
• SSE
• SSE2
Der Floating-Point Scheduler besitzt einen Puffer mit 36 Einträgen, aufgeteilt in 12 Zeilen zu je
drei Makrooperationen. Die Daten zu den Instruktionen werden mittels Datenweiterleitung verfügbar gemacht. Dies ermöglicht, dass ein Befehl schon Daten aus Registern verwenden kann, die
11
noch nicht vollständig aus dem Speicher geladen wurden, da die Daten direkt dem Befehl zur
Verfügung gestellt werden[7, Anhang A.13][14, Kapitel 5.3, Daten-Hazards].
Die Floating-Point Execution Unit ist als eigenständiger Koprozessor implementiert worden und
kann alle Befehle der oben angegebenen Technologien ausführen. Nach dem Floating-Point Scheduler werden die Befehle durch die Floating-Point Execution Unit auf drei parallel arbeitende
Ausführungseinheiten verteilt:
• FADD
• FMUL
• FSTORE
FADD bezeichnet die Einheit, welche für Additionen benutzt wird, sie besteht aus einer SSE,
SSE2, SSE3, 3DNow! und MMX ALU und beinhaltet einen x87 Addierer. Dieselbe Technologie
befindet sich in der FMUL Einheit, nur dass hier anstatt Addierer Multiplizierer verwendet werden.
FSTORE ist dafür zuständig, die Ergebnisse der Berechnungen abzuspeichern[7, Anhang A.14].
12
Abbildung 1.5: Das Speichersystem im Athlon6412
Das Speichersystem des AMD64 besteht aus dem 1st und 2nd Level Cache, Puffern, dem Arbeitsspeicher und weiteren Einheiten. Im Folgenden werden nur die im Bild 1.5 weiß dargestellten
Einheiten betrachtet. Die Caches sind in Blöcke fester Größe eingeteilt (cache line size), welche
beim AMD64 64Byte beträgt. Im Datenblatt[5, S. 161/205] waren Größen von 32 und 64 Byte
angegeben, welche abhängig von der Implementation seien. Die beim Athlon64 verwendete Größe
wurde mit Prime 9513 unter Windows XP folgendermaßen ermittelt: Zuerst wurde Prime95 aus
der oben angegebenen Quelle heruntergeladen und installiert. Die Installation startet das Programm automatisch. Unter Options → CPU lassen sich im unteren Bereich CPU Information“
”
die Informationen ablesen.
Der First Level Cache ist insgesamt 128KiB groß, aufgeteilt in jeweils 64KiB für Daten und Instruktionen. Dagegen ist der 512KiB große Level 2 Cache sowohl für Daten als auch für Instruktionen
geeignet. Der L2 Cache kann exklusiv angesprochen werden, dann enthält er Daten, welche nicht
im L1 Cache vorhanden sind.
Was den Arbeitsspeicher betrifft, so gibt es verschiedene Strategien, auf diesen zuzugreifen. Es
sind z.B. Out-of-order Lesezugriffe auf den RAM erlaubt, solange der Vorgang für die Applikation transparent bleibt. Out-of-order Schreibzugriffe sind generell nicht erlaubt, zuerst müssen alle
Instruktionen des Programms welche vor dem Schreibzugriff ausgeführt werden, beendet sein. Lesezugriffe werden in aller Regel vor Schreibzugriffen ausgeführt, damit der Programmablauf nicht
ins Stocken kommt. Diese Vorgehensweise soll die Ausführungsgeschwindigkeit generell erhöhen[5,
S. 162/206]. Zum Beispiel können ohne Probleme zwei Lesezugriffe auf die gleiche SPeicherstelle
gleichzeitig erfolgen. Bei einem Schreib- und einem Lesezugriff muss ein Zugriff blockiert werden,
da nur so sichergestellt ist, dass die Daten im Speicher konsistent bleiben.
Damit sind die für die Befehlsausführung wichtigsten Teile des Athlon64 beschrieben. Es zeigt
sich hier, dass trotz der sehr neuen Technologie immer noch Rückstände des ersten x86 Prozessor
(8086) zu finden sind (z.B. Real Mode; die Möglichkeit, 16 Bit Register zu adressieren, etc.). Damit
12 AMD64
Architecture Programmer’s Manual
(http://www.amd.com/us-en/assets/content type/white papers and tech docs/24593.PDF), Seite 160 (204),
Abbildung 7-1
13 http://mersenne.org/gimps/p95v2414.exe, Benchmark
13
wird deutlich, dass selbst die aktuell verwendete Technologie aus Gründen der Abwärtskompatibilität noch in der Lage ist, Programme auszuführen, welche für den 8086 geschrieben wurden. Der
Athlon64 ist also kompatibel zu insgesamt drei Prozessorgenerationen der x86 Familie: 16 Bit, 32
Bit und momentan 64 Bit.
14
Kapitel 2
32-Bit Befehle auf einer 64-Bit
CPU
Im Compatibility Mode kann der Athlon64 32 Bit Befehle ausführen, während ein 64 Bit Betriebssystem geladen ist. Die Befehle können nur auf 32 Bit breite Register zugreifen, profitieren also
nicht von der 64 Bit Erweiterung, aber auf die zustätzlich vorhandenen Register kann zugegriffen werden. 32 Bit Programme im 64 Bit Kompatibilitätsmodus könnten also von der Theorie
her schneller ablaufen als 32 Bit Programme im 32 Bit Modus. Allerdings unterstützt der 64 Bit
Compatibility Modus keine 16 Bit Programme (Real Mode und Virtual 8086 Mode).
15
Kapitel 3
Benchmarken des AMD Athlon64
3.1
3.1.1
Einrichten des Testsystems
Das Testsystem
• Prozessor AMD Athlon64 3200+, Sockel 939, Venice, Revision E6
• Taktfrequenz: 2GHz
• Frontside-Bus: 1GHz
• Arbeitsspeicher: 2x512 MB DDR400 RAM
• Hauptplatine: MSI K8T Neo2 Revision 1.4
• Festplatte: 13,6 GB Seagate Medialist 13640
3.1.2
Gentoo Linux 32 Bit
Zum Untersuchen des AMD Athlon 64 haben wir ein Gentoo System in der Version 2007.0 mit
dem Kernel 2.6.23-gentoo-r3 SMP“ eingerichtet, für die Installation sind wir nach der Installa”
tionsanleitung unter www.gentoo.org1 vorgegangen. Portage und Stage Archiv waren vom Stand
Dezember 2007. Die zur Kompilierung des Systems genutzten Compilerflags waren folgende:
CFLAGS= -march=athlon -O3 -pipe“
”
Für die Installation haben wir folgende USE-Flags genutzt, von denen die unterstrichen für unseren
Versuch relevant sind:
• 3dnow
• fftw
• mmx
• acpi
• fortran
• ncurses
• bash-completion
• ginac
• pcntl
• bindist
• gsl
• sse
• crypt
• hal
• sse2
• fbcon
• minimal
• unicode
Um den MySQL-Server inklusive Benchmarks zu installieren, musste das USE Flag minimal“
”
entfernt werden.
1 http://www.gentoo.org/doc/de/handbook/handbook-x86.xml
16
3.1.3
Gentoo Linux 64 Bit
Zur Installation des 64 Bit Gentoo haben wir die Installationsdokumentation der Gentoo amd64
Architektur2 zu Rate gezogen. Die USE-Flags haben wir identisch zu denen im 32 Bit Modus
gesetzt, nur die Compiler Flags waren verschieden:
CFLAGS= -march=athlon64 -O3 -pipe“
”
Auch hier mussten wir darauf achten, dass die Installation des MySQL-Servers erst nach Entfernung des USE-Flags mininal“ möglich war. Mit dem Flag -march=athlon64“ legten wir fest, dass
”
”
nur 64 Bit Befehle ausgeführt werden können. Um ein 64 Bit Intel System zu installieren, muss, um
Unterstützung für EM64T Extended Memory 64 Technology3 , d.h. mehr als 4GB Arbeitsspeicher
zu erhalten, das Compiler Flag ’march’ auf den Wert ”nocona”gesetzt werden.
3.1.4
Ablauf der Installation
Für die Installation wurde jeweils die Minimalinstallations-CD für x864 und amd645 heruntergeladen und gebootet. Nachdem das System hochgefahren war, wurde das Passwort für den root
Account eingerichtet. Auf das Einrichten eines normalen Benutzers wurde verzichtet. Der DMA
Modus der Festplatte war schon standardmäßig aktiviert. Da das System direkt am Rechner eingerichtet wurde und nicht über eine Internetverbindung, wurde kein SSH Server gestartet.
Die Netzwerkeinrichtung musste nicht durchgeführt werden, der Rechner hatte direkt nach dem
Booten Internetzugriff.
Die 13,6GB Festplatte wurde folgendermaßen partitioniert:
• 1. Partition: 5,36GB JFS, Gentoo 32 Bit
• 2. Partition: 5,36GB JFS, Gentoo 64 Bit
• 3. Partition: 1.94GB Swap
Die Installation des Stage3 Archives und von Portage haben wir wie in der Anleitung vorgegeben durchgeführt und die Compiler Optionen wie oben beschrieben gesetzt. Die Vorbereitungen
zur Installation des Systems haben wir ebenso der Anleitung entnommen. Die Kernelkonfiguration wurde in der Standardkonfiguration belassen, wir haben lediglich den Prozessortyp geändert
(Processor Type and features -> Processor Family wurde auf Athlon64 gesetzt). Einträge in der
/etc/fstab haben wir getätigt, wie in der Dokumentation vorgesehen. Die Einträge haben wir dabei natürlich an das System angepasst. Die Netzwerkkarte erhält ihre IP-Adresse per DHCP, die
Netzwerkkonfiguration wird beim Systemstart geladen. Die Tastaturbelegung wird auf deutsch
eingestellt, als Zeitzone kommt Europe/Berlin zum Einsatz. Bei der Installation der Systemtools
wurde nur ein DHCP Client installiert. Als Bootloader kommt GRUB zum Einsatz, die menu.lst
enthält keinerlei zusätzliche Kerneloptionen wie z.B. Framebufferunterstützung.
Nach der Installation wurde der Rechner neu gebootet und für jedes System folgende Software
installiert:
• NBench 2.2.2
• Cachebench 2.0
• MySQL-Server 5.0.44
2 http://www.gentoo.org/doc/de/handbook/handbook-amd64.xml
3 http://de.wikipedia.org/wiki/Intel
64
4 ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/releases/x86/2007.0/installcd/install-x86-minimal-2007.0.iso
5 ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo/releases/amd64/2007.0/installcd/install-amd64-minimal-
2007.0.iso
17
NBench ist im Portage verfügbar und kann einfach über emerge nbench“ installiert werden. Auf”
gerufen wird es mit nbench“, die Benchmarkergebnisse werden auf der Konsole ausgegeben.
”
Cachebench wurde heruntergeladen, entpackt und mit make linux-lam && make cache-bench“
”
kompiliert. Anschließend wurde der Benchmark mit make cache-run“ gestartet. Die Ergebnisse
”
werden im Verzeichnis results“ abgelegt.
”
Der MySQL-Server wird mit
emerge mysql
installiert, ein Benchmark wird mitgeliefert. Gentoo legt diesen in
/ u s r / s h a r e / mysql / s q l −bench
ab. Vor der Ausführung muss ein Datenbankbenutzer angelegt und die Datenbank initialisiert
werden. Dies geschieht mittels der Befehle
e b u i l d / var /db/ pkg / dev−db/ mysql − 5 . 0 . 4 4 / mysql − 5 . 0 . 4 4 . e b u i l d c o n f i g
zum Erstellen der Init-Skripte, sowie
/ u s r / b i n / mysqladmin −u r o o t password ’ r s t ’
um das Passwort des Datenbankadministrators zu setzen. Der Benchmark wird mit
sh bench−i n i t . p l
initialisiert und mit
sh run−a l l −t e s t s −−s e r v e r=mysql −−u s e r=r o o t −−password=r s t −−l o g
gestartet. Sämtliche Benchmarkergebnisse wurden zwischengespeichert, um später wiederaufbereitet präsentiert werden zu können.
18
3.2
Auswahl geeigneter Benchmarks
Zur Auswahl geeigneter Testszenarien musste analysiert werden, welche Arten von Benchmarks
relevant sein würden. Dazu gehörten zum Einen aufgrund der sich unterscheidenden Adressierungsarten im 32 bzw. 64Bit-Modus Cache- und Speicheranbindungstests, sowie das Testen der
CPU-Leistung (wegen der zusätzlich gewonnenen Register im 64Bit-Modus), zum Anderen das
Verhalten bei einem Datenbankbenchmark mit SQL-Bench6 (wegen zuvor gesicheteten Testergebnisse von TecChannel [2, TecChannel Benchmark] und der Tatsache, dass Datenbanken heutzutage
unerlässlich geworden sind).
Um sich einen Überblick über die noch zur Auswahl stehenden Benchmarks zu machen, wurde auf
Google7 nach OpenSource-Varianten gesucht. Hierbei stießen wir auf Cachebench8 , welches die
Cacheanbindung zur CPU testet, sowie NBench9 , welches Geschwindigkeitsmessungen bei diversen CPU-, Cache- und Festplattentests macht. Im Folgenden gehen wir nun näher auf die einzelnen
Benchmarktools ein.
3.2.1
Cachebench
Cachebench ist ein Benchmarktool, welches Informationen bezüglich der Bandbreite bei Lesezugriffen bei unterschiedlich langen Vektoren eines Datentyps (hier double, da kein längerer Typ
wählbar war) in einer Kompileroptimierten Schleife ermittelt. Für den Fall, dass die Vektorlänge
kleiner als die jeweilige Cachegröße (L1, L2,...) ist, wird jeweils in den hierarisch übergeordneten Cache geschrieben (z.B. L1 = 256kb, L2 = 128kb, L3 = 64kb, V L = 300kb - V wird in L1
und L2 geschrieben, L3 bleibt unangetastet). Im Falle der Überschreitung wird zusätzlich auf den
hierarschisch untergeordneten Speicher zugegriffen (letzenendes Hauptspeicher oder sogar Swap).
Wir haben uns für dieses Programm entschieden, um den Durchsatz in (MB/s) als Messwert für
unsere Zwecke zu nutzen, und aus dem weiteren Grund, dass das Programm in der Lage ist, ein
Diagramm im GNU-Plot-Format zu generieren. Cachebench ist mittlerweile kein eigenes Benchmarktool mehr, sondern wurde in die Low Level Characterization Benchmarks10 aufgenommen.
Ziel von Cachebench ist es, die Effektivität des Caches bei idealer Nutzung sowie der Optimierung
durch High-Level-Compiler zu testen. Da Applikationen auf ideale Ausnutzung des Caches angewiesen sind, können sie von den Ergebnissen, die Cachebench liefert, profitieren.
Cachebench besteht derzeit aus acht verschiedenen Benchmarks, von denen jeder einzelne Zugriff auf Daten unerschiedlicher Länge zugreift. Dabei werden für jede Vektorlänge entsprechend
Zugriffszeiten protokolliert, welche anschließend mit der jeweils eingestellten Länge multipliziert
die Übertragung in MB/s (1 MB = 1048576 Bytes) ergeben. Die Ergebnisse werden nach Beendigung des Benchmarks per Skript in ein für GNU-Plot umgängliches Format gewandelt und auf
der Festplatte abgelegt.
Die acht durchgeführten Benchmarks sind:
• Cache Read
• Hand tuned Cache Write
• Cache Write
• Hand tuned Cache Read/Write/Modify
• Cache Read/Modify/Write
• Memory Set (aus C-Bibliothek)
• Hand tuned Cache Read
• Memory Copy (aus C-Bibliothek)
6 http://dev.mysql.com/doc/refman/5.1/de/mysql-benchmarks.html
7 http://www.google.de
8 http://icl.cs.utk.edu/projects/llcbench/cachebench.html
9 http://www.tux.org/
mayer/linux/bmark.html
10 http://icl.cs.utk.edu/projects/llcbench/
19
Da es in unserem Test lediglich auf die Auswertung der Differenzen bei den Datenübertragungsraten im 32 bzw. 64Bit-Modus ankam, entschieden wir uns für eine Hand voll Tests, auf
deren Unterschiede wir nicht näher eingehen werden, da sie nichts mit dem eigentlichen Versuchshintergrund zu tun haben.
Cache Read
Bei diesem Test werden Datensätze aus dem Cache gelesen. Um eine Optimierung seitens des
Compilers (hervorgehobener Bereich) auf Grund der Nichtverwendung der Variable ’register’ zu
verhindern, wurde diese innerhalb des inneren Schleifenrumpfes nach dem Schreibvorgang mit
Aufruf der Funktion fake out optimizations(. . . ) 11 ausgelesen und an /dev/null12 geschrieben. Es
findet somit eine Verwendung statt. Der Aufruf dieser Funktion ist ebenfalls in den nachfolgenden
Tests Cache-Write und Cache-Read/Modify/Write enthalten.
for a l l vector length
timer s t a r t
f o r i t e r a t i o n count
<−−
f o r I=0 t o v e c t o r l e n g t h <−−
r e g i s t e r += memory [ I ]
<−−
timer stop
Listing 3.1: Pseudocode - Cachebench (Cache Read)
Cache Write
Bei diesem Test werden Datensätze in den Cache geschrieben. Die Ergebnisse werden stark beeinflusst von der eingestellten Cachingstrategie (in unseren Tests XXX). So würde z.B. ein write-back
Cache eine wesentlich höhere Performanz bei diesem Benchmark zeigen, da es häufig unnötigte
Zugriffe zum Hauptspeicher verhindert.
for a l l vector length
timer s t a r t
f o r i t e r a t i o n count
f o r I=0 t o v e c t o r l e n g t h
memory [ I ] = r e g i s t e r++
timer stop
Listing 3.2: Pseudocode - Cachebench (Cache Write)
Cache Read/Modify/Write
Bei diesem Test wird doppelt soviel Speicherverkehr produziert, wie in den beiden zuvor erwähnten
Tests, da er Daten aus dem Cache einliest, verändert und anschließend zurückschreibt (2 Transfervorgänge). Bei der Berechnung der Bandbreite werden beide Transferrichtungen berücksichtigt,
jedoch auch die registerinterne Berechnung (Inkrementation) mit einbezogen. Die erreichte Bandbreite dieses Tests liegt meist höher als die Summe der Bandbreiten in den vorangehenden Tests
(Cache Read und Cache Write), was darauf zurückzuführen ist, das der Compiler Möglichkeiten
zur Ablaufoptimierung nutzt und Speicherzugriffsgruppierungen vornimmt, um die Auslastung des
Speichers minimal zu halten.
for a l l vector length
timer s t a r t
f o r i t e r a t i o n count
11 Quelltextdatei
- cachebench.c (Zeile 291-298)
12 http://de.wikipedia.org/wiki//dev/null
20
f o r I=0 t o v e c t o r l e n g t h
memory [ I ]++
timer stop
Listing 3.3: Pseudocode - Cachebench (Cache Read/Modify/Write)
Memory Set
Die C-Bibliothek stellt eine Funktion memset() zur Verfügung, um Speicherregionen zu initialisieren. Sie ist oft stark optimiert, da sie häufig in Anwendungen in- und außerhalb des Betriebssystems
Verwendung findet und kann zum Teil sogar hardwaregestützt ausgeführt werden.
for a l l vector length
timer s t a r t
f o r i t e r a t i o n count
f o r I=0 t o v e c t o r l e n g t h
memset ( v e c t o r , 0 xf0 , l e n g t h )
timer stop
Listing 3.4: Pseudocode - Cachebench (Memory Set)
Memory Copy
Ebenfalls von der C-Bibliothek zur Verfügung gestellt wird die Funktion memcpy(). Sie wird häufig
bei der Inline-Assembler-Programmierung13 und in vielen der bereitgestellen Fortran-Bibliotheken
wie z.B. MPI verwendet.
for a l l vector length
timer s t a r t
f o r i t e r a t i o n count
f o r I=0 t o v e c t o r l e n g t h
memcpy( d e s t , s r c , l e n g t h )
timer stop
Listing 3.5: Pseudocode - Cachebench (Memory Copy)
3.2.2
NBench
NBench für Linux ist die Version 2 des vom BYTE Magazin veröffentlichten BYTEmark-Benchmarktools
(vormals bekannt als BYTE’s Native Mode Benchmarks)14 . Das Tool besteht aus einer Reihe von
Benchmarks, welche CPU, Speicher und Floating-Point-Unit (FPU) testen und die Ergebnisse
protokollieren.
Die folgenden Test können durchlaufen werden:
• Numerische Sortierung
• Lösung eines Optimierungsproblems
• String-Sortierung
• IDEA (Verschlüsselung)
• Bitfeld-Manipulationen
• Huffmann (Komprimierung)
• Gleitkomma-Emulation
• Neuronales Netz
• Fourier-Reihe
• LU-Faktorisierung
13 Unter
Inline-Assembler-Programmierung wird im Allgemeinen das direkte Einbinden von Assembler-Code in
C/C++ Quelltexte verstanden.
14 http://www.byte.com/bmark/bmark.html
21
Die Tests werden im nachfolgenden Kapitel kurz beschrieben. Tiefergehende Informationen
befinden sich auf der Webseite des BYTEmark-Benchmarks (Spezifikation)15 .
Numerische Sortierung
Bei diesem Benchmark wird ein numerisches Array (eindimensional, bestehend aus 32Bit-Integers)
nach dem Heapsort-Algorithmus16 sortiert. Ein teilsortiertes Array bedeutet keinen Vorteil, da der
Heapsort-Algorithmus eine Komplexität von N log2 N aufweist. Dieser Test wurde laut Spezifikation aufgenommen, da Sortierung in der Computerwelt eine sehr hohe Bedeutung zu verzeichnen
hat (häufige Verwendung in Betriebssystemen, Datenbanken, etc.). Rückgabewert des Benchmarks
ist die Anzahl der sortierten Arrays pro Sekunde (Durschnittswert).
String-Sortierung
Die Aufgabe dieses Benchmarks ist das Testen der Eigenschaft, wie schnell ein System Bytes
bewegt (kopieren von eindimensionalen Byte-Arrays). Quelladressen der Strings sind bekannt (aligned address), Zieladressen unbekannt (arbitrary addresses). Die zu sortierenden String sind zufälliger Länge, angefangen bei 4 Bytes bis maximal 80 Bytes. Sortiert wird auch hier per HeapsortAlgorithmus. Der Unterschied zur numerischen Sortierung ist, dass dort jeweils nur 32 Bit bewegt
werden. Rückgabewert dieses Benchmarks ist die Anzahl der sortierten Strings pro Sekunde.
Bitfeld-Manipulation
Bei diesem Benchmark wird analysiert, wie schnell ein System im Stande ist aufeinanderfolgende
Bits in einem Vektor zu invertieren. Der Test z.B. stellt eine Speicherorganisation nach. ’bit maps’
(nicht zu Verwechseln mit dem Grafikdateiformat) werden zum Großteil zur Belegungsprüfung
und Organisation von Speicherblöcken verwendet, wobei eine logische 0 die Bedeutung eines freien
Blocks darstellt. In diesem Test werden die verschiedenen auftretenden Szenarien nachgebildet:
• Zurücksetzen einer beliebigen Anzahl aufeinanderfolgender Bits
• Setzen einer beliebigen Anzahl aufeinanderfolgender Bits
• Invertieren einer beliebigen Anzahl aufeinanderfolgender Bits
Beim Test wird ein Abschnitt mit einer Reihe zufällig gewählter Befehle zum Verändern der Vektorinhalte ausgeführt. Da bei jedem Test dieselbe Befehlsreihenfolge eingehalten wurde (Befehlsfolge
lag in Form eines Skripes vor, welcher sich im Programmverzeichnis des Benchmarks befand), war
bei jedem Durchlauf dieselbe Voraussetzung gegeben. Rückgabewert des Tests ist die Anzahl der
ausgeführten Bit-Operationen pro Sekunde (Durchschnittswert).
Gleitkomma-Emulation
Hier wird ein Gleitkomma-Rechensystem nach IEEE 75417 nachgestellt, in welchem verschiedene
Rechenoperationen getätigt werden. Das Programm erzeugt drei 1-dimensionale Arrays (Arraylänge % 4 = 0) und lädt das erste mit zufällig gewählten Gleitkommazahlen. Anschließend werden
die Arrays in vier gleich große Gruppen unterteilt, in denen jeweils Additionen, Subtraktionen,
Multiplikationen und Divisionen durchgeführt werden. Rückgabewert des Benchmarks ist die Anzahl der ausgeführten Gleitkomma-Operationen pro Sekunde (Durchschnittswert).
Wie schon zu vermuten ist, ist dieser Test heutzutage nicht mehr praxisbezogen, da CPUs mittlerweile Gleitkommarecheneinheiten besitzen, jedoch kann man ihn zum Messen der Rechenleistung
eines PCs durchaus noch einsetzen.
15 http://www.byte.com/bmark/bdoc.htm
16 http://de.wikipedia.org/wiki/Heapsort
17 http://de.wikipedia.org/wiki/IEEE
754
22
Fourier-Reihe
Dieser Benchmark ist eine Art Gleitkomma-Benchmark, um trigonometrische und transzendente
Funktionen auszuführen. Er berechnet die ersten n Fourier-Koeffizienten der Funktion f (x) =
(x + 1)x im Intervall xi = xn+1 − xn = 0, 2. Bei der Berechnung der Integrale zum Erhalt der
Koeffizienten kommt bei diesem Benchmark die Trapezregel zum Einsatz. Rückgabewert ist die
Anzahl der berechneten Koeffizienten pro Sekunde (Durchschnittswert).
Auch bei diesem Test ist der Praxisbezug durch die Erweiterungen und Integration der Gleitkommaeinheit in den Prozessor verloren gegangen. Zur damaligen Zeit konnte durch Verwendung
unterschiedlicher C-Bibliotheken bei verschiedenen mathematischen Berechnungen ein Geschwindigkeitsvorteil gewonnen werden, welcher mit diesem Test ersichtlich wurde. Heutzutage wird der
größte Teil an mathematischen Berechnungen hardwareunterstützt durchgeführt.
Lösung eines Optimierungsproblems
Dieser Test besteht aus einem Aufgabenzuordnungs-Algorithmus, welcher nach Verarbeitungskosten priorisierten Maschinen Jobs zur Verarbeitung vermittelt. Der Algorthmus wurde laut Angaben
der Entwickler anhand einer Schritt-für-Schritt Anleitung, enthalten in Quantative Decision Making for Business - Gordon, Pressman and Cohn (New Jersey, 1990), entwickelt. Seine Aufgabe ist
es, die Gesamtverarbeitungskostenkosten zu minimieren. Der Benchmark testet die CPU-Fähigkeit
der Array-Manipulation an aufgestellten 101 × 101 Matrizen, welche aus ’long integers’ bestehen.
Rückgabewert des Benchmarks ist die Anzahl der Manipulationen pro Sekunde (Durschnittswert).
IDEA (Verschlüsselung)
Der International Data Encryption Algorithm18 verschlüsselt 64 Bit Blöcke mit einer Schlüssellänge
von 128 Bit. Der IDEA benchmark führt eine itertiert Ver- und Entschlüsselung eines Strings
durch. Angelegt werden drei Strings (jeweils 4000 Byte lang): Der erste enthält den Originaltext,
der zweite den verschlüsselten Text, der dritte den entschlüsselten Text, wobei die Inhalte des
ersten und dritten String identisch sein sollten. Rückgabewert ist die Zahl der Iterationen pro
Sekunde (Durchschnittswert).
Da in diesem Benchmark für Zahlen > 32Bit der Datentyp ’long’ verwendet wird, ist er auch auf
heutigen Systemen noch interessant, da z.B. bei 64-Bit Systemen ganze Blöcke verarbeitet werden
können.
Huffman (Komprimierung)
Der Huffman-Algorithmus19 ist ein Entropiekodierungsverfahren20 , welches zur Komprimierung
von Text- und Grafikformaten eingesetzt wird (z.B. bei pkZip (RFC 195121 ), JPG22 und MP323 ).
Bei diesem Benchmark wird ein String mit einer Länge von 5000 Bytes in einer Schleife (komprimiert und dekomprimiert). Rückgabewert ist die Anzahl der durchgeführten Iterationen pro
Sekunde (Durchschnittswert).
Neuronales Netz
Der Benchmark simuliert ein rückpropagierendes24 neuronales Netzwerk25 und erzeugt dabei 2dimensionale Bit-Vektoren der Größe 5x7, welche die Abbildung von Buchstaben darstellen sollen.
Anschließend wird eine Routine ausgelöst, welche die Erkennung anhand verschiedener Merkmale
18 http://de.wikipedia.org/wiki/International
Data Encryption Algorithm
coding
20 http://de.wikipedia.org/wiki/Entropiekodierung
21 http://tools.ietf.org/html/rfc1951
22 http://de.wikipedia.org/wiki/Jpg
23 http://de.wikipedia.org/wiki/MPEG-1 Audio Layer 3
24 http://de.wikipedia.org/wiki/Backpropagation
25 http://de.wikipedia.org/wiki/Neuronales Netzwerk
19 http://en.wikipedia.org/wiki/Huffman
23
erlernt. Laut Spezifikation basiert dieser Test auf Gleitkommaberechnungen, häufiger Nutzung der
exp() Funktion und Arrayreferenzen. Rückgabewert ist die Anzahl der Routinendurchläufe pro
Sekunde (Durchschnittswert).
LU-Faktorisierung
Die LU-Faktorisierung ist ein Verfahren zum Lösen linearer Gleichnungen. Angenommen A sei eine
n × n Matrix, so erhält man per LU-Faktorisierung zwei n × n Matrizen, welche folgende Gleichung
erfüllen: An = Ln ∗ Un . Ln ist eine dabei eine untere Dreiecksmatrix, U eine obere Dreiecksmatrix.
In diesem Benchmark ist A immer eine 101 × 101 Matrix26 Es wird damit begonnen ein ’lösbares’
lineares Gleichungssystem aufzustellen, indem eine Identitätsmatrix A aufgestellt und ein Vektor b mit zufälligen Werten gefüllt wird. Anschließend werden die Gleichungen verändert, indem
zeilenweise mit Konstanten multipliziert wird oder Zeilen addiert bzw. subtrahiert werden. Die Ergebnismatrix wird dann per LU-Faktorisierung gelöst. Rückgabewert ist die Anzahl der Durchläufe
pro Sekunde (Durchschnittswert).
3.2.3
SQL-Bench
Da aus gesichteten bereits durchgeführten Benchmarks hervorging, dass Datenbanken auf 64-BitSystemen im Durchschnitt schneller laufen [2, TecChannel Benchmark], haben wir ebenfalls ein
solches Testszenario erstellt, um diese These zu stützen. Anhand von SQL-Bench können Benutzer
ermitteln, welche Operationen eine gegebene SQL-Implementierung gut oder weniger gut ausführt.
Der Benchmark besteht aus Perl-Skripten, welche wiederholt auf die Datenbank zugreifen. Zur Anbindung von Perl an die Datenbank wird das Perl-DBI-Modul verwendet. Es ist zu beachten, dass
der Benchmark nur einen Thread verwendet. Gemessen wird also die Mindestdauer27 der durchgeführten Operation.
Da zu diesem Benchmark leider nicht mehr Informationen zur Verfügung standen (anstelle dessen
wird auf die Quelltexte verwiesen28 ), war es im Nachhinein lediglich möglich stichhaltige Aussagen
bezüglich der Performanz, nicht jedoch der Gründe dafür zu treffen. Auf Grund nicht vorhandener
Perl-Kenntnisse und der internen Umsetzung der MySQL-Befehle (Maschinencode) hätte dies den
Zeitrahmen für dieses Projekt deutlich gesprengt.
Ausgeführt und in die Bewertung einbezogen werden folgende Befehle:
• ALTER TABLE
• BIG TABLES
• CONNECT
• CREATE
• INSERT
• SELECT
26 Die
Anzahl an Zeilen und Spalten wurde seitens der Entwickler auf 101 festgelegt und kann nur durch eingreifen
in den Quellcode, d.h. Setzen verschiedener globaler Variablen und Rekompilierung des Quelltextes, geändert
werden.
27 In einer normalen Serverumgebung werden bei Datenbankzugriffen mehrere Threads gestartet, wenn gleichzeitig
mehrere Benutzer Zugriff anfordern.
28 http://dev.mysql.com/doc/refman/5.1/de/mysql-benchmarks.html
24
3.3
3.3.1
Auswertung der Benchmarkergebnisse
Cachebench
Cache Read
Abbildung 3.1: Cachebench Ergebnisse - Read
Auf Grund der widersprüchlichen Ergebnisse dieses Benchmarks sind nur Spekulationen möglich, welche das Verhalten erklären könnten, jedoch nicht belegen. Es ist im 32 Bit Modus ein
Einbruch bei einer Blockgröße von 64KiB festzustellen, der sich dadurch erklären ließe, dass der
L1 Datencache bei dieser Größe sein maximales Fassungsvermögen erreicht hat und danach auf den
L2 Cache zugegriffen wird, welcher langsamer ist. Dies trifft aber auch auf den 64 Bit Modus zu,
dessen Graph diesen Einbruch aber nicht zeigt. Auch eine Wiederholung des 32 Bit Benchmarks
brachte keine Klärung, die Kurven der Benchmarkergebnisse waren bis auf minimale Abweichungen
identisch. Wiederholt wurde der Benchmark, um Störeinflüsse des Betriebssystems ausschließen
zu können. Bei 64 Bit ist ein kleiner Einbruch bei 512KiB zu erkennen, welcher sich durch das
Fassungsvermögen des L2 Cache erklären lässt. Auch hier ist dieser Einbruch im jeweils anderen
Test (32 Bit) nicht zu erkennen.
25
Cache Write
Abbildung 3.2: Cachebench Ergebnisse - Write
Das Messergebnis vom Cache Write Benchmark zeigt einen deutlichen Einbruch bei einer Blockgröße von 512 KiB. Dies lässt sich dadurch erklären, dass der L1 Cache nicht benutzt wird, sondern direkt in den L2 Cache geschrieben wird. Sobald dieser komplett gefüllt ist, wird auf den
Arbeitsspeicher zugegriffen, hier fällt die Geschwindigkeit daher stark ab.
26
Cache Read/Modify/Write
Abbildung 3.3: Cachebench Ergebnisse - Read/Modify/Write
Im Benchmark zum Read/Modify/Write sind deutlich zwei Einbrüche in der Performanz zu
erkennen. Einer im Bereich von 64KiB Blockgröße und der Zweite im Bereich von 512KiB Blockgröße. Dies lässt sich darauf zurückführen, dass bei 64KiB Blockgröße der L1 Cache komplett
gefüllt ist, um größere Blöcke zu bearbeiten, müssen diese in den L2 Cache ausgelagert werden,
was sich auf die Bearbeitungsgeschwindigkeit niederschlägt. Der zweite Einbruch lässt sich genauso
erklären, nur hat jetzt der L2 Cache sein Fassungsvermögen erreicht und es muss auf den RAM
zugegriffen werden. Dadurch sinkt die Geschwindigkeit ein weiteres Mal ab.
27
Memory Set
Abbildung 3.4: Cachebench Ergebnisse - Memory Set
Im Benchmark zum Memory Set sind genau wie beim R/M/W Benchmark zwei Einbrüche zu
erkennen. Dies kann mit derselben Begründung erläutert werden.
Der Unterschied zwischen 32 und 64 Bit lässt sich dadurch erklären, dass der Athlon64 im 32 Bit
Modus nur die halbe Registerbreite zur Verfügung hat und somit für die gleiche zu bearbeitende
Datenmenge die doppelte Zeit benötigt.
28
Memory Copy
Abbildung 3.5: Cachebench Ergebnisse - Memory Copy
Der Benchmark lässt die gleichen Rückschlüsse auf das Ergebnis zu wie Memory Set, nur mit
einer Einschränkung: Da bei Memory Copy Speicher-Speicher Transfers ausgeführt werden, wird
der Speicher de facto in zwei Hälften geteilt. Daher finden die Einbrüche auch bei der jeweils
halben Vektorlänge gegenüber Memory Set statt.
29
3.3.2
NBench
Numerische Sortierung
Abbildung 3.6: NBench Ergebnisse - Numerische Sortierung
In dem Diagramm ist zu erkennen, dass 64 Bit Technologie einen leichten Geschwindigkeitsvorteil hat. Diese Differenz ist durch die zusätzlich vorhandenen Register zu erklären. Es ist also
sinnvoll, 64 Bit in einem Bereich einzusetzen, in dem Sortieralgorithmen mittels Bäumen genutzt
werden.
String-Sortierung
Abbildung 3.7: NBench Ergebnisse - String-Sortierung
Es ist zu erkennen, dass der String Sort im 64 Bit Modus deutlich schneller abläuft. Eine
Erklärung liefern die zusätzlichen Register, sowie deren erhöhte Bandbreite, welche die Datenverarbeitung zusätzlich beschleunigt. String-Sortierung findet vermehrte Anwendung in Datenbanken
sowie Betriebssystemen.
30
Bitfeld-Manipulation
Abbildung 3.8: NBench Ergebnisse - Bitfeld-Manipulation
In dem Diagramm ist zu erkennen, dass die Berechnung unter 32 Bit schneller abläuft. Dies
ist darauf zurückzuführen, dass die Bitmasken zur Änderung im 32 Bit Modus schneller generiert
werden können.
Ein Beispiel:
• Original Bitfolge: 10101b
• 3. Bit soll invertiert werden, die Maske hierzu ist 00100b
• XOR mit Original 10101b und Maske 00100b ergibt 10001b (Ergebnis)
Man erkennt, dass eine Maske pro Invertiervorgang generiert und logisch verknüpft werden muss.
Diese Arbeit kann im 32 bit Modus schneller ausgeführt werden, da nur die Hälfte an Bits generiert
werden muss.
31
Gleitkomma-Emulation
Abbildung 3.9: NBench Ergebnisse - Gleitkomma-Emulation
Die Gleitkomma-Emulation hat im 64 Bit Modus einen Vorteil, da sie von den zusätzlich
vorhandenen Registern profitiert. Aufgrund der hohen Speicherlast, die dieser Bechmark fordert,
ist die 64 Bit Architektur wegen der doppelten Registerbreite im Vorteil, da pro Taktzyklus doppelt
so viele Daten verarbeitet werden können.
Fourier-Reihe
Abbildung 3.10: NBench Ergebnisse - Fourier-Reihe
Es ist deutlich ein Leistungsabfall unter 64 Bit zu erkennen, dies lässt sich nicht erklären.
Heise [11, News vom 27.1.03 auf Heise] machte im Jahr 2003 ebenfalls diese Feststellung, äußerte
sich jedoch nicht weiter. Auch in einem Forum[12, NBench Ergebnis] testete ein Benutzer seinen
Prozessor und stellte die Ergebnisse online.
32
Lösung eines Optimierungsproblems
Abbildung 3.11: NBench Ergebnisse - Lösung eines Optimierungsproblems
In diesem Test ist zu bemerken, dass beim 64Bit-Benchmark entsprechend des ’long-integerformat’ berechnungstechnisch ein größerer Zahlenbereich abgedeckt wird (64 anstelle von 32 Bit),
was zur Folge hat, dass abgelegte Daten im Cache mehr Speicherplatz belegen. Dies hat wiederum
zur Folge hat, dass früher in den RAM ausgelagert wird. Diese Performanzeinbußen können wie
ersichtlich auch die acht zusätzlichen Register nicht wettmachen.
IDEA (Verschlüsselung)
Abbildung 3.12: NBench Ergebnisse - IDEA (Verschlüsselung)
Die Verschlüsselung ist unter 64 Bit deswegen schneller, da die höhere Registerbreite es zulässt,
die zu verschlüssenden Blöcke in einem Register zu speichern, während im 32 Bit Modus jeder Block
zweigeteilt abgelegt wird und damit nur in minimal zwei Zyklen bearbeitet werden kann.
33
Huffman (Komprimierung)
Abbildung 3.13: NBench Ergebnisse - Huffman (Komprimierung)
Der 64 Bit Modus ist schneller, da in einem Zyklus wegen der Registerbreite doppelt so viele
Daten komprimiert werden können.
Neuronales Netz
Abbildung 3.14: NBench Ergebnisse - Neuronales Netz
Da für dieses Benchmarkergebnis leider nicht genügend Informationsquellen zur Verfügung
standen, beziehen wir uns lediglich auf das Ergebnis: Es ist ein leichter Geschwindigkeitsvorsprung
im 64Bit-Modus ersichtlich ( 3% Differenz). Da in diesem Benchmark zumeist nur Gleitkommaund Integeroperationen (beides in 32Bit!) durchgeführt werden, ist der Leistungszuwachs möglicherweise auf die zusätzlichen Register zurückzuführen, jedoch nicht durch Fakten (inklusive
Quellen) untermauerbar.
34
LU-Faktorisierung
Abbildung 3.15: NBench Ergebnisse - LU-Faktorisierung
Bei diesem Benchmark zeigt sich ein ähnliches Verhalten wie im zuvor beschriebenen Absatz.
35
3.3.3
SQL-Bench
Tabelle 3.1: SQL-Bench Messergebnisse
32 Bit
64 Bit
ALTER TABLE
22,95s
15,96s
BIG TABLES
8,63s
9,22s
CONNECT
35,07s
36,73s
CREATE
1057,48s 912,45s
INSERT
514,43s 473,98s
SELECT
287,63s 252,86s
64 Bit Technologie ist in allen Tests, bis auf große Tabellen oder den Verbindungsaufbau,
schneller. Es macht also Sinn, einen MySQL Server auf 64 Bit aufzusetzen, da der Nachteil der
langsameren Verbindung durch den restlichen Geschwindigkeitszuwachs meist aufgewogen wird.
Außerdem wird generell versucht, die Tabellengröße möglichst gering zu halten, um aufwendige
Suchen in großen Tabellen zu vermeiden. Wird ein MySQL-Server allerdings z.B. im wissenschaftlichen Bereich eingesetzt, in dem große Tabellen verarbeitet werden, so ist 64 Bit im Nachteil.
Auch häufiger Verbindungsauf- und -abbau bringt bei 64 Bit weniger Performanz.
3.4
Weitere Auswertung und Anmerkungen
Aus den Ergebnissen der NBench- und SQL-Benchmarks wurden zur besseren und genaueren
Übersicht Beschleunigungsfaktoren errechnet.
• NBench
– Numerische Sortierung: 1,141
– String-Sortierung: 1,366
– Bitfeld-Manipulation: 0,858
– Gleitkomma-Emulation: 1,832
– Fourier-Reihe: 0,579
– Lösung eines Optimierungsproblems: 0,959
– IDEA (Verschlüsselung): 1,28
– Huffman (Komprimierung): 1,119
– Neuronales Netz: 1,042
– LU-Faktorisierung: 1,03
– Gesamtbeschleunigung: 1,021
• SQL-Bench
– ALTER TABLE: 0,695
– BIG TABLES: 1,068
– CONNECT: 1,847
– CREATE: 0,863
– INSERT: 0,875
– SELECT: 0,879
– Gesamtbeschleunigung: 0,9045
36
Es gibt zu den Testergebnissen Anmerkungen, welche wir an dieser Stelle nicht vorenthalten
möchten. Dazu gehört die Tatsache, dass die Aktivierung/Deaktivierung von MMX, SSE und SSE2
auf die Testergebnisse keinen Einfluss genommen hat, was durch setzen betreffender USE-Flags
(mmx,sse,sse2) und erneutes Kompilieren der Benchmark-Software mit bzw. ohne entsprechende
Compiler-Flags ermittelt werden konnte. Das folgende Beispiel zeigt den Aufruf zum Kompilieren
mit entsprechenden Compiler-Flags für MMX, SSE sowie SSE2:
g c c <.c−Datei> −03 −p i p e −msse −msse2 −mmmx
Die Untersuchung, in wiefern sich MMX, SSE und SSE2 auf die Verwendung der CPU im 32-/64Bit-Modus auswirken führte durch die genannte Problematik leider ins Leere.
37
Kapitel 4
Fazit
Bevor wir ein geeignetes Fazit aufstellen konnten, mussten wir uns der Tatsache bewusst werden,
dass Benchmarks sowie Datenblätter mitunter schlecht dokumentiert waren, so dass sich Beispiesweise über die Arbeitung von SQL-Befehlen auf einer CPU kein Informationsmaterial finden ließ
(bis auf kilometerlange Quelltexte). Auch die Erklärungen bezüglich Instruktionsgrößen, Befehlspfade und Speicherzugriff wurden unklar erläutert, wodurch das Rückschließen der Ergebnisse auf
architektur- bzw. compilerbedingte Eigenschaften erschwert wurde.
Dennoch ziehen wir folgendes Fazit:
Die neueste Erweiterung der x86er Architektur bringt viele Vorteile mit sich. Zum Einen der
extrem vergrößerte Adressraum, zum Anderen die zusätzlichen und verbreiterten Register. Allerdings muss man bei aller Euphorie ein wenig auf die Bremse treten, denn die Erweiterungen lassen
sich nur dann komplett nutzen, wenn der Anwender ein 64 Bit Betriebssystem besitzt. Da diese
Systeme noch nicht wirklich verbreitet sind, profitieren Anwender im 32 Bit Modus größtenteils
nur von der neuen Hardware (z.B. in die CPU integrierter Speichercontroller), welche die neue
Prozessorgeneration mit sich gebracht hat, nicht jedoch von für die Hardware optimierte Software,
da diese zum größten Teil noch nicht marktreif ist.
Anwender, welche im wissenschaftlichen Bereich oder im Finanzwesen tätig sind, würden von
64 Bit aufgrund der Testergebnisse bei Datenbankanwendungen profitieren (diese werden in den
genannten Bereichen am häufigsten genutzt), auf Grund der schnelleren Verarbeitung von 64BitDatentypen und der Tatsache, dass mehr RAM adressiert und somit genutzt werden kann (Datenbanken sind meist speicherlastig). Auch Grafikdesigner können von der 64Bit-Architektur Performancegewinne spüren, da Kompressionsverfahren schneller abgewickelt werden können und für
langwierige und komplexe Bearbeitung ebenfalls mehr physikalischer RAM-Speicher nützlich ist.
38
Abbildungsverzeichnis
1.1
1.2
1.3
1.4
1.5
Aufbau der 286er Architektur . .
Ringmodell des Protected Mode .
Aufbau der 386er Architektur . .
Aufbau der AMD64 Architektur
Das Speichersystem im Athlon64
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
7
10
13
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
Cachebench Ergebnisse - Read . . . . . . . . . . . . . . .
Cachebench Ergebnisse - Write . . . . . . . . . . . . . . .
Cachebench Ergebnisse - Read/Modify/Write . . . . . . .
Cachebench Ergebnisse - Memory Set . . . . . . . . . . .
Cachebench Ergebnisse - Memory Copy . . . . . . . . . .
NBench Ergebnisse - Numerische Sortierung . . . . . . . .
NBench Ergebnisse - String-Sortierung . . . . . . . . . . .
NBench Ergebnisse - Bitfeld-Manipulation . . . . . . . . .
NBench Ergebnisse - Gleitkomma-Emulation . . . . . . .
NBench Ergebnisse - Fourier-Reihe . . . . . . . . . . . . .
NBench Ergebnisse - Lösung eines Optimierungsproblems
NBench Ergebnisse - IDEA (Verschlüsselung) . . . . . . .
NBench Ergebnisse - Huffman (Komprimierung) . . . . .
NBench Ergebnisse - Neuronales Netz . . . . . . . . . . .
NBench Ergebnisse - LU-Faktorisierung . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
27
28
29
30
30
31
32
32
33
33
34
34
35
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
3.1
SQL-Bench Messergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
36
Literaturverzeichnis
[1] The Cachebench Report1 , Ein Cachebench Bericht mit guter Einführung und einigermaßen
verständlicher Erklärung, November 1998
[2] TecChannel Benchmark2 , Mehr Performance: Linux mit 64-Bit-Programmen, Mai 2005
[3] NBench/BYTEmark Documentation3 , 2005
[4] AMD64 Architecture Programmers Manual Volume 1: Application Programming4 , September
2007
[5] AMD64 Architecture Programmers Manual Volume 2: System Programming5 , September
2007
[6] AMD64 Architecture Programmers Manual Volume 3: General-Purpose and System Instructions6 , September 2007
[7] Software Optimization Guide for AMD64 Processors7 , September 2005
[8] BIOS and Kernel Developers Guide for AMD AthlonTM 64 and AMD OpteronTM Processors8 , Februar 2006
[9] AMD Functional Data Sheet, 939-Pin Package9 , Mai 2005
[10] Performance Characterization of SPEC CPU2006 Integer Benchmarks on x86-64 Architecture10 , 2006
[11] Athlon 64: Bis zu 50 Prozent mehr Performance im 64-Bit-Modus11 , 27. Januar 2003
[12] Re: Erfahrungen mit 64Bit-Linux gesucht, Seite 112 , 27.10.2007
[13] The Branch Selectors13
[14] RST.pdf14
1 http://icl.cs.utk.edu/projects/llcbench/cachebench.pdf
2 http://www.tecchannel.de/server/linux/429791/
3 http://www.byte.com/bmark/bdoc.htm
4 http://www.amd.com/us-en/assets/content
type/white papers and tech
type/white papers and tech
6 http://www.amd.com/us-en/assets/content type/white papers and tech
7 http://www.amd.com/us-en/assets/content type/white papers and tech
8 http://www.amd.com/us-en/assets/content type/white papers and tech
9 http://www.amd.com/us-en/assets/content type/white papers and tech
10 http://www.iiswc.org/iiswc2006/IISWC2006S2.2.pdf
11 http://www.heise.de/newsticker/meldung/33991
12 http://www.meinews.net/showpost.php?p=665338&postcount=5
13 http://www.chip-architect.com/news/2003 09 21 Detailed Architecture
14 http://www.weblearn.hs-bremen.de/risse/RST/docs/RST.pdf
5 http://www.amd.com/us-en/assets/content
41
docs/24592.PDF
docs/24593.PDF
docs/24594.PDF
docs/25112.PDF
docs/26094.PDF
docs/31411.PDF
of AMDs 64bit Core.html#4.7