para//el 2012 - Softwarekonferenz für Parallel Programming, 23.-25. Mai 2012

[pumuckl]

Para//el 2012 - Softwarekonferenz für Parallel Programming, Concurrency und Multicore-Systeme

23.-25. Mai, Karlsruhe

Parallele Rechner gibt es schon seit Längerem, mit dem Einzug von Mehrkernprozessoren in PCs, mobile Geräte und andere Hardware wird die Herausforderung, parallele Programme zu schreiben, immer mehr zum Mainstream-Alltag. Im Rahmen einer Verlosung von c++.de habe ich eine Eintrittskarte zu der Veranstaltung ergattern können und bin so in den Genuss einiger interessanter Talks an den beiden Session-Tagen gekommen. Der dritte Tag bestand aus drei Workshops im kleineren Kreis.

Die Idee zur Konferenz kam den Veranstaltern von heise.de und dpunkt-Verlag im Jahr 2010, die Para//el 2012 war die erste und sicher nicht die Letzte Konferenz dieser Art in Deutschland. Mit 160 Teilnehmern und 40 Vortragenden war die Konferenz bereits kurz nach der Frühbucherzeit ausgebucht, es konnten nach Angaben der Veranstalter nur ca. zwei Drittel der eingereichten Vorträge berücksichtigt werden.

Tag 1

Keynote: Grundlagen der Mutlicore-Programmierung (Walter F. Tichy)

In seiner Keynote skizziert Walter F. Tichy (Karlsruher Institut für Technologie) die Entwicklung von Prozessoren und Parallelrechnern, insbesondere von Mehrkernprozessoren. Single-Cores für den PC sind heute praktisch nicht mehr zu kaufen, Mehrkerner halten auch in mobilen Geräten Einzug: 2011 ist das erste Smartphone mit einem 5-Kern Prozessor auf den Markt gekommen.

Das Mooresche Gesetz der immer weiter steigenden Rechengeschwindigkeit muss unter einem neuen Gesichtspunkt gesehen werden: zwar verdoppelt sich die Zahl der Schalteinheiten pro Fläche auf aktuellen Chips immer noch alle 1-2 Jahre, allerdings heißt das nicht, dass sich diese Schalteinheiten alle in einem Kern wiederfinden und mit entsprechend erhöhter Taktrate nutzen lassen. In neueren Prozessoren bleibt die Taktfrequenz weitgehend konstant, auch steigt die Zahl der Schalteinheiten pro Prozessorkern kaum noch. Stattdessen kann man das Mooresche Gesetz jetzt fast direkt auf die Zahl der Kerne pro Prozessorchip beziehen.

Die Konsequenzen der Entwicklung sind klar, wer die Ressourcen moderner Prozessoren nutzen will muss umdenken und für Mehrkerner programmieren. Die Zeit, dass Programme automatisch mit der nächsten Rechnergeneration schneller ablaufen und mehr Daten verarbeiten können, ist vorbei.

Im Anschluss erklärt Tichy die Terminologie der Parallelverarbeitung und zeigt an Hand eines Beispiels eines der größten Probleme des Parallelcomputings und eine Lösung: Race Conditions und Synchronisation. Zu guter Letzt gab es noch einen kurzen Überblick über häufig anzutreffende Muster der Parallelverarbeitung und ein Anwendungsbeispiel mit verschiedenen Lösungsansätzen. An Hand dieses Beispiels wurde ein inhärentes Probleme der parallelen Softwareentwicklung deutlich: Man kann den Performancegewinn eines Programms durch verschiedene mögliche Parallelisierungen nicht ordentlich abschätzen. Vielmehr ist nur durch Performancemessungen herauszufinden, welche der verschiedenen Möglichkeiten die schnellste für einen gegebenen Datenbestand ist.

Typische Fehler in parallelen Programmen (Oliver Denninger, Frank Padberg)

