Warum bei Parallelprogrammierung neue Werkzeuge unumgänglich sind

Seite 2: Neues von der Tool-Front

Inhaltsverzeichnis

Nicht nur die Werkzeuge selbst erfuhren Änderungen, auch in Bezug auf die Bibliotheken für Parallelprogrammierung gibt es Bewegung. Die bereits im Vorjahr vorgestellte Technik Cilk – ein Satz von Spracherweiterungen für Tasks und Datenparallelisierung – ist als Cilk Plus im aktuellen Parallel Studio enthalten, und die Threading Building Blocks (TBB), eine Template-Bibliothek für die Parallelprogrammierung unter C++, kletterten inzwischen auf Version 3.0. Seit der TBB 3.0 lassen sich wahlweise auch Sprachfeatures von C++0x einsetzen. Die Bibliothek liegt als Open-Source-Version vor und kann für Linux und Windows eingesetzt werden, wobei sie sich auch in Visual Studio integrieren lässt.

Auf der letztjährigen Konferenz wurde bereits ein erster Ausblick auf eine Bibliothek für parallelisierte Daten gegeben, mit dem Arbeitstitel "Ct", diese liegt nun als Array Building Blocks vor. Laut Reinders ist sie derzeit in bestimmten Einsatzszenarien bereits sehr performant, könne allerdings durch kleine Änderungen auch relativ langsam werden. Das ist eine der Aufgaben, die Reinders auf der Agenda seines Teams für die kommenden Monate sieht. Zum Jahreswechsel soll das dann zusammen mit einer Version von TBB 4.0 zu Parallel Building Blocks (PBB) zusammenfasst sein.

Intels Vorstellung der Parallel Building Blocks

(Bild: intel.com)

Eine wichtige Aussage gab Reinders den Zuhörern noch mit auf den Weg, warum sie sich bei der Parallelprogrammierung besser auf Bibliotheken abstützen sollen und nicht auf nativen Anwendungen – seien es POSIX-Lösungen oder Winthreads: Nur bei Bibliotheken, deren Komponenten in sich abgestimmt sind, wird man auch geeignete Profiling- oder Analysetools finden, um die Programme zu verbessern. Nach seinem Wunsch idealerweise Intels Palette.

Trotzdem arbeitete und arbeitet Intel anscheinend auch hart daran, dass seine Komponenten kompatibel zu anderen Compilern, Herstellerbibliotheken und Laufzeitumgebungen sind. Ein Beispiel ist die Austauschbarkeit von OpenMP zwischen Intel, gcc und Microsofts Implementierung, oder die Abstimmung der Synchronisationsmechanismen innerhalb der Laufzeitumgebungen der diversen Compiler.

In einer Live-Demo zeigte Heinz Bast, wie man in einem rechenintensiven Programm durch schrittweise Ergänzung mit Intel-Werkzeugen die Anzahl pro Iteration benötigter Zyklen von 2000 auf etwa 200 reduziert. Zunächst wird das Programm mit dem Intel-Compiler übersetzt, um den ersten Optimierungsschritt zu beginnen. Danach werden Programmteile mit Cilk Plus oder OpenMP parallelisiert, was bei Berechnungen und Initialisierungen zu Gewinnen führt. Analysen mit Inspector XE zeigen auf, wo durch die Parallelisierung potenzielle Deadlocks und Data-Races lauern, sodass diese sich beseitigen lassen. Wem das noch nicht ausreicht, fügt dann Aufrufe aus Intels Math Kernel Library hinzu, in der sich mathematische und statistische Berechnungen befinden. Der Ablauf zeigt gut auch Intels Philosophie der Parallelprogrammierung: Intel-Compiler, Intel-Analyse-Tool, Intel-Bibliotheken – in dieser Reihenfolge soll der Softwareentwickler das Potenzial eines Multicore-Systems erschließen.

