Live-Berichterstattung von der dotnet Cologne 2011 – Teil 3
Intel-Ausstellungsbereich mit Florian und Monika
Und nun zu den Developer-Tools, die jeder Parallel-Programmierer kennen sollte. Zumindest deren Unterschiede, Stärken und Schwächen, denn so fällt es nicht nur leichter, sich für das richtige Werkzeug zu entscheiden, sondern auch Fehler im Code zu minimieren. Aber natürlich lassen sich die Tools im Einsatz auch kombinieren.
Merken Sie sich auf jeden Fall diesen Namen: Parallel Building Blocks. Denn diese Toolsuite vereint drei der wichtigsten Werkzeuge für Parallel-Programmierer: Cilk Plus, Threading Building Blocks (TBB) und die neuen Intel Array Building Blocks (ArBB), die derzeit noch in der Beta-Phase sind.
Cilk und Intel Array Building Blocks (ArBB) werde ich hier näher vorstellen.
Cilk Plus
Cilk Plus ist unbestritten das einfachste Tool und auch für Einsteiger sicher gut geeignet. Streng genommen sind sich Cilk und OpenMP recht ähnlich. Beide produzieren schnellen, parallelen Code ohne viel Overhead. Und beide werden von Intel Compilern unterstützt. Das gilt im Übrigen auch für OpenMP in der Version 3. Es gibt aber auch gravierende Unterschiede, die Cilk für Entwickler deutlich attraktiver machen als OpenMP.
Das beginnt schon bei der Bedienung. Wer sich jemals mit Cilk auseinandergesetzt hat, wird sich an das Schlüsselwörter-Prinzip erinnern. Mit den drei Kommandos cilk_spawn, cilk_sync, cilk_for erledigen Sie die wichtigsten Aufgaben im Code. Dabei kontrolliert die Cilk Plus Runtime die Threads und deren zeitliche Ausführung. Gerade dieser sehr zuverlässige Cilk Runtime Scheduler hebt sich wohltuend von OpenMP ab. Die Zahl der Threads im Code wird hierbei automatisch den vorhandenen Prozessorkernen angepasst. Der Entwickler kann dies aber auch korrigieren, wenn er das möchte.
Auch auf Data Races hat Cilk Plus eine Antwort. Natürlich lassen sich Variablen auch mit der Mutex-Methode schützen, aber Cilk Plus geht hier deutlich eleganter vor, indem es Hyperobjects nutzt. Das sorgt für eine deutliche bessere Performance.
Herauszuheben sind last but not least die Array Notations in Cilk Plus. Darüber freut sich der Compiler, der Vektoranweisungen viel besser verarbeiten kann als Schleifen. Weitere Infos gibt es übrigens auf der sehr guten Seite www.cilk.com.
Intel Threading Building Blocks (TBB)
Die Intel Threading Building Blocks (TBB) bieten eine C++-Laufzeitbibliothek und sind als Open Source oder per Compiler verfügbar. Sie sind plattform- und sprachenunabhängig und adressieren vor allem fortgeschrittene Developer. Mit anfängertauglichen Parallelfunktionen wie „parallel_for“ statt „for“ werden die TBB aber auch zunehmend für Einsteiger interessant.
Intel Array Building Blocks (ArBB)
Die jüngste Sprössling der Parallel Building Blocks heißt Intel Array Building Blocks (ArBB).
Vereinfacht ausgedrückt erledigen die ArBB folgenden Job für Code in C++: Sie parallelisieren und optimieren nativen Code, und zwar genau für die Hardware, für die er konzipiert wurde und geben den Code an den Compiler zurück.
Vorteil für den Entwickler: Er muss den Code auch für unterschiedliche Pattformen nur ein einziges Mal schreiben, kann ihn mit ArBB neu kompilieren und dann automatisch auf die Ziel-Hardware ausrichten. Wer es selber ausprobieren möchte: ArBB steht als Beta zum kostenlosen Download bereit.
So, das war’s aus Köln. In der nächsten Woche werde ich wieder live berichten – dann vom ISN Black Belt Event in München. Schönes Wochenende!
Live-Berichterstattung von der dotnet Cologne 2011 – Teil 2
Hier nun Teil 2 (hier geht’s zum ersten Teil) meiner Berichterstattung von der dotnet Cologne. Mittlerweile habe ich nicht nur spärliches Mittagessen hinter mir (gab nur noch lauwarme Frikadellen, den Rest hat die Schar der Entwickler in geschätzten sieben Minuten geplündert. Wieder mal ein Beweis für den Leitspruch „Wer zu spät kommt…“). Aber lassen wir das. Nahrhafter als der Snack war auf jeden Fall die sehr detaillierte Präsentation von Hubert Haberstock zu den aktuellen Intel Developer-Tools für Parallel-Programmierung.
Hubert Haberstock während der dotnet Cologne 2011
Klasse: Seine Ausführungen gingen bis auf Code-Ebene, und zwar immer am gleichen Beispiel. So konnte man wunderbar vergleichen, wie sich nicht nur die Code-Syntax, sondern auch die Anforderungen an den Programmierer ändern, je nachdem, welches Tool er bevorzugt wird Aber der Reihe nach:
Unter dem Motto „Parallelisierung und Skalierbarkeit in nativer C/C++ Softwareentwicklung – leichter als je zuvor“ hat Hubert zunächst die Unterschiede der Programmierung mit Managed und nativem Code erläutert. In der Kürze: Managed Code wird übersetzt und dann in der Laufzeitumgebung ausgeführt, nativer Code hingegen setzt dagegen direkt auf der Hardware auf.
Natürlich ist es deutlich komplizierter, nativen Code zu programmieren. So muss der Entwickler für Thread-Sicherheit sorgen. Die Mühen werden aber belohnt, denn der Code lässt sich sehr einfach vektorisieren. Zudem nutzt die fertige App die Power der Hardware voll aus und läuft daher schneller. Zu guter Letzt erhält und behält der Developer dank nativem Code jederzeit volle Kontrolle über die Hardware – zum Beispiel CPU-Kerne und GPU.
Sandy Bridge IVY kommt
Um das Thema Parallelisierung wird in der Zukunft kein professioneller App-Entwickler für PC-Anwendungen herumkommen. Das ist keine persönliche Einschätzung, sondern eine Prognose, die sich sehr leicht nachvollziehen lässt, wenn man einen Blick auf die kommenden Prozessorfamilien wirft. Nach Sandy Bridge wird Sandy Bridge IVY kommen, die nächste Generation der Mehrkernprozessor-Systeme im 22-Nanometer-Herstellverfahren. Nur paralleler Code ist dann in der Lage, den Geschwindigkeitsvorsprung zu nutzen, den die Hardware vorgibt. Und daran wird sich nichts mehr ändern
Parallelisieren? Gerne! Aber wie?
Es gibt sehr viele unterschiedliche Möglichkeiten, um seriellen Code zu parallelisieren, es gibt kostenlose und sehr teure Tools. Und es gibt einsteigerfreundliche Methoden und sehr komplizierte, die selbst Profis vor Herausforderungen stellen. Hubert hat das sehr gut demonstriert, indem er Compiler-Switches für Autovektorisierung (sehr einfach) nativem Threading via Win 32-API oder POSIX gegengestellt hat. Threading ist sehr kompliziert, belohnt den Entwickler aber mit hoher Kontrolle über Apps und Hardware und großer Thread-Sicherheit.
Mit seinen Werkzeugen deckt Intel ein breites Spektrum an Parallelisierungs-Tools ab, angefangen vom Einsteiger-freundlichen Cilk über die Threading Building Blocks (TBB) bis hin zu den neuen Intel Arrray Buidling Blocks (ArBB).
Diese drei Tools werde ich im nächsten Blog-Beitrag detailliert beschreiben und vergleichen und damit den Report von Huberts sehr gutem Vortrag fortsetzen.
OOP 2011: Stephen Blair-Chappell über Chancen und Grenzen der Parallel-Programmierung
Am gestrigen Dienstag hatte ich auf der OOP 2011 die Gelegenheit, den sehr interessanten Vortrag „Parallelising Legacy Programs“ von Stephen Blair-Chappell, Mitarbeiter der Intel Compiler Labs zu verfolgen. Zu Deutsch: Es ging um das Thema „Parallelisieren bestehender Anwendungen“. Klingt zunächst recht trocken und sehr theoretisch. Stephen hat – trotz vieler Code-Beispiele – seinen Vortrag aber didaktisch sehr gut aufgebaut, so dass auch Einsteiger viel nützliches Wissen mitnehmen konnten.
Im Übrigen hatte ich auch die Gelegenheit, nach der Session mit Stephen persönlich zu sprechen und ein kurzes Video-Interview zu führen. Das werde ich selbstverständlich auch in Kürze auf dieser Seite veröffentlichen.
Fallstricke
Zurück aber zu den Vorteilen und Fallstricken der Parallel-Programmierung. Stephen konnte anhand früherer Projekte sehr eindrucksvoll demonstrieren, dass der erste Schritt der Parallelisierung immer darin besteht, den vorhandenen Code zu verstehen und zu analysieren. Klingt banal, in der Praxis aber passieren genau hier die meisten Fehler. So verfallen auch erfahrene Programmierer der Verlockung, vorschnell neuen Code zu implementieren, anstatt frühere Schwachstellen zu korrigieren. Der Effekt: Trotz erfolgreicher Ausrichtung auf mehrere Prozessorkerne zeigen die Anwendungen keinen nennenswerten Geschwindigkeitsgewinn.
4-Stufen-Methode
Dann ist die Ursachenforschung kompliziert und sehr aufwändig. Stephen erklärte, dass mitunter sogar ein aktiver Virenscanner als Bremsklotz einer Parallel-Anwendung fungieren kann. Diese Dinge sollte man demnach schon beim Check des seriellen Codes im Auge behalten. Daraus ergibt sich für Programmierer eine 4-Stufen-Methode bei der Parallelisierung, die grundsätzlich eingehalten werden sollte:
- Analyse des seriellen Codes hinsichtlich möglicher “Hotspots”
- Implementierung von Parallelkonstrukten auf Basis passender Programmiermodelle
- Fehlersuche mithilfe geeigneter Tools
- Optimierung des neuen, parallelisierten Codes
Die für die Implementierung gewählten Programmiermodelle (Sprache, Bibliotheken, Methoden) sind dabei sowohl vom ursprünglichen Code als auch von der Zielsetzung des Projektes abhängig. Stephen konnte hier in unterschiedlichen Szenarien beispielsweise die Vorteile von Cilk und OpenMP erläutern und verdeutlichten, dass sowohl der Compiler als auch die Hardware eines Systems über die Performance der Anwendung entscheiden.
Am Ende des Vortrags ging Stephen auf ein Thema ein, das bei aller Begeisterung für Multicore gerne übersehen wird: Auch Parallel-Programmierung ist nicht immer der Weisheit letzter Schluss. In einigen Fällen reicht es aus, den seriellen Code zu optimieren. Aber diese Frage sollte eigentlich schon während der Analyse beantwortet werden.
Infos aus erster Hand zu Cilk
Wie ich ja kürzlich per Twitter vermeldet habe, saß ich am Dienstag mit Mario Deilmann von Intel beisammen, um über ein paar mögliche Themen für das Software Dev Blog zum Thema Multicore-Programmierung zu reden. Und so haben wir diverse Themen evaluiert und identifiziert, und als erstes Ergebnis veröffentliche ich heute ein paar Infos zu Cilk, die mir Mario in mein iPhone diktiert hat. Und so gibt es dann nach und nach zu Cilk und den anderen Themen weitere interessante Informationen.
Die Idee von Cilk ist recht einfach: Man erhält ein serielles Programm, wie man das schon von OpenMP kennt. Allerdings kann das mit OpenMP “unterwandert” werden, indem man Abhängigkeiten in den Code einbaut. Bei Cilk hingegen werden die zu parallelisierenden Codeteile einfach mithilfe bestimmter Spawn-Konstrukte ausgelagert. Zudem können die so parallelisierten Abschnitte wieder serialisiert werden, indem man die Spawn-Befehle einfach wieder aus dem Code herausnimmt. Daneben gibt es ein weiteres Cilk-Konstrukt, das mittels einer for-Methode Schleifen parallelisiert.
Das Tolle an Cilk ist der zugeghörige Scheduler, der sehr schlau ist und task-orientiert arbeitet, und nicht wie bei OpenMP thread-basiert. Dabei werden stets möglichst viele Tasks an den Scheduler übergeben, der diese mit einem intelligenten Algorithmus auf die vorhandenen Thread-Ressourcen verteilt. Der Scheduler ist übrigens derart skalierend, dass auch große Rechensysteme optimal ausgenutzt werden.
So skalierte ein cilk-optimiertes Schachprogramm auf einem Rechner mit 512 Kernen so gut, dass es den dritten Platz in einem großen Schachturniert belegte. Der Trick des Cilk-Schedulers besteht übrigens darin, dass die Tasks per Zufall auf die Threads verteilt werden und nicht nach “menschlichen” Kriterien. Ach ja: Das Work Stealing hat seinen Ursprung im Cilk-Scheduler und wurde sukzessive in die Microsoft-Scheduler eingebaut.
Daneben muss mit Cilk nicht darauf geachtet werden, dass die zu parallelisierenden Aufgaben (Tasks) logisch angeordnet sind. Einzige Voraussetzung für eine cilk-basierte Parallelisierung ist die Unabhängigkeit der Tasks zueinander, so dass jeder Task eine Spawn-Methode zugewiesen werden kann. Darüber hinaus dürfen die jeweiligen Codeabschnitte nicht von globalen Variablen abhängen beziehungsweise diese nicht modifizieren. Ansonsten bekommt man es ganz leicht mit Data Races zu tun.
Allerdings ist zu berücksichtigen, dass es mit Cilk wie bei OpenMP, TPL und PPL vor allem um eine Lastverteilung geht, und nicht um eine Verteilung von Funktionalitäten auf die vorhandenen Ressourcen.
Schön an Cilk ist auch die einfache Handhabung: Außer den beiden Spawn- und For-Konstrukten muss man nichts lernen, sodass selbst ungeübte C- und C++-Entwickler Cilk ziemlich schnell einsetzen können. Das Gute an Cilk ist auch seine Vorhersehbarkeit: Sobald das cilk-optimierte Programm vorliegt, kann man anhand der gegebenen Parameter genau berechnen, was die Parallelisierung in Sachen Rechenleistung bringen wird.
Eine Besonderheit an Cilk sind die sogenannten Hyperobjects, mit denen ein parallelisierter Codeabschnitt seine eigene Sicht auf globale Variablen bekommt. Soll heißen, dass jeder Thread seinen eigenen Zugriff auf die globalen Variablen erhält, ohne diese zu verändern, so dass es nicht zu Data Races kommen kann. Dabei wird das Ganze lock-frei realisiert, da für jeden Thread eine eigene Speicherzelle angelegt wird, deren Inhalte am Schluss wieder zusammen geführt werden, so dass das richtige Ergebnis in der globalen Variable steht. Praktisch an Hyperobjects ist auch die Tatsache, dass man eigene anlegen kann. Damit ist Cilk ein ganzes Stück flexibler als OpenMP oder TBB.