An Hand von Fehlern aus Open Source Projekten wie Mozilla, Jetty und MySQL werden die häufigsten Fehlerursachen in parallelen Programmen veranschaulicht. Solche Fehler können sich in verschiedenster Weise manifestieren: Abstürze, aufhängen, falsche Ergebnisse, Performanceverluste usw. Eines der größten Probleme solcher Nebenläufigkeitsfehler ist die Nachstellbarkeit: auf Grund der nichtdeterministischen Eigenschaften paralleler Programme sind solche Fehler extrem schwierig bis unmöglich zu debuggen. Kleinste Änderungen können das Auftreten solcher Fehler verhindern, verändern oder erst hervorbringen.

Die Vortragenden zeigen an Hand von Codeausschnitten, Sequenzdiagrammen und Zugriffsdiagrammen ausgewählte typische Fehler und ihre Lösung. Die typischen Denkfehler von Entwicklern können dabei in drei Hauptkategorien eingeteilt werden: Atomaritätsverletzung (Beispiel: i++ ist nicht atomar), ungültige Annahmen über die Reihenfolge, in der bestimmte Anweisungen ausgeführt werden sowie Verklemmungen (Deadlocks). Diese drei Typen machen laut einer Studie die häufigsten Fehler paralleler Programme aus, andere tauchen nur selten auf.

Plattformunabhängige Parallelprogrammierung mit C++ und Qt (Matthias Nagorni)

Matthias Nagorni (freiberuflicher Consultant) stellt Qts Möglichkeiten für den Umgang mit parallelen Programmen vor. Im Mittelpunkt stehen QThreads und das Verschieben von QObjects in andere Threads, sowie die Synchronisierung mittels QMutex. QFutures, ein eingebauter Threadpool und die taskbasierte Programmierung mit QRunnable werden kurz angesprochen, kommen aber zu kurz, insbesondere was den Vergleich zu ähnlichen Frameworks (Threading Building Blocks, Parallel Patterns Library) und einige diesbezügliche Fragen aus dem Publikum betrifft. Besonders zu erwähnen sei noch, dass nicht jedes Problem mit Synchronisierung zu lösen ist: ca. einem Viertel der Fehler soll nicht mit zusätzlichen Sperren beizukommen sein.

Concurrency im neuen C++11-Standard (Detlef Vollmann)

Wenn ein Talk "C++" im Titel hat, ist er natürlich Pflicht für mich, vor allem wenn er von einem Mitglied des Standard-Committees gehalten wird. Detlef Vollmann (vollmann engineering gmbh) stellt in seinem Talk die Features des neuen C++-Standards vor, die das parallele Programmieren betreffen.

Der erste der vier Hauptpunkte befasst sich mit dem Speichermodell, insbesondere wird im Vortrag auf die Problematik von Cache-Inkohärenzen eingegangen. Der Vortragende geht nicht weiter auf die neue Speicherklasse thread_local ein, da sie mit zukünftigen Erweiterungen nicht gut zusammenarbeitet und für non-PODs noch gar nicht implementiert wurde. Stattdessen werden die Bedeutung von funktionslokalen static Variablen und std::call_once angesprochen und die Tatsache, dass volatile in C++ nichts mit paralleler Programmierung zu tun hat.

Punkt zwei des Vortrags ist die "mid-level library". Unter diese Bezeichnung fallen std::async , std::future und std::promise . Es wird auf einige Details von std::async eingegangen, z.B. dass man innerhalb der aufgerufenen Funktion kein thread_local benutzen und nicht schreibend auf geteilten Speicher zugreifen sollte.

Im Anschluss kam die "low-level library" zur Sprache, diese umfasst Threads, Mutexe, Locks und condition_variable . Der vierte und letzte Punkt sind atomics, die für lock-free Algorithmen notwendig sind (experts only!).

Wie schon an den Bezeichnungen "mid-level" und "low-level" zu erkennen ist, war die Quintessenz des Vortrags, dass die Concurrency-Features der Standardbibliothek weniger für den Ottonormal-Entwickler geeignet sind, sondern vielmehr auf Bibliotheken zurückgegriffen werden sollte, die Abstraktionen auf höherer Ebene anbieten wie z.B. Thread Building Blocks (TBB) und die Parallel Patterns Library (PPL). In einem Ausblick für C++17 (der Arbeitstitel für den nächsten Standard) wurden entsprechend auch task-basierte Parallelisierung, die Erweiterung der asynchronen Operationen (z.B. future::then() ) und wichtige Klassen wie z.B. MessageQueues genannt.

