12 Thesen und Antithesen zur Multicore-Programmierung

Gestern auf der OOP 2009 hielt Professor Walter F. Tichy von der Uni Karlsruhe einen Vortrag mit dem Titel “Herausforderung Mehrkernsysteme”. Darin beschäftigte er sich mit diversen Aspekten der Parallelprogrammierung. Und das zu Recht, denn das Thema scheint ein echter Renner zu sein; der Raum war auf jeden Fall gut gefüllt.

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.

Keine ähnlichen Artikel.