PDF-Ausgabe herunterladen (28.1 MB) - elektronik industrie

Embedded
Entwicklungssoftware
der zu untersuchende Bereich markiert (wie in Bild 5 schattiert
angezeigt) und dann per Doppelklick das Zoomen gestartet.
Bild 1: Hotspot-Analyse – Funktionen und dazugehörige CPU-Laufzeiten.
Bild 2: Hotspotanalyse im Quellcode.
Bild 3: Auffinden von Programmineffizienz auf Funktionsebene.
unterlegt) Bereiche hingewiesen, wie das oben erwähnte CPI-Beispiel
zeigt.
Wartezyklenanalyse von Locks
Wenn man ein paralleles Programm untersucht, ist ausser der optimalen
Nebenläufigkeit (parallele Ausnutzung der vorhandenen
Prozessorkerne durch Threads) vor allem die Wartezyklenanalyse
von Locks und deren Effizienz von grossem Belang. Will ein Thread
A zum Beispiel auf eine globale Variable zugreifen, die von
einem anderen Thread B bereits genutzt und gelocked (gesperrt)
ist, muss der erste (Thread A) solange warten bis Thread B seinen
Lock auf die globale Variable freigibt. Dies kann bei vielen Threads
und längeren Lock-Bereichen zu einer Quasi-Serialisierung eines
parallelen Programms führen. Zumindest wird der Programmablauf
verlangsamt.
Bild 4 zeigt qualitativ an, welche Funktionen nicht optimal mit
Locking umgehen. Lange rote Balken sind ein Indiz für Lock-probleme.
Auch hier kann man wieder in den Sourcecode einsteigen.
Dort kann man dann eroieren, wie das Problems zu optimieren
oder zu lösen ist. Eventuell hat man eine Lockingmethode mit zuviel
Overhead gewählt. Eventuell ist durch Codeumstellungen wie
der Nutzung privater Variablen innerhalb der verschiedenen Threads
eine Vermeidung von Locks möglich. Aber auch die Nutzung
von „Concurrent Containers“ wie es das Threading Building
Block (TBB) Model von Intel offeriert, kann eine Lösung darstellen.
Lock-und Waits-Analyse
Eine weitere Darstellung im Zeitbereich ist die Lock-und Waits-
Analyse (Bild 6). Es wir dann angezeigt, wann Threads Programm
ausführen ( dunkelgrün) und wann sie im Wartemodus verharren
(hellgrün). Synchornisierungspunkte zwischen den Threads werden
durch gelbe Pfeile verdeutlicht. Auch hier ist eine Hineinzoomen
möglich, um einen höhere Auflösung und damit bessere
Deutung des parallelen Programmablaufs zu ermöglichen. Die
blauen Zeitmarkierungen sind Rahmen, die der Softwareentwickler
gezielt per API in sein Programm vor dem Testlauf einbauen
kann. So wäre es z.B. möglich, gezielt als Rahmen, ein Bild in einem
Spieleprgramm zu markieren und zu filtern. Bei Spielen ist
das sinnvoll, da Einzelbilder (Frames) und for allem “Frames pro
Sekunde“ ein natürlicher Performanceindikator für das Spiel ist.
Die erkannten Ineffizienzen (Load-Imbalances, Synchronisierungsoverhead
und so weiter) kann man wie zum Teil durch die
oben beschriebenen Ansätze oder durch optimierte Lockmechanismen
verbessern.
Vergleichsmodus
Zuletzt sei noch der Vergleichsmodus erwähnt. Dieser Modus ist
hilfreich für Regressionstests, die in der Regel einmal am Tag und
bevorzugt über Nacht laufen. Sie lassen sich auch mit dem Kommandozeilenmodus
(Command Line Mode; CLI) kombinieren
und von dort aus starten CLI-Kommandos sind per „Cut und
Paste“-Verfahren aus dem Amplifier XE (auch entsprechend aus
dem Inspector XE) heraus einfach zu initialisieren. (sb) n
Autor: Edmund Preiss ist Manager für das Business Development
der Intel Softwareentwicklungswerkzeuge in EMEA.
Bild 4: Effizenzanalyse von Locks (Wait for Locks).
Bild 5: Thread-Analyse über die Zeitachse.
Nebenläufigkeitsanalyse der Threads
Noch effizienter ist die Nebenläufigkeitsanalyse der Threads mittels
einer zeitlichen Darstellung. In Bild 5 kann man im zeitlichen
Ablauf erkennen, ob ein Thread tatsächlich aktiv ist (running).
Dieser Thread wird entsprechend grün hinterlegt. Vor allem ist zu
sehen, wieviel CPU-Zeit benötigt wird und zwar sowohl pro Thread
als auch über alle Threads zusammen (braune Histogrammdarstellung).
Ein Hineinzoomen in diesen Zeitablauf, um sich Bereiche
genauer anzusehen, ist möglich. Dazu wird mit der Maus
Bild 6: Thread –Nebenläufigkeitsanalyse (Concurrency Analysis) in
Zeitdarstellung
Bilder: Intel
76 elektronik industrie 04/2011
www.elektronik-industrie.de
74_Intel_416 (sb).indd 76 01.04.2011 13:35:00