Parallel-Studio-Serie (4): mehr Infos zum Parallel Amplifier

Mit dem vierten und letzten Teil endet unsere kleine Serie rund ums Parallel Studio. Thema des heutigen Blogeintrags: Parallel Amplifier. (Hier geht’s zu den Teilen eins, zwei und drei).

Wie ich ja schon berichtet habe, sucht der Parallel Amplifier nach Optimierungspotenzial in Multithread-Anwendungen. Für eine optimale Performance also. Hierfür leistet das Tuningtool eine ganze Menge:

Aufspüren von Hotspots: An welchen Stellen verbrät die Anwendung besonders viel Zeit und was kann ich dagegen tun? Hierzu werden die kritischen Bereiche grafisch dargestellt und können so schneller identifiziert werden. Zudem liefern die Stack-Aufrufe wichtige Infos über das Laufzeitverhalten der Anwendung.

Parallelität verbessern: Wo klappt es mit der Parallelisierung noch nicht so gut und welche Quellcode-Abschnitte könnte man noch weiter simultan schalten? Um diese Fragen beantworten zu können, erhält der Anwendungsentwickler grafisch aufbereitete Hinweise darauf, welche Programmabschnitte die vorhandenen CPU-Ressourcen über- bzw. unterbeanspruchen. Genau an diesen Stellen lässt sich dann der Quellcode tunen.

Wartezeiten finden: Wo muss die Anwendung zu lange warten, weil bestimmte Abhängigkeiten existieren? Wie kann ich diese Hotspots identifizieren und möglichst auflösen? Auch hierfür stellt der Parallel Amplifier die betreffenden Quellcode-Abschnitte grafisch dar und zeigt in Balkenform die Auslastung der Prozessoren an. So lassen sich Idle-Zustände relativ einfach herausfinden.

Eine weitere praktische Eigenschaft des Parallel Amplifier ist dessen Transparenz in Sachen Laufzeitverhalten. So lässt sich jede Funktion, jeder Callaufruf und jede Prozedur bis auf jede einzelne Quellcode-Zeile herunterbrechen und analysieren. Das gibt dem Programmierer ein gutes Gefühl dafür, wo es klemmt und wo er noch mehr machen muss.

Und es lassen sich mehrere Testläufte aufzeichnen und die Ergebnisse miteinander vergleichen. Auch das sorgt im Problemfall für zusätzliche Hinsweise darauf, dass die parallelisierte Anwendung weiter optimiert werden muss – oder sich gar Fehler eingeschlichen haben.