Diplomarbeit. Universität Ulm Institut für Angewandte Informationsverarbeitung

Transkript

1 Diplomarbeit Optimierung der Start- und Ausführungsgeschwindigkeit einer verteilten Überwachungs- und Steuerungsanwendung auf einem Embedded-Linux Gerät Universität Ulm Institut für Angewandte Informationsverarbeitung Vorgelegt von : Lionel Montheu Matrikelnummer: Geboren am: in Kamerun Angefertigt bei: NDSatCom Friedrichshafen Begin: Abgabetermin: Betreuer: Dipl. Ing. Markus Flad NDSatCom Friedrichshafen 1. Gutachter: Prof. Dr. Franz Schweiggert Universität Ulm 2. Gutachter: Dr. Michael Weixler NDSatCom Friedrichshafen

2 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Ulm, den 31. Juli 2008

3 INHALTSVERZEICHNIS Inhaltsverzeichnis Inhaltsverzeichnis 5 Abbildungsverzeichnis 8 Tabellenverzeichnis 9 1 Einleitung Die Firma ND SatCom Einordnung Das M&C System Aufgabenstellung Gliederung Profiling Definition Profilingtechniken Nichtinvasives Profiling Invasives Profiling Instrumentierung auf Quellcode Ebene Instrumentierung zur Übersetzungszeit Instrumentierung auf Objekt Ebene Instrumentierung zur Laufzeit Sampling vs. Instrumentierung Code Profiler Code Profiler unter Linux gprof Beschreibung Bewertung OProfile Beschreibung

4 INHALTSVERZEICHNIS Bewertung Valgrind Beschreibung Bewertung Code Profiler unter Windows DevPartner for Visual C Die Benutzerobefläche Vor- und Nachteile Rational Quantify Die Benutzeroberfläche Vor- und Nachteile VTune Performance Analyzer Die Benutzeroberfläche Vor- und Nachteile Visual Team Suite Das M&C System Design und Architektur Der CECS Server Design des CECS Servers Aufbau einer Driver Task Variablenproxy Action Handler Aufbau einer Processing/Agent Task Konfiguration eines CECS Servers Konfiguration der Tasks im M&C Server Nachrichtenaustausch im CECS Embedded Linux Geräte Redundancy Control Unit RCU- Konfigurationen Antenna Control Units Front Panel Controller Analyse und Optimierung Einschränkungen Allgemeine Vorgehensweise Suche nach Engstellen Analyse der Engstelle Messung des Performancegewinns Startdauer

5 INHALTSVERZEICHNIS Ausführungszeit Testumbegung Grobsystemanalyse Ergebnisse der ersten Messungen Analyse und Interpretation der ersten Messungen Quellcode Optimierung Zentrale Fabrikmethode Logginginformationen Auslesen der Konfigurationsdatei Fehler in einer Konfigurationsdatei Zwischenspeichern der Complete Response Verbesserung der Textverarbeitung Versenden von Nachrichten über TCP Programmoptimierung Entfernen von unbenutztem Code Dynamische Bibliotheken bevorzugen Komprimierung einer ausführbaren Datei Zusammenfassung Performanceverbesserungen Ausblick Schlusswort Glossar 96 Abkürzungsverzeichnis 100 Literaturverzeichnis 103 Index 105 5

6 6 INHALTSVERZEICHNIS

7 ABBILDUNGSVERZEICHNIS Abbildungsverzeichnis 1.1 Ein mobiles Übertragungsfahzeug (SNG) Der Übersetzungsprozess eines C Programms Visualisierung der Ausgabe von gprof mit kprof KCachegrind im Einsatz Aufbau des Tesprogramms zur Auswertung der Profiler Menu zum Steuern der Profilingaufgaben Toolbar zum Steuern der Profilingaufgaben Registerkarte mit (u.a) detaillierter Funktionsliste Übersicht über die Ausführungszeiten Ausschnitt einer annotierten Quelldatei Beispiel eines Aufrufgraphen Vergleich zwischen 2 Profiling- Sitzungen PurifyPlus Menü in Visual Studio Starten einer Profiling Sitzung Übersicht aller Threads und Threadzustände zur Programmlaufzeit Tabelle der aufgerufenen Funktionen Aufrufgraph des Hauptprogramms Tabelle aller aufgerufenen Funktionen, dargestellt nach Modul Ein Aufrufgraph im VTune Analyzer Aufbau eines M&C Systems Struktur eines CECS Servers Aufbau einer Driver Task Aufbau einer Agent bzw. Processing Task Sequenzdiagramm der Startprozedur im CECS Ablauf bei der Neuverbindung einer Task im CECS Die Redundancy Control Unit Beispiel einer Redundanzschaltung RCU Display mit der Konfiguration SW