Aus dem Bereich der Analysetools stellte Levent Akyil die aktuelle Version des VTune Analyzer vor. Bei den Zuhörern stieß die neue Funktion der "Frame-Analyse" auf Interesse. Bei der klassischen Hotspot-Analyse ergibt sich eine Aussage, welche Funktionen oder Aufrufketten am meisten CPU-Zeit verbrauchen. Diese werden dann zur Optimierung vorgeschlagen. In vielen Anwendungen ist dieser Engpass aber gar nicht das wesentliche Problem, wenn zum Beispiel Frame-Anwendungen (ein Spiel oder ein Video) zu optimieren sind. Denn für die Masse der Frames ist das Programm jeweils rechtzeitig fertig, nur manchmal dauert eine Berechnung länger als die pro Frame zur Verfügung stehende Zeit. Für den Betrachter stellt sich dieses Verhalten als klassischer "Lag" dar – ein Bild hängt oder ruckelt kurz.

Mit der aktuellen Version des VTune Analyzer kann man nun genau solche "zu langsamen" Frames untersuchen und die Ursachen finden. Die Hotspot-Analyse beschränkt sich damit nicht mehr nur auf den reinen Code, sondern wird auch ein Stück weit situationsabhängig. Interessant ist auch, dass man als Entwickler selbst Programmabschnitte als Beginn und Ende von Frames definieren kann, womit sich völlig neue Optimierungspotentiale ergeben.

Auf der Suche nach langsamen Frames mit dem VTune Analyzer


Intel-Plattformen finden sich auch zahlreich im Embedded-Umfeld, meistens im Zusammenhang mit dem Atom-Prozessor. Selbstverständlich sind die Intel-Werkzeuge auch dafür ausgelegt, wobei hier wesentlich die Anwendungsfelder Cross-Entwicklung (die Software wird nicht auf dem Zielsystem entwickelt, sondern auf einem anderen System) und Remote-Debugging (das Debugging wird von einem zweiten Rechner ferngesteuert, über eine TCP/IP-Verbindung oder ein spezielles JTAG-Interface) hinzukommen. Interessant sind auch die vorgestellten Möglichkeiten der Remote-Analyse – durch zusätzlichen Code auf dem Zielsystem lassen sich Informationen über den Ablauf sammeln und wieder zurück auf das Entwicklungssystem übertragen. Danach können genau wie bei den "normalen" Analysetools Auswertungen in Bezug auf Optimierungsmöglichkeiten, überflüssige Wartezeiten oder Fehlverhalten des Codes gefahren werden.

Eine Frage bewegte die Zuhörer natürlich besonders: Was geschieht mit MeeGo? Durch die künftige Zusammenarbeit von Nokia mit Microsoft fällt hierbei ein starker Partner im Mobiltelefonbereich weg. Intel wird deswegen aber nicht Bange, man verspricht sich vor allem im Segment der Tablets günstige Einsatzmöglichkeiten, auch als Gegengewicht zu Googles Android.

Remote-Debugging einer MeeGo-Applikation


Intels Strategie zur besseren Ausnutzung der Rechenleistung der hauseigenen Prozessoren stellte sich auf der diesjährigen ISC relativ klar dar: Der Compiler optimiert selbst bereits so weit wie möglich. Sobald die Compiler-Automatismen nicht mehr greifen, verschafft sich der Entwickler mit dedizierten Analyse- und Auswertungstools einen Überblick zu Engpässen im Programm. Und wenn dann diese Stellen parallelisiert und optimiert werden, sind die vorgefertigten Parallelisierungsbibliotheken umfangreich anzuwenden.

Die größte Herausforderung für Intel liegt hierbei sicherlich darin, den Bekanntheitsgrad der eigenen Tools zu steigern, aber auch die Welt der Programmierer davon zu überzeugen, dass bei der Parallelprogrammierung der Einsatz neuer Softwarewerkzeuge unumgänglich ist. Die Intel Software Conference 2012 wird zeigen, was davon bereits realisiert wurde.

Marcus Bäckmann
ist als Projektleiter für Factory Automation und Produktions-IT tätig. Von Zeit zu Zeit betätigt er sich als Übersetzer und Buchautor rund um die Sprachen C und C++.
(ane)