Ein Werkzeug zur Untersuchung des Cacheverhaltens von Datenstrukturen mittels Ereigniszählern. Tobias Gaugler

Größe: px
Ab Seite anzeigen:

Download "Ein Werkzeug zur Untersuchung des Cacheverhaltens von Datenstrukturen mittels Ereigniszählern. Tobias Gaugler"

Transkript

1 Ein Werkzeug zur Untersuchung des Cacheverhaltens von Datenstrukturen mittels Ereigniszählern Tobias Gaugler

2

3 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Diplomarbeit Ein Werkzeug zur Untersuchung des Cacheverhaltens von Datenstrukturen mittels Ereigniszählern Tobias Gaugler Aufgabensteller : Prof. Dr. W. Karl Betreuerin : Dr. Jie Tao Tag der Anmeldung : 07. Oktober 2005 Tag der Abgabe : 06. April 2006 Institut für Technische Informatik Prof. Dr. W. Karl Prof. Dr. J. Henkel Prof. Dr.-Ing. R. Dillmann Prof. Dr.-Ing. U. Hanebeck Fakultät für Informatik Universität Karlsruhe (TH) Institut für Technische Informatik

4

5 Erklärung Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe angefertigt zu haben. Die verwendeten Hilfsmittel und Quellen sind im Literaturverzeichnis vollständig aufgeführt. Karlsruhe, den 06. April 2006 (Tobias Gaugler)

6

7 Inhaltsverzeichnis 1 Einführung Motivation Ziel dieser Arbeit Gliederung dieser Arbeit Stand der Forschung gprof tprof ompp qprof Cache Scope HP Caliper Intel VTune Diskussion Grundlagen Cache Architektur des Itanium2 Prozessors Ereigniszähler Performance Counter Register Das Format der pmd-register Das Format der pmc-register weitere Register zur Steuerung der PMU Zusammenfassung: Programmierung der PMU Zusätzliche Register der Itanium2 PMU Techniken zum Auslesen der Ereigniszähler Sampling von Cache-Fehlzugriffen Probleme beim zeitbasierten Sampling Probleme beim ereignisbasierten Sampling Lösung: Event Address - Register Werkzeuge zum Lesen von Ereigniszählern perfmon pfmon I

8 Inhaltsverzeichnis 3.6 Visualisierung von Cache-Fehlzugriffen mit YACO Der Profiler dataprof Design und Implementierung Auslesen der Ereigniszähler Zuordnung der Ereigniszähler-Daten zu Datenstrukturen statische Datenstrukturen dynamische Datenstrukturen Analyse der aufgezeichneten Daten und textuelle Ausgabe Ausgabe für YACO Verwendete Datenstrukturen Overhead Overhead durch Instrumentierung Overhead durch Sampling Beschränkungen Diskussion Ergebnisse Experimenteller Aufbau Testergebnisse Finden von Programm-Engpässen mit dataprof Qualität der gewonnenen Daten Zuordnungsrate Zusammenfassung und Ausblick Zusammenfassung Ausblick A Ausgabe von pfmon 71 B Leistungsdaten des CG-Benchmarks 73 II

9 Abbildungsverzeichnis 3.1 Itanium2 Prozessor-Block-Diagramm (aus [Rus04].) PMU Register der Itanium Architektur Das Format der Register pmd4 pmd7 auf dem Itanium Das Format der Register pmc4 pmc7 auf dem Itanium Das Format der Register pmc0 pmc3 auf dem Itanium Aktivieren eines Ereigniszählers Ungenauigkeit des zeitbasierten Samplings Ungenauigkeit des ereignisbasierten Samplings Die Register des D-EAR beim Itanium2 Prozessor. Für die Register pmd2, pmd3 und pmd17 ist die Konfiguration im Cache-Modus dargestellt Das Ergebnis einer Abtastung des D-EAR Sampling der D-EAR mit perfmon YACO in der Übersichts-Ansicht; zur Markierung der einzelnen Fenster sind diese durchnummeriert YACO: Fehlzugriffe nach Datenstrukturen Anzeige der 3D-Phasen mittels YACO Der Ablauf einer Leistungsanalyse mit dataprof Sampling der Event-Address -Register mit pfmon Der generelle Aufbau eines virtuellen Adressraums eines Prozesses unter Linux. Die Bereiche, in denen dataprof Datenstrukturen erkennen und zuordnen kann, sind schraffiert dargestellt Die Ausgabe von mit dataprof gelieferten Daten mit YACO Die verwendete Datenstruktur bei der Ansicht pro Datenstruktur Die verwendete Datenstruktur bei der Ansicht pro Funktion und pro Quellcodezeile Die Zuordnungsrate der Fehlzugriffe zu einzelnen Datenstrukturen bei Benchmarks aus der NPB-Suite III

10 Abbildungsverzeichnis IV

11 Kapitel 1 Einführung 1.1 Motivation Die Lücke zwischen Prozessor- und Speichergeschwindigkeit wird immer größer. Deshalb ist es wichtig, den Zugriff auf den Speicher zu optimieren. Um den Geschwindigkeitsunterschied zu überbrücken, werden so genannte Cache-Speicher zwischen den Registern des Prozessors und dem Hauptspeicher benutzt. Diese schnellen Zwischenspeicher sollen die zeitliche und räumliche Lokalität der zugegriffenen Datenadressen ausnutzen, um den Prozessor möglichst schnell mit Daten zu versorgen. Diese Cache-Speicher sind jedoch in ihrer Größe sehr beschränkt, und die Daten werden, je nach Organisationsart der Caches, schneller oder weniger schnell wieder aus dem Cache verdrängt. Bei einem weiteren Zugriff auf ein verdrängtes Datum kommt es zu einem Fehlzugriff und das Datum muss wieder aus dem Hauptspeicher nachgeladen werden, was wiederum Zeit kostet. Deshalb ist es nötig, darauf zu achten, dass die Cache-Speicher optimal ausgenutzt werden und die Datenstrukturen, auf die zugegriffen wird, möglichst optimal im Cache abgelegt werden. Für Programmierer ist der Cache-Speicher weitgehend transparent, d.h. er hat keinen direkten Zugriff auf den Cache. Um jedoch ein Programm zu optimieren, d.h. es schneller zu machen, ist neben der Optimierung der benutzten Algorithmen auch nötig, den Zugriff auf den Speicher zu verbessern. So ist es für einen Programmierer auch wichtig zu wissen, wie gut der Cache ausgenutzt wird. Um dies herauszufinden, gibt es dreierlei Möglichkeiten: Einerseits kann man mit mathematischen Methoden das Verhalten des Programms anhand des Quellcodes modellieren, wie dies beispielsweise von Compilern getan wird [Gho00][Riv98]. Die Integration solcher Modelle in den Compiler ist jedoch sehr komplex und es werden zur Analyse auch nur statische Daten verwendet. Das dynamische Verhalten zur Laufzeit von Programmen kann nicht untersucht werden. Eine zweite Methode ist die Benutzung von Cache-Simulatoren [CAC06][Tao05], die alle Lade- und Schreiboperationen aufzeichnen und das Cacheverhalten anhand eines vorgegebenen Caches durchrech- 1

12 Kapitel 1. Einführung nen. Diese Methode liefert zwar sehr detaillierte Daten über das Cache-Verhalten eines Programms, die Güte dieser Daten ist jedoch vom Simulator abhängig. Ein großer Nachteil bei der Verwendung von Simulatoren ist zudem, dass die Laufzeit des Programms bis zu 1000 mal länger dauert als die Ausführung ohne Simulator. Die dritte Methode ist die Verwendung von so genannten Ereigniszählern 1. Damit können hardwareseitig Ereignisse aufgezeichnet werden und der Programmierer hat direkt nach Ausführung des Programms Ergebnisse. Diese Herangehensweise ist die direkteste und wird auch im folgenden gewählt. Die meisten aktuellen Prozessoren verfügen über eine so genannte Performance Monitoring Unit (PMU), eine Hardware-Einheit, die zur Laufzeit Daten über das ausgeführte Programm sammelt. Die PMU besteht aus Kontroll- und Datenregistern, die als Ereigniszähler bezeichnet werden, und die programmiert werden können, unterschiedliche Ereignisse aufzuzeichnen. Es kann beispielsweise die Anzahl der CPU-Zyklen oder die Anzahl der ausgeführte Befehle beobachtet werden, aber auch Cache- oder TLB-Fehlzugriffe können beobachtet werden. Die Anzahl der Ereigniszähler und die Anzahl der erfassbaren Ereignisse variiert von Prozessor zu Prozessor sehr stark. So stellt die UltraSPARC IIIi [Sun03] Architektur beispielsweise Zwei Zähler bereit, um 70 verschiedene Ereignisse wie Cache-Fehlzugriffe, Fließkomma-Operationen, Sprungvorhersagen oder CPU-Zyklen zu beobachten. Der Intel Pentium IV Prozessor [Inta] stellt gar 18 Zähler bereit, um auch genauere Daten wie Pipelinekonflikte darzustellen. Im folgenden wird die PMU des Intel Itanium2 Prozessors [Int04] benutzt, die es erlaubt, bis zu vier Ereignisse gleichzeitig zu beobachten. Neben der bei allen PMUs vorhandene Möglichkeit des Zählens von Ereignissen, stellt diese PMU auch die Fähigkeit bereit, zusammen mit Cache-Fehlzugriffen die genauen Daten- und Befehlsadressen zu liefern, bei denen Fehlzugriffe aufgetreten sind. Dadurch ist es möglich, gezielt Datenstrukturen zu benennen, deren Zugriff einen Engpässe im Programm darstellt. Bei bisherigen Lösungen ist meistens nur eine zeitliche Analyse des Programms möglich, wobei immer nur Programmteile angegeben werden können, in denen Engpässe vorliegen. In der vorliegenden Arbeit wird jedoch ein datenstrukturorientierter Ansatz benutzt, der es ermöglicht, direkt Datenstrukturen zu benennen, bei denen Fehlzugriffe aufgetreten sind. Dadurch wird es für den Programmierer direkt möglich, den Zugriff auf diese Datenstrukturen zu verbessern bzw. die Speicherbereiche, die diese Datenstrukturen nutzt, besser an den Cache anzupassen. Die hier vorgestellte Lösung bietet zudem die Möglichkeit, bis auf einzelne Hauptspeicherblöcke genau anzugeben, wo ein Fehlzugriff aufgetreten ist. Dadurch können einzelne Elemente von Arrays ausgemacht werden, bei deren Zugriff viele Cache-Fehlzugriffe aufgetreten sind. So kann die Optimierung sehr detailliert erfolgen. Da die erhaltenen Ergebnisse sehr komplex sein können und es für einen Menschen sehr viel einfacher ist, Zusammenhänge zu erfassen, wenn diese graphisch dargestellt werden, ermöglicht es das in dieser Arbeit erstellte Werkzeug auch, die Ergebnisse als Eingabe für 1 Im Englischen werden diese auch als Performance Counter bezeichnet. 2

13 1.2. Ziel dieser Arbeit das am Institut für Technische Informatik der Universität Karlsruhe (TH) erstellte Visualisierungswerkzeug YACO [Qua05] aufzubereiten. 1.2 Ziel dieser Arbeit Bisherige Werkzeuge zur Untersuchung des Laufzeitverhaltens von Programmen stellen Methoden bereit, um Programmbereiche ausfindig zu machen, in denen besonders viel Zeit verbracht wird. Diese Werkzeuge zeigen einem Programmierer zwar auf, dass er sein Programm optimieren soll und zeigen ihm auch Stellen im Programmcode, an denen er ansetzen kann, den eigentlichen Grund für die Programmverzögerung an den gezeigten Stellen geben sie jedoch nicht. An genau diesem Punkt setzt das im folgenden vorgestellte Werkzeug dataprof an. Ziel dieses Werkzeugs ist es, unter Verwendung von Ereigniszählern, Cache-Fehlzugriffe zu beobachten und diese zurück auf Datenstrukturen abzubilden. Dadurch ist es für einen Programmierer direkt ersichtlich, welche Datenstrukturen er verbessern muss, um das Laufzeitverhalten seines Programms zu verbessern. Um den Programmierer noch weiter zu unterstützen soll es auch, wie bisherige Werkzeuge, direkt Programmteile identifizieren, in denen viel Zeit verbraucht wurde. Als zusätzliche Eigenschaft soll es auch Eingabedaten für das vorhandene Visualisierungswerkzeug YACO liefern, um auch das Cache-Verhalten einer Datenstruktur auf Hauptspeicherblockgröße zu beobachten. 1.3 Gliederung dieser Arbeit Kapitel 2 beschäftigt sich zunächst mit existierenden Werkzeugen, mit denen bereits das Laufzeitverhalten von Programmen untersucht werden kann. In Kapitel 3 wird daraufhin erst einmal die eingesetzte Cache-Architektur des Intel Itanium Prozessors beschrieben. In weiteren Abschnitten des Kapitels wird auf die eingesetzten Ereigniszähler des Prozessors genauer eingegangen und es werden Werkzeuge zum Lesen der Ereigniszähler vorgestellt. Zudem wird am Ende des Kapitels das Visualisierungswerkzeug YACO vorgestellt. Kapitel 4 stellt dann das Programm dataprof vor, das im Rahmen dieser Diplomarbeit geschrieben wurde. Es wird auch bereits auf Vor- und Nachteile eingegangen. Im Kapitel 5 wird anhand von Messungen gezeigt, wie mit dataprof Datenstrukturen, deren Zugriff optimiert werden sollte, erkannt werden und wie genau die Erkennungsrate bei vorhandenen Benchmarks ausfällt. In Kapitel 6 erfolgt eine Zusammenfassung der Arbeit und ein Ausblick auf weitere Arbeiten. 3

14 Kapitel 1. Einführung 4

15 Kapitel 2 Stand der Forschung In diesem Kapitel sollen existierende Profiler dargestellt werden. Als Profiler bezeichnet man Programme, mit denen man das Laufzeitverhalten von Software analysieren kann. Ein Profiler hilft einem Entwickler, Problembereiche in seinem Programm zu finden, an denen besonders viel Zeit verbraucht wird. Mit den meisten Profilern ist es möglich, die Ausführungszeit für bestimmte Code-Bereiche zu messen. Daneben stellen viele die Möglichkeit bereit, Aufrufgraphen von Funktionen zu erstellen, womit der zeitliche Zusammenhang unterschiedlicher Programmabschnitte dargestellt wird. Neben der Messung des rein zeitlichen Ablaufs von Programmen gibt es auch Profiler, die beispielsweise die Nutzung der Cache-Speicher oder die Trefferrate von Cache-Zugriffen messen und so indirekt Bereiche anzeigen, in denen viel Zeit verbracht wird. Dadurch wird direkt auf den Grund von Fehlzugriffen eingegangen. Mit einem Profiler ist es so möglich, Engpässe in einem Programm zu erkennen. Je genauer die Ausgabe eines Profilers ist und je genauer er Angaben über die Lage und den Grund eines Engpasses in einem Programm macht, desto leichter ist es für den Programmierer, diesen zu erkennen und zu beseitigen. Um ein Profil einer Anwendung zu erhalten gibt es zweierlei Techniken. Auf der einen Seite werden die zu untersuchenden Programme instrumentiert, d.h. es werden bestimmte Marken ins Programm eingetragen, an denen dann Messungen erfolgen. Das Programm wird so verändert, um die gewünschten Performance-Daten zu erhalten. Bei der Instrumentierung unterscheidet man zwischen verschiedenen Typen: manuelle Instrumentierung: es werden von Hand bestimmte Marken im Quellcode gesetzt, welche später vom Profiler erkannt und ausgewertet werden. Instrumentierung durch den Compiler: durch spezielle Compiler Optionen werden Marken gesetzt (beispielsweise gcc -pg), eine Veränderung des Quellcodes ist nicht nötig. Laufzeit-Instrumentierung: zur Laufzeit werden bestimmte Marken in das Programm eingefügt. Es ist nicht nötig, das Programm neu zu übersetzen oder gar den Quellco- 5

16 Kapitel 2. Stand der Forschung de zu verändern. Dadurch ist es auch möglich, Programme zu untersuchen, die nicht im Quellcode vorliegen. Die andere Methode ist das Sampling, welches in Kapitel 3.4 genauer beschrieben wird. Damit ist es möglich, ohne Veränderung eines Programms Leistungsdaten zu erhalten. Traditionelle Profiler benutzen zeitbasiertes Sampling, wodurch sie Leistungsangaben in bestimmten Zeitabschnitten erhalten. Darüber hinaus ist es auch möglich, nach einer bestimmten Anzahl von Ereignissen eine Messung durchzuführen, wobei man dann von ereignisbasiertem Sampling spricht. Es ist zu beachten, dass sowohl durch Instrumentierung der Anwendung als auch durch Sampling ein gewisser Overhead entsteht, welcher das Laufzeitverhalten des Programms verändern kann. Deshalb sollte dieser Overhead möglichst klein gehalten werden. Oftmals benutzen Profiler auch kombinierte Verfahren aus Sampling und Instrumentierung. Im folgenden sollen nun existierende Profiler kurz zusammen mit ihren Vor- und Nachteilen beschrieben werden. Die vorgestellten Programme können in unterschiedliche Klassen und ihrer Tauglichkeit, Engpässe zu lokalisieren, eingeteilt werden. Einerseits gibt es die klassischen Profiler. Deren Ergebnisse sind beschränkt auf das Anzeigen von quellcodebasierten Werten. Dadurch kann zwar dem Programmierer in Form von Quellcodezeilenangaben angezeigt werden, wo ein Engpass in seinem Programm vorliegt, aber der Grund für die Schwachstelle kann damit nicht ausgemacht werden. Mit erweiterten Profilern ist es auch möglich, datenstrukturorientierte Messungen vorzunehmen und somit auf die Ursachen dieser Engpässe hinzudeuten. 2.1 gprof gprof ist eine Kommandozeilen-Werkzeug, welches sehr einfach die Performance Merkmale eines Programms messen kann. Es ist einzuordnen in die Klasse der klassischen Profiler. Damit können sowohl flache Profile, d.h. Profile, welche die Laufzeiten von einzelnen Funktionen oder Code-Zeilen anzeigen, als auch Aufrufgraphen erstellt werden. gprof ist ein compilerinstrumentierter Profiler. Um ein ein Programm mit gprof zu untersuchen, ist es notwendig, es mit der Option -pg zu übersetzen. Bei der Ausführung des Programms wird dann eine Datei erstellt, mit welcher gprof eine Leistungsanalyse durchführen kann. Mittels eingefügten Marken wird hierbei unter Zuhilfenahme von Sampling ein Leistungsprofil erstellt. Durch Aufruf von gprof unter Angabe der erstellten Datei und des zu untersuchenden Programms kann daraufhin ein Leistungsbericht ausgegeben werden, der anzeigt, in welchen Funktionen wie viel Zeit verbracht wurde und wie oft diese aufgerufen wurden. Dies ist auch auf Ebene einzelner Code-Zeilen möglich. Es gibt unterschiedliche Ausführungen von gprof. Eine, die nur single-threaded Programme untersuchen kann, wird vom GNU Projekt [GNU05] bereitgestellt. Bei dieser können zwar theoretisch auch multi-threaded Programme untersucht werden, aber jeder durch fork() 6