8 ABBILDUNGSVERZEICHNIS 5.4 RCU Display mit der Konfiguration SW Die Antennekontrolleinheiten Der FPC und ein Leistungsverstärker M&C Bibliothekstruktur Start der RCU Software Verlauf der Ausführungszeiten Aufrufbaum der Funktion CFactory<CTaskProxy>:: Create() Aufrufbaum der Funktion CFactory<CWorker>:: Create() Ausführungszeiten beim Senden und Empfangen von Nachrichten Einige Objektfabriken in der M&C Bibliothek Die annotierte Fabrikmethode Die Funktion AppendCompleteHandler::Append() Auslesen eines Wertes in der.ini Datei Auslesen eines Wertes in der.ini Datei (optimiert) Ablauf bei einer Complete Request Geänderter Ablauf bei einer Complete Request Versenden von Nachrichten über TCP und UDP Versenden von Nachrichten über TCP (optimiert)

9 TABELLENVERZEICHNIS Tabellenverzeichnis verschiedene Messungen der Startdauer der RCU Hardwareunterschiede zwischen Windowsumgebung und RCU Ausführungszeiten (in Millisekunden) nach Funktion und Konfiguration(1) Ausführungszeiten (in Millisekunden) nach Funktion und Konfiguration(2) Anzahl der Funktionsaufrufe in SW09 und SW Startzeit der M&C Software (SW06) mit optimierter Fabrikmethode Verbesserungen bei SW Zusammenfassung der Verbesserungen auf verschiedenen Geräten

10 10 TABELLENVERZEICHNIS

11 LISTINGSVERZEICHNIS Listingsverzeichnis 2.1 Messung der Ausführungszeit durch Differenz zwischen Systemzeiten Übersetzung einer Anwendung mit Profilingfunktionalität Ein flat profile mit gprof Ein call graph mit gprof Beispiel von Quellcodeannotierung mit gprof Konfiguration einer Profilingsitzung mit OProfile Durchführung einer Profilingsitzung mit OProfile Zusammenfassung der Profilingsitzung mit OProfile Performanceprofil eines einzelnen Programms mit OProfile Fehlerhafter Aufrufgraph mit OProfile Simulationsoverhead mit Valgrind Compilerausgabe bei Übersetzung mit Profilingunterstützung Interne Konfiguration des CECS Servers Liste aller verwalteten Tasks Konfiguration der Treiber- Task IDU Einige textbasierte Komponentenspezifikationen Ausschnitt der geänderten Fabrikmethode Optimierung der Funktion AppendCompleteHandler::Append Verwendung von CFastTextNotifyParser in der.ini Datei Testfall 1 : Verwendung von ostringstream und des << Operators Testfall 4 : Verwendung eines char Arrays und sprintf() Durchführung von TestFall Durchführung von TestFall Das Makro SNPRINTF Funktionen zum Verschicken von Nachrichten Komprimierung eines Programms mit UPX

12

13 1. EINLEITUNG Kapitel 1 Einleitung 1.1 Die Firma ND SatCom Im Juli 2000 wurde aus dem Bereich SatCom des Unternehmens Nortel DASA ein eigenständiges Tochterunternehmen, die ND SatCom GmbH gegründet. Etwa zwei Jahre später im September 2002 wurde die GmbH in eine AG umgewandelt. Anteilseigner der ND SatCom AG waren damals die SES 1 Astra (Luxemburg) und AUGUSTA Technology AG (Frankfurt/Main). Seit Juni 2006 wurde die Firma ND SatCom AG wieder in eine GmbH umgewandelt und gehört jetzt zu 100% zu SES Astra. Die ND SatCom GmbH ist weltweit durch regionale Vertriebs- und Servicebüros vertreten. Der Hauptsitz des Unternehmens mit Verwaltung und Fertigung befindet sich in Friedrichshafen. Sie ist einer der führenden Anbieter von Satellitengestützten Lösungen für Breitband VSAT 2, Broadcast und militärische Kommunikationsnetzwerke. Ihre Technologien werden weltweit bei Unternehmen, Broadcastern, Regierungsbehörden, dem Militär sowie für Medien, Internet und im Bereich Telekommunikation eingesetzt. 1.2 Einordnung Ein Teil der Projekte der ND SatCom GmbH wird im Bereich Broadcast abgewickelt. Hierbei unterstützt die ND SatCom GmbH den vollständigen Bereich der Rundfunk- und Fernsehübertragung. Die Hauptentwicklungsgebiete liegen in der Bereitstellung von Satellitenbodenstationen für Breitbandübertragungen, des Weiteren der Entwicklung von Satellite News Gathering (SNG) Fahrzeugen (vgl. Abb. 1.1) und den dazugehörigen Komponenten für die Satellitenübertragung. Hauptabnehmer befinden sich vor allem im Bereich privaten und öffentlich-rechtlichen Sendeanstalten weltweit. 1 Société Européenne des Satellites 2 Very Small Aperture Terminal 13

