Parallelisierungspotenzial von Anwendungen mit Hilfe von Parkour bestimmen
Also, es gibt ja Tools, die kaum ein Mensch kennt, was wirklich eine Schande ist. Denn mit einem Werkzeug wie Parkour, das begabte Wissenschaftler der Universität von Kalifornien in San Diego entwickelt haben, lässt sich das Leben eines Software-Ingenierus sicherlich vereinfachen. Was aber genau tut Parkour hierfür?
Nun, zunächst einmal stelle man sich vor, dass man eine seriell/sequentiell programmierte Anwendung gebaut hat, von der man gerne wissen möchte, ob sie auf einem Multicore-System schneller laufen würde, wenn sie parallel programmiert wäre. Und das betrifft schließlich einen Großteil sämtlicher Computersysteme, die derzeit am Markt zu kaufen sind. Denn das Parallelisieren von Software-Anwendungen kostet Zeit und Geld und sollte damit wohl überlegt sein.
Und genau hier setzt Parkour an. Anhand einer hirarchischen Analyse sämtlicher kritischen Pfade einer Anwendung (Hierarchical Critical Path Analysis) ermittelt das Tool diejenigen Codebereiche, die sich ganz besonders für die Parallelisierung von seriellem Code eignen. Hierzu gehören vor allem Schleifen und Rekursionen, aber auch andere Konstrukte. Für diese Analyse muss allerdings keine Instrumentalisierung (Instrumantation) des Codes vorgenommen werden, da dies der Parkour-Compiler übernimmt. Das Ergebnis der vollständigen Anaylse einer Anwendung mit Hilfe von Parkour stellt eine Vorhersage anhand eines 64-Core-Systems dar. Damit lässt sich relativ genau prognostizieren, in welchem Ausmaß die serielle Anwendung im parallelisierten Fall skalieren würde, und zwar auf 1, 2, 4, 8, 16, 32 und 64 Prozessorkernen.
Die Grenzen von Parkour werden allerdings bei kurzem Nachdenken recht schnell klar: Neben der hilfreichen Aussage, in welchem Umfang die Anwendung auf x Kernen laufen würde, fehlen nützliche Hinweise, in welchen Bereichen die Parallelisierung des Software-Programms sinnvoll wäre. Hierfür benötig man also andere Tools, so wie Intel Parallel Advisor oder CilkView, wobei CilkView ähnlich wie Parkour arbeitet. Parallel Advisor hingegen gibt Auskunft darüber, an welchen Stellen Optimierungspotenzial besteht und wie dies zu implementieren ist. Allerdings steht Parallel Advisor nur C/C++-Entwickler zur Verfügung. Mehr Infos hierzu finden Sie auch bei Intel.
Ach ja: Die Herren Amdahl und Gustafson haben sich schon vor vielen Jahren zur Skalierbeit von Software-Anwendungen so ihre Gedanken gemacht.
Fehler im Multithread-Code aufspüren: Thread Checker
Beim Erstellen von parallel programmiertem Quellcode treten im Gegensatz zu seriellem Sourcecode zwei mögliche Probleme sehr viel häufiger auf: Race Conditions und Dead Locks. Beide sind mit herkömmlichen Mitteln nicht aufspürbar, so dass ein spezielles Tool erforderlich ist, dass diese Aufgaben erledigen kann. Dieses Software-Werkzeug nennt sich Thread Checker und ist Bestandteil des VTune Performance Analyzer, der sich wiederum vollständig in Visual Studio integrieren lässt.
Damit steht der Thread Checker in der bekannten Entwicklungsumgebung zur Verfügung. Eine Einschränkung gibt es allerdings: Es lassen sich nur nativ programmierte Anwendungen mit dem Thread Checker überprüfen, also nur C++ und Visual Fortran. .NET-Entwickler bleiben derzeit leider außen vor. Dies wird sich allerdings mit Visual Studio 2010 ändern, das ja Ende nächsten Jahres auf den Markt kommen soll.
Exkurs: Race Conditions und Dead Locks
Race Conditions treten vor allem dann auf, wenn ein parallel programmiertes Programm zur Laufzeit zwei Thread generiert, die beide auf ein gemeinsames Datum zugreifen und davon nichts wissen. So erzeugt Thread A beispielsweise ein Datum X und speichert es, was Thread B genauso tut, ohne darüber Bescheid zu wissen, dass Thread A das Datum X gerade geändert. Dies kann natürlich zu unvorhergesehenen Problemen und Fehlern im weiteren Programmablauf führen.