17 2.2. tprof erzeugte Kind-Prozess überschreibt die Ausgabedatei von gprof. Eine Version für parallele Systeme, die für jeden Kind-Prozess eine eigene Datei anlegt, gibt es beispielsweise für AIX [IBM05]. Vorteile + Anzeige des Aufrufgraphen. + Anzeige, wie oft eine Funktion/Code-Zeile aufgerufen wurde. Nachteile Eingeschränkte Unterstützung von multi-threaded Programmen Nur Zeitmessung, keine Angabe über Cache-Fehlzugriffe. Keine datenorientierten Messungen möglich, d.h. keine Angabe über den Grund, warum in einer Funktion/Zeile so viel Zeit verbraucht wurde. Keine Unterstützung von Ereigniszählern. Beispiel: Das folgende Beispiel aus der Dokumentation von gprof [GNU05] zeigt die Ausgabe eines flachen Profils von gprof. Es wird für jede Funktion angegeben, wie oft die jeweilige Funktion aufgerufen wurde, und wie viel Zeit darin verbracht wurde. Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name open offtime memccpy write mcount tzset 2.2 tprof Der tprof Profiler [IBM05] erlaubt es, die CPU Nutzung sowohl individueller Programme als auch des ganzen Systems zu beobachten. Er ist ebenso wie gprof ein klassischer Profiler. Er zeigt an, welches Programm- oder Programmteil die meiste CPU-Zeit benötigt. Die Messung erfolgt hierbei mittels zeitbasiertem Sampling, wobei keine Veränderung am Ursprungsprogramm nötig ist, d.h. es erfolgt keine Instrumentierung. Um jedoch für jede 7

18 Kapitel 2. Stand der Forschung Code-Zeile Ausgaben zu erhalten, ist bei der Programmübersetzung zu beachten, Debug- Symbole mit einzubinden (Option -g). Mit tprof ist es im Gegensatz zu gprof nicht möglich, Aufrufgraphen zu erstellen. Allerdings ist es möglich, für alle Programme auf dem System, für jedes Unterprogramm und auch für den Kern Leistungsdaten zu sammeln. Somit ist es möglich, Programme mit mehreren Threads zu beobachten. Vorteile + Keine Instrumentierung nötig. + Systemweites Beobachten möglich, d.h. es können auch multi-threaded Programme untersucht werden. Nachteile Keine Aufrufgraphen. Nur Untersuchung der Laufzeit, keine datenorientierte Messung möglich. Keine Unterstützung von Ereigniszählern. 2.3 ompp Speziell für die Analyse von OpenMP Anwendungen existiert der Profiler ompp [Für05]. Dieser kann durch Instrumentierung der OpenMP-Konstrukte [Ope05] Leistungsdaten für jede instrumentierte Region liefern. Die Instrumentierung erfolgt dabei automatisiert durch Einfügen von POMP Anweisungen mittels opari [Moh01]. Somit ist es möglich, pro Thread die Zeit und Anzahl für die Ausführung einer Region, von Barrieren, von parallelen Bereichen, von section - und single -Bereichen, und von kritischen Bereichen zu messen. OmpP ist auch als klassischer Profiler zu betrachten. Vorteile + Volle Unterstützung von multi-threaded OpenMP Programmen. + Speziell auf OpenMP Anwendungen zugeschnitten. Nachteile Es wird nur die Zeit für einzelne Regionen gemessen, d.h. es wird keine datenorientierte Untersuchung durchgeführt. Keine direkte Verknüpfung mit dem Quellcode möglich. Keine Unterstützung von Ereigniszählern. 8

19 2.4. qprof Beispiel: Das folgende Beispiel aus [Für05] zeigt, wie man mit ompp Load-Balancing Probleme von OpenMP Programmen erkennen kann. In der Spalte exitbart ist deutlich zu erkennen, dass die Threads Null und Eins etwa gleichviel Zeit verbraucht haben wohingegen die Threads Zwei und Drei beinahe keine Zeit verbraucht haben. Dies zeigt ein Problem bei der Lastverteilung an. TID exect execc exitbart exitbarc * Die Spalte exect steht hierbei für die gesamte Ausführungszeit jedes Threads und execc für die Anzahl der Ausführungen jedes Threads. ExitBarT steht für die Zeit, in der ein Thread in OpenMP exit barriers von Worksharing-Konstrukten verbracht hat. Entsprechend steht exitbarc dafür wie oft ein Thread in exit barriers war. 2.4 qprof qprof [Boe03] ist ein Kommandozeilen-Profiler für Linux. Es werden mehrere Hardware- Plattformen unterstützt, wobei auf Itanium Prozessoren auch mittels Ereigniszählern Leistungswerte erfasst werden können. Ansonsten wird normales zeitbasiertes Sampling benutzt. Eine Instrumentierung ist nicht nötig. Dadurch können auch Informationen über dynamisch gebundene Bibliotheken gesammelt werden. Mit qprof ist es möglich, auch multi-threaded Programme zu untersuchen. Es können allerdings nur flache Profile erstellt werden, d.h. es können keine Zusammenhänge zwischen einzelnen Code-Bereichen erkannt werden. Die Ausgabe von qprof gibt an, in welchen Bereichen, d.h. in welchen Funktionen, Zeilen oder Befehlen, Zeit verbraucht wurde. Auf dem Itanium können mittels der Ereigniszähler beispielsweise auch Fehlzugriffe in bestimmten Code-Bereichen dargestellt werden. Es ist zu beachten, dass die Ergebnisse von qprof sowohl die Systemals auch die Benutzerebene mit einschließen. Da es nicht möglich ist, mittels qprof Angaben über die genaue Quelle von Leistungsengpässen zu erhalten 1, ist qprof als klassischer Profiler zu betrachten. Vorteile + Auf Itanium auch Unterstützung von Ereigniszählern. + Volle Unterstützung von multi-threaded Programmen. 1 d.h. es werden nur Quellcode-Bereiche angegeben, wo viel Zeit verbracht wurde und nicht die Datenstrukturen selbst, bei deren Zugriff die Zeit verbraucht wurde. 9

20 Kapitel 2. Stand der Forschung + Sehr feine Granularität bis auf die Befehlsebene. + Keine Beschränkung auf Messung von Laufzeit. Nachteile Nur flache Profile werden unterstützt; keine Aufrufgraphen. Keine datenorientierten Messungen möglich. Beispiel: In nachfolgendem kurzen Beispiel wird gezeigt, in welchen Quellcodezeilen eines Programms die meiste Zeit verbraucht wird (Quelle: [Boe03]). $./a.out qprof: /home/hboehm/qprof/a.out: 118 samples, 118 counts main:dumb_test.c:34 47 ( 40%) main:dumb_test.c:35 47 ( 40%) main:dumb_test.c:36 24 ( 20%) 2.5 Cache Scope Cache Scope [Buc04] ist ein Profiler zur Untersuchung von Programmen unter Berücksichtigung ihrer L1-Cache Fehlzugriffe und der Latenz für die Auflösung derselben. Es ist mit diesem Profiler möglich, sowohl datenorientiert als auch quellcodeorientiert Programme zu untersuchen. Somit kann in Programmen gezielt nach Datenstrukturen und Funktionen, in welchen die meiste Zeit verbraucht wird, gesucht werden. Cache Scope benutzt dazu die PMU des Itanium Prozessors um genaue Informationen über die Cache- Fehlzugriffe von Programmen zu erhalten. Um die mit den Ereigniszählern gewonnenen Daten den entsprechenden Datenstrukturen zuzuordnen, ist es nötig zu wissen, wo diese im Speicher liegen. Deshalb werden dynamische Datenstrukturen zur Laufzeit instrumentiert. Die Messung selbst erfolgt mittels Sampling der Event-Address -Register. Durch diesen Ansatz, können Datenstrukturen gefunden werden, in welchen die meiste Zeit verbracht wird. Die Ausgabe dieses Profilers erfolgt mittels eines Java Programms, welches tabellarisch die Engpässe anzeigt. Eine weitere graphische Ausgabe ist nicht möglich. Ebenfalls ist nicht vorgesehen, multi-threaded Programme zu untersuchen. Vorteile + Laufzeit-Instrumentierung, d.h. die zu untersuchenden Programme müssen nicht speziell angepasst werden; Debug-Symbole in den zu untersuchenden Programmen sind aber von Vorteil, um die einzelnen Funktionen zu ermitteln. 10

21 2.6. HP Caliper + Sowohl eine datenorientierte als auch eine quellcodeorientierte Untersuchung der Programme ist möglich, wodurch auch auf die Ursache von Engpässen in Programmen hingedeutet wird. Nachteile Keine Unterstützung von multi-threaded Programmen. Die graphische Ausgabe erfolgt nur tabellarisch. 2.6 HP Caliper HP Caliper [Hew05a] ist ein kommerzieller Kommandozeilen-Profiler von Hewlett Packard für Linux oder HP-UX auf der Itanium Architektur. Es können umfangreiche Leistungsberichte in unterschiedlichen Formaten erstellt werden. Um eine Leistungsanalyse eines Programms durchzuführen, ist es nicht notwendig, dieses neu zu übersetzen; die Instrumentierung erfolgt zur Laufzeit. Die Messungen von HP Caliper erfolgen mittels der PMU des Itanium Prozessors. Ein großer Teil der Fähigkeiten der PMU wird dabei ausgenutzt. Es ist sowohl die Beobachtung einzelner Threads als auch von multi-threaded Programmen oder des gesamten Systems möglich, sowohl auf Benutzer- als auch auf Systemebene, sowie das Einbeziehen oder Ausschließen von dynamisch gebundenen Bibliotheken. Eine Zuordnung von Leistungsengpässen zu Quellcodezeilen oder zu zurückübersetzten Assembler-Befehlen ist möglich und es wird eine genaue Beschreibung der Engpässe geliefert. Ein Advisor gibt Tipps, um den Engpass mittels Compiler-Optionen oder Optimierung des Quellcodes zu beheben. Darüber hinaus ist es möglich, Leistungsdaten von bereits gestarteten Programmen zu erhalten. Eine datenorientierte Analyse des zu untersuchenden Programms erfolgt allerdings nicht. Vorteile + Sehr detaillierte Leistungsdaten unter Verwendung von Ereigniszählern. + Keine Beschränkung auf Messung der Laufzeit; es kann auch auf Basis von Cache- Fehlzugriffen gemessen werden. + Keine Veränderung der zu untersuchenden Programme ist nötig; es wird dynamisch instrumentiert. + Volle Unterstützung von multi-threaded Programmen. + Sehr feine Granularität bis auf die Befehlsebene. 11

22 Kapitel 2. Stand der Forschung Nachteile Keine datenorientierte Analyse ist möglich, wodurch keine Ursachen für das Laufzeitverhalten des Programms möglich ist. Keine Schnittstelle zur graphischen Ausgabe der Ergebnisse. 2.7 Intel VTune Der wohl umfangreichste am Markt erhältliche Profiler ist Intel VTune [Intd]. Dieser enthält neben Kernel Modulen zum Auswerten der PMU, einer tabellarisch aufgearbeiteten Ausgabe der Leistungsdaten auch eine graphische Ausgabe, um die Ergebnisse der Leistungsanalyse dem Benutzer in Form von Balkendiagrammen zu präsentieren. VTune ist sowohl für Intel IA32 als auch für Intel EM64T und Itanium Prozessoren verfügbar. Es gibt Versionen für Microsoft Windows und für Linux, welche sich direkt in die Entwicklungsumgebungen Visual Studio.NET bzw. Eclipse einbinden lassen. Die Leistungsanalyse erfolgt hierbei mittels zeitbasiertem oder ereignisbasiertem Sampling, so dass prinzipiell keine Instrumentierung erfolgen muss. Dabei wird ein großer Teil der PMUs der Prozessoren ausgenutzt, sodass auf dem Itanium auch genaue Event-Address -Register benutzt werden [Cho02]. Der Benutzer, der sein Programm optimieren will, gibt zu Beginn der Untersuchung an, unter welchen Gesichtspunkten 2 er sein Programm untersuchen will. Nach einem Durchlauf des Programms wird dem Benutzer in Form von Aufrufgraphen oder durch Angabe von Funktionen, die als Engpässe erkannt wurden, präsentiert, wo er sein Programm optimieren kann. Die Genauigkeit der Ausgabe ist bis auf einzelne Quellcodezeilen möglich. Mittels der Intel Threading Tools, die als Plugins für VTune erhältlich sind, insbesondere des Intel Thread Profilers [Intc], ist es möglich, Lastverteilungsengpässe einzelner Threads zu erkennen. Dazu ist jedoch eine compilerbasierte Instrumentierung nötig. Eine datenorientierte Analyse ist mit VTune allerdings nicht möglich und somit keine genaue Zuordnung eines Engpasses zur Quelle des Engpasses. Vorteile + Sehr detaillierte Leistungsdaten unter Verwendung von Ereigniszählern. + Graphische Ausgabe von Leistungsdaten des untersuchten Programms. + Direkte Zuordnung zum Quellcode. + Untersuchung von multi-threaded Programmen. 2 Dies können Cache-Fehlzugriffe, CPU-Zeit, Trefferraten von Sprungvorhersagen oder sonstige Ereignisse von Ereigniszählern sein. 12

23 2.8. Diskussion Nachteile Keine datenorientierte Untersuchung von Leistungsengpässen. 2.8 Diskussion Wie in diesem Kapitel dargestellt, existiert bereits eine große Anzahl von Profilern für die Leistungsuntersuchung von Programmen. Die meisten von ihnen stellen jedoch nur eine ablauforientierte Untersuchung der Programme bereit. Damit ist es zwar möglich aufzuzeigen, in welchen Bereichen eines Programms die meiste Zeit verbraucht wird, teilweise sogar bis auf einzelne Sourcecode-Zeilen. Wenn jedoch in einem Bereich festgestellt wird, dass darin viel Zeit verbracht wird, und in diesem Bereich auf mehrere Datenstrukturen zugegriffen wird, der Einfachheit halber seien diese mit A und B bezeichnet, kann nicht identifiziert werden, ob jetzt der Zugriff auf Datenstruktur A oder der auf Struktur B lange gedauert hat. Mit den traditionellen Profilern kann nur geraten werden, welcher Zugriff die Ausführung verzögert hat. Um jedoch den genauen Grund für die Verzögerung herauszufinden, ist es nötig, eine datenorientierte Analyse des Programms vorzunehmen. Soweit mir bekannt ist, kann bisher auf aktuell vorhandener Hardware nur Cache Scope eine solche Analyse durchführen. Eine Untersuchung mittels Simulatoren ist natürlich leicht möglich, da hierbei jeder Speicher-Zugriff bekannt ist. Auf aktueller Hardware braucht es jedoch eine Unterstützung des Prozessors, beispielsweise in Form von Ereigniszählern, um solch eine Untersuchung durchführen zu können, d.h. an Daten der Leistung von Programmen zu gelangen. Für einen Menschen ist es sehr viel einfacher, Zusammenhänge zu erkennen, wenn diese graphisch dargestellt werden. Deshalb ist es wünschenswert, dass ein Profiler dem Anwender auch graphisch darstellt, wo die Schwachstellen in seinem Programm liegen. Werkzeuge, wie beispielsweise Intel VTune, bereiten ihre Ergebnisse sehr anschaulich für den Benutzer auf. Es wäre allerdings wünschenswert, dass es auch ein Programm gibt, welches datenorientiert arbeitet und seine Ergebnisse graphisch aufbereiten kann. Das Programm Cache Scope, welches die datenorientierte Analyse beherrscht, kann nur mittels Tabellen darstellen, in welchen Datenstrukturen die größte Verzögerung erfolgte. Mit dem am Institut für Technische Informatik der TH Karlsruhe erstellten YACO steht ein Werkzeug für die genaue Darstellung von Cache-Fehlzugriffen, einem der Hauptgründe für das schlechte Laufzeitverhalten von Programmen, bereit. Um eine datenstrukturorientierte Analyse auf aktueller Hardware mit einer graphischen Ausgabe und dem Detail- Grad der Anzeige, wie es YACO bietet, zu erhalten, ist deshalb die Entwicklung eines Programms zur Analyse von Ereigniszähler-Daten und zur Aufbereitung der Daten in ein für YACO verständliches Format nötig. Der Detail-Grad, den YACO verlangt, also beispielsweise die blockweise Darstellung von Datenstrukturen, ist dabei von dem zu entwickelnden Tool zu verlangen. Die Beschreibung eines solchen Werkzeugs und die Bewertung desselben erfolgt in den Kapiteln 4 und 5. 13

24 Kapitel 2. Stand der Forschung 14

25 Kapitel 3 Grundlagen In diesem Kapitel sollen zunächst Grundlagen über die verwendete Hardware-Architektur (in Abschnitt 3.1) und über die Ereigniszähler des Itanium Prozessors (in Abschnitt 3.2) geliefert werden. Außerdem werden Techniken und Werkzeuge zum Lesen der Ereigniszähler und zum Visualisieren von Cache-Fehlzugriffen vorgestellt (in den Abschnitten 3.3, 3.5 und 3.6). 3.1 Cache Architektur des Itanium2 Prozessors Der Cache des Itanium2 besteht aus drei Cache-Ebenen. Level-1 ist aufgeteilt in einen Daten-Cache (L1D) und einen Befehls-Cache (L1I), Level-2 (L2) ist ein gemeinsamer Daten- und Befehls-Cache (unified). Ebenso ist der Level-3-Cache (L3) ein unified Cache. Der L1I-Cache hat eine Größe von 16 KByte, ist 4-fach assoziativ und hat eine Cache- Zeilengröße von 64 Byte. Interessanter für diese Arbeit ist der L1D-Cache. Dieser besitzt auch eine Größe von 16 KByte, ist ebenfalls 4-fach-assoziativ und hat auch eine Cache-Zeilengröße von 64 Byte. Die Lade-Latenz des L1D-Caches beträgt nur einen CPU-Zyklus, die Schreib-Latenz 3 Zyklen. Der L1D-Cache benutzt eine Durchschreibe- Strategie (write-through policy) ohne Write-Allocation für Schreibzugriffe, was bedeutet, dass bei einem Write-Hit sowohl im L1D-Cache als auch im L2-Cache das Datum aktualisiert wird, bei einem Write-Miss wird das Datum jedoch nur im L2-Cache geschrieben und die Cache-Zeile des L1D-Caches wird invalidiert 1. Wie im Prozessor-Block- Diagramm (Abbildung 3.1) dargestellt, ist der L1D-Cache fest im Integer-Datenpfad integriert. So müssen alle Integer-Loads durch den L1D-Cache, um in die 128 Integer-Register des Itaniums zu gelangen. Ebenso gehen alle L1D-Cache-Fehlzugriffe durch den L1D- Cache, nachdem das gesuchte Datum aus dem L2-, L3-Cache oder dem Speicher nachgeladen wurde, um in die Integer-Register zu gelangen. Eine Besonderheit des L1D-Caches 1 Für eine genauere Beschreibung der hier verwendeten Begriffe im Zusammenhang mit Caches möchte ich auf [Qua05] verweisen. 15