Erlang, Open Source und die Finanzindustrie (Erfahrungsbericht der Baader Bank AG)

Im Wertpapierhandel müssen laufend unzählige Informationen verarbeitet werden. In einem typischen Programm kommen Ankaufs- und Verkaufsorders zu diversen Wertpapieren, außerdem müssen Kursupdates von mehreren Börsenplätzen verarbeitet werden und resultieren in eigenen Ordern für die internen Konten der Bank. Bei der Baader Bank werden mehrere hunderttausend solcher Events pro Sekunde verarbeitet. Maxim Minin und Reinhard Braumandl (beide Baader Bank) stellen in ihrem Vortrag vor, wie die Aktor-basierte Sprache Erlang bei der Bewältigung dieser Aufgabe die natürliche Umsetzung der notwendigen parallelen Algorithmen unterstützt.

Numerobis Multicoris - Entwurfsmuster und Datenstrukturen für parallele Programme (Urs Gleim, Tobias Schüle)

Wie der aus Asterix und Obelix entnommene Name Numerobis schon sagt, geht es bei diesem Vortrag um Architekturelemente paralleler Software. Im ersten Teil wird die Anwendung von taskbasierter Parallelisierung vorgestellt. Tasks sind sehr viel leichtgewichtiger als Threads, bei richtiger Programmierung vermeidet man viele der Probleme von Threads und stellt im Gegenzug die Skalierbarkeit für zukünftige Multicore-Architekturen sicher. Tasks sind kleine isolierte und in sich abgeschlossene Aufgaben, die typischerweise in einem Threadpool abgearbeitet werden.

Punkt zwei auf der Agenda des Vortrags ist datenbasierte Parallelisierung - typische Lehrbuch-Beispiele hierfür beschäftigen sich meistens mit Rechnungen auf größeren ein- oder mehrdimensionalen Arrays, wobei die Berechnungen auf Teilen dieser Arrays parallel ausgeführt werden können. Der dritte Teil des Vortrags ist verschiedenen Datenstrukturen und ihrer Eignung für den parallelen Zugriff gewidmet. Namentlich werden hier Synchronisierungsprobleme am Beispiel einer verketteten Liste verdeutlicht.

Als Abschluss des ersten Tages gab es Flammkuchen, Bier und Wein bei gutem Wetter und unterhaltsamen sowie informativen Gesprächen im Innehof des Veranstaltungsortes.

Tag 2

Die Konferenz ging am zweiten Tag so informativ weiter wie sie am ersten Tag angefangen hatte. Leider war ich nur bis zur Kaffeepause am Nachmittag anwesend, konnte also nicht die letzten beiden Slots des Tages besuchen. Die anderen Vorträge haben den Verlust aber mehr als wettgemacht.

Das Multi-Core-Dilemma - Ursachen und Auswege (Michael Wiedeking)

Der Vortrag fing humorvoll an: "Haben Sie den Ablauf beim Flammkuchenbacken gestern abend gesehen? Die vier Worker-Threads, die da an der Arbeit waren?" Gemeint waren die vier Leute, die in guter Abstimmung wie am Fließband Flammkuchenteig geknetet und gewalzt, belegt, in den Ofen geschoben und an die Leute ausgegeben haben. Ebenso humorvoll ging es weiter: "Stellen Sie sich vor, sie wollen einen DVD-Abend veranstalten und dazu Pizza machen, haben dafür aber nur 90 Minuten Zeit".

Das Pizza-Beispiel immer an der Hand ging es durch die Multicore-Welt, mit Einblicken in die Hardware älterer und aktueller Prozessoren, den Unterschieden zwischen Multicore-Threading und Hyperthreading, den damit verbundenen Problemen wie z.B. false Sharing und natürlich nochmal dem Vergleich von Amdahls und Gustafsons Gesetz. Laut ausgegebenem Foliensatz waren offenbar noch Übersichten über die Parallelitäts-Features einzelner Programmiersprachen geplant, allerdings ist dort das Pizza-Beispiel nicht enthalten.

Scheinbar hatte Michael Wiedeking es noch am Abend vorher inspiriert von den Flammkuchen schnell eingebaut. Die sprachgebundenen Details kann man ja auch andernorts nachschlagen. Fazit des Vortrags: "Der Flaschenhals ist die Ruhezeit für den Hefeteig. Machen Sie stattdessen Flammkuchen: fast die gleichen Zutaten, keine Ruhezeit, kürzere Backzeit. Lassen Sie einfach die Hefe weg." Unterhaltsam und anschaulich zugleich.

Das "Let It Crash"-Prinzip (Pavlo Baron)

Mit einem BSOD als Folienhintergrund kommt diese etwas provokant betitelte Präsentation daher. Pavlo Baron erklärt den Zuhörern, dass der Entwickler, Tester und Nutzer unserer Software Murphy heißt. Und dass wir in keinem Fall wissen können, was alles schief gehen kann. Das häufig anzutreffende Procedere des defensiven Programmierens wird etwas abwertend als "Errorhandler of fear" bezeichnet, doch was ist die Alternative?

Es folgt die Aufforderung, "jemand anderen" die Aufräumarbeit nach Fehlern machen zu lassen. Code sollte nicht durch übervorsichtige Fehlerbehandlung überfrachtet werden. Wenn etwas nicht funktioniert, dann soll man es fehlschlagen lassen.

Was braucht man für diese Art der Programmierung, und welche Sprache liefert das? Pavlo Baron stellt danach die Features einer Sprache vor, nennt ihren Namen aber erst spät: Erlang. Anschließend wird die provokante Aussage "let it chrash" ein wenig relativiert, defensive Programmierung hat schließlich doch auch ihren Platz, sie muss nur sinnvoll eingesetzt werden und nicht als blind zu befolgendes Dogma. Was man aus dem Vortrag am Ende mitnehmen kann ist neben der Promo für Erlang die Erkenntnis, dass man nicht blind für alle Eventualitäten programmieren sollte, sondern sich bei Fehlern immer fragt, ob es einem etwas nützt, sie zu abzufangen.

Keynote: Can we make sequential software rare? (Tim Mattson)

Tim Mattson ist der Parallelwelt ein Begriff. Er ist unter Anderem Coautor des Buches "Patterns for Parallel Programming" und hat seit 1993 bei Intel an der Entwicklung paralleler Hardware mitgewirkt. In seiner Keynote zeigt er Facetten eines sehr aktuellen Problems auf: während parallele Hardware allgegenwärtig ist, kann man das von paralleler Software ganz und garnicht sagen. Es wird eine parallele Entwicklungsumgebung/Sprache nach der anderen erfunden, verfeinert, überholt und verworfen, den heiligen Gral der parallelen Software hat aber trotz aller Mühen noch niemand gefunden.

Tim Mattson propagiert eine Teilung der Entwicklerteams und der Software in zwei Schichten, angelehnt an die Spiele-Entwicklung: Die "Productivity programmers" machen ca. 90% des Entwicklungsteams aus und entwickeln die Softwarelogik auf einer höheren Ebene, während "Efficiency programmers" auf der Ebene darunter die Möglichkeiten der parallelen Hardware je nach Plattform in Performance umwandeln. Ein wichtiger Schlüssel zur Entwicklung paralleler Programme ist das Erkennen und Nutzen von parallelen Entwurfsmustern sowie die Möglichkeit, diese Muster in Frameworks zu nutzen.

Fazit: eine Veranstaltung, deren Besuch sich gelohnt hat. Im Alltag begegnet man diesen Themen noch nicht ständig, aber die weitere Entwicklung der (parallelen) Hardware wird diese Inhalte bereits in naher Zukunft zum notwendigen Grundwissen vieler Softwareentwickler machen.