Para//el 2012 - Tag 2

pumuckl

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 das 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äter: 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 zu fragen, 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.