Was war deine größte Herausforderung beim Umstieg auf die Parallelprogrammierung?

Was ist ein guter Tipp für angehende Parallelprogrammierer?

Was bringen Sandy Bridge und AVX für parallel ablaufende Anwendungen?

Der zweite Teil hingegen befasst sich mit Fragen wie:

Welche Programmiermodelle werden sich durchsetzen?

Laut Asafs Aussage werden objektorientierte Programmiermodelle wie C++ zwar weiterhin bestehen, allerdings stoßen sie beim Parallelprogrammieren immer wieder an ihre Grenzen, da es sehr schwer ist, Tasks zu kontrollieren. Asaf glaubt, dass man in Zukunft auf der obersten Abstraktionsebene viel stärker in Tasks denken muss, um dann im weiteren Verlauf mit Objekten arbeiten zu können. Allerdings behebt auch diese Heransgehensweise nicht das Problem immer wieder auftretender Zufallsabstürze, wie man sie beispielsweise bei Borland C++ 5.0 beobachten kann. Fazit: neue Programmiermodelle müssen her! Und Tools wie der VTune Amplifier XE für das Aufspüren potenzieller Abstürze von parallel programmierten Anwendungen.

Welche Programmiersprachen bevorzugst du?

Asaf setzt für seine Programme – der ersten Frage zum Trotz – am liebsten noch auf C und C++ (für den Programmcode) und auf C# (für das Programmieren für Bedieneroberflächen). Zudem lassen sich beide Sprachen mithilfe von .NET-Wrappern prima innerhalb derselben Entwicklungsumgebung wie Visual Studio verwenden.

Was sollte man Studenten empfehlen, die sich mit dem Thema Parallelprogrammierung beschäftigen wollen?

Guter parallel programmierter Code beginnt bereits mit dem Design. Denkt also nicht seriell, sondern parallel! Gute Anwendungen müssen sogar parallel programmiert sein, da der Computer von Haus parallel arbeitet, da er ja auf mehrere Ereignisse aus unterschiedlichen Richtungen gleichzeitig reagieren muss. Um den seriellen Eingabestrang, dem wir immer noch unterworfen sind, aufzubrechen, sollte man laut Asaf mit Threads oder Thread-Pools arbeiten. Parallelprogrammierung beginnt also in den Köpfen und erfordert sehr viel Arbeit und Umdenken beim Einsatz bekannter Modelle.

Das vollständige Interview können Sie auf dem SoftTalk-Blog nachlesen (Teil 1 und Teil 2).

Zudem möchten wir Sie an dieser Stelle noch einmal herzlich zu der exklusiven und kostenlosen Entwickler-Veransaltung einladen! Es sind nur noch wenige Plätze frei. Melden Sie sich am besten noch heute an!

Nun aber zu dem Interview: Eine wichtige Frage handelt von den Herausforderungen, mit denen Asaf in Sachen Parallelprogrammierung konfrontiert wurde. Dazu hat er eine ganz einfache Antwort parat: Der Umstieg war die größte Hürde, da es gar nicht so einfach war, parallel und nicht mehr seriell zu denken. So hatte er echte Schwierigkeiten, für kritische Code-Abschnitte einen Mutex anstatt eines Locks zu verwenden. Außerdem musste er beispielsweise erst mal lernen, dass ein Mutex nicht die kritische Sektion, sondern die betreffende Ressource, also die involvierten Speicherbereiche schützt.

Ein sehr schönes Bild hält Asaf auf die Frage bereit, was denn der beste Tipp in Sachen Parallelprogrammierung sei. Sein Antwort: Man muss wie Menschen und nicht wie Maschinen denken. Als konkreten Fall nennt er einen Schnellimbiss, bei dem mehrere Leute an mehreren Verkaufstheken gleichzeitig bestellen, und diese Bestellungen anschließend von verschiedenen Mitarbeitern des Restaurants bearbeitet und an die Kunden ausgegeben werden. Genau so verhält es sich nämlich mit asynchroner Datenverarbeitung mithilfe von Task-Queues, Worker-Threads und vielem mehr.

Interessant sind auch Asafs Antworten auf die Fragen, was Sandy Bridge und AVX für Entwickler tun können. So sieht er in der neuen Core-Architektur eine erhebliche Verbesserung für parallel programmierte Anwendungen, da aufgrund des Core-to-Core-Designs Daten schneller zwischen den einzelnen Prozessorkernen hin- und herfließen können, was die Zahl an Bottlenecks erheblich reduziert.