26 Kapitel 3. Grundlagen Abbildung 3.1: Itanium2 Prozessor-Block-Diagramm (aus [Rus04].). des Itaniums ist, dass alle Fließkomma Lese- und Schreibzugriffe am L1D-Cache vorbeigehen. Diese werden an den L2-Cache weitergeleitet, welcher direkt an die 128 Floatingpoint -Register angeschlossen ist. Im Falle einer Fließkomma Schreibe-Anweisung auf eine Zeile, die im L1D-Cache liegt, wird diese Zeile invalidiert. Falls auf einer Zeile sowohl Fließkomma- als auch Integer-Werte liegen, wird diese durch einen Schreibzugriff auf den Fließkomma-Wert im L1D-Cache invalidiert. Wird im folgenden wieder auf den Integer Wert zugegriffen, erfolgt ein Fehlzugriff und die Zeile muss aus dem L2-Cache nachgeladen werden. Es können pro CPU-Zyklus 2 Ladeoperationen in die Integer Register erfolgen. Der L2-Cache des Itanium2 Prozessors ist ein unified Cache, welcher eine Größe von 256 KByte aufweist. Er ist achtfach assoziativ organisiert und besitzt eine Cache-Zeilengröße von 128 Byte. Die Lade-Latenz beträgt mindestens 5 Zyklen für einen Integer-Zugriff bzw. mindestens 6 Zyklen für einen Zugriff auf Fließkomma-Werte. Es kann auch zu längeren Latenzen kommen. Da der L2-Cache ein nicht-blockierender (non-blocking) Cache ist, ist ein zusätzlicher Zwischenspeicher zwischen L1D- und L2-Cache nötig. In diesen werden Anfragen an den L2 Cache zunächst eingetragen. Wenn ein Fehlzugriff im L1D-Cache auftritt und es keine Abhängigkeiten mit anderen auftretenden oder im Zwischenspeicher vorhandenen Fehlzugriffen gibt, so dauert es 5 Zyklen, bis der Fehlzugriff aufgelöst wird. 16

27 3.2. Ereigniszähler Wenn allerdings Abhängigkeiten mit bereits anliegenden Fehlzugriffen vorliegen, so kann es länger dauern, bis der Fehlzugriff aufgelöst werden kann. Abschnitt in [Int04] erläutert dies genauer. Als Schreib-Strategie verwendet der L2-Cache Write-Back mit Write-Allocate. Dies bedeutet, dass ein Datum im Falle eines Schreibe-Fehlzugriffs sowohl in den L2-Cache als auch in den L3-Cache geschrieben wird ( Write-Allocate ), allerdings wird bei einer Veränderung des Datum im L2-Cache dies nur durch spezielle Bits (Altered Bit, Modified Bit und Dirty Bit) vermerkt und erst bei Verdrängung aus dem L2-Cache wird der L3-Cache aktualisiert ( Write-Back ). Pro CPU-Zyklus können bis zu 4 Ladeoperationen vom L2-Cache zu den Floating-point -Registern erfolgen. Der L3-Cache des hier verwendeten Itanium2 Prozessors ist ein unified-cache, welcher eine Größe von 3 MByte besitzt und 12-fach assoziativ ist. Die Cache-Zeilengröße beträgt 128 Byte. Der Lesezugriff auf Integer-Daten ist mit einer minimalen Latenz von 14 CPU- Zyklen möglich, der Fließkomma-Zugriff mit einer minimalen Latenz von 15 Zyklen. 3.2 Ereigniszähler In diesem Abschnitt wird die grundlegende Funktion und Konfiguration der Performance Monitoring Unit (PMU) des Itanium Prozessors beschrieben. Die PMU des Itanium Prozessors stellt 4 Ereigniszähler bereit, die dazu programmiert werden können, mehr als hundert verschiedene Ereignisse zu registrieren. Dazu zählen sowohl einfache Zähler als auch erweiterte Monitore um beispielsweise Daten- und Befehls- Caches und Sprungvorhersagen zu beobachten [Mos02] [Int04] Performance Counter Register Die PMU besteht aus einer Anzahl von Registern, die programmiert werden können, um verschiedene Ereignisse zu zählen. Man unterscheidet bei den Registern zwischen performance monitoring data Registern (pmd) und performance monitoring configuration Registern (pmc). Die pmd-register sammeln die Daten und die pmc-register konfigurieren, welche Ereignisse beobachtet werden sollen. Von der Itanium Architektur (auch IA-64 Architektur genannt) her sind 256 pmc und 256 pmd-register möglich, die jeweils 64 Bit breit sind. Als Monitor bezeichnet man eine Kombination von Konfigurations- und Datenregistern, wobei die Architektur des Itanium nur reine Zähl-Monitore vorsieht. Diese Zähl-Monitore benutzen nur ein pmd-register für die Ausgabe. Darüber hinaus gibt es auch CPU spezifische Monitore, die in dieser Arbeit vor allem benutzt werden. Diese verwenden auch mehrere pmd-register und benutzen diese auch anderweitig, nicht nur zum Zählen (siehe dazu auch Kapitel 3.2.2). Jeder Zähl-Monitor kann dazu programmiert werden, genau ein Ereignis zu zählen. Die Itanium Architektur sieht vor, dass genau 4 Zähl-Monitore, die 4 Paare von Registern benutzen, unterstützt werden. Das minimale Set von Registern besteht demnach aus pmc4 pmc7 und pmd4 pmd7. So wird pmd4 durch pmc4 konfiguriert, pmd5 durch pmc5, und die anderen entsprechend. Die weiteren 17

28 Kapitel 3. Grundlagen Performance Monitor Überlauf Register pmc0 pmc1 pmc2 pmc3 pmc4 pmc5 pmc6 Performance Monitor Konfigurations Register pmd4 pmd5 pmd6 Performance Monitor Daten Register Prozessor Status Register PSR Default Control Register DCR Performance Monitoring Vektor Register PMV pmc7 pmd7 Abbildung 3.2: PMU Register der Itanium Architektur. pmd-register sind CPU spezifisch. Die Register pmd4 pmd7 werden jeweils hochgezählt, wenn ein Ereignis auftritt. Im Falle eines Überlaufs, beginnen sie wiederum bei 0 an zu zählen und der Überlauf wird in den Überlauf-Registern pmc0 pmc3 registriert. Drei weitere Register beeinflussen das Verhalten der PMU: psr, dcr und pmv. Das psr (processor status register) enthält Bits für das Starten und Stoppen des Monitorings, das dcr (default control register) bestimmt, ob das Monitoring auch während einer Unterbrechungsroutine weitergeführt wird und das pmv (performance monitoring vector register) enthält Daten, die im Falle eines Überlaufs benötigt werden. Abbildung 3.2 zeigt die durch die Itanium Architektur vorgeschriebenen Register. Auf der verwendeten Maschine (siehe auch Abschnitt 5.1) sind die Register folgendermaßen implementiert: cat /proc/pal/cpu0/perfmon_info PMC/PMD pairs : 4 Counter width : 47 bits Cycle event number : 18 Retired event number : 8 Implemented PMC : 0-15 Implemented PMD : 0-17 Cycles count capable : 4-7 Retired bundles count capable : 4-7 Wie ersichtlich ist implementiert der verwendete Itanium2 Prozessor die Konfigurationsregister 0 15 und die Datenregister Darüber hinaus verwendet er 47 Bit breite Zähler. Es werden vier pmc/pmd Paare angeboten, wie es die Architektur des Itaniums vorschreibt. 18

29 3.2. Ereigniszähler Vorzeichen ü Zähler Abbildung 3.3: Das Format der Register pmd4 pmd7 auf dem Itanium reserved ena ism ble hold thres umask es ig pm oi ev plm Abbildung 3.4: Das Format der Register pmc4 pmc7 auf dem Itanium Das Format der pmd-register Abbildung 3.3 zeigt das Format der Register pmd4 pmd7. Ein solches pmd-register ist 64 Bit breit, die Implementierung beim Itanium2 sieht aber nur 47 Bit zum Zählen vor. Darüber hinaus enthält es noch ein Überlauf-Bit (Bit 47) und eine Vorzeichenerweiterung (Bits 48-63). Ein pmd-register kann nur von der Systemebene aus geschrieben werden, jedoch kann es auch von der Benutzerebene aus gelesen werden. Das Lesen der Bits der Vorzeichenerweiterung liefert den Wert des Überlauf Bits zurück. Dadurch erscheinen die Werte des Zählers vorzeichenerweitert. Ein Zähler-Überlauf tritt ein, wenn ein Stellenübertrag (carry out) bei Bit 46 auftritt und das Überlauf-Bit gesetzt wird. Dieser Vorgang wird in den Performance Monitoring Überlauf Registern vermerkt und dadurch kann eine Unterbrechungsroutine ausgelöst werden. Um diese Unterbrechung früher, d.h. vor Ablauf der 2 47 Ereignisse auszulösen, kann das Register mit einem Wert N beschrieben werden, so dass die Unterbrechungsroutine bereits nach 2 47 N Ereignissen ausgelöst wird. Bei einer solchen Vor-Initialisierung ist unbedingt darauf zu achten, dass das Bit 47 (Überlauf) mit 0 initialisiert wird. Es ist auch möglich, dass eine Software kontinuierlich die Register pmd4 pmd7 ausliest. Die Zähler-werte erscheinen dann aufsteigend Das Format der pmc-register Bei den pmc-registern unterscheidet man zwischen den Register pmc0 pmc3, in denen Überläufe registriert werden und den Konfigurationsregistern pmc4 pmc7, die zur Konfiguration der Zähl-Register verwendet werden. Die pmc-register sind nur von der Systemebene des Betriebssystems aus zugänglich. Die pmc-register vier bis sieben sind wie in Abbildung 3.4 aufgebaut. Das Feld es (event selection, Auswahl des zu beobachtenden Ereignisses) dient zusammen mit dem Feld umask (unit mask, Parameter des Ereignisses) dazu, das zu beobachtende Ereignis zu setzen. Da das Feld es 8 Bit breit ist kann ein Itanium Prozessor maximal 256 verschiedene Ereignisse beobachten, wobei allerdings im verwendeten Prozessor nicht alle implementiert sind. Die IA-64 Architektur sieht vor, dass mindestens die folgenden Ereignisse implementiert sind: 19

30 Kapitel 3. Grundlagen pmc0 pmc1 pmc2 pmc reserviert Überlauf res fr reserviert reserviert reserviert Abbildung 3.5: Das Format der Register pmc0 pmc3 auf dem Itanium2. Anzahl der CPU Zyklen Anzahl der ausgeführten Befehle Die Felder plm (privilege level mask, legt fest, auf welcher Ebene das Ereignis beobachtet werden soll, z.b. nur auf Benutzerebene oder nur auf Systemebene oder auf beiden), pm (privileged monitor, legt den Typ des Monitors fest; im Falle eines bevorzugten Monitors wird es gesetzt ansonsten nicht) und ism (instruction set mask, legt fest bei welchem Befehlssatz beobachtet werden soll, d.h. wenn IA-32 Befehle ausgeführt werden, oder wenn IA-64 Befehle ausgeführt werden, oder immer oder nie) legen zusammen fest, wann Ereignisse aufgezeichnet werden sollen. Das Feld pm ist vor allem deshalb nötig, um bei einer Beobachtung des gesamten Systems dafür zu sorgen, dass Anwendungen, die den Monitor nicht gestartet haben, das Beobachten nicht stören können, indem sie selbst Ereigniszähler verwenden. Wenn nur eine einzelne Anwendung beobachtet werden soll, muss das pm Bit nicht gesetzt werden. Das oi Bit (overflow interrrupt, Überlauf Unterbrechung) legt fest, ob eine Unterbrechung ausgelöst werden soll, wenn ein Überlauf stattfindet (das Bit ist gesetzt) oder nicht (das Bit ist nicht gesetzt) und das ev Bit (external visibility) leitet eine Benachrichtigung an den Prozessor weiter, falls es gesetzt ist. Zum ev Bit siehe auch Kapitel in [Int04]. Das Feld threshold legt fest, wann ein Ereigniszähler hochgezählt werden soll. Erst wenn ein bestimmter Wert überschritten wird, wird der Zähler inkrementiert. Das Bit in Feld enable muss gesetzt sein, wenn Ereignisse beobachtet werden sollen und das Bit ig wird nicht beachtet. Zuletzt sollte das Feld mit 0 initialisiert werden, um eine korrekte Funktionsweise der PMU zu gewährleisten. Die Register pmc0 pmc3 sind wie in Abbildung 3.5 aufgebaut. Die Register pmc1 pmc3 und die Bits 1 3 und 8 63 von pmc0 sind reserviert, d.h. wenn sie geschrieben werden, wird dies vom Prozessor nicht beachtet und wenn sie gelesen werden, liefern sie Null zurück. Interessant an diesen Performance-Monitor Überlauf-Registern sind hauptsächlich das fr-bit (freeze Bit), welches das Sammeln von Performance Daten unterbindet, wenn es gesetzt ist, und die Überlauf-Bits, die gesetzt werden, wenn ein Daten Register übergelaufen ist, d.h. Bit 4 repräsentiert pmd4, Bit 5 pmd5 und so weiter. Das freeze Bit wird automatisch von der Hardware gesetzt, wenn ein Zähler überläuft und das oi Bit des 20

31 3.2. Ereigniszähler Monitors gesetzt ist. Software ist dafür zuständig, dass dieses Bit wieder auf Null gesetzt wird, um weiteres Zählen zu ermöglichen weitere Register zur Steuerung der PMU Zwei weitere Register sind zur Steuerung der PMU nötig, wie ja bereits in Abbildung 3.2 gezeigt: psr und dcr. Da eine Software zur Auswertung der Ereigniszähler sich nicht auf die Kontextwechselinformation des Betriebssystem verlassen kann, stellt die Itanium Architektur drei globale Bits bereit (psr.up, psr.pp und dcr.pp, d.h. ein Bit mit der Bezeichnung up im psr, eines mit der Bezeichnung pp im psr und eines mit der Bezeichnung pp im dcr) und für jeden Monitor noch das pm Bit seines Konfigurationsregisters. Zusätzlich wird durch das plm Feld der pmc-register vier bis sieben noch festgelegt, auf welcher Betriebsystemebene die Zähler arbeiten sollen. Dieser Wert wird mit dem Feld cpl des psr verglichen, um zu bestimmen, wann gemessen wird. Wie in Abschnitt beschrieben wurde, können die pmc i Register (4 i 7) durch das Bit pm als Zähler auf Benutzerebene (falls das Bit nicht gesetzt ist) oder auf Systemebene (falls das Bit gesetzt ist) programmiert werden. Ein Zähler auf Benutzerebene wird aktiviert, indem das Bit up des psr gesetzt ist. Dieses Bit kann durch die Software zur Steuerung der Ereigniszähler gesetzt werden. Ein Zähler auf Systemebene wird durch das pp Bit des psr einund ausgeschaltet. Dieses Bit kann nur von Ebene Null (Systemebene) aus gesetzt werden. Das pp Bit des dcr wird ins pp Bit von psr kopiert, wenn eine Unterbrechung ausgeführt wird. Dies erlaubt es, Ereignisse, die während einer Unterbrechung aufgetreten sind, zu beobachten: falls das pp Bit des dcr Null ist, werden keine Ereignisse während einer Unterbrechung registriert, falls es eins ist, werden die Ereignisse zu den Systemereignissen hinzu gezählt Zusammenfassung: Programmierung der PMU Um Ereigniszähler zu verwenden, müssen die in den letzten Abschnitten beschriebenen Register entsprechend gesetzt werden. Abbildung 3.6 zeigt den Zusammenhang der einzelnen Register. Ein Ereigniszähler ist demnach aktiv, wenn das freeze Bit nicht gesetzt ist (pmc0.fr == 0), die Rechte im pmc-register mit denen des Prozessor Status Registers übereinstimmen (pmc[i].plm[psr.cpl] == 1) und der Zähler eingestellt ist auf Benutzerebene zu operieren (pmc[i].pm == 0) und das up Bit des psr gesetzt ist (psr.up == 1) oder der Zähler eingestellt ist, auf Systemebene zu operieren (pmc[i].pm == 1) und das pp Bit des psr gesetzt ist (psr.pp == 1). Um die Zähler zu programmieren, ist sicherzustellen, dass die PMU inaktiv ist. Dies ist zu erreichen, indem entweder das freeze Bit gesetzt wird, oder die Bits pp und up des psr auf Null gesetzt werden. 21

32 Kapitel 3. Grundlagen pmc0.fr == 0? nein ja pmc[i] aus pmc[i].plm[psr.cpl] == 1? nein ja pmc[i] aus pmc[i].pm == 1? ja nein psr.pp == 1? psr.up == 1? nein ja ja nein pmc[i] aus pmc[i] an pmc[i] aus Abbildung 3.6: Aktivieren eines Ereigniszählers Zusätzliche Register der Itanium2 PMU Zusätzlich zu den durch die IA-64 Architektur vorgeschriebenen Register, wie in Abschnitt beschrieben, stellt die PMU des Itanium Prozessors weitere Register bereit, um Ereignisse genauer zu beschreiben. In diesem Abschnitt wird vor allem auf die PMU des Itanium2 Prozessors eingegangen, die auch für diese Arbeit verwendet wurde. Zusammengefasst stellt die PMU dieses Prozessors noch folgende Features bereit: Opcode matching: dadurch kann die Beobachtung auf einzelne Befehle eingeschränkt werden. Address range checking: dadurch kann die Beobachtung auf einen Adressbereich beschränkt werden. Es kann auf einem Bereich im Datenadressraum oder auf einem Bereich im Befehlsadressraum beobachtet werden. Event address registers (EAR): dadurch können die genauen Daten- und Befehlsadressen von Cache oder TLB 2 Fehlzugriffen beobachtet werden. Dazu werden noch die Latenzen für die Auflösung eines Fehlzugriffs von der PMU bereitgestellt. Branch trace buffer (BTB): dadurch können Traces von bedingten Sprungbefehlen aufgezeichnet werden. Dabei ist es möglich festzulegen, welche Art von Sprungbe- 2 Translation Lookaside Buffer 22