14 1.3. DAS M&C SYSTEM Satellitenbodenstationen lassen sich in zwei Kategorien unterteilen. Zum einen gibt es die Empfangsstationen (Downlinks): sie können ein großes Übertragungsvolumen empfangen. Zum anderen gibt es die Sendestationen (Uplinks): sie senden die Programme zum Satelliten. SNG Fahrzeuge sind spezielle Fahrzeuge, welche mit einer Technik für digitale Satellitenübertragung, in Einzelfällen auch für analoge Satellitenübertragung ausgerüstet sind. Sie wurden entwickelt, um vom Ort des Geschehens zur Sendezentrale Nachrichten zu übertragen. Abbildung 1.1 Ein mobiles Übertragungsfahzeug (SNG) (Quelle: Das M&C System Zur Steuerung und Überwachung dieser Bodenstationen und SNG Fahrzeuge entwickelt die ND SatCom GmbH eine Überwachungs- und Kontrollsoftware, das Monitor and Control (M&C) System. Das M&C System ist eine proprietäre Softwarelösung, welche als Client- Server System realisiert ist. Der M&C Server kommuniziert mit den verschiedenen Geräten der Bodenstation mit Hilfe von entsprechenden Treibermodulen. Auf Grundlage dieser Treibermodule können im M&C Server automatisierte Aufgaben realisiert werden (z.b. Redundanzüberwachungen, Antennennachführung, etc.). Der M&C Server kann auf Windows Platformen eingesetzt werden, läuft aber auch auf unterschiedlichen Embedded-Linux Umgebungen. Die Mensch-Maschinen-Kommunikation ist Aufgabe des Clients. Es handelt sich dabei meistens um eine graphische Benutzerschnittstelle, welche Änderungen vom Server sofort anzeigt und über die Einstellungen an den Geräten der Bodenstation gemacht werden können. Die Struktur, sowie weitere Grundlagen über das M&C System werden in Kap. 4 genauer beschrieben. 14

15 1. EINLEITUNG 1.4 Aufgabenstellung Vor allem im Umfeld der Embedded-Linux Geräte besteht der Wunsch nicht nur nach einer höheren Verarbeitungsgeschwindigkeit sondern auch nach einer schnelleren Startgeschwindigkeit des M&C Servers. Auch im Windows Bereich sind solche Verbesserungen erstrebenswert. Die Aufgabe in der Diplomarbeit ist also zunächst die Messung und Auswertung der Ausführungsgeschwindigkeit in verschiedenen Szenarien. Der M&C Server ist ein nebenläufiges Programm. Dies macht die Messung nicht trivial und es müssen Lösungen erarbeitet werden wie die Messung mit vielen Threads (teilweise über 50) zu aussagekräftigen Auswertungen führen kann. Auf Grundlage der Messung sollte das bestehende System untersucht werden. Dabei ist es auch nötig ein tieferes Verständnis des bestehenden Laufzeitsystems und des CECS-Frameworks zu erlangen. Es wird erwartet, dass diese Auswertung eine oder mehrere Engstellen im System identifiziert. Eine weitere Aufgabe ist daher die Untersuchung unterschiedlicher Möglichkeiten der Geschwindigkeitsoptimierung. Dabei ist es evtl. nötig verschiedene Algorithmen gegenüberzustellen. Möglicherweise ist aber auch eine Diskussion über die Änderungen an der bestehenden Softwarearchitektur notwendig. Als weiterer Schritt sollte die Geschwindigkeitsoptimierung implementiert werden, die das größte Potential besitzt. Auch die Optimierung an mehreren Stellen ist durchaus denkbar. Abschließend sollte die Diplomarbeit durch entsprechende Messungen die dann erzielten Geschwindigkeitssteigerungen in verschiedenen Szenarien darstellen. 1.5 Gliederung Damit man ein bestehendes System optimieren kann, ist es erfoderlich, die Stellen im System herauszufinden, die eventuelle Engpässe darstellen. Dafür wird das System während seiner Ausführung untersucht. Kapitel 2 gibt einen Überblick über die gängigen Techniken, welche für die Messung der Ausführungszeit von Programmen verwendet werden. Anschließend werden im Kapitel 3 einige Tools (sowohl unter Linux als auch unter Windows), welche die Analyse eines Programms während seiner Ausführung sowie die Ermittlung von u.a. Performanceinformationen ermöglichen, vorgestellt und verglichen. Das Kapitel 4 befasst sich mit wesentlichen Grundlagen über das M&C System wie z.b. dessen Struktur und Funktionsweise. Im Kapitel 5 werden verschiedene Embedded-Linux Geräte, in denen die M&C Software zum Einsatz kommt, kurz vorgestellt. Nach den theoretischen und technischen Grundlagen in den früheren Kapiteln wird im Kapitel 6 zuerst eine Grobsystemanalyse durchgeführt. Nach dieser Analyse werden die vorgenommenen Optimierungsschritte nicht nur auf Quellcodeebene, sondern auch direkt im ausführbaren Programm erklärt. Kapitel 7 stellt den durch die Optimierung erzielten Gewinn dar und abschließend werden weitere Ideen, welche möglicherweise einen Optimierungspotenzial besitzen, kurz beschrieben. 15

16 GLIEDERUNG

17 2. PROFILING Kapitel 2 Profiling 2.1 Definition In der Softwareentwicklung entstehen häufig Probleme durch ineffiziente Programmierung. Um diese Probleme aufzudecken muss die Software während ihrer Laufzeit analysiert werden. Dabei werden Messungen gemacht, die für eine spätere Auswertung verwendet werden. Anhand dieser Messungen können z.b. Aussagen über die Ausführungszeit, die Aufrufsreihenfolge, die Aufrufshäufigkeit von Funktionen sowie über das Speicherverhalten der Software getroffen werden. Dieses Vorgehen nennt man das Profiling. Das Profiling ist ein entscheidender Schritt in der Optimierungsanalyse. Aus den Erkenntnissen, die über die Systemanalyse gemacht wurden, wird später entschieden, was in der Software zu ändern ist um die Software bezüglich definierter Eigenschaften zu optimieren. 2.2 Profilingtechniken Die Techniken zur Ermittlung von Laufzeitsinformationen über Programmen lassen sich insgesamt in 2 Kategorien aufteilen: nichtinvasive Profilingtechniken und invasive Profilingmethoden Nichtinvasives Profiling Beim nichtinvasiven Profiling wird das beobachtete Programm vor seiner Ausführung nicht modifiziert. Ein Vertreter für diese Technik ist das Sampling und es basiert im Prinzip auf das folgende Verfahren: Parallel zum beobachteten Programm läuft ein anderes Programm, welches für die Messung der Performance zuständig ist. Der Beobachter löst periodisch ein Interrupt 1 aus und liest den 1 kurzfistige Unterbrechung eines Programm um eine Unterbrechungsroutine auszuführen 17

18 2.2. PROFILINGTECHNIKEN Inhalt des Programmzählers. Anschließend wird der Stack durchsucht um herauszufinden welche Prozedur sich gerade in Ausführung befand. Danach wird die Anzahl der Schnappschüsse für die zugehörige Prozedur erhöht. Befindet sich die Funktion f nacheinander in n Schnappschüssen, so kann (anhand der Snapschussfrequenz) eine statistische Aussage über die Ausführungsdauer der Funktion f gemacht werden. Diese Technik bietet mehrere Vorteile, aber auch Nachteile: + Der bestehende Code braucht nicht geändert zu werden. + Es ist sowohl Anwendungsprofiling als auch Systemprofiling möglich. + Das zu beobachtende Programm läuft mit der (relativ) gleichen Geschwindigkeit und somit hat die Untersuchung der Ausführungszeit keinen direkten Einfluß auf die Ausführungszeit selbst. + Durch Auswahl einer geeigneten Samplingfrequenz kann man die Untersuchung auf solche Funktionen beschränken, die mindestens eine bestimmte Ausführungsdauer besitzen. Eventuell muss der bestehende Code mit der Unterstützung von Profiling neu übersetzt werden. Messergebnisse sind nicht exakt da sie auf einer statistischen basis beruhen Aus der Analyse kann ein Aufrufsgraphen produziert werden, welcher aber auch auf einer statistischen Basis beruht Invasives Profiling Beim invasiven Profiling wird die auszuführende Software vor der Analyse modifiziert. Dabei werden an bestimmten Stellen im Code Aufrufe auf Überwachungsfunktionen hinzugefügt. Dieses Vorgehen wird auch Instrumentierung genannt. Es gibt verschiedene Formen [TAO 04, Seite 2] der Instrumentierung. Diese Formen unterscheiden sich bei dem Zeitpunkt (auf dem Weg vom Quellcode zum ausführbaren Code), in welchem die Instrumentierung stattfindet. Abb. 2.1 zeigt den Übersetzungsvorgang eines C- Programms: der C Quelltext wird zuerst durch einen Präprozessor durchlaufen, welchen z.b. Makroersetzungen durchführt. Der daraus entstehende, reine C Quellcode wird anschliessend durch den Compiler in Assembler Quelltext übersetzt. Dabei wird das Programm (u.a.) auf Syntax und Semantik geprüft. Danach erzeugt der Assembler aus diesem Quelltext Objekt-Code in Maschinensprache. Schließlich wird der Objekt-Code gegebenenfall mit anderen Objekt-Codes (z.b. aus einer Archiv) zusammengelinkt und das Ergebnis ist ein ausführbares Programm. Durch die Instrumentierung wird die Ausführung des Programms jedoch langsamer, denn die Ausführung von Profilingroutinen selbst CPU Zeit verbraucht. Je höher die Anzahl an instrumentierten Funktionen, desto grösser der Overhead. 18

19 2. PROFILING Abbildung 2.1 Der Übersetzungsprozess eines C Programms (Quelle: [SWGT 04, Seite 115]) Instrumentierung auf Quellcode Ebene Diese Form der Instrumentierung wird manuell durch den Programmierer vorgenommen. An bestimmten Stellen im Quellcode werden explizit Routinen zur Ermittlung von Performanceinformationen aufgerufen. Im folgenden Listing 2.1 wird beispielsweise die Ausführungszeit einer Prozedur aus einer trivialen Art (über die Differenz zwischen Systemzeiten) berechnet. long timebefore = System. c u r r e n t T i m e M i l l i s ( ) ; dosomejob ( ) ; long timeafter = System. c u r r e n t T i m e M i l l i s ( ) ; long duration = timeafter timebefore ; Listing 2.1 Messung der Ausführungszeit durch Differenz zwischen Systemzeiten Bei dieser Art der Messung treten folgende Probleme auf: Wird der laufende Prozess aus irgendeinem Grund durch den Scheduler im Betriebssystem zugunsten eines anderen Prozesses vorläufig unterbrochen, so wird die Ausführungsdauer des anderen Prozesses auch mitgezählt. D.h. die so berechnete Zeit (vor allem bei Nebenläufigkeit) entspricht nicht immer der Realität. Falls innerhalb der Funktion dodomejob() ein Thread 2 erzeugt wird, welcher eventuell auch eine zeitintensive Aufgabe ausführt, so ist es mit dieser Methode nicht möglich, 2 leichtgewichtiger Prozess 19

20 2.2. PROFILINGTECHNIKEN die zusätzliche Ausführungszeit des erzeugten Threads in der Berechnung mit hinzu zu beziehen. Diese Technik ist eher für kleine Programme geeignet und setzt voraus, dass man schon eine Idee darüber hat, welche Funktion zeitintensiv ist. Andernfalls muß die Ausführungsdauer jeder möglichen Funktion von Hand direkt im Code gemessen werden, was die Suche der zeitintensiven Abschnitten erschwert. Ausserdem ist es erforderlich, der bestehende Quellcode zu modifizieren, was nicht immer gewünscht ist Instrumentierung zur Übersetzungszeit Bei manchen Compilern ist es möglich, Profilingfunktionalitäten durch die Verwendung von bestimmten Compileroptionen zu aktivieren. Wird z.b. bei dem GNU C Compiler (gcc) bzw. GNU C++ Compiler (g++) die Option -pg während der Übersetzung eines Programm angegeben, so werden Profilingroutinen zum Programm hinzugefügt. Nach erfolgreicher Ausführung dieses Programms entsteht dann eine Datei gmon.out, die durch entsprechende Tools (vgl. Kap ) ausgewertet werden kann Instrumentierung auf Objekt Ebene Diese Art der Instrumentierung erfolgt nach dem Übersetzen des Originalcodes und vor dem Linkervorgang. Dabei werden die existierenden Objektdateien z.b. bei jedem Funktionsaufruf und -rücksprung mit Aufrufen auf Analyseroutinen gepatcht. Durch diesen zusätzlichen Code wird das Programm um eine Logik zur Ermittlung von Analysedaten erweitert. Auf dieser Weise können z.b. zuverlässige Informationen über die Ausführungszeit und die Aufrufsreihenfolge von Funktionen ermittelt werden. Zusammenfassung der Vor- und Nachteile: + Der Code kann durch entsprechende Tools automatisch instrumentiert werden. + Diese Methode liefert zuverlässige ergebnisse (im Gegensatz zum Sampling, vgl ). Der Quellcode muss neu übersetzt werden. Das instrumentierte Programm läuft langsamer Instrumentierung zur Laufzeit Eine weitere Profilingmethode ist die Simulation. Bei dieser Methode wird die Ausführung des Zielprogramms bei einem (mehr oder weniger zuverlässigen) Modell der Zielplattform simuliert [WEIDENDORFER 04, Seite 2]. D.h die Instruktionen des Quellprogramms werden nicht direkt (durch die CPU) ausgeführt, sondern durch den Simulator der Zielplattform. Je detaillierter das 20

21 2. PROFILING Modell, desto genauer sind die berechneten Ausführungszeiten. Jedoch kann die Simulationszeit in der Praxis erheblich grösser werden. Bei dieser Methode ist eine Neuübersetzung des Quellprogramms auch nicht notwendig Sampling vs. Instrumentierung Die Sampling Technik liefert keine genaue Ergebnisse, da sie auf statistiche Messungen beruht. Durch wiederholtes Profiling des Programms kann eventuell die Approximierung verbessert werden. Fall aber genaue Ergebnisse verlangt sind, ist die Instrumentierung besser geeignet. Die vollständige Code- Implementierung ist jedoch bei großen Programmen wegen des verursachten Overheads nicht praktisch. Deswegen ist es wenn möglich ratsam, zuerst die Sampling Technik anzuwenden um die Zeitintensiven Routinen zu erkennen. Erst dann kann man gezielt nur diese Funkionen instrumentieren, um genaue Werte über die jeweiligen Ausführungszeiten zu bekommen. 21

22 PROFILINGTECHNIKEN

23 3. CODE PROFILER Kapitel 3 Code Profiler Im Kapitel 2 wurden verschiedene Methoden beschrieben mit denen es möglich ist, eine Anwendung zu Profilen. Ein Tool dessen Funktion die Untersuchung einer Anwendung während ihrer Laufzeit ist, wird Profiler genannt. Profiler sind meistens für bestimmte Programmiersprachen und Plattformen zugeschnitten. Da eine Optimierung sowohl auf der Linux als auch auf der Windows Plattform erwünscht waren, wurden zu Beginn der Diplomarbeit mehrere Profiler unter Linux und Windows evaluiert und verglichen. 3.1 Code Profiler unter Linux Die Auswahl an Profiler unter Linux ist nicht so groß wie unter Windows. Trotzdem gibt es verschiedene Tools zur Performanceanalyse, welche auf unterschiedlichen Methoden beruhen. Darunter zählt man gprof, OProfile und Valgrind gprof Beschreibung Der GNU Profiler (gprof) ist in den meisten Unix Systemen schon vorhanden, da er zum Paket GNU Binutils gehört. Dieses Tool wird in Kombination mit gcc oder mit g++ verwendet. Dabei erfolgt das Profiling in 3 Schritten: Zuerst wird das zu analysierende Programm mit gcc (bzw. g++) mit der Option -pg kompiliert und gelinkt (Listing 3.1). Dies führt dazu, dass der Kompiler zusätzlichem Code zur Ausgabe von Profilinginformationen [MAN 03, Sektion 1] in die ausführbare Datei hinzufügt. Es ist auch nützlich, die Option -g zu verwenden um das erzeugte Profil mit Debuginformationen (z.b. Symbolnamen) zu ergänzen. Dann wird das Programm wie gewohnt ausgeführt und periodisch (100 mal pro Sekunde) werden Profilingdaten gesammelt. Erst bei der sauberen Terminierung des Programms 23

24 3.1. CODE PROFILER UNTER LINUX (mit exit() oder return) wird eine Datei gmon.out generiert ([GRAHAM 82, Seite 18-3]). Anschliessend werden die Profilingdaten aus der Datei gmon.out mittels gprof ausgewertet. [ lionel@benq ] $ [ lionel@benq ] $ l s CallGraphNoThread. cpp [ lionel@benq ] $g++ g pg CallGraphNoThread. cpp o callgraph nothreads [ lionel@benq ] $ l s CallGraphNoThread. cpp callgraph nothreads [ lionel@benq ] $. / c allgraph nothreads [ lionel@benq ] $ l s CallGraphNoThread. cpp gmon. out callgraph nothreads Listing 3.1 Übersetzung einer Anwendung mit Profilingfunktionalität gprof unterstützt 3 verschiedene Arten von Profilen: eine tabellarische Auflistung von Funktionen mit zugehörigen Profilinginformationen (sog. flat profile, vgl. Listing 3.2), eine tabellarische Auflistung von Funktionen, in welcher die Aufrufsreihenfolge dieser Funktionen im Vordergrund steht (sog. call graph, vgl. Listing 3.3), eine tabellarische Darstellung des Quellcodes, beim welcher die ausgeführten Codezeilen mit Profilinginformationen versehen sind (vgl. Listing 3.4). [ lionel@benq ] $gprof callgraph nothreads p b Flat p r o f i l e : Each sample counts as 0.01 seconds. % cumulative s e l f s e l f t o t a l time seconds seconds c a l l s s / c a l l s / c a l l name c a l l g r a p h ( ) methoda( bool ) methodb ( bool ) methodc ( ) [ lionel@benq ] $ Listing 3.2 Ein flat profile mit gprof 24

25 3. CODE PROFILER Das obere flat profile (Listing 3.2) lässt sich beispielsweise auf der folgenden Art interpretieren: Die Funktion callgraph besitzt eine durchschnittliche Ausführungszeit von 6.03 Sekunden und wurde während der Programmausführung 2 mal aufgefuren. Die Ausführungszeit dieser Funktion ist die höchste und beträgt 29,18% der gesamten Ausführungszeit des Programms. Die ganze Programmausführung hat insgesamt 12,06 Sekunden gebraucht. [ lionel@benq ] $gprof callgraph nothreads c b no f l a t p r o f i l e Call graph g r a n u l a r i t y : each sample h i t c overs 2 byte ( s ) f o r 0.08% o f s e c s index % time s e l f c h i l d r e n c a l l e d name <spontaneous > [ 1 ] main [ 1 ] /2 c a l l g r a p h ( void ) [ 2 ] /2 main [ 1 ] [ 2 ] c a l l g r a p h ( void ) [ 2 ] /2 methoda( bool ) [ 3 ] /2 c a l l g r a p h ( void ) [ 2 ] [ 3 ] methoda( bool ) [ 3 ] /2 methodb ( bool ) [ 4 ] /2 methoda( bool ) [ 3 ] [ 4 ] methodb ( bool ) [ 4 ] /1 methodc ( ) [ 5 ] /1 methodb ( bool ) [ 4 ] [ 5 ] methodc ( ) [ 5 ] Index by f u n c t i o n name [ 3 ] methoda( bool ) [ 5 ] methodc ( ) [ 4 ] methodb ( bool ) [ 2 ] c a l l g r a p h ( void ) [ lionel@benq ] $ Listing 3.3 Ein call graph mit gprof Aus dem oberen Aufrufgraphen (Listing 3.3) ist im Index [4] zu sehen, dass die Funktion methodb durch methoda aufgerufen wurde und selbst methodc aufruft. Die Ausgabe von gprof kann auch auf eine bequeme Art mittels Hilfsanwendungen visualisierung werden. Abb. 3.1 zeigt z.b. die Darstellung des Aufrufgraphen mit dem Tool kprof. 25