next up previous contents
Next: Guaranteed Percentage Up: Simulationsaufbau Previous: Aufwand   Inhalt


Testumgebung

Die in Java geschriebene Testumgebung, in die der Scheduler zunächst für die Versuche eingebettet wird, ist in Abbildung 3.2 dargestellt und besteht aus vier Teilen, die jeweils in einer Klasse implementiert sind:

Abbildung 3.2: Aufbau des Software-Simulators

Zusätzliche Hilfsklassen verwalten Konstanten und Konfigurationsdaten, die als Kommandozeilenparameter übergeben werden können. Eine Übersicht über die Kommandozeilenoptionen befindet sich in Anhang B.

Der Scheduler selbst besteht aus einer Klasse, die die allgemeinen Aufgaben erledigt, und mehreren davon abgeleiteten Klassen, die für das eigentliche Scheduling zuständig sind, also die Berechnung der Prioritäten. Das ist der Teil, der in Abbildung 3.2 schattiert dargestellt ist.

Da dieser Simulator keine Execute-Stufe enthält, kann er keine echten Java Bytecodes ausführen. Daher ist es auch nicht notwendig, sie zu dekodieren. Vielmehr werden die Bytecodes in Klassen eingeteilt und aus jeder Klasse nur ein Vertreter verwendet. Eine Klasse ist bestimmt durch die Länge der enthaltenen Bytecodes, die auftretenden Latenzen und die benötigte Ausführungszeit.

Aus diesen Klassen werden Pseudoprogramme gebildet, indem zufällig eine Klasse ausgewählt und ihr Vertreter in die Programmdatei geschrieben wird. Das Verhältnis der verschiedenen Klassen zueinander wird anhand der Caffeine-Benchmarks ausgezählt. Der Anteil der Speicherbefehle kann zusätzlich variiert werden, um sehr speicherintensive Programme simulieren zu können.

Andererseits ist es auch möglich, reale Programme in ihrem Ablaufverhalten nachzubilden. Dazu wird ein Java-Programm auf einem Simulator ausgeführt, der jeden Befehl mitprotokolliert und dadurch einen Trace erzeugt, der den genauen Ablauf des Programms wiederspiegelt. Jeder Bytecode wird dann mit einem Zusatzprogramm auf die Klassen abgebildet.

Die Klassen von Befehlen, die in der Simulation unterschieden werden, sind in Tabelle 3.2 zusammengefaßt. Die Klassen der Microcodes und der Trap-Routinen teilen sich noch in mehrere Unterklassen auf, abhängig von deren Länge und Latenzverhalten.

In der Prozessorarchitektur beschreibt die Latenz üblicherweise die Verweildauer eines Befehls in einer Pipeline, ist also mindestens eins. Hier beschreibt die Latenz wie im mehrfädigen Prozessorentwurf die Anzahl der Takte, die nach einem Befehl kein weiterer Befehl des selben Thread folgen darf. Diese entsprechen in einem einfädigen Prozessor der Anzahl der Leertakte. Die Laufzeit für den Aufruf einer Trap-Routine setzt sich aus den Takten des Aufrufs und denen für den Rücksprung zusammen.


Tabelle 3.2: Die Klassen von Bytecodes
Name Länge Latenzen[*] Laufzeit Anteil
  (Bytes) (Takte) (Takte) (%)
1-Byte-Befehle 1 0 1 37,0
2-Byte-Befehle 2 0 1 33,8
3-Byte-Befehle 3 0 1 1,6
Speicher 2 1 1 13,3
Sprünge 3 2 1 13,2
Sammelklassen:        
Microcode 1 oder 2 1 oder 2 mehrere 0,7
Traps 1 oder 3 2 14+7 0,4

Die Latenzen werden in der zweiten Versuchsreihe in Abschnitt 3.4 genauer betrachtet.

Der Vorteil dieser Versuchsanordnung ist, daß man die Programme sehr einfach variieren kann, ohne ein lauffähiges Programm schreiben zu müssen, das genau den gewünschten Anteil an Speicherzugriffen enthält. Durch die Softwareimplementierung können auch Situationen simuliert werden, die in Hardware so nicht möglich wären, etwa latenzfreie Sprünge, die nur mit einem Branch-Target-Buffer und einer perfekten Sprungvorhersage realisierbar wären.

Der Scheduler legt eine nach Priorität sortierte Liste aller lauffähigen Threads an, aus der im nächsten Takt vor dem Dekodieren nur noch einer der beiden vorderen Einträge ausgewählt werden muß. Wenn der höchstpriorisierte Thread im vorangegangenen Takt keine Latenz erzeugt hat, wird er ausgeführt, sonst der zweite in der Liste. An dieser Stelle kann nur noch dieser eine Thread ungültig werden, da die Ausführbarkeit für alle anderen Threads schon vor dem Scheduling feststeht.


next up previous contents
Next: Guaranteed Percentage Up: Simulationsaufbau Previous: Aufwand   Inhalt
Alexander Schulz
2000-06-18