33 3.3. Techniken zum Auslesen der Ereigniszähler fehlen beobachtet werden sollen: die genommenen, die nicht genommenen, die richtig vorhergesagten oder die nicht richtig vorhergesagten. Es wird jeweils die Quellund die Zieladresse von der PMU bereitgestellt. 3.3 Techniken zum Auslesen der Ereigniszähler Nach [Moo02] gibt es vor allem 2 Modi zum Auslesen der Daten, welche die PMU bereitstellt: 1. den Zähl-Modus und 2. den Abtast-Modus 3. Beim Zähl-Modus werden die Zahlen, die ein bestimmter Ereigniszähler zurück liefert, einfach aufsummiert. Dieser Modus ist vor allem dazu geeignet, ein grobes Bild über das Verhalten des untersuchten Programms zu erhalten. So werden die Ereigniszähler beim Start des Programms aktiviert und beim Beenden des Programms wieder deaktiviert. Die gesamte Anzahl von Cache Fehlzugriffen oder die gesamte Laufzeit des Programms in CPU Zyklen kann beispielsweise dadurch beobachtet werden. Beim Abtast-Modus hingegen, wird in bestimmten Abständen eine Messung vorgenommen und diese dann aufgezeichnet. Man unterscheidet beim Sampling zwischen zeitbasiertem Sampling und ereignisbasiertem Sampling. Beim zeitbasierten Sampling wird in vorher festgelegten Zeitabständen eine Messung vorgenommen. Beim ereignisbasierten Sampling erfolgt eine Messung immer nach einer bestimmten Anzahl von Ereignissen. So bedeutet eine Sampling Rate von Eins, dass nach jedem Auftreten eines Ereignisses eine Messung erfolgt und diese dann aufgezeichnet wird. Dieses Aufzeichnen erfolgt beim Itanium Prozessor dadurch, dass eine Unterbrechung ausgelöst wird, die die Arbeit des Aufzeichnens erledigt. So kann beispielsweise ein Zähler, wie oben beschrieben, mit einem bestimmten Wert vorbelegt werden, so dass bei einem Überlauf des Zählers eine Unterbrechung ausgelöst wird und somit eine Abtastung erfolgt. Um eine Sampling Rate von 1 zu erreichen, ist beim Itanium2 demnach der Zähler mit dem Wert vorzubelegen. Es ist natürlich bei dieser Messmethode zu beachten, dass durch eine zu häufige Unterbrechungsbehandlung ein immenser Overhead zustande kommt. Andererseits ist es nicht möglich, durch eine zu seltene Abtastung ein repräsentatives Ergebnis zu erhalten, da zu viele Ereignisse einfach nicht aufgezeichnet werden. Somit muss beim Sampling immer ein Kompromiss zwischen Genauigkeit der Messung und Größe des Overheads geschlossen werden. Es bietet sich außerdem an, die Sampling Rate während einer Messung nicht konstant zu lassen, sondern diese während der Messung zufallsbedingt zu variieren, um auch ein im Gleichtakt mit der Messung auftretendes Phänomen beobachten zu können. 3 Im folgenden auch unter der englischen Bezeichnung Sampling verwendet. 23

34 Kapitel 3. Grundlagen Beim Sampling kann ein Trace eines Zählers aufgezeichnet werden, indem beim Aufzeichnen des Zählerwertes zusätzlich noch der Wert des aktuellen Befehlszählers notiert wird. Damit können beispielsweise Cache Fehlzugriffe über die Laufzeit des Programms verfolgt werden. Dabei gibt es allerdings gewisse Probleme mit traditionellen Sampling- Techniken, die im folgenden dargestellt werden. Es wird nun vor allem auf das Sampling von Cache-Fehlzugriffen und auf die Event- Address -Register eingegangen, sowie auf die speziellen Vorteile dieser Register für diese Arbeit. 3.4 Sampling von Cache-Fehlzugriffen Beim Aufzeichnen von Cache-Fehlzugriffen und beim darauf folgenden Zuordnen von Datenstrukturen zu Cache-Fehlzugriffen ist es notwendig, die genauen Daten- und Befehlsadressen zu kennen. Nur so kann man die Fehlzugriffe auf Stellen im Quellcode und in Datenstrukturen zuordnen. Dies geschieht durch Abbildung der Befehlsadresse (IP, instruction pointer) zu Zeilen im Quellcode bzw. durch Zuordnung von Datenadressen zu vorher bekannten Adressbereichen von Datenstrukturen. Durch traditionelle Sampling Techniken ist es nur möglich, die Befehlsadresse zu beobachten, das Beobachten der Datenadresse ist nicht möglich. Ein weiteres, gravierendes Problem beim traditionellen Sampling besteht außerdem darin, dass durch die parallele Ausführung und durch tiefe Pipelines bei aktuellen Prozessoren nicht garantiert wird, dass die Adresse, bei der die Messung aufgenommen wird, auch die ist, bei der der Fehlzugriff stattgefunden hat. Beim Itanium kann dieser Unterschied zwischen Adresse des Fehlzugriffs und Adresse der Messung bis zu 48 Befehle betragen. Dadurch ist dann eine korrekte Zuordnung des Fehlzugriffs zu der Quelle des Fehlzugriffs nicht mehr möglich. Die folgenden beiden Beispiele aus [Mos02] veranschaulichen dieses Problem Probleme beim zeitbasierten Sampling In Abbildung 3.7 wird dargestellt, welches Problem beim zeitbasierten Sampling auftreten kann. Angenommen an Adresse 0x1000 tritt beim Lesen von Register r32 ein Cache- Fehlzugriff auf. Da der Itanium weiterarbeiten kann, obwohl mehrere Cache-Fehlzugriffe ausstehen, verarbeitet er zunächst weitere Befehle. Erst wenn das Datum, an welchem der Fehlzugriff aufgetreten ist, gebraucht wird, wird die Befehlsverarbeitung unterbrochen (stall), bis das Datum vom Cache geliefert wird. Dies geschieht im vorliegenden Beispiel an Adresse 0x1040. Da ja in bestimmten Zeitabschnitten aufgrund des Samplings eine Messung erfolgt, ist es wahrscheinlich, dass der Zeitabschnitt genau zu dem Zeitpunkt abläuft, wenn gerade ein Fehlzugriff aufgelöst wird, wie hier im Fall bei der Addition. Verschlechternd kommt hinzu, dass die Architektur des Itanium Prozessors so genannte Bundles vorsieht. Das sind immer drei vom Compiler zusammengefasste Befehle. Nur an Bundleadressen findet eine Unterbrechung statt, so dass die Timer-Unterbrechung erst an 24

35 3.4. Sampling von Cache-Fehlzugriffen Adresse Code 0x1000: ld8 r32=[r3];; Zeit (code) 0x1040: add r1=r32,1 nop.i 0x0 nop.i 0x0 0x1050: stall load latency Timerunterbrechung ip = 0x1050 (code) 0x10a0: cpm.eq p6, p7=r0, r5 Abbildung 3.7: Ungenauigkeit des zeitbasierten Samplings. Adresse 0x1050 stattfindet. Das zeitbasierte Sampling gibt also die Adresse 0x1050 als Adresse des Fehlzugriffs an, obwohl dieser eigentlich durch einen Zugriff auf ein Datum an Adresse 0x1000 erfolgte Probleme beim ereignisbasierten Sampling Da die PMU des Itanium Prozessors auch ereignisbasiertes Sampling vorsieht, könnte man annehmen, dadurch entstehe oben genanntes Problem nicht. Diese Annahme ist jedoch falsch, wie Abbildung 3.8 veranschaulicht. Hier wird angenommen, dass nach einer vorher festgelegten Anzahl von L2 Fehlzugriffen eine Messung erfolgt, welche den IP des aufgezeichneten Fehlzugriffs registriert. Um jeden Fehlzugriff aufzuzeichnen, wird eine Sampling Rate von 1 benutzt. Dazu wird das entsprechende pmd-register mit dem Wert vorinitialisiert, so dass beim Auftreten des Überlaufs eine Unterbrechung ausgelöst wird. Nach dem Lesezugriff an Adresse 0x1000 dauert es eine Weile, bis die PMU den Fehlzugriff bemerkt und ihn als L2 Fehlzugriff einordnet. Währenddessen führt die CPU weitere Befehle aus. Bis die PMU den Zähler erhöht, den Überlauf entdeckt und die Unterbrechung auslöst, ist die CPU bereits einige Bundles weiter in ihrer Befehlsverarbeitung. Als Adresse des Fehlzugriffs wird die Adresse aufgezeichnet, an der die Überlaufunterbrechung stattgefunden hat. Beim hier vorliegenden Beispiel wäre das Adresse 0x10a0, also noch weiter von der eigentlichen Adresse des Fehlzugriffs entfernt als im obigen Beispiel des zeitbasierten Samplings. Durch diese beiden Beispiele soll verdeutlicht werden, dass weder zeitbasiertes Sampling noch ereignisbasiertes Sampling dafür geeignet ist, die genaue Adresse eines Fehlzugriffs zu finden. Deshalb ist es durch diese beiden Techniken auch nicht möglich, Bereichen im Quellcode bestimmten Fehlzugriffen zuzuordnen, geschweige denn bestimmten Datenstrukturen. 25

36 Kapitel 3. Grundlagen Adresse Code 0x1000: ld8 r32=[r3];; Zeit (code) 0x1040: add r1=r32,1 nop.i 0x0 nop.i 0x0 0x1050: stall load latency PMU registriert Ereignis f f f f f f f f f f f f f f f f Überlauf pmd Register pmd Register (code) 0x10a0: cpm.eq p6, p7=r0, r5 Überlaufunterbrechung ip = 0x10a0 Abbildung 3.8: Ungenauigkeit des ereignisbasierten Samplings reserviert ism rsv. umask reserviert mode pm rsv. plm 0 pmc11 63 Datenadresse 0 pmd2 63 reserviert stat ov Latenz 0 pmd3 63 Befehlsadresse 4 3 vl 2 bn 1 slot 0 pmd17 Abbildung 3.9: Die Register des D-EAR beim Itanium2 Prozessor. Für die Register pmd2, pmd3 und pmd17 ist die Konfiguration im Cache-Modus dargestellt Lösung: Event Address - Register Um die oben genannten Probleme zu umgehen, stellt der Itanium Prozessor die so genannten Event-Address -Register (EAR) bereit. Von diesen gibt es einerseits eine Variante, die durch Sampling genaue Adressen von Befehlsfehlzugriffen aufzeichnet. Diese wird Instruction Event Address Register (I-EAR) genannt. Andererseits gibt es eine Variante, die die genauen Adressen von Datenfehlzugriffen registriert, welche Data Event Address Register (D-EAR) genannt wird. Diese registriert zusätzlich zur genauen Befehlsadresse, an welcher der Fehlzugriff aufgetreten ist 4, noch die genaue Datenadresse und die Zeit, die gebraucht wurde, um den Fehlzugriff aufzulösen und die Prozess-ID des auslösenden Threads. Dadurch ist es möglich, das genaue Cache Level in dem das Datum gefunden wurde und den Thread, der den Fehlzugriff ausgelöst hat, zu bestimmen. 4 In den obigen Beispielen jeweils 0x

37 3.4. Sampling von Cache-Fehlzugriffen umask 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb-0xf Latenz 4 Zyklen 8 Zyklen 16 Zyklen 32 Zyklen 64 Zyklen 128 Zyklen 256 Zyklen 512 Zyklen 1024 Zyklen 2048 Zyklen 4096 Zyklen es wird nichts beobachtet Tabelle 3.1: Mögliche umask Einträge des D-EAR, wenn es im Cache-Modus arbeitet. Ein D-EAR (siehe Abbildung 3.9) besteht aus den Registern pmc11 zur Konfiguration und den Registern pmd2, pmd3 und pmd17 zur Registrierung der Daten. Somit ist das D-EAR ein Beispiel für einen Monitor mit mehr als zwei Registern. Das Format von pmc11 ähnelt sehr dem der Register pmc4 pmc7. So gibt es dort ebenfalls Felder für plm, ism und pm, welche auch die gleiche Bedeutung besitzen. Somit ergibt sich auch das gleiche Verfahren zum Aktivieren des Monitors, wie es bereits oben beschrieben wurde. Zusätzlich zu der Eigenschaft, Cache Fehlzugriffe zu beobachten ist es auch möglich, TLB Fehlzugriffe und ALAT 5 Fehlzugriffe mit diesem Monitor zu beobachten. Dies geschieht durch Setzen der Bits im Feld mode. Falls das Bit 8 gesetzt ist, werden ALAT Fehlzugriffe beobachtet, ansonsten, wenn Bit 7 gesetzt ist, TLB Fehlzugriffe. Wenn beide Bits im mode Feld nicht gesetzt sind, werden L1 Cache Lade- Fehlzugriffe beobachtet. Ich möchte hierbei nochmals betonen, dass mit dem EAR nur Lade-Fehlzugriffe beobachten können! Tabelle 3.1 zeigt die möglichen Werte für das umask Feld, wenn das EAR programmiert ist, im Cache-Modus zu arbeiten. Diese Parameter bestimmen, ab welcher Latenz ein Fehlzugriff aufgezeichnet werden soll, d.h. beispielsweise werden, wenn das umask Feld auf 0x0 gesetzt ist, L1 Fehlzugriffe, die länger als 4 Zyklen brauchen, um aufgelöst zu werden, aufgezeichnet. Entsprechend werden bei einem Wert des umask Feldes von 0x1 nur L1 Fehlzugriffe aufgezeichnet, die mehr als 8 Zyklen brauchen bis das Datum im L1 Cache bereit steht. Ebenso werden die anderen umask Werte benutzt. Es ist dadurch möglich, nur Fehlzugriffe einer bestimmten Cache-Ebene zu beobachten, da bekannt ist, welche Latenz für das Auflösen eines Fehlzugriffs einer bestimmten Ebene nötig ist. Die Register pmd2, pmd3 und pmd17 enthalten die Daten, die durch Sampling des D- EAR gesammelt worden sind. Die Konfiguration dieser Register im Cache-Modus ist in 5 Advanced Load Address Table 27

38 Kapitel 3. Grundlagen Abbildung 3.9 dargestellt. Es ist kein kontinuierliches Auslesen dieser Register möglich wie bei den normalen Ereigniszähler Daten-Registern 6 ; ein Auslesen ist nur möglich, wenn das freeze Bit gesetzt ist, d.h. ein Zähler-Überlauf in einem der Register pmd4 pmd7 stattgefunden hat. Das Register pmd2 stellt dann die 64-Bit Datenadresse bereit, bei der ein L1 Cache Lade-Fehlzugriff stattgefunden hat. Im Register pmd3 steht in den Bits 0 12 die Latenz für die Auflösung des Fehlzugriffs. Das Feld ov (overflow, Überlauf) zeigt an, dass der Latenzzähler ein- oder mehrmals übergelaufen ist, bevor er gelesen wurde. Die Bits 14 und 15 von pmd3 zeigen an, ob das D-EAR überhaupt gültige Daten enthält, d.h. ob die Daten in pmd2, pmd3 und pmd17 gültig sind. Dies ist nicht der Fall, wenn beide Bits nicht gesetzt sind. Wenn Bit 14 gesetzt ist, Bit 15 aber nicht, so bedeutet dies, dass in pmd2, pmd3 und höchstwahrscheinlich in pmd17 gültige Daten liegen. Das letztgenannte Register besitzt noch ein eigenes Gültigkeitsbit (vl), das gesetzt ist, wenn die Befehlsadresse in den Bits 4 63 korrekt ist. Diese Adresse gibt die Startadresse des 2-Bundle Bereiches an, in dem der Fehlzugriff aufgetreten ist. Das genaue Bundle wird im Feld bn angezeigt. Dabei bedeutet ein gesetztes Bit im bn-feld, dass der Fehlzugriff im zweiten Bundle aufgetreten ist, ansonsten im ersten Bundle. Da ein Bundle immer aus genau drei Befehlen besteht, wird durch das Feld slot angezeigt, an welchem von den dreien ein Fehlzugriff aufgetreten ist. Um diese genauen Werte eines Cache Lese-Fehlzugriffs zu erhalten, ist es notwendig, dass eine Befehlsadresse über mehrere Prozessor-Zyklen hinweg verfolgt wird, d.h. von dem Befehl aus, an dem der Fehlzugriff aufgetreten ist bis zu dem, an dem er aufgelöst wurde. Es ist allerdings nur möglich zu einem Zeitpunkt ein solches Ereignis mit einem D-EAR aufzuzeichnen. Da bei einem Itanium Prozessor mehrere gleichzeitige Ladevorgänge möglich sind, können einige Fehlzugriffe mit diesem Verfahren somit nicht registriert werden. Zu einem Zeitpunkt kann nur genau ein Lade-Zugriff beobachtet werden und die anderen werden ignoriert. Sampling der D-EAR beim Itanium Prozessor erfolgt so: Wenn eine Lade-Operation erfolgt, wählt der Prozessor zufällig aus den gleichzeitig auftretenden eine aus und verfolgt diese. Falls ein Fehlzugriff auftritt, der eine höhere Latenz als die eingestellte aufweist, und die vorher eingestellte Anzahl an Ereignissen aufgetreten ist (Sampling-Zähler = 1/Sampling-Rate), und somit ein Überlauf erfolgt, werden die entsprechenden Daten in den Registern pmd2, pmd3 und pmd17 bereitgestellt. Falls die eingestellte Anzahl an Ereignissen noch nicht eingetreten ist, d.h. falls der Sampling-Zähler noch nicht 1/Sampling- Rate erreicht hat, wird dieser erhöht und der Beobachtungszyklus beginnt von vorne. Obwohl so nicht jeder Fehlzugriff aufgezeichnet werden kann, ist es durch die zufällige Auswahl eines davon doch möglich, ein statistisch genügend genaues Ergebnis zu erhalten. Quantitativ ausgedrückt, kann nur etwa jeder zehnte Fehlzugriff beobachtet werden [Mar05]. Das folgende Beispiel aus [Mos02] verdeutlicht, welche Daten durch Sampling des D- EAR erhalten werden können und wie diese dem Quellcode zugeordnet werden können. 6 Gemeint sind die Register pmd4 pmd7. 28