Als Beispiel führt er die Berechnung einer Aufgabe an, die ohne AVX vier Prozessorkerne mitsamt aller Sycnhronisationsalgorithmen erfordert. Mithilfe von AVX geschieht dies wegen der breiteren Register auf einem einzigen Prozessorkern, was natürlich viel zu besser handhabbar ist. AVX kann laut Asaf in bestimmten Fällen bis zu 16 Prozessorkerne eliminieren.

Die Fortsetzung des interssanten Interviews können Sie am Freitag hier lesen.

Foto: Simon Muhm - www.simon-muhm.de

Es soll ja Leute geben, die mit ihrem Wochenende etwas anzufangen wissen: Entweder gehen sie in die Berge zum Wandern oder besuchen Tante Ilse aufm Land oder machen sonst was. Und was mache ich?

Ich treibe mich lieber an zwei Tagen auf dem GameCamp Munich 2009 herum, das vorigen Samstag und Sonntag bei Microsoft in Unterschleißheim stattgefunden hat.

Jetzt mag sich manch einer fragen: GameCamp, was’n das?! Hierzu habe ich erst kürzlich etwas verfasst, was bei der Beantwortung dieser Frage weiterhelfen könnte. Insgesamt war das GCMUC09 eine gut gelungene Veranstaltung, die gemeinsam von Microsoft und Flobbymedia initiiert und organisiert wurde. Den Machern des Barcamps ging es vor allem darum

die interdisziplinäre Vernetzung der Branche, die Entwicklung neuer Thesen und Ideen sowie die Förderung der Videospielkultur

voranzutreiben. Ob ihnen das gelungen ist, kann ich nicht sagen. Aber am Ende waren wohl alle (sehr) zufrieden. Behandelt wurden unter anderem folgende Themen:

• Vermarktung von Spieletiteln

• Pressearbeit ohne Presseabteilung

• Was macht eigentlich die Gema?

• Interaktives Storytelling

• Was ist vom Killerspieleverbot zu halten?

• Programmieren lernen mit Serious Games anhand von AntMe

• In-Game Advertising

• Multicore-Programmierung für 3D-Spiele

Darüber hinaus waren mit einem eigenen Stand vertreten:

• Intel mit zwei coolen 3D-Demos, die ziemlich eindrucksvoll gezeigt haben, wie ein komplexes 3D-Spiel zum Leben erwacht, wenn es nicht nur auf einem, sondern auf acht Prozessorkernen gleichzeitig läuft.

• Qantm, die unter anderem angehenden Spieleprogrammierern und -designern dabei helfen, ihren Job in Zukunft richtig gut zu machen.

• Die Jungs von Game-TV, die mit Kamera und Mikro bewaffnet (sic!) den ein oder anderen Anwesenden interviewt haben.

Und sonst? Es gibt eine Menge Bilder vom GameCamp zu begutachten und wer wissen will, was an den zwei Tagen alles passiert ist, sollte sich mal den Twitter-Stream geben. Na dann, bis zum GameCamp Munich 20X!

Um am Intel SPP teilnehmen zu können, muss man sich natürlich erst mal registrieren. Logisch. Um dies ein wenig schmackhafter zu machen, verschenkt Intel derzeit 50 Exemplare des Buchs Multi-Core Programming, das ich übrigens auf meinem Schreibtisch liegen habe. Dabei handelt es um einen wirklich gelungenen Einstieg in das Thema und eine nützliche Wissensdatenbank für alle Entwickler. Also, ran an den Speck!

Apropos Speck: Software-Entwicklung für den relativ neuen Intel-Prozessor Core i7 ist noch kein echtes Mainstream-Thema. Zwar gibt es schon eine ganze Weile ein eigenes SDK, aber Experten auf diesem Terrain sind noch eher rar. Um diesen Umstand zu verbessern, bietet Intel am nächsten Dienstag (10. Februar, 17 Uhr MEZ) ein 60-minütiges Webinar genau zu diesem Thema an. Der Titel:

Create Applications with Superior Performance and Energy-Efficiency: An Introduction to the Software Development Kit for the new Intel Core i7 Platform

Das ist doch genau das Richtige für angehende Multicore-Entwickler, oder?! Und wie gesagt: Davon gibt es nicht so wahsinnig viele. Ach ja: Um an diesem internetbasierten Training teilnehmen zu können, muss man sich für das Intel Black Belt-Programm anmelden. Das ist allerdings ein Klacks – verglichen mit Multithreading für Multicore-Prozessoren.

Im Laufe seines Referats stellte Professor Tichy mehrere Thesen in Sachen Parallelprogrammierung auf, die ich hier ein wenig aufdröseln will.

