Keine Stagnation bei der parallel 2016

Nach vier Jahren in Karlsruhe musste die Konferenz bei ihrer fünften Auflage aus organisatorischen Gründen nach Heidelberg ausweichen. Auch wenn sich hier nicht mehr traditionell Flammkuchen in parallel betriebenen Öfen fertigen ließ, haben sich die Räumlichkeiten als so gut herausgestellt, dass die Konferenz aller Wahrscheinlichkeit nach nicht mehr an den alten Ort zurückkehrt.

Doch nicht nur die Räumlichkeiten haben sich verändert, auch inhaltlich hat sich einiges getan. Während im letzten Jahr versuchsweise ein spezieller Fortran-Track angeboten wurde, gab es diesmal lediglich zwei Vorträge, die Beispiele in dieser Programmiersprache zeigten. In einem der beiden ging es um allgemeine Kenntnisse, die sich auch in jeder anderen Sprache hätten zeigen lassen. Was die Sprachen angeht, hat wieder C/C++ dominiert, jedoch dicht gefolgt von Java sowie anderen Sprachen auf der JVM. .NET war mit C# wieder vertreten, und auch Betrachtungen zur parallelen Programmierung mit JavaScript durften nicht fehlen.

Das zeigt, dass die parallele Programmierung nicht mehr nur im akademischen Bereich, bei der Bildverarbeitung und nun selbst in Embedded-Systemen zu Hause ist, sondern langsam auch im Bereich der Business-Anwendungen ankommt. Das scheint jetzt erst Fahrt aufzunehmen, was daran zu erkennen ist, dass die Java-Vorträge nicht nur gut besucht waren, sondern die Teilnehmer häufig Interesse an den Grundlagen betonten. Bei C/C++ oder hardwarenäheren Vorträgen ging es hingegen teilweise stärker um spezialisierte Optimierungen – hier handelte es sich neben Embedded-Systemen vornehmlich um die GPU-Programmierung. So ist es den Veranstaltern gelungen, sowohl Parallelisierungsprofis als auch Einsteiger in diese Materie anzusprechen. Mit Hinblick auf das Interesse bei den "Business-Sprachen" sowie den Grundlagen könnte es sinnvoll sein, diesen Bereich in der kommenden Auflage weiter zu stärken.

Parallelisierung – gewusst wo und wie?

Die Konferenz startete mit einer Keynote von Ulrich Drepper. Der einstige Chefentwickler und Verwalter des "GNU C standard library"-Projekts zeigte diverse hardwarenahe Probleme auf, die bei der parallelen Programmierung eine Rolle spielen, insbesondere wenn es um die Synchronisierung von Algorithmen geht, die eine CPU oder gar einen Rechner überschreiten. Hier können die Latenzen, die bei der Kommunikation entstehen, bereits massive Auswirkungen zeigen. Solche Latenzen steigen bei mehrschichtigen Applikationen – und zusätzliche Schichten entstehen zwangsläufig bei der Virtualisierung. Moderne Hardware trägt dem ansatzweise Rechnung, indem sich beispielsweise eine physische Netzwerkkarte logisch wie mehrere verhält und so einzelne Applikationen direkt darauf zugreifen können, ohne dass dazwischenliegende Schichten die gemeinsame Nutzung gewährleisten müssen.

Auch Latenzen im Speicherzugriff, gemeinsames IO und einiges andere mehr stellen besondere Herausforderungen an die parallele Programmierung und führen oft zu einem geringeren als dem erwarteten (bzw. erhofften) Durchsatz. Die entsprechenden Kenntnisse, anders zu programmieren, schaffen hier Vorteile, selbst schon bei Programmen, die gar nicht parallel arbeiten, wie Bernd Marquardt eindrucksvoll in einem Vortrag demonstrierte. Und so lautete die Botschaft diverser Sessions: Kenne die Eigenarten moderner Hardware, wenn Performanz benötigt wird. Andernfalls kann die Performanz durch Parallelisierung gar leiden. Das zeigte unter anderem Detlev Vollmann, dessen einfache Zähler im Durchsatz einbrachen, als er sie parallelisierte. Erst mit richtig eingesetzter Parallelität konnte er den Durchsatz steigern. Wichtiges Grundlagenwissen für Entwickler, die schon eine Weile "multithreaded" programmieren.

Eine weitere Botschaft aus der Keynote sei hier noch erwähnt: Oft werden große Datenmengen zur weiteren Verarbeitung von einem Knoten zu einem anderen verschoben. Schneller sei es meist, stattdessen die Daten auf einem Knoten zu belassen und die (relativ kleinen) Programme zu verschieben – oder gleich alle vorzuhalten.

In der zweiten Keynote wollte Philipp Haller vornehmlich über reaktive Programmierung in Scala sprechen. Das tat er auch, jedoch verkürzt, da er sich nach kurzer Rückfrage bei den Teilnehmern stark auf die Grundlagen konzentrierte. Einen interessanten Ansatz verfolgte Luc Bläser. Er nutzte den bekannten Begriff der Code Smells, um ihn auf gern gemachte Fehler im Bereich der nebenläufigen Entwicklung anzuwenden. So zeigte er eine subjektive Sammlung schlechter Programmierung und bot auch Abhilfe dazu an. Es entstand die Idee, solche "Parallel Code Smells" in größerem Stil zu sammeln und auszuwerten – ein Vorhaben, das zahlreiche Teilnehmer begrüßten.

Ausbaufähig oder nicht – das ist die Frage

Der Umgang mit speziellen Problemen, die Nutzung der meist vorhandenen GPU, Erfahrungen aus dem Bereich Embedded inklusive Automotive, dies gehörte zu Themen, die verstärkt Teilnehmer ansprachen, die sich länger damit auseinandersetzen. Auch hier wurde teilweise im Vergleich zum Vorjahr umgeschichtet und ausgebaut. Fast schon stellt sich die Frage, ob hier drei parallele Sessions reichen oder künftig mehr anzubieten ist. Sicherlich eine Frage der Teilnehmerzahl.

Mit rund 150 Teilnehmern entsprach sie etwa dem Vorjahresniveau. Sollte die Konferenz in Heidelberg verbleiben, besteht jedoch noch Luft nach oben: In diesen Räumlichkeiten sollte es möglich sein, auch 200 Teilnehmern ein interessantes Programm bieten zu können. So bleibt es spannend, wie sich die Konferenz weiterentwickeln wird. Ihren Nutzen für den Projektalltag hat die Konferenz zumindest bewiesen.

Michael Müller
ist als Bereichsleiter Softwareentwicklung der InEK GmbH verantwortlich für Projekte im Web-, Java- und .NET-Umfeld. Daneben betätigt er sich als freier Autor und verfasst Fachartikel zu diversen Entwicklungsthemen sowie Buchrezensionen. (ane)