39 3.5. Werkzeuge zum Lesen von Ereigniszählern pmd2 = 0x c04 pmd3 = 0x5 (5 Zyklen ) pmd17= 0x ip = 0x D EAR Wert von r <f>: : [MFI] addl r16=4812,r1 nop.f 0x0 addl r17=4808,r1;; : [MNI] ld4 r14=[r16];; adds r14=1,r14 nop.i 0x0;; : [MMB] adds r15=1,r14 st4 [r17]=r14 nop.b 0x0;; : [MFB] st4 [r16]=r15 nop.f 0x0 br.ret.sptk.many b0 Abbildung 3.10: Das Ergebnis einer Abtastung des D-EAR. In Abbildung 3.10 wird rechts die Funktion f eines Programms dargestellt und links daneben die Ergebnisse die das D-EAR aufgezeichnet hat. Die Abtastung hierbei war so eingestellt, dass Fehlzugriffe mit mehr als 4 Zyklen Latenz aufgezeichnet wurden. Es wird angenommen, dass die Lade Operation an Adresse 0x einen Cache Fehlzugriff ausgelöst hat, welcher mittels Sampling aufgezeichnet wurde. Die Werte im D-EAR sind gültig, da Bit Drei von pmd17 gesetzt ist (daher die Acht an letzter Stelle). Wenn die letzten vier Bits von pmd17 auf Null gesetzt werden, erhält man die genaue Befehlsadresse des Fehlzugriffs. Dieser brauchte laut pmd3 5 Zyklen, bis er aufgelöst wurde. In pmd2 steht der Wert des Registers, also die Datenadresse, bei dessen Ladevorgang der Fehlzugriff aufgetreten ist. Wenn eine Abtastung stattfindet, wird zudem noch der Wert der aktuellen Befehlsadresse aufgezeichnet, in diesem Fall 0x , was der Adresse des darauf-folgenden Bundles entspricht. Dieses Beispiel zeigt, dass es möglich ist, Datenstrukturen direkt Cache Fehlzugriffen zuzuordnen, wenn noch bekannt ist, an welchen Datenadressen welche Datenstrukturen liegen. 3.5 Werkzeuge zum Lesen von Ereigniszählern Die Abschnitte 3.2 und 3.4 haben bereits dargestellt, wie die PMU des Itanium Prozessors aufgebaut ist und programmiert werden kann. Das Programmieren ist jedoch wie oben angedeutet nur auf Systemebene möglich. Deshalb ist es nötig, dass der Betriebssystem-Kern entsprechende Schnittstellen bereitstellt. Für IA64-Linux gibt es hierfür die Kernel Module perfmon [Hew06], OProfile [opr05] und Module aus der Intel VTune -Suite [Intd], die genau diesem Zweck dienen. 29

40 Kapitel 3. Grundlagen Start initialisiere PMU Register mit den Werten der "short Sampling" Periode führe Sampling durch schreibe Werte der pmd Register in den "Sampling Buffer" hoher Overhead geringer Overhead nein "Sampling Buffer" gefüllt? ja bilde "Sampling Buffer" in den Addressraum des untersuchenden Programmes ab initialisiere PMU Register mit den Werten der "long Sampling" Periode Lade Operation des Prozessors Fehlzugriff? ja Latenz größer als angegeben? ja Sampling Zähler Überlauf? ja nein nein nein Ignoriere Lade Operation Ignoriere Lade Operation Erhöhe Sampling Zähler Durchführung des Sampling Abbildung 3.11: Sampling der D-EAR mit perfmon perfmon Da OProfile jedoch nicht die erweiterten Fähigkeiten der Itanium PMU benutzen kann, wie beispielsweise die in dieser Arbeit benötigte Fähigkeit zum genauen Sampling, kam es hier nicht zum Einsatz [Lev04]. Die Entscheidung gegen VTune ist dadurch begründet, dass es nur kommerziell verfügbar ist. Deshalb wurde für diese Arbeit perfmon verwendet. Perfmon ermöglicht es, fast alle Fähigkeiten der PMU auszunutzen. Es stellt hierzu verschiedene Systemaufrufe bereit. Mit perfmon ist es darüber hinaus möglich, ereignisbasiertes Sampling durchzuführen. Es ist sowohl möglich, pro Thread Messungen durchzuführen, als auch systemweit. So kann man auch multi-threaded Programme, wie OpenMP Anwendungen, untersuchen. Um den Overhead durch zusätzliche Fehlzugriffe der Unterbrechungsbehandlungen abzuschwächen, richtet perfmon einen so genannten Sampling Buffer auf Systemebene ein. Der Overhead ist vor allem groß, wenn eine Umschaltung von System- auf Benutzerebene erfolgt. Deshalb werden bei perfmon, wenn der Sampling-Zähler übergelaufen ist, die Werte der pmd-register zunächst in den Sampling Buffer eingetragen. Daraufhin werden die Register der PMU wieder neu initialisiert. Erst wenn der Puffer voll ist, wird dieser dem Programm auf Benutzerebene zur Verfügung gestellt. Dies geschieht dadurch, dass perfmon den Sampling Buffer in den Adressraum des messenden Programms einblendet. Durch dieses Vorgehen wird verhindert, dass ein zu häufiger Kontext-Wechsel stattfindet, der durch damit verbundene zusätzliche Fehlzugriffe die Ergebnisse verfälscht. 30

41 3.5. Werkzeuge zum Lesen von Ereigniszählern Bei perfmon ist es deshalb möglich, zwei verschiedene Sampling- Raten anzugeben: durch die short Sampling -Periode wird bestimmt, nach wie vielen Ereignissen eine Abtastung erfolgen soll. Ist danach der Sampling Buffer noch nicht voll, wird die PMU wieder mit den Daten der short Sampling -Periode programmiert. Ist der Puffer jedoch gefüllt, so wird der Puffer geleert und die PMU mit den Werten der long Sampling -Periode wieder initialisiert. Anders ausgedrückt, kann man bei perfmon eine Sampling-Rate auf Systemebene ( short Sampling -Periode) und eine auf Benutzerebene ( long Sampling -Periode) angeben, d.h. eine nur zur Benutzung auf Systemebene und eine, wenn auf die Benutzerebene umgeschaltet wird. Es ist zu beachten, dass die Sampling-Rate beim Kontext- Wechsel ( long sampling -Periode) größer ist als bei einer Unterbrechung auf Systemebene ( short-sampling -Periode), um die vermehrt auftretenden Fehlzugriffe beim Kontext- Wechsel zu maskieren. Das Sampling der D-EAR mit perfmon und der Zusammenhang zwischen Sampling Buffer, short Sampling -Periode, long Sampling -Periode und Overhead wird durch Abbildung 3.11 verdeutlicht. Beim Starten der Performance-Untersuchung werden zunächst die Register der PMU mit den Werten der short Sampling -Periode initialisiert. Daraufhin wird das Sampling gestartet, d.h. es werden Lade-Operationen verfolgt. Falls die Lade-Operation ein Cache-Fehlzugriff ist, und die Latenz größer ist, als vorher angegeben, und der Sampling-Zähler den Wert 1/Sampling-Rate erreicht hat, so werden die Werte der pmd-register geschrieben. Ansonsten werden die Lade-Operationen ignoriert bzw. es wird der Sampling-Zähler hoch gesetzt, und die nächste Ladeoperation wird verfolgt. Die Werte der pmd-register werden im Falle eines Überlaufs in den Sampling Buffer geschrieben. Ist dieser noch nicht gefüllt, so werden die Register der PMU erneut mit den Werten der short Sampling -Periode initialisiert und das Sampling beginnt von vorne. Ist der Sampling Buffer allerdings gefüllt, so wird dieser in den Adressraum des untersuchenden Programms eingeblendet und die PMU wird mit den Werten der long Sampling -Periode initialisiert, bevor das Sampling wieder gestartet wird. Die perfmon-schnittstelle wurde von Hewlett-Packard entwickelt und steht für eine Reihe von Plattformen bereit, sowohl für Linux 2.4 als auch Linux 2.6. Es werden neben allen Itanium Prozessoren auch Intel EM64T/Xeon, Intel Pentium M und P6 Prozessoren und AMD 64-Bit Opteron Prozessoren unterstützt. Neuerdings gibt es auch eine Implementierung für Pentium 4. Eine passende Bibliothek zum Programmieren der PMU wird außerdem von Hewlett-Packard in Form der libpfm bereitgestellt. Aufbauend auf dieser Bibliothek arbeitet beispielsweise PAPI [pap05], eine API für den Zugriff auf Performance Counter. Allerdings stellt PAPI keine Mittel bereit, um direkt auf die EAR des Itanium Prozessors zuzugreifen. Deshalb wurde für diese Diplomarbeit das pfmon-tool [Hew06] verwendet. Dieses benutzt auch direkt die libpfm und somit die perfmon-schnittstelle. Pfmon ist ein Kommandozeilen-Programm, mit dem Programme unter voller Ausnutzung der Itanium PMU untersucht werden können. Aktuelle Zusammenhänge der unterschiedlichen IA64-Linux Kernel und der entsprechenden perfmon-, libpfm- und pfmon-versionen sind in Tabelle 3.2 dargestellt. 31

42 Kapitel 3. Grundlagen Linux-Kernel-Version perfmon-version libpfm-version pfmon-version Linux 2.4.x perfmon1.x libpfm2.x pfmon2.x Linux 2.6.x perfmon2.x libpfm3.x pfmon3.x Tabelle 3.2: Aktuelle Zusammenhänge der Linux Kernel Versionen und den Versionen der auf perfmon aufbauenden Werkzeuge zur Nutzung der PMU pfmon In diesem Kapitel soll nun eine kurze Einführung zu pfmon2 gegeben werden. Diese Version wurde auch während dieser Arbeit benutzt, da auf dem vorhandenen Itanium Cluster ein Linux der Version 2.4 installiert ist. Pfmon ist ein Werkzeug, mit dem unmodifizierte Programme untersucht werden können. Durch einfache Angabe von Parametern kann man so die Performance eines Programms mittels pfmon erhalten: $ pfmon -k -u -e CPU_CYCLES,IA64_INST_RETIRED ls /dev/null /dev/null CPU_CYCLES IA64_INST_RETIRED Im vorliegenden Beispiel werden für den Aufruf des Programm ls mit dem Parameter /dev/null Ereigniszähler-Werte für die Anzahl der CPU Zyklen und die Anzahl der ausgeführten Befehle gemessen. Durch die Angaben -k und -u wird angegeben, dass sowohl auf Systemebene ( kernel-level ) als auch auf Benutzerebene ( user-level ) gemessen werden soll. Wenn keine Angabe erfolgt, so wird auf Benutzerebene gemessen. Mit -e wird angegeben, welche Ereignisse beobachtet werden sollen 7. Diese sind durch Kommata voneinander zu trennen. Dabei ist es auf dem Itanium Prozessor möglich, maximal vier Ereignisse gleichzeitig anzugeben. Wenn kein Ereignis angegeben wird, so werden die CPU Zyklen gemessen. Zur Messung der Ereigniszähler erstellt pfmon zunächst eine perfmon-umgebung, dann wird ein Kind-Prozess, welcher die Umgebung des Eltern-Prozesses übernimmt, erstellt (fork()). Bevor das zu untersuchende Programm mittels execve() gestartet wird, wird die PMU programmiert und gestartet. Pfmon wartet nun, bis das zu untersuchende Programm beendet ist, d.h. bis es das Signal SIGCHLD empfängt. Danach werden die pmd-register des Kind-Prozesses gelesen und die Umgebung des Kind-Prozesses wieder gelöscht. Neben den im obigen Beispiel verwendeten Parametern stellt pfmon noch eine große Anzahl von weiteren Parametern zur Verfügung. Die wichtigsten und für diese Arbeit am interessantesten werden im folgenden dargestellt: -l: Es werden alle von pfmon auf der vorhandenen Maschine bekannten Ereignisse 7 In diesem Falle die Anzahl der CPU Zyklen und die Anzahl der ausgeführten Befehle. 32

43 3.5. Werkzeuge zum Lesen von Ereigniszählern aufgezählt. Beispiel: $ pfmon -l ALAT_CAPACITY_MISS_ALL ALAT_CAPACITY_MISS_FP ALAT_CAPACITY_MISS_INT BACK_END_BUBBLE_ALL BACK_END_BUBBLE_FE BACK_END_BUBBLE_L1D_FPU_RSE BE_BR_MISPRED_DETAIL_ANY BE_BR_MISPRED_DETAIL_PFS... -i event: Es werden kurze Informationen über das zu messende Ereignis ausgegeben, wobei event eines der Ereignisse ist, die man mittels pfmon -l erhält. Beispiel: $ pfmon -i DATA_EAR_CACHE_LAT4 Name : DATA_EAR_CACHE_LAT4 VCode : 0x5c8 Code : 0xc8 PMD/PMC: [ ] Umask : 0000 EAR : Data (Cache Mode) BTB : No MaxIncr: 1 (Threshold 0) Qual : [Instruction Address Range] [OpCode Match] [Data Address Range] Group : None Set : None Desc : Data EAR Cache -- >= 4 Cycles --system-wide: Es wird systemweit gemessen, d.h es werden Ereignisse aller Prozesse auf allen Prozessoren gemessen. Die Ausgabe erfolgt pro CPU. Durch Angabe der Option --aggregate-results werden die Ereignisse aller CPUs zusammengefasst. Beispiel: 33

44 Kapitel 3. Grundlagen $ pfmon --system-wide /bin/ls /dev/null /dev/null CPU CPU_CYCLES CPU CPU_CYCLES CPU CPU_CYCLES CPU CPU_CYCLES --long-smpl-periods=lvalue und --short-smpl-periods=svalue: Durch die Angabe von lvalue und svalue wird die Sampling-Rate der long Sampling -Periode bzw. der short Sampling -Periode, wie oben beschrieben, angegeben. Wenn nur eine der beiden Perioden angegeben wird, so wird diese sowohl als short- als auch long Sampling Periode benutzt. --smpl-periods-random=bitmask:seed: Durch die Angabe einer bitmask und einer seed wird sowohl die short Sampling -Periode als auch die long Sampling -Periode zufällig um den dort angegebenen Wert variiert. Wenn beispielsweise eine Sampling-Rate von angegeben wurde und der Wert von smpl-periods-random auf ff:5 gesetzt wurde, so variiert die Sampling-Rate zwischen und smpl-outfile=file: Die Ausgabe des Samplings wird in die Datei file umgeleitet. --smpl-output-format=format: Die Ausgabe wird wie im Format format ausgegeben, wobei auf dem verwendeten Rechner die Formate detailed-itanium2, raw, compact, btb, und example zur Verfügung stehen. Eine Übersicht der vorhandenen Formate liefert pfmon -I. Detailed-itanium2 gibt eine sehr genaue Belegung der einzelnen Register inklusive Erklärung aus. Raw liefert eine binäre Ausgabe (wobei allerdings nirgends beschrieben ist, wie das Ergebnis kodiert ist). Das btb -Format ist speziell zum Verfolgen der Sprungvorhersagen und das example -Format bietet eine übersichtliche, aber gekürzte Form der Ausgaben. In dieser Arbeit wird das Format compact benutzt, welches für jedes Sample eine Zeile erzeugt und in je einer Spalte den Wert eines pmd-registers, sowie die Prozess-ID des auslösenden Prozesses, die CPU, auf welcher der Fehlzugriff aufgezeichnet wurde, den IP an welcher ein Sample aufgezeichnet wurde und die verwendete Sampling-Rate ausgibt. Dadurch ist eine sehr einfache Weiterverarbeitung der Daten möglich. --with-header: Vor der Ausgabe wird ein ausführlicher Header geschrieben, in dem das aktuelle 34

45 3.6. Visualisierung von Cache-Fehlzugriffen mit YACO Datum, die verwendete Hard- und Software-Konfiguration, die verwendeten pfmon- Parameter und die Belegung der einzelnen Register vermerkt wird. Zudem wird das verwendete Ausgabe-Format beschrieben. In Anhang A wird eine beispielhafte Ausgabe des Samplings der Event-Address -Register mit pfmon gezeigt. 3.6 Visualisierung von Cache-Fehlzugriffen mit YACO Nachdem in Kapitel 2 bereits Profiler vorgestellt wurden, die auch teilweise eine graphische Oberfläche integrieren, soll im folgenden nun ein Werkzeug vorgestellt werden, welches ausschließlich dafür gedacht ist, Cache-Fehlzugriffe graphisch darzustellen. Dadurch soll dem Benutzer, welcher sein Programm optimieren will, eine intuitive Hilfe zur Lokalisierung der Engpässe durch Cache-Fehlzugriffe gegeben werden. Zur Visualisierung des Cache-Verhaltens von Programmen gibt es auch andere Visualisierungswerkzeuge wie beispielsweise das Cache Visualization Tool (CVT), den CACHE behavior VIsualiZer (CACHEVIZ) oder Thor, deren Vor- und Nachteile genauestens in [Qua05] beschrieben werden. Deshalb, und weil das im Zuge dieser Arbeit erstellte Werkzeug eine Ausgabe-Schnittstelle für YACO besitzt, wird nur dieses Werkzeug vorgestellt. Unter YACO (Yet Another Cachevisualizer for Optimization) [Qua05] versteht man ein Programm zur umfassenden Visualisierung von Cache-Fehlzugriffen, welches im Rahmen einer Diplomarbeit am Institut für Technische Informatik an der Universität Karlsruhe erstellt wurde. Mit diesem Werkzeug ist es möglich, Daten über die Ausnutzung von Caches graphisch darzustellen. Dabei erfolgt die Visualisierung datenorientiert und nicht wie bei VTune IP-orientiert (ablauforientiert). Einen Screenshot der Anwendung wird in Abbildung 3.12 gezeigt. Die Oberfläche von YACO besteht aus vier Fenstern, einem Hauptdarstellungsfenster (1), einem Erklärungs- und Hilfefenster für die jeweilige Ansicht (2), einem Datenstruktur- Informationsfenster (3), welches Informationen über die aktuell ausgewählte Datenstruktur anzeigt, und einem Cache-Informationsfenster (4), welches Informationen über den Cacheaufbau des zugrunde liegenden Rechners bereitstellt. Im Hauptdarstellungsfenster wird die vom Benutzer gewünschte Ansicht angezeigt. In Abbildung 3.12 ist die Übersichts- Ansicht dargestellt, d.h. es wird dem Benutzer das generelle Cacheverhalten seines Programms in den unterschiedlichen Caches dargestellt. Es wird hierbei mittels Balken- und Kreisdiagrammen das Verhältnis zwischen Cache-Treffern und Fehlzugriffen und eine Aufteilung der Fehlzugriffe in Unterkategorien dargestellt. Das ganze erfolgt pro Cache- Level. Als zweite Ansicht stellt YACO in Form von Säulendiagrammen Fehlzugriffe aufgeteilt nach Datenstrukturen dar (Abbildung 3.13). Wiederum kann zwischen verschiedenen Klassen von Fehlzugriffen unterschieden werden. Zudem kann ausgewählt werden, auf welcher Cache Ebene die Betrachtung erfolgen soll. Mit dieser Datenstruktur- Fehlzugriffs -Ansicht ist es möglich, bestimmte Datenstrukturen mit vielen Cache-Fehlzugriffen auszumachen und das Programm für den Zugriff auf diese zu optimieren. Der ge- 35

46 Kapitel 3. Grundlagen Abbildung 3.12: YACO in der Übersichts-Ansicht; zur Markierung der einzelnen Fenster sind diese durchnummeriert. 36

47 3.6. Visualisierung von Cache-Fehlzugriffen mit YACO Abbildung 3.13: YACO: Fehlzugriffe nach Datenstrukturen. 37

48 Kapitel 3. Grundlagen naueren Charakterisierung der Datenstrukturen dient die dritte Ansicht: Datenstruktur- Informationen 8. Hierbei wird für eine Datenstruktur pro Hauptspeicherblock die Anzahl der Treffer und die Anzahl der Fehlzugriffe angezeigt. Da sich eine Datenstruktur über sehr viele Hauptspeicherblöcke erstrecken kann, ist eine Zoom-Funktion eingebaut, mit welcher der darzustellende Hauptspeicherblock-Bereich eingestellt werden kann. Durch diese Ansicht kann erkannt werden, in welchen Bereichen einer Datenstruktur besonders viele Cache-Fehlzugriffe vorkommen. Es wird jedoch das Cache-Verhalten einer Datenstruktur über das gesamte untersuchte Programm dargestellt. Um auch in bestimmten Programmteilen diese Übersicht zu erhalten, kann man das Programm in so genannte Phasen einteilen, welche unterschiedliche Programmteile repräsentieren. Diese Phasen können beispielsweise einzelne oder mehrere Funktionen umfassen oder bestimmte Schleifen- Iterationen. Phaseninformationen können mit YACO sowohl zweidimensional als auch dreidimensional dargestellt werden. Abbildung 3.14 stellt eine solche Phasen-Information in 3D dar. Abbildung 3.14: Anzeige der 3D-Phasen mittels YACO. Entlang der z-achse sind die einzelnen Phasen abgetragen. Auf der x-achse werden hierbei die einzelnen Blöcke der Datenstruktur angezeigt und auf der y-achse wird die Anzahl 8 Eine Bild dieser Ansicht zeigt Abbildung 4.4 in Kapitel 4. 38

49 3.6. Visualisierung von Cache-Fehlzugriffen mit YACO der Fehlzugriffe abgetragen. In dieser 3D-Ansicht ist keine Unterscheidung zwischen den einzelnen Cache-Ebenen möglich, dies beherrscht nur die 2D Phasenansicht, bei der jedoch immer nur eine Phase angezeigt werden kann. Als letzte Ansicht stellt YACO noch eine Datenstruktur-Zugriffsverfolgungs -Ansicht bereit. Hiermit kann eine Datenstruktur über die Zeit im Cache verfolgt werden. Ebenso wird angezeigt, was passiert, wenn die gewählte Datenstruktur auf ein einen bestimmten Cache-Block zugreift, d.h. ob z.b. ein Cache-Treffer oder Fehlzugriff erfolgt. Durch diese umfangreichen Darstellungen ist es für einen Benutzer sehr einfach, konkrete Datenstrukturen auszumachen, bei deren Zugriff besonders viel Zeit verbraucht wird und er kann der Zugriff auf diese Datenstrukturen gezielt verbessern. Eine Optimierung kann dann folgendermaßen aussehen: 1. Cache Verhalten des ganzen Programms allgemein betrachten. 2. Cache-Verhalten der einzelnen Datenstrukturen betrachten. 3. Die Datenstruktur mit den meisten Fehlzugriffen herausnehmen und diese genauer betrachten. 4. Das Verhalten der Datenstruktur in unterschiedlichen Phasen betrachten. 5. Den Zugriff auf die identifizierte Datenstruktur im Programm optimieren. 6. Nach der Optimierung wieder bei Punkt Eins einsteigen, um zu überprüfen, ob die Optimierung etwas gebracht hat. 39

50 Kapitel 3. Grundlagen 40

51 Kapitel 4 Der Profiler dataprof In diesem Kapitel soll das Werkzeug dataprof genauer beschrieben werden, mit dem es möglich ist, mittels der Ereigniszähler des Intel Itanium Prozessors eine genaue datenorientierte Analyse eines mit der Programmiersprache C erstellten Programms durchzuführen. Es ermöglicht, bis auf Hauptspeicherblockgröße das Cacheverhalten einzelner Datenstrukturen zu untersuchen. Darüber hinaus können Leistungsdaten in einem für YACO verständlichen Format ausgegeben werden, sodass die mit dataprof erhaltenen Daten für den Benutzer graphisch dargestellt werden können. In Abschnitt 4.1 wird zunächst die generelle Arbeitsweise von dataprof beschrieben. In den darauffolgenden Unterabschnitten wird auf Details eingegangen, wie die Ereigniszähler gelesen werden (Abschnitt 4.1.1), welche Datenstrukturen erkannt werden können und wie sie erkannt werden (Abschnitt 4.1.2) und wie die Ausgabe erfolgt (Abschnitt 4.1.3). Danach wird eine Analyse des Overheads von dataprof durchgeführt (Abschnitt 4.2). Anschließend erfolgt ein Beschreibung der Beschränkungen (Abschnitt 4.3), die sich durch das gewählte Vorgehen ergeben. Das Kapitel schließt ab mit einer Diskussion über das erstellte Werkzeug (Abschnitt 4.4). 4.1 Design und Implementierung Das generelle Vorgehen bei der Benutzung von dataprof wird in Abbildung 4.1 dargestellt. Bei der Leistungsanalyse eines Programms werden zunächst während der Ausführung des Programms Ereigniszähler-Daten über das Cacheverhalten mittels pfmon gesammelt und in eine Datei geschrieben. Dazu werden die Data-Event-Address -Register des Itanium Prozessors benutzt. Zudem wird die Lage und die Größe der benutzten dynamisch allozierten Datenstrukturen mittels der für dataprof geschriebenen Bibliothek libmalloc_hook ermittelt. Darüber hinaus werden, unter Benutzung von Debug-Information der Binärdatei des untersuchten Programms, Daten über die Lage und Größe statischer Datenstrukturen erfasst. Mittels dataprof werden die gemessenen Fehlzugriffe daraufhin einzelnen Daten- 41

52 Kapitel 4. Der Profiler dataprof Ausführen des Programms Protokollieren der Lage der dynamischen Datenstrukturen Ausgabe der Lage der dynamischen Datenstrukturen in eine Datei libmalloc_hook Binary des Programms Protokollieren der Lage der statischen Datenstrukturen pfmon Lesen der Ereigniszähler Ausgabe der Ereigniszählerdaten in eine Datei Quellcode des Programms dataprof textuelle Ausgabe des Cacheverhaltens Ausgabe für YACO Abbildung 4.1: Der Ablauf einer Leistungsanalyse mit dataprof. strukturen zugeordnet. Es erfolgt entweder eine textorientierte Ausgabe nach Datenstrukturen oder eine textorientierte Ausgabe nach Funktion und Datenstruktur. Innerhalb von Funktionen können auch einzelne Quellcodezeilen ausgegeben werden, in denen Fehlzugriffe bestimmter Datenstrukturen aufgetreten sind. Darüber hinaus ist es möglich, eine Ausgabe in den für YACO nötigen Formaten zu erstellen, und so pro Hauptspeicherblock das Verhalten der einzelnen Datenstrukturen graphisch zu beobachten. Die Ausgabe der Sichten erfolgt jeweils getrennt nach Threads. Dadurch dass die Programmanalyse erst nach Beendigung des Programms erfolgt, wird sichergestellt, dass der Overhead durch die Zuordnung eines Cache-Fehlzugriffs zu einer Datenstruktur die Programmausführung nicht zusätzlich beeinflusst. Über den durch die Messmethode erzeugten Overhead, gibt Abschnitt 4.2 Aufschluss. 42

53 4.1. Design und Implementierung Auslesen der Ereigniszähler Das Auslesen der Ereigniszähler erfolgt in dieser Arbeit mit pfmon, welches in Kapitel bereits beschrieben wurde. Dabei werden unter Benutzung von ereignibasiertem Sampling die Data-Event-Address -Register gelesen, um genaue Adressen von Cache- Fehlzugriffen zu erhalten. Abbildung 4.2 fasst noch einmal das Vorgehen beim Sampling zusammen. Ein zufällig ausgewählter Ladezugriff wird verfolgt. Falls dabei ein Fehlzugriff auftritt und die Latenz des Fehlzugriffs größer ist, als die zu Beginn der Messung angegebene 1, wird getestet, ob der Sampling-Zähler überläuft. Wenn ja, werden die in den Registern pmd2 2, pmd3 3 und pmd17 4 enthaltenen Daten zusammen mit weiteren Informationen (siehe dazu Tabelle 4.1), die bei der Aufzeichnung gespeichert werden, im Sampling-Puffer abgelegt. Andernfalls wird der Sampling-Zähler inkrementiert und die nächste Lade-Operation wird verfolgt. Falls der Sampling-Puffer voll ist, wird dessen Inhalt in den Adressraum des messenden Programms eingeblendet, in diesem Falle in den von pfmon. Das Sampling erfolgt in dieser Arbeit systemweit, damit für alle Threads des untersuchten Programms Cache-Fehlzugriffe beobachtet werden können. Mit einer Heuristik wird bestimmt, welche Fehlzugriffe dem ausgeführten Programm zugeordnet werden können und welche von anderen auf dem System laufenden Prozessen verursacht wurden. Dies ist möglich, da beim Aufzeichnen für jeden Fehlzugriff die entsprechende Prozess-ID (PID) mit notiert wird. Die einzelnen Threads des untersuchten Programms können dadurch ebenfalls auseinander gehalten werden. Beim Einlesen der Daten durch dataprof wird anhand der aufgezeichneten Befehlsadressen und den im Programm enthaltenen Debug-Informationen überprüft, ob der Fehlzugriff innerhalb des untersuchten Programms aufgetreten ist. So werden Fehlzugriffe in mit dem Programm gebundenen Bibliotheken gleich zu Beginn verworfen, da diese nicht zugeordnet werden können und auch für die Programmoptimierung nicht von Bedeutung sind. Anhang A zeigt anhand eines Beispiels, welche Daten und in welcher Form die Daten von pfmon geliefert werden Zuordnung der Ereigniszähler-Daten zu Datenstrukturen Um Cache-Fehlzugriffe bestimmten Datenstrukturen zuordnen zu können, ist es wichtig, die Lage der Datenstrukturen während der Programmausführung zu kennen. Allerdings können von dataprof nicht alle Datenstrukturen erkannt und zugeordnet werden. Deshalb soll hier zunächst der virtuelle Adressraum eines Programms unter Linux vorgestellt werden, welcher in Abbildung 4.3 schemenhaft dargestellt wird. 1 in der vorliegenden Arbeit werden alle Fehlzugriffe, die eine größere Latenz als vier Zyklen haben, also alle L1-Fehlzugriffe, aufgezeichnet 2 Darin ist die genaue Datenadresse, an welcher der Fehlzugriff aufgetreten ist, gespeichert. 3 Darin ist die Latenz gespeichert 4 Darin ist die genaue Befehlsadresse gespeichert, an welcher der Fehlzugriff aufgetreten ist. 43

54 Kapitel 4. Der Profiler dataprof Lade Zugriff? nein ja Fehlzugriff? nein ja Latenz größer als angegeben? ja Sampling Zähler Überlauf? ja nein Erhöhe Sampling Zähler nein schreibe aufgezeichnete Daten in den Sampling Puffer pmd2 (Datenadresse) pmd3 (Latenz) pmd17 (Befehlsadresse) Sampling Puffer reinitialisiere Sampling Zähler nein Sampling Puffer voll? ja bilde Sampling Puffer in den Adressraum von pfmon ab schreibe Daten in Datei x dcd0 0x0001ad4683da116e 0x x600000ffffffc360 0x x c x dcd0 0x0001ad4683e9ba73 0x x600000ffffffc360 0x x c x bf5c0 0x0001ad4683f x x e55a8 0x x a99... Abbildung 4.2: Sampling der Event-Address -Register mit pfmon. 44

55 4.1. Design und Implementierung Ausgabe: (x 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8 x 9 x 10 ) Parameter Bedeutung x 1 Nummer des Eintrags x 2 Prozess-ID, bei der die Messung aufgezeichnet wurde x 3 CPU-Nummer x 4 Befehlsadresse, an der die Messung aufgezeichnet wurde x 5 Zeitstempel x 6 Bit-Maske der übergelaufenen Daten-Register der PMU x 7 Anfangswert des Übergelaufenen Daten-Registers x 8 genaue Datenadresse, bei der der Fehlzugriff aufgetreten ist x 9 Latenz für die Auflösung des Fehlzugriffs x 10 genaue Befehlsadresse, bei der der Fehlzugriff aufgetreten ist Zeilenvorschub, d.h. neue Zeile () beliebig oft wiederholbar Tabelle 4.1: Das Format der Ausgabe beim Sampling der Data-Event-Address -Register mit pfmon. Im Text-Segment steht der Programm-Code in Maschinensprache. Statisch allozierte und globale Datenstrukturen 5, welche bereits initialisiert sind, werden im Daten-Segment abgelegt. Die nicht initialisierten statischen Datenstrukturen 6 stehen im BSS-Segment 7. Im Heap-Segment schließlich werden die dynamischen Datenstrukturen, für die der Speicher beispielsweise mit malloc() alloziert wird, abgelegt. Dieser wächst in Richtung der aufsteigenden Adressen. Es ist nicht garantiert, dass die dynamischen Datenstrukturen bei jedem Aufruf des Programms an der gleichen Datenadresse abgelegt werden, vielmehr wird an der nächsten freien Adresse die Datenstruktur begonnen. Auf dem Stack liegen dann letztendlich alle lokalen oder auch automatischen Datenstrukturen 8. Das sind alle, die innerhalb einer Funktion und nicht als static deklariert werden. Ebenso werden die Parameter und die Rückgabewerte einer Funktion auf dem Stack gespeichert. Der Stack wächst in Richtung der absteigenden Adressen. Beim Aufruf einer Funktion werden zunächst die Parameter der Funktion auf den Stack gelegt. Danach werden dort auch die automatischen Datenstrukturen abgelegt. Der Stack wächst nach unten. Es können Funktionen so rekursiv aufgerufen werden und jede Instanz hat dennoch eigene lokale Variablen. Beim Beenden eines Funktionsaufrufs wird der Speicherplatz wieder freigegeben und der Stack schrumpft wieder nach oben. Die Lage von Datenstrukturen auf dem Stack ist abhängig vom Zeitpunkt, an welchem eine Funktion aufgerufen wurde und deshalb auch nicht oh- 5 In der Programmiersprache C sind das alle mit der Speicherklasse static. 6 Diese sind automatisch mit Null initialisiert. 7 BSS ist die Abkürzung für Block Started by Symbol. 8 In der Programmiersprache C sind das alle mit der Speicherklasse automatic. 45

56 Kapitel 4. Der Profiler dataprof Stack Adressen aufsteigend Heap BSS Daten Segment Text Segment Abbildung 4.3: Der generelle Aufbau eines virtuellen Adressraums eines Prozesses unter Linux. Die Bereiche, in denen dataprof Datenstrukturen erkennen und zuordnen kann, sind schraffiert dargestellt. ne weiteres nach Programmende eindeutig zu identifizieren, da jede Datenadresse mit der Zeit mehrere Datenstrukturen aufgenommen hat. Mit dataprof und der zur Erkennung von dynamischen Datenstrukturen geschriebenen Bibliothek libmalloc_hook können nur statische Datenstrukturen im Daten- oder BSS- Segment (mittels der Debug-Informationen) und dynamische Datenstrukturen auf dem Heap (mittels Instrumentierung des malloc()-aufrufes durch die libmalloc_hook ) erkannt und zugeordnet werden. Diese Bereiche sind in Abbildung 4.3 schraffiert dargestellt. Im folgenden soll nun beschrieben werden, wie dies erfolgt statische Datenstrukturen Die Adressen von statischen Datenstrukturen werden bereits beim Übersetzen eines Programms festgelegt. Wenn man Debug-Symbole beim Übersetzen in das Binary eines Programms mit einbindet, ist es möglich, später bei der Leistungsanalyse den Start und die Größe einer Datenstruktur aus dem Binary zu lesen. Dazu wird bei dataprof die dwarflib benutzt, eine Bibliothek, welche das Auslesen von Debug-Symbolen nach dem DWARF Standard [Fre05] ermöglicht. Dieser Standard wird von allen aktuellen C-Compilern 9 zum Einbinden von Debug-Information in ein Binary unterstützt. In der vorliegenden Arbeit wurde zum Einbinden möglichst umfangreicher Debug-Informationen der Intel Compiler icc mit den Optionen -g und -debug extended benutzt. Mit der Option -debug extended werden erweiterte Debug-Informationen ins Binary mit eingebunden, mit denen es 9 Mit aktuellen C-Compilern sind vor allem die Compiler gcc ab Version 3.1 der GNU Compiler Collection [GNU06] und der icc von Intel [Intb] gemeint. 46

57 4.1. Design und Implementierung auch möglich ist, Laufzeit-Informationen von lokalen Datenstrukturen zu erhalten. Diese erweiterten Möglichkeiten werden von dataprof jedoch im Augenblick noch nicht benutzt. Die eingebundenen Debug-Symbole ermöglichen es zudem, Befehlsadressen den zugehörigen Quellcodezeilen zuzuordnen. Da dataprof direkt die libdwarf benutzt, sind zusätzliche Programme wie beispielsweise addr2line oder nm 10 nicht nötig dynamische Datenstrukturen Zur Erkennung der Lage von dynamischen Datenstrukturen ist es wichtig, während der Ausführung eines Programms die Lage und die Größe der Datenstrukturen zu ermitteln, da diese nicht bei jeder Ausführung an derselben Stelle liegen. Vielmehr wird der Speicher für diese Datenstrukturen immer an der nächst höheren freien Adresse alloziert. Um die Lage der Datenstrukturen während des Samplings der Ereigniszähler zu protokollieren, wurde eine Bibliothek geschrieben (libmalloc_hook), welche den Aufruf von malloc() abfängt. Bei der GNU libc [GNU01] kann dies einfach erfolgen, indem der Zeiger auf die von der libc bereitgestellte malloc-funktion mit einem Zeiger auf eine eigene malloc- Funktion überschrieben wird. Dieses Verfahren wird in der libmalloc_hook verwendet. Dadurch erfolgt ein für das Programm transparenter Aufruf der eigenen malloc-funktion, in der zunächst das von der libc implementierte malloc() aufgerufen wird, um Speicher zu allozieren. Zusätzlich wird danach die Größe des reservierten Speicherbereichs, die Startadresse des reservierten Speicherbereichs und die Befehlsadresse des Aufrufs von malloc() ausgegeben. Mit den im Binary des Programms enthaltenen Debug-Informationen ist es möglich, nach Ausführung des Programms, die aufgezeichnete Befehlsadresse einer bestimmten Quellcodezeile zuzuordnen und somit einer Deklaration einer dynamischen Datenstruktur. Als Name für die Datenstruktur wird der bei der Allokation zugewiesene benutzt. Die von libmalloc_hook erhaltenen Daten haben das in Tabelle 4.2 beschriebene Format. Durch diese Vorgehensweise ist es möglich, die Lage und die Größe aller dynamisch von malloc() reservierter Datenbereiche aufzuzeichnen. In vielen Programmen wird der dynamische Speicher für eine Datenstruktur auch nach und nach reserviert. Wenn in der Zwischenzeit für eine andere Datenstruktur eine dynamische Speicherallokation erfolgt, so kann es auch vorkommen, dass ein Speicherbereich für eine Datenstruktur nicht an fortlaufenden Adressen liegt, sondern dass zwischen den zugewiesenen Datenbereichen, Datenbereiche anderer Datenstrukturen liegen. Dennoch gehören die einzelnen Datenbereiche alle zu einer Datenstruktur. Dadurch, dass bei dataprof die Zuordnung eines Datenbereichs zu einer Datenstruktur über die Befehlsadresse erfolgt, und so gleiche Befehlsadressen einer Datenstruktur zugeordnet werden, ist es möglich, auch solche verteilten Datenstrukturen zu beobachten. 10 Addr2line und nm sind Teil der GNU binutils [GNU05] und ermöglichen ebenfalls die Zuordnung einer Adresse zu einer Quellcodezeile bzw. die Ausgabe der in einem Programm benutzten statischen Datenstrukturen. 47

58 Kapitel 4. Der Profiler dataprof Ausgabe: (0 :: x 1 :: x 2 :: x 3 ) Parameter Bedeutung Zweck der Ausgabe x 1 Größe des allozierten Speicherbereichs Größe des Datenbereichs x 2 Die Anfangsadresse des allozierten Startadresse des Datenbereichs Speicherbereichs x 3 Die Befehlsadresse, von der aus malloc() aufgerufen wurde Zeilenvorschub, d.h. neue Zeile () beliebig oft wiederholbar Ermöglicht das Zurückschließen auf die Datenstruktur, welcher der Datenbereich zuzuordnen ist Tabelle 4.2: Das Format der Ausgabe von libmalloc_hook. Die libmalloc_hook kann auf zweierlei Möglichkeiten verwendet werden. Die eine Möglichkeit besteht darin, beim Bauen des Programms die Bibliothek dynamisch mit einzubinden. Andererseits kann man auch die Umgebungsvariable LD_PRELOAD mit dem Pfad auf die libmalloc_hook initialisieren. Dadurch wird der dynamische Linker angewiesen, die Bibliothek zu laden, bevor er auf die Bibliotheken der Standard-Bibliothek zugreift. In der libmalloc_hook wird der Zeiger auf die malloc-funktion der libc überschrieben, bevor das erste mal darauf zugegriffen wird, und alle Aufrufe von malloc() werden in allen Programmen an die selbst implementierte malloc-funktion weitergeleitet. Es ist zu beachten, dass alle Aufrufe von malloc(), also auch die anderer Programme oder Bibliotheken, bei Benutzung der libmalloc_hook mit aufgezeichnet werden. Es sollte deshalb bei Verwendung der LD_PRELOAD-Variante die Umgebungsvariable nach der Messung wieder auf leer ( ) gesetzt werden, um nicht unnötig viele Daten aufzuzeichnen, obwohl dataprof beim Auswerten der Daten durch Überprüfung der Befehlsadressen diejenigen verwirft, die dem Quellcode nicht zugeordnet werden können. Die Ausgabe der mittels libmalloc_hook gemachten Instrumentierung erfolgt durch printf-anweisungen. Dadurch ergibt sich ein gewisser Overhead, auf welchen in Abschnitt eingegangen wird Analyse der aufgezeichneten Daten und textuelle Ausgabe Die Ausgabe von dataprof erfolgt pro Thread, sodass Cache-Fehlzugriffe von multi-threaded OpenMP Programmen detailliert angezeigt werden können. Hier soll zunächst auf die textuelle Ausgabe von dataprof eingegangen werden. Vorgesehen sind drei Sichten, die sich im Detailgrad in ihrer Ausgabe unterscheiden: 48

59 4.1. Design und Implementierung Datenstruktur-Ansicht: Diese Ansicht liefert L1-Cache Fehlzugriffe pro Datenstruktur. Es werden nur diejenigen Datenstrukturen angezeigt, in welchen Fehlzugriffe aufgezeichnet wurden. Ansicht pro Funktion und Datenstruktur: Zur genaueren Lokalisierung eines Engpasses wird für jede Datenstruktur, in welcher Fehlzugriffe aufgetreten sind, die Funktion angegeben, in der sich die Fehlzugriffe ereignet haben. Ansicht pro Befehlsadresse und Datenstruktur: Diese Ansicht liefert eine noch genauere Angabe, in welchen Programmteilen sich beim Zugriff auf welche Datenstruktur Fehlzugriffe ereignet haben. Für jede Datenstruktur wird angegeben, in welcher Funktion und in welcher Quellcodezeile ein Fehlzugriff aufgetreten ist. Zu beachten bei den einzelnen Ansichten ist insbesondere, dass diese durch eine datenorientierte Analyse der mittels der Ereigniszähler gewonnenen Daten erzeugt wird. So wird die für jeden Fehlzugriff aufgezeichnete Datenadresse der durch libmalloc_hook oder durch Debug-Symbole registrierten Datenstruktur zugeordnet. Dies erfolgt bei dataprof über eine Hash-Funktion, um nicht für jeden Fehlzugriff die Datenadresse mit allen Datenbereichen aller Datenstrukturen vergleichen zu müssen. Die Angaben über den Bereich im Programm wird wie bei herkömmlichen Profilern über die aufgezeichnete Befehlsadresse und die Debug-Informationen ermittelt. In allen drei Ansichten wird das jeweilige Cache-Level angegeben, in dem der Fehlzugriff aufgelöst wurde. Da durch die Event-Address -Register nur Level-1 Fehlzugriffe registriert werden, erfolgt die Aufschlüsselung nach L1-, L2- und L3-Fehlzugriffen durch die mit jedem Fehlzugriff erhaltene Latenz. So sind alle in der Spalte L1-Misses angegebenen Fehlzugriffe L1-Fehlzugriffe, die im Level2-Cache aufgelöst werden konnten, d.h. die eine Latenz haben, die 5 oder mehr CPU-Zyklen beträgt. Wenn die Latenz eines Fehlzugriffs 14 und mehr Zyklen beträgt, so wird dieser zu den L2-Fehlzugriffen gezählt. L3-Fehlzugriffe sind all diejenigen, die mehr als 25 CPU-Zyklen zur Auflösung benötigen. Da nur Lese-Fehlzugriffe im L1-Cache aufgezeichnet werden und diese dann durch die Latenzen den unterschiedlichen Cache-Ebenen zugeordnet werden, sind die Werte in den Spalten der L2- und L3-Fehlzugriffe kleiner als die Werte in der Spalte mit den L1- Fehlzugriffen. Die Tabellen 4.3, 4.4 und 4.5 zeigen die textuelle Ausgabe von dataprof. Es wird jeweils das Ergebnis eines Threads angezeigt. Als Testprogramm wurde der MG-Benchmark aus der NAS Parallel Benchmark Suite für OpenMP [Omn00] mit der Problemgröße B verwendet. Eine Optimierung durch den Compiler erfolgte nicht. In der Datenstruktur-Ansicht nach Tabelle 4.3 erfolgt nur eine grobe Zusammenfassung des Cache-Verhaltens der einzelnen Datenstrukturen. Es wird eine globale Übersicht über das Cache-Verhalten einzelner Datenstrukturen im gesamten Programm angezeigt. Die ersten drei Spalten spezifizieren die Datenstruktur und den Ort ihrer Deklaration. Die folgenden drei Spalten und die letzte Spalte geben das Cache-Verhalten aus. Spalte Sieben 49

60 Kapitel 4. Der Profiler dataprof srcfile declli symbol L1Miss L2Miss L3Miss #malloc size tot. misses mg.c 206 u[l][k] mg.c 208 u[l][k][j] mg.c 212 v mg.c 214 v[k] mg.c 216 v[k][j] mg.c 223 r[l][k] mg.c 225 r[l][k][j] lt Tabelle 4.3: Die Datenstruktur-Ansicht von dataprof. und Acht geben die Größe der Datenstruktur in Byte und die Anzahl der Aufrufe von malloc() zur Allokation der Datenstruktur an. Falls mehrmals malloc() aufgerufen wurde, so ist nicht garantiert, dass die Datenstruktur an fortlaufenden Adressen liegt. Wie in Tabelle 4.3 deutlich wird, sind im Programm MG vor allem die Datenstrukturen u[l][k][j], v[k][j] und r[l][k][j], d.h. die dritten Dimensionen der Datenstrukturen u und r sowie die zweite Dimension der Datenstruktur v, zu optimieren. Zu beachten ist im auf dem Itanium auch, dass vor allem Datenstrukturen zu optimieren sind, bei denen viele L2- oder L3-Fehlzugriffe auftreten, da ein Fließkomma-Datum immer im L1-Cache einen Fehlzugriff verursacht. Die Ansicht nach Funktion und Datenstruktur (Tabelle 4.4) liefert schon eine genauere Übersicht. In der ersten Spalte wird die Funktion angegeben, in der Fehlzugriffe aufgetreten sind. Spalte Zwei zeigt die Datenstruktur an, in welcher die in den folgenden Spalten angegebenen Fehlzugriffe aufgelöst werden konnten. Dabei bedeutet ein Eintrag in der Spalte mit den L1 Fehlzugriffen, dass dieser im L2-Cache aufgelöst wurde. Zu beachten ist hierbei, dass bei einer Zeile, die das Cacheverhalten einer Funktion darstellt, alle Fehlzugriffe, die in der Funktion 11 aufgetreten sind, angegeben werden. Die angegebenen Werte schließen also auch Fehlzugriffe mit ein, die zwar bei Ausführung der Funktion aufgetreten sind, aber nicht einer Datenstruktur zugeordnet werden können. Dies sind Fehlzugriffe, die von Datenstrukturen verursacht wurden, welche im Stack-Segment des Speichers abgelegt wurden. Durch diese Ansicht ist zu erkennen, in welcher Funktion ein Datenstruktur besonders problematisch ist. So ist in Tabelle 4.4 ersichtlich, dass bei einem Zugriff auf die Datenstruktur u in der Funktion resid des MG-Benchmarks besonders viele Fehlzugriffe auftreten und dass die Latenz zum Auflösen dieser Fehlzugriffe besonders groß ist. Die letzte und genaueste textuelle Ausgabe zeigt das Cache-Verhalten von Datenstrukturen in einzelnen Quellcodezeilen und somit Stellen im Quellcode, die einer Optimierung bedürfen. In Tabelle 4.5 wird das Verhalten der Datenstrukturen in der Funktion resid verdeutlicht. Die Aufteilung der Spalten ist ähnlich wie bei der Ansicht nach Funktion. 11 Die Zuordnung eines Fehlzugriffs zu einer Funktion erfolgt hierbei über die aufgezeichnete Befehlsadresse und Debug-Informationen im Programm. 50

61 4.1. Design und Implementierung function data structure L1 latency L2 latency L3 latency total latency norm2u3(mg.c) v[k][j] r[l][k][j] interp(mg.c) u[l][k][j] comm3(mg.c) u[l][k] u[l][k][j] v[k][j] r[l][k] r[l][k][j] rprj3(mg.c) r[l][k][j] resid(mg.c) r[l][k] r[l][k][j] u[l][k] u[l][k][j] v v[k] v[k][j] psinv(mg.c) u[l][k] u[l][k][j] r[l][k][j] main(mg.c) lt vranlc(c_randdp.c) zran3(mg.c) v[k][j] randlc(mg.c) total program Tabelle 4.4: dataprof: Ansicht pro Funktion und Datenstruktur. 51

62 Kapitel 4. Der Profiler dataprof function data structure L1 latency L2 latency L3 latency total latency / line resid(mg.c) r[l][k] r[l][k][j] u[l][k] u[l][k][j] v v[k] v[k][j] Tabelle 4.5: dataprof: Ansicht pro Befehlsadresse, Funktion und Datenstruktur. 52

63 4.1. Design und Implementierung Abbildung 4.4: Die Ausgabe von mit dataprof gelieferten Daten mit YACO. Zusätzlich wird bei den Datenstrukturen jeweils noch die genaue Quellcodezeile angegeben, in der die Fehlzugriffe auftraten. Zu beachten ist hierbei, dass erst die einzelnen Zeilen angegeben werden und danach in Summe die Daten für die komplette Datenstruktur. Ebenfalls wie bei der Ansicht pro Funktion ist zu beachten, dass Angaben in einer Zeile, die eine Funktion beschreiben, wieder alle Fehlzugriffe, also auch die nicht zugeordneten, beinhalten. In Tabelle 4.5 erkennt man, dass vor allem in den Zeilen 531, 532, 533, 534 und 538 auf die Datenstruktur u zugegriffen wird und dadurch die größte Latenz in der Funktion resid erzeugt wird. Optimierungen sind vor allem an den Zeilen 531, 533 und 534 nötig Ausgabe für YACO Die Ausgabe für das Visualisierungstool YACO liefert Cache-Fehlzugriffe pro Hauptspeicherblock. Die dafür benötigten Daten werden von dataprof in Dateien geschrieben. Teilweise geschieht dies automatisch, teilweise müssen die Ausgaben aber auch von Hand angepasst werden. Eine Ausgabe der Datenstruktur-Information mit von dataprof gelieferten Daten stellt Abbildung 4.4 dar. Es werden oben die L2-Fehlzugriffe dargestellt und unten die L1- Fehlzugriffe. Neben dieser Datenstruktur-Information kann mit den von dataprof für YACO gelieferten Daten auch die Übersichts-Ansicht, die Übersicht über die einzelnen Datenstrukturen und die 2D- und 3D-Phaseninformations-Ansicht dargestellt werden. Von YACO hierfür verlangt sind Angaben über die Größe und den Aufbau des Caches, über die Lage der Datenstrukturen im Programm, eine Übersichtsinformation, die jedem Hauptspeicherblock Cache-Fehlzugriffe zuordnet und eine Phaseninformation, die das Programm in einzelne Phasen aufteilt und für jede Phase die zugegriffenen Hauptspeicher- 53

Codesigned Virtual Machines

Codesigned Virtual Machines Codesigned Virtual Machines Seminar Virtualisierung Philipp Kirchhofer philipp.kirchhofer@student.kit.edu Institut für Technische Informatik Lehrstuhl für Rechnerarchitektur Universität Karlsruhe (TH)

Mehr

Performance Counter im Pentium 4

Performance Counter im Pentium 4 Fachbereich Angewandte Informatik Performance Counter im Pentium 4 Seminararbeit von Michael Pietz Bonn, 03. Januar 2002 Inhaltsverzeichnis Seite 1 Abbildungsverzeichnis... 2 2 Tabellenverzeichnis... 2

Mehr

Technische Informatik I. Übung 3 Speicherhierarchie. v t d 0 d 1 d 2 d 3 0 1 2 3. Technische Informatik I Übung 3. Technische Informatik I Übung 3

Technische Informatik I. Übung 3 Speicherhierarchie. v t d 0 d 1 d 2 d 3 0 1 2 3. Technische Informatik I Übung 3. Technische Informatik I Übung 3 Institut für Kommunikationsnetze und Rechnersysteme Technische Informatik I Paul J. Kühn, Matthias Meyer Übung 3 Speicherhierarchie Inhaltsübersicht Aufgabe 3.1 Daten-Cache Aufgabe 3.2 Virtueller Speicher

Mehr

IBM Software Demos Rational Performance Tester Extension for Citrix

IBM Software Demos Rational Performance Tester Extension for Citrix Willkommen zur Online-Vorführung der IBM Rational Performance Tester- Erweiterung für Citrix Systems. Diese Demo zeigt Ihnen, wie Sie mittels der Rational Performance Testers No-Code Tests die Skalierbarkeit

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

Installationscheckliste Pervasive Server Engine Version 7.94, Stand 16.10.2012

Installationscheckliste Pervasive Server Engine Version 7.94, Stand 16.10.2012 Installationscheckliste Pervasive Server Engine Version 7.94, Stand 16.10.2012 Pervasive Server Engine Checkliste für die Neuinstallation in einem Windows-Netzwerk Bitte prüfen Sie auf unseren Webseiten

Mehr

17.2 MS-Access Projekte

17.2 MS-Access Projekte 964 Von MS-Access 2000 zum SQL-Server 17.2 MS-Access Projekte MS-Access-Projekte, die die Dateiendung adp besitzen, werden als Front-End-Anwendung verwendet. Für die Back-End-Seite gibt es mehrere Möglichkeiten.

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

BEDIENUNGSANLEITUNG Programmier-Software FPS10SOFT

BEDIENUNGSANLEITUNG Programmier-Software FPS10SOFT BEDIENUNGSANLEITUNG Programmier-Software FPS10SOFT 1. Allgemeines über FPS10SOFT: Auf Rechnern mit dem Betriebssystem Windows 2000, Windows XP oder ähnlichem ist die Programmier-Software FPS9SOFT (DOS-Anwendung)

Mehr

EXPANDIT. ExpandIT Client Control Kurzanleitung. utilities. be prepared speed up go mobile. Stand 14.11.07

EXPANDIT. ExpandIT Client Control Kurzanleitung. utilities. be prepared speed up go mobile. Stand 14.11.07 ExpandIT Client Control Kurzanleitung Stand 14.11.07 Inhaltsverzeichnis ExpandIT Client Control 3 Installationshinweise 3 System-Voraussetzungen 3 Installation 3 Programm starten 6 Programm konfigurieren

Mehr

Effiziente Java Programmierung

Effiziente Java Programmierung Effiziente Java Programmierung Seminar Implementierung moderner virtueller Maschinen am Beispiel von Java SS 2009 von Reinhard Klaus Losse 20. Mai 2009 Gliederung Definition Effizienz Werkzeuge zum Messen

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

Instruktionssatz-Architektur

Instruktionssatz-Architektur Institut für Informatik 3: Rechnerarchitektur Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2005/2006 Übersicht 1 Einleitung 2 Bestandteile der ISA 3 CISC / RISC Übersicht 1 Einleitung 2 Bestandteile

Mehr

Mobile Security Configurator

Mobile Security Configurator Mobile Security Configurator 970.149 V1.1 2013.06 de Bedienungsanleitung Mobile Security Configurator Inhaltsverzeichnis de 3 Inhaltsverzeichnis 1 Einführung 4 1.1 Merkmale 4 1.2 Installation 4 2 Allgemeine

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

DATA BECKERs Praxishandbuch zu SUSE Linux 10

DATA BECKERs Praxishandbuch zu SUSE Linux 10 DATA BECKERs Praxishandbuch zu SUSE Linux 10 Daniel Koch DATA BECKER Hardware vor dem Kauf prüfen 4. So läuft jede Hardware Längst wird Linux von vielen Hardwareherstellern unterstützt. Ganz reibungslos

Mehr

Profiling und Coverage mit GNU und Bare Embedded Systems

Profiling und Coverage mit GNU und Bare Embedded Systems Profiling und Coverage mit GNU und Bare Embedded Systems Life is too short for bad tools! Prof. Erich Styger erich.styger@hslu.ch +41 41 349 33 01 Coverage und Profiling Coverage: Analyse der Testabdeckung

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück Jörg Ehrichs Übersetzung: Burkhard Lück 2 Inhaltsverzeichnis 1 Wacom-Tablett-Einstellungen 5 1.1 Profilverwaltung...................................... 5 1.2 Allgemeine Tablett-Einstellungen und -Informationen.................

Mehr

SX3 PC Software rev. 0.99c

SX3 PC Software rev. 0.99c SX3 PC Software rev. 0.99c SX3 ist ein Programm zur Steuerung einer Selectrix Digitalzentrale unter Linux bzw. Windows. Mit SX3 haben Sie die Möglichkeit Selectrix -Loks zu fahren, Weichen zu Schalten

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

Systemmonitoring unter Linux

Systemmonitoring unter Linux Systemmonitoring unter Linux CPU-Counter B.Sc. Wirtsch.-Inform. Arno Sagawe, 29.06.10 Department of Informatics Scientifics Computing 1 Gliederung Systemmonitoring Protokolle und Dateien für das Systemmonitoring

Mehr

Problembehandlung bei Active Directory-bezogenen DNS- Problemen

Problembehandlung bei Active Directory-bezogenen DNS- Problemen Problembehandlung bei Active Directory-bezogenen DNS- Problemen (Engl. Originaltitel: Troubleshooting Active Directory - Related DNS Problems) Die Active Directory-Funktionen hängen von der richtigen Konfiguration

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Workflow+ Installation und Konfiguration

Workflow+ Installation und Konfiguration Workflow+ Installation und Konfiguration Systemübersicht Workflow+ Designer Mit dem Workflow+ Designer werden Workflows und Eingabemasken erstellt. Mit der integrierten Test- und Debugging Funktion können

Mehr

Im Original veränderbare Word-Dateien

Im Original veränderbare Word-Dateien Das Von-Neumann-Prinzip Prinzipien der Datenverarbeitung Fast alle modernen Computer funktionieren nach dem Von- Neumann-Prinzip. Der Erfinder dieses Konzeptes John von Neumann (1903-1957) war ein in den

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

2.2 Rechnerorganisation: Aufbau und Funktionsweise

2.2 Rechnerorganisation: Aufbau und Funktionsweise 2.2 Rechnerorganisation: Aufbau und Funktionsweise é Hardware, Software und Firmware é grober Aufbau eines von-neumann-rechners é Arbeitsspeicher, Speicherzelle, Bit, Byte é Prozessor é grobe Arbeitsweise

Mehr

Multicore Herausforderungen an das Software-Engineering. Prof. Dr.-Ing. Michael Uelschen Hochschule Osnabrück 15.09.2010

Multicore Herausforderungen an das Software-Engineering. Prof. Dr.-Ing. Michael Uelschen Hochschule Osnabrück 15.09.2010 Multicore Herausforderungen an das Software-Engineering Prof. Dr.-Ing. Michael Uelschen Hochschule Osnabrück 15.09.2010 Inhalt _ Motivation _ Herausforderung 1: Hardware _ Herausforderung 2: Software-Partitionierung

Mehr

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 2

Mehr

ekey TOCAhome pc Software Inhaltsverzeichnis 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3

ekey TOCAhome pc Software Inhaltsverzeichnis 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3 Inhaltsverzeichnis Software ekey TOCAhome pc 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3 3. MONTAGE, INSTALLATION UND ERSTINBETRIEBNAHME... 3 4. VERSION... 3 Version 1.5 5. BENUTZEROBERFLÄCHE...

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Programmieren. Wie entsteht ein Programm

Programmieren. Wie entsteht ein Programm Wie entsteht ein Programm 1/9 1. Schritt: Programmentwurf Der wichtigste Teil beim Erstellen eines Programms ist der Programmentwurf. Dabei wird das vorgegebene Problem analysiert, es wird ermittelt, welche

Mehr

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

Mehr

TIMI: Technische Informatik für Medieninformatiker

TIMI: Technische Informatik für Medieninformatiker TIMI: Technische Informatik für Medieninformatiker Bachelor-Studiengang Digitale Medien Medieninformatik SS 2004 Niels Pollem Arbeitsgruppe Rechnernetze (Prof. Dr.-Ing. Ute Bormann) Scheduling:

Mehr

Service & Support. Wie ist der User Mode Process Dumper für Diagnosezwecke bei WinCC und PCS7 einzurichten? User Mode Process Dumper.

Service & Support. Wie ist der User Mode Process Dumper für Diagnosezwecke bei WinCC und PCS7 einzurichten? User Mode Process Dumper. Deckblatt Wie ist der User Mode Process Dumper für Diagnosezwecke bei WinCC und PCS7 einzurichten? User Mode Process Dumper FAQ April 2011 Service & Support Answers for industry. Fragestellung Dieser Beitrag

Mehr

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note:

Name: ES2 Klausur Thema: ARM 25.6.07. Name: Punkte: Note: Name: Punkte: Note: Hinweise für das Lösen der Aufgaben: Zeit: 95 min. Name nicht vergessen! Geben Sie alle Blätter ab. Die Reihenfolge der Aufgaben ist unabhängig vom Schwierigkeitsgrad. Erlaubte Hilfsmittel

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/13 Verarbeitungsgrundlagen Teil 2 Virtual Storage el0100 copyright

Mehr

Anleitung zu ChipScope Pro

Anleitung zu ChipScope Pro Anleitung zu ChipScope Pro Das von Xilinx gelieferte Tool ChipScope Pro erlaubt die Implementierung eines Logic Analysator Kerns auf dem Spartan III Baustein. 1.1 Erstellen eines Logic Analysator Kerns

Mehr

a.i.o. control AIO GATEWAY Einrichtung

a.i.o. control AIO GATEWAY Einrichtung a.i.o. control AIO GATEWAY Einrichtung Die folgende Anleitung beschreibt die Vorgehensweise bei der Einrichtung des mediola a.i.o. gateways Voraussetzung: Für die Einrichtung des a.i.o. gateway von mediola

Mehr

Die Mikroprogrammebene eines Rechners

Die Mikroprogrammebene eines Rechners Die Mikroprogrammebene eines Rechners Das Abarbeiten eines Arbeitszyklus eines einzelnen Befehls besteht selbst wieder aus verschiedenen Schritten, z.b. Befehl holen Befehl dekodieren Operanden holen etc.

Mehr

IP Remote Controller

IP Remote Controller 4-450-999-41 (1) IP Remote Controller Anleitung der Einstellsoftware für das RM-IP10 Setup Tool Software-Version 1.0.0 2012 Sony Corporation Inhalt Einführung... 3 Vorbereiten des PCs... 3 Einstellen von

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Benutzerhandbuch Edith-Aktuelles

Benutzerhandbuch Edith-Aktuelles Benutzerhandbuch Edith-Aktuelles Den eigenen Internetauftritt verwalten so geht s! Eine Orientierungshilfe der NetzWerkstatt Programmierung: Die NetzWerkstatt GbR Geschäftsführer: Dirk Meinke und Sven

Mehr

5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista

5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista 5.0 5.3.3.6 Übung - Überwachen und Verwalten von Systemressourcen in Windows Vista Einführung Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung verwenden Sie administrative Tools zur

Mehr

Karlsruher Institut für Technologie

Karlsruher Institut für Technologie Karlsruher Institut für Technologie Lehrstuhl für Programmierparadigmen Sprachtechnologie und Compiler WS 2010/2011 Dozent: Prof. Dr.-Ing. G. Snelting Übungsleiter: Matthias Braun Lösung zu Übungsblatt

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme Software Bedienungsanleitung ENiQ Access Management: Online-Inbetriebnahme V1.0 April 2015 Inhaltsverzeichnis 1 Voraussetzungen... 3 2 Allgemeine Hinweise... 3 3 Generelle Einstellungen... 3 4 Dienste

Mehr

RÖK Typo3 Dokumentation

RÖK Typo3 Dokumentation 2012 RÖK Typo3 Dokumentation Redakteur Sparten Eine Hilfe für den Einstieg in Typo3. Innpuls Werbeagentur GmbH 01.01.2012 2 RÖK Typo3 Dokumentation Inhalt 1) Was ist Typo3... 3 2) Typo3 aufrufen und Anmelden...

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP

5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP 5.0 5.3.3.7 Übung - Überwachen und Verwalten von Systemressourcen in Windows XP Einführung Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung verwenden Sie administrative Tools zur Überwachung

Mehr

Thema: Systemsoftware

Thema: Systemsoftware Teil II 25.02.05 10 Uhr Thema: Systemsoftware»Inhalt» Servermanagement auf BladeEbene» Features der ManagementSoftware» Eskalationsmanagement» Einrichten des Betriebssystems» Steuerung und Überwachung»

Mehr

HowTo. Konfiguration VSA unter SAP NetWeaver 2004(s) Java

HowTo. Konfiguration VSA unter SAP NetWeaver 2004(s) Java HowTo Konfiguration VSA unter SAP NetWeaver 2004(s) Java Avira Support Juni 2009 Inhaltsverzeichnis SAP Systemvoraussetzungen... 2 SAP Plattformen... 2 OS Systemvoraussetzungen... 2 Java-spezifische Konfiguration

Mehr

Erweiterungen der EXPO-IP Virtuellen Messe

Erweiterungen der EXPO-IP Virtuellen Messe Release Notes 06/2010 Erweiterungen der EXPO-IP Virtuellen Messe Neue Features für Veranstalter und Aussteller EXPO-IP KG Robert Bosch Strasse 7-64293 Darmstadt info@expo-ip.com 1 Inhaltsverzeichnis Für

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Schulungsunterlagen CoDeSys V3 OPC Server

Schulungsunterlagen CoDeSys V3 OPC Server Impressum Copyright epis Automation GmbH & Co. KG 2013. Alle Rechte, auch der Übersetzung vorbehalten. Das Kopieren oder Reproduzieren, ganz oder auch nur auszugsweise, in irgendeiner Form (Druck, Fotokopie,

Mehr

eassessment Oracle DB Engine Whitepaper

eassessment Oracle DB Engine Whitepaper eassessment Oracle DB Engine Whitepaper DOKUMENT: TYP: eassessment Oracle DB Engine Whitepaper Plattformdokumentation ERSTELLT VON: nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION:

Mehr

BACKUP Datensicherung unter Linux

BACKUP Datensicherung unter Linux BACKUP Datensicherung unter Linux Von Anwendern Für Anwender: Datensicherung in Theorie und Praxis! Teil 4: Datenrettung Eine Vortragsreihe der Linux User Group Ingolstadt e.v. (LUG IN) in 4 Teilen Die

Mehr

Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome

Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome (Timo Heinrich, t_hein03@uni-muenster.de) Inhaltsverzeichnis: 0.Einleitung 1.Teil: Helloworldprogramm 1.1 Quellcode: Helloworld.cpp 1.2

Mehr

IMBA. Installationsanleitung. SQL Server-Datenbankadapter. Das Instrument für den fähigkeitsgerechten Personaleinsatz

IMBA. Installationsanleitung. SQL Server-Datenbankadapter. Das Instrument für den fähigkeitsgerechten Personaleinsatz Das Instrument für den fähigkeitsgerechten Personaleinsatz IMBA SQL Server-Datenbankadapter Installationsanleitung gefördert durch das Bundesministerium für Gesundheit und Soziale Sicherung Vorbereitung

Mehr

UltraSPARC T1 (Niagara)

UltraSPARC T1 (Niagara) UltraSPARC T1 (Niagara) Vortrag im Rahmen des Seminars Ausgewählte Themen in Hardwareentwurf und Optik HWS 06 Universität Mannheim Jochen Kinzel 1 Inhalt Überblick Core Crossbar Level 2-Cache DRAM-Controller

Mehr

MySQL Community Server 5.1 Installationsbeispiel

MySQL Community Server 5.1 Installationsbeispiel MySQL Community Server 5.1 Installationsbeispiel Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der untermstrich-datenbank

Mehr

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0 Gauß-IT-Zentrum DHCP für Institute Zielgruppe: DV Koordinatoren Version 1.0 1 DHCP für Institute Inhalt Dynamic Host Configuration Protocol (DHCP) für Institute 2 DHCP-Interface im KDD 2 DHCP beantragen

Mehr

Anleitung für eine Erstinstallation der TAP-Programme

Anleitung für eine Erstinstallation der TAP-Programme Anleitung für eine Erstinstallation der TAP-Programme Die folgende Installationsanleitung bezieht sich auf alle drei TAP-Programme (TAP, KiTAP, TAP-M), da die wesentlichen Schritte identisch sind. Vorbereitung

Mehr

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 E-Mail: sales@softvision.de Web: www.softvision.de Inhaltsverzeichnis

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Alles unter Kontrolle

Alles unter Kontrolle Alles unter Kontrolle Messung der Testabdeckung mit Open-Source-Tools Tim Wellhausen kontakt@tim-wellhausen.de http://www.tim-wellhausen.de 29.06.2008 Zusammenfassung: Unit-Tests sind vielleicht nicht

Mehr

Collax Monitoring mit Nagios

Collax Monitoring mit Nagios Collax Monitoring mit Nagios Howto Dieses Howto beschreibt die Konfiguration der Aktiven Überwachung auf einem Collax Server. Intern verwendet das System dafür Nagios. Primär wird Nagios zur Selbstüberwachung

Mehr

TYPO3 Redaktoren-Handbuch

TYPO3 Redaktoren-Handbuch TYPO3 Redaktoren-Handbuch Kontakt & Support: rdv interactive ag Arbonerstrasse 6 9300 Wittenbach Tel. 071 / 577 55 55 www.rdvi.ch Seite 1 von 38 Login http://213.196.148.40/typo3 Username: siehe Liste

Mehr

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01 Installation, Konfiguration, Verwendung Version 1.01 Seite 2 von 20 OPC-Server VM OPC Revision Version Erstellt am Versionsnummer Bemerkung 1.00 26.07.2013 Erstellung 1.01 05.11.2013 2.14 - Reiter der

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Optimierung des Energieverbrauchs eingebetteter Software

Optimierung des Energieverbrauchs eingebetteter Software Optimierung des Energieverbrauchs eingebetteter Software Welchen Einfluss hat eine Programmänderung auf den Energiebedarf einer Applikation? Welcher Programmteil verursacht den größten Energieverbrauch?

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

Leitfaden zur Installation von BitByters.Backup

Leitfaden zur Installation von BitByters.Backup Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,

Mehr

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP Inhaltsverzeichnis Dokumenteninformation... 2 Voraussetzungen... 2 Einschränkungen... 2 Installation von ESTOS Metadir...

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Graphing - SNMP DATA - MRTG II

Graphing - SNMP DATA - MRTG II Graphing - SNMP DATA - MRTG II Netzwerkmanagement Software hat sich in den letzten Jahren vom hilfreichen Produkt zur integralen Grundlage für den professionellen IT Betrieb gewandelt. Grosse und leistungsfähige

Mehr

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster Webseitennavigation mit dem Content-Management-System Imperia Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster 10. Januar 2006 Inhaltsverzeichnis 1. Einführung 4 2. Rubrikenstruktur

Mehr

Tutorial Grundlagen der Softwareverteilung

Tutorial Grundlagen der Softwareverteilung Tutorial Grundlagen der Softwareverteilung Inhaltsverzeichnis 1. Einführung... 3 2. Clientsysteme einrichten... 3 2.1 Den SDI Agent verteilen... 3 2.2 Grundeinstellungen festlegen... 4 3. Softwareverteiler...

Mehr

Installationsanleitung PowerSDR-IQ v1.19.3.15 SV1EIA für den Betrieb mit LIMA-SDR

Installationsanleitung PowerSDR-IQ v1.19.3.15 SV1EIA für den Betrieb mit LIMA-SDR Installationsanleitung PowerSDR-IQ v1.19.3.15 SV1EIA für den Betrieb mit LIMA-SDR 02.07.2010 Bernd Wehner DL9WB Talbahnstraße 17 47137 Duisburg dl9wb@darc.de - 1 - 1. Systemvoraussetzungen Damit PowerSDR

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Vielen Dank, dass Sie sich für die Software der myfactory International GmbH entschieden haben.

Vielen Dank, dass Sie sich für die Software der myfactory International GmbH entschieden haben. Vielen Dank, dass Sie sich für die Software der myfactory International GmbH entschieden haben. Um alle Funktionen unserer Software nutzen zu können, sollten Sie bitte in Ihrem Browser folgende Einstellungen

Mehr

Makros erstellen und aufrufen Dr. V.Thormählen

Makros erstellen und aufrufen Dr. V.Thormählen Inhalt Mit Makros arbeiten... 2 Makro erstellen... 3 Makro aufrufen... 4 1. Tastenkürzel zuordnen... 4 2. Schnellzugriffsleiste anpassen... 6 3. Menüband anpassen... 8 Fazit... 11 Listings Listing 1: Codezeilen

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch Parallels Plesk Panel Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix Administratorhandbuch Copyright-Vermerk Parallels Holdings, Ltd. c/o Parallels International GmbH Vordergasse 59 CH-Schaffhausen

Mehr

AVR-Mikrocontroller in BASCOM programmieren, Teil 3

AVR-Mikrocontroller in BASCOM programmieren, Teil 3 jean-claude.feltes@education.lu 1/8 AVR-Mikrocontroller in BASCOM programmieren, Teil 3 Alle Beispiele in diesem Kapitel beziehen sich auf den Mega8. Andere Controller können unterschiedliche Timer haben.

Mehr

Informatik I WS 07/08 Tutorium 24

Informatik I WS 07/08 Tutorium 24 Info I Tutorium 24 Informatik I WS 07/08 Tutorium 24 15.11.07 Bastian Molkenthin E-Mail: infotut@sunshine2k.de Web: http://infotut.sunshine2k.de Review / Organisatorisches o Probleme bei Foliendownload?

Mehr

EINRICHTUNG DER PORTMAPPERDIENSTE VON WWW.FESTE-IP.NET!

EINRICHTUNG DER PORTMAPPERDIENSTE VON WWW.FESTE-IP.NET! EINRICHTUNG DER PORTMAPPERDIENSTE VON WWW.FESTE-IP.NET! Auf den folgenden Seiten haben wir verschiedene Anwendungsfälle für unseren IPv6 Portmapper dokumentiert. Bitte bearbeiten Sie immer nur einen Anwendungsfall.

Mehr

Anleitung: Installation von WISO Mein Büro auf einem Mac

Anleitung: Installation von WISO Mein Büro auf einem Mac Anleitung: Installation von WISO Mein Büro auf einem Mac Lieber WISO Mein Büro Anwender, WISO Mein Büro ist bisher eine reine Windows-Anwendung und lässt sich somit leider nicht direkt auf einem Macintosh

Mehr