These #1: Die Informatik erlebt gerade eine Evolution: Weg von der sequenziellen Programmierung hin zur parallelen Entwicklung. Parallelität gab es bis dato nur in Nischenbereichen wie Numerisches Rechnen, Betriebssystemen und Datenbanken und Parallelität auf Instruktionsebene. Meine Antithese dazu: Stimmt!

These #2: Es gab immer wieder spezielle Parallelrechner wie den Atanasoff-Berry-Rechner von 1942, der ausschließlich lineare Gleichungen mit 30 Koeffizienten lösen konnte. Dazu gehörte aber auch der Illiac-IV, ein SIMD-Rechner mit verteiltem Speicher und 64 Prozessoren. Dieser Großrechner wurde 1976 gebaut und war bis 1981 der schnellster Rechner der Welt. Natürlich erwähnte Tichy auch den Cray-1 Vektorrechner, der ebenfalls aus dem Jahr 1976 stammt und wohl den bekanntesten Vertreter der prähistorischen Parallelrechner darstellt. Das Alles (und viel mehr) mündete schließlich in riesigen Clustersystemen der Gegenwart, die allesamt auf der Webseite Top500.org zu bestaunen sind. Meine Antithese dazu: Eine schöne Liste!

These #3: Es gibt neben Intel-CPUs wie Core 2 Quad oder Core i7 weitere Parallelprozessoren, die allerdings (beispielsweise die Grafik-CPU Geforce 8 von Nvidia) hauptsächlich für Spezialbereiche konzipiert sind. Meine Antithese dazu: Wie sagte erst kürzlich ein bekannter Chefentwickler zu mir: “CUDA und die angeblich enorme Rechenleistung der Geforce-GPUs ist vor allem eins: Marketing!”

These #4: Die Moore’sche Regel hat eine Variation erfahren, die wir an der Uni Karlsruhe sogar ein wenig verfeinern wurde: “Die der Anzahl Prozessoren pro Chip wird sich mit jeder Chip-Generation bei etwa gleicher Taktfrequenz verdoppeln”. Meine Antithese dazu: Ja, das sagt Intel auch. Dann wird es wohl stimmen …

These #5: Was sollen wir mit all den Kernen nur anfangen, die uns in Zukunft zur Verfügung stehen? Die Antworten lieferte Professor Tichy postwendend selbst: automatische Protokollführer; inhaltsbasierte Bildersuche mithilfe einer Datenbank; intuitive Schnittstellen mit Bild- und Sprachverarbeitung; vorausschauende Anwendungen, die “ahnen”, was der Benutzer will; Modellierung des Benutzers und der Umgebung; Erhöhung der Zuverlässigkeit (Redundanzen). Meine Antithese dazu: Wie wäre es mit weiteren Beispielen: Videoschnitt, Bildbearbeitung, 3D-Spiele, skalierende Betriebssysteme und Videoencoding, um nur einige zu nennen.

These #6: Es gibt natürlich Probleme bei der parallelen Programmierung, die aber nicht dazu führen dürfen, dass darunter die Qualität leidet. Meine Antithese dazu: In der Tat, dass würden wohl die Kunden und Endanwender nicht tolerieren!

These #7: Paralleltools sind immer noch unzureichend vorhanden. Meine Antithese dazu: Ach, und was ist mit folgenden Werkzeugen: Parallel Composer, Thread Checker, Threading Building Blocks, VTune Performance Analyzer und andere mehr?

These #8: Software-Entwickler sind oder werden nicht gut genug ausgebildet. Meine Antithese dazu: Ja, das sagen andere auch. Wie gut, dass es zum Beheben dieses Dilemmas die passenden Programme gibt.

These #9: Der Weg zum fehlerfrei programmierten Parallelcode ist lang und steinig. Dabei sind vor allem massive Umstrukturierungen des Quellcodes notwendig. Und potenzielle Abhängigkeiten sowie mögliche Seiteneffekte müssen unbedingt beachtet werden. Meine Antithese dazu: Ja, dazu habe ich mir auch schon so meine Gedanken gemacht. Resultat: beliebte Fehler bei der Parallelprogrammierung, fünf Multicore-Programmierregeln und die passenden Multithreading-Konzepte.

These #10: Es gibt immer noch bestimmte Dinge in der Parallelprogrammierung, die kaum oder gar nicht funktionieren. Dazu gehört die oft ausgesprochene Empfehlung, Parallelkonstrukte nach und nach hinzuzufügen. Selbst vor allem laufzeitkritische Pfade zu parallelisieren bringt meist nichts. Darüber hinaus hat die feingranulare Parallelisierung innerer Schleifen nach Tichy keinen wesentlichen Effekt. Meine Antithese dazu: Es ist sicherlich kein einfaches Unterfangen, sequenziellem Quellcode paralleles Leben einzuhauchen, aber es gibt die passenden Methoden und Tools (siehe Antithese #7). Darüber hinaus lassen sich vor allem nummerische Probleme sehr gut mithilfe von parallelen Konstrukten lösen (auch im Nachhinein).

These #11: Parallelisierung darf nicht per Trial-and-Error erfolgen. Und man muss gut abschätzen, wo die Parallelisierung am meisten bringt – und wo nicht! Meine Antithese dazu: Gut gebrüllt, Löwe! Denn nur ein guter Parallelquellcode produziert keine ungewollten oder unvorhersehbaren Laufzeitfehler. Mit Tools wie dem Thread Checker lässt sich das übrigens überprüfen.

These #12: Es sind bessere Programmiersprachen zum Ausdruck paralleler Abläufe notwendig, aber auch parallele Algorithmen und Bibliotheken. Und Tools für das Debuggen von Parallelisierungsfehlern sowie Tools für parallele Programmierung. Meine Antithese dazu: Wie gut, dass es hierfür schon das ein oder andere gibt.

Wichtig erscheint mir auf jeden Fall die Feststellung, dass “in Zukunft [...] Parallelrechner ungefragt und flächendeckend zur Verfügung stehen” werden. Ganz klar, das ist der Trend, und wenn man sich die Roadmap von Intel ansieht, wird schnell klar, dass der Core i7 nur der Anfang der Multicore-Ära ist.

Ebenso wichtig sind die potenziellen Multicore-Anwendungen, die Professor Tichy aufzählt: Dazu gehören natürlich Medienprogramme wie DivX und 3D-Spiele wie Crysis oder Sacred 2 (und Bildbearbeitungstools wie Silver Efex Pro von Nik Software). Aber auch weniger spektakuläre Anwendungen wie Logistikplaner, Tabellenkalkulation, Suchalgorithmen und Sicherheitsüberprüfungen profitieren vom Multithread-Code. Zusammengefasst könnte man mit Tichys Worten sagen:

Diejenigen Firmen, die jetzt die richtigen Anwendungen identifizieren und parallelisieren, werden in Zukunft zu den Gewinnern gehören, zumal Beschleunigung durch Abwarten – das heißt: das Setzen auf weiter steigende Taktfrequenzen – nicht mehr funktioniert.

Aber Professor Tichy weist zu Recht auch darauf hin, dass es große Hemmschwellen seitens der Software-Entwickler gibt, da sie sich durchaus dessen bewusst sind, dass es beim Parallelisieren von Anwendungen so hässliche Dinge wie Race Conditions, Dead Locks, Reihenfolgeprobleme und andere Synchronisationstücken gibt. Außerdem lassen sich bestimmte Fehler einfach nicht reproduzieren, da sie oft erst zur Laufzeit auftreten.

An dieser Stelle gibt es übrigens ein erstes “Hm?!”. Denn Testtools wie der Thread Checker sind durchaus in der Lage, potenzielle Fehler aufzuspüren, bevor ein einziger Betatester oder Endanwender die Software in den Händen hält. Dies ist naturgemäß nicht trivial, aber es sind entsprechende Tools vorhanden.

Ein weiterer wichtiger Punkt in seinem Vortrag hat mit den sequenziellen Algorithmen zu tun, die immer noch zu einem Großteil in existierenden Anwendungen implementiert sind. Die große Herausforderung hierbei ist natürlich das Aufspüren des Parallelisierungspotenzials. Dies lässt sich zum einen mit Tools wie VTune Performance Analyzer oder Thread Profiler erledigen. Zum anderen muss man als Entwickler noch einen wichtigen Schritt weiter gehen: Wie mache ich aus einem sequenziellen ein paralleles Software-Konzept? Und genau an diesem Punkt scheitern immer noch ganz viele.

Jetzt ist übrigens die Gelegenheit gekommen für ein zweites “Hm?!”. Und zwar bezüglich Professor Tichys Aussage, dass es derzeit keine vernünftigen Compiler und Bibliotheken gibt, die ein gewisses Maß an Parallelimus in sich bergen. So stecken beispielsweise im Intel C++-Compiler eine ganze Menge an parallelen Konstrukten und Bibliotheken, die mit wenigen Hangriffen in den Quellcode übernommen werden können. Und Programmiermethoden wie OpenMP erledigen dies sogar automatisch – von den Threading Building Blocks und den multicore-optimierten Bibliotheken ganz zu schweigen.

Aber für Professor Tichy steht außer Frage, dass es hierzulande kluge Köpfe gibt, die durchaus in der Lage sind, mit den richtigen Tools und den richtigen Konzepten die Multicore-Programmierung voranzutreiben und für Anwendungen zu sorgen, die auf 4, 8, 16 oder gar 256 Prozessorkernen skalieren. Und dann wird es auch so kommen, wie Professor Tichy abschließend scheibt:

Bessere Produkte mit intuitiveren Schnittstellen, Sprach- und Videoverarbeitung, mehr Intelligenz und eingehender Modellierung des Nutzers und der Umgebung werden entstehen.

Ach ja: Ich werde mir nächste Woche auf der OOP 2009 den Vortrag von Professor Tichy zum Thema “Herausforderung Mehrkernsysteme” anhören – und dazu mit ihm ein Interview führen. Darauf bin ich schon sehr gespannt!

• Java – Quo Vadis?

• Entwurf von mobilen iPhone-Anwendungen für Firmen

• Was ein Software-Architekt wissen sollte

• Herausforderung Mehrkern-Systeme

• How to be an IT Superhero – The Future of Application Development

• Warum Anwendungen nicht skalieren – Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert

• Programmierung für Multicore CPUs

• 10 Jahre Model-Driven Software Development

• Ursprung des Computers (Horst Zuse!)

Daneben gibt es interessante Ganztagskurse, die am Montag und am Freitag stattfinden. Und wer es besonders lange mag, dem seien die “Night School Sessions” empfohlen.

Übrigens: Falls Sie nicht wissen sollten, warum es keinen triftigen Grund gibt, von der OOP 2009 fernzubleiben, sollten Sie sich mal die zehn Gründe dafür zu Rate ziehen. Und fünf Argumentationshilfen für den Chef gibt’s auch gleich dazu.

Neben den zahlreichen Vorträgen und Workshops wird auch eine Ausstellung geboten, auf der zahlreiche Unternehmen wie Borland, Oracle und andere ihre Lösungen zeigen. Und der Bitkom ist ebenfalls anwesend.

Ich habe mich übrigens gerade akkreditiert und werde vor Ort sein, um mit einigen Leuten über das Thema Multicore-Programmierung zu sprechen. So wie mit Professor Walter F. Tichy von der Uni Karlsruhe, der zu dem Thema Multicore-Plattformen eigene Vorlesungen anbietet. Darauf bin ich schon sehr gespannt.

Das Problem ist eher, dass es zu wenige Leute gibt, die die Kenntnisse haben, um diese Compiler effektiv anzuwenden und die Hardware optimal ausnutzen können.

Mit „diese Compiler“ meint er unter anderem Intel-Compiler, die ständig weiterentwickelt werden. Aber auch den Einsatz von OpenMP in Verbindung mit Standard-Compilern sieht er in diesem Kontext als großen Vorteil.

Das bedeutet also, dass es vor allem bei der Ausbildung hakt, da es die jeweiligen Einrichtungen bis dato offensichtlich noch nicht geschafft haben, neue Techniken wie Multicore-Systeme in den Vorlesungsplan zu integrieren.

Eine kurze Stichprobe via Google mit dem Suchbegriff „Vorlesung Multicore“ fördert es dann tatsächlich zu Tage: Parallele Programmierung steht bei den allermeisten Unis und FHs noch nicht auf der Tagesordnung. Als lobenswerte Ausnahmen sind hier die FH Kiel zu nennen (sic!), die Uni Augsburg, die TU Chemnitz, die TU Dortmund, die Uni Karlsruhe, die Uni München, die Uni Potsdam und die Uni Stuttgart.

Dass sich noch nicht mehr Unis und FHs mit dem Thema Multicore-Programmierung befassen, ist doch ein wenig überraschend, da sich Intel seit über zwei Jahren mit einem groß angelegten Ausbildungsprogramm an Universitäten und Fachhochschulen wendet, um diesen das Thema paralleles Programmieren schmackhaft zu machen.

Das beginnt mit einer finanziellen Unterstützung, geht weiter über das Bereitstellen von Entwicklertools und endet bei Experten der Intel Software College Group, die an Unis und FHs Kurse zum Thema Multicore-Programmierung geben. Fragt sich nur, warum nicht mehr Einrichtungen auf diesen Zug aufspringen?