dotnet Cologne 2010, ein voller Erfolg – Teil 2

Wie ich bereits berichtete, habe ich mich letzte Woche auf der dotnet Cologne 2010 herumgetrieben und mir dabei die Sessions von Rami Radi, Mario Deilmann, Oliver Sturm und Bernd Marquardt zu Gemüte geführt. Auf die Session von Rami bin ich ja bereits ausführlich eingegangen, und jetzt folgen noch die von Mario, Oliver und Bernd.

Dr. Mario Deilmann (so sein vollständiger Name) ist bei Intel für Compiler und ähnlich geartete Software-Tools zuständig. Mit seiner Lunch-Session ging er der Frage nach, welches Programmier- bzw. Thread-Modell für skalierende Anwendungen das beste sei. Skalierend bedeutet in diesem Zusammenhang, dass parallelisierter Quellcode nicht nur optimal auf zwei Prozessorkerne verteilt wird, sondern auch auf vier, sechs, acht oder 256 Kernen läuft – und zwar ohne Leistungseinbußen.

Hierfür ist laut Mario zunächst einmal ein passendes Profiling-Tool wie der Intel VTune Performance Analyzer erforderlich, mit dem man diejenigen Funktionen, Module und andere Stellen des Quellcodes aufspürt, die für die meiste Rechenleistung und -zeit verantwortlich sind. Denn das sind oft die Stellen, an denen man als Software-Entwickler ansetzen sollte. In vielen Fällen sind das zum Beispiel Schleifenkonstrukte, die sich bestens zum Parallelisieren eignen.

Eine der passenden Programmiermodelle wusste Mario natürlich gleich darzustellen: OpenMP. Allerdings weist diese pragma-basierte Parallelisierung von seriellen Anwendungen auch diverse Nachteile auf: Man denkt als Programmierer in Threads anstatt in Tasks (was laut Mario eigentlich ein absolutes No-Go sein sollte), es lassen sich keine eingebetteten Parallelkonstrukte realisieren und mit lokalen Daten geht OpenMP ebenfalls nur suboptimal um. Aber für die schnellen ersten Ergebnisse für parallel ausführbare Programme ist OpenMP laut Mario eine gute Wahl.

Außerdem unterstützt OpenMP keine objektorientierten Programmiersprachen wie C++, was natürlich in vielen Fällen ein klares KO-Kriterium ist. Aber wozu gibt es beispielsweise die Intel Threading Building Blocks. Mit dieser Thread-sicheren, hochoptimierten Sammlung von fertigen C++-Konstrukten lassen sich sequentiell programmierte Anwendungen recht schnell und ohne größere Kenntnisse der Parallelprogrammierung in parallel ablaufende Programme umwandeln. Praktisch an Intel TBB ist deren Vielseitigkeit: OS-seitig werden Linux, Mac OS und Windows unterstützt, und es gibt sogar eine nicht-kommerzielle Variante, die den LGPL-Lizenzrichtlinien unterliegt.

Neben OpenMP und Intel TBB existieren noch weitere Ansätze, wie sich Software parallelisieren lässt. Dazu gehört das noch recht junge Projekt Cilk++ von Intel, das einen ähnlichen Weg einschlägt wie Intel TBB, allerdings einen Parallel Debugger sein Eigen nennt, ein SDK bietet und auf hunderten von Prozessorkernen skalieren soll. Und vergessen sollte man natürlich auch nicht Parallel Studio, das unter anderem die Tools Parallel Inspector und Parallel Amplifier aufweist, mit deren Hilfe man Fehler im Quellcode aufspüren kann (Inspector) und sich die Anwendung weiter optimieren lässt (Amplifier). Das geht sogar so weit, dass Laufzeitfehler wie Race Conditions und Dead Locks aufgespürt werden können – bevor dies der Anwender später tut.

So, und die Sessions von Oliver Sturm und Bernd Marquardt sind dann morgen dran. Versprochen!