Im Übrigen hatte ich auch die Gelegenheit, nach der Session mit Stephen persönlich zu sprechen und ein kurzes Video-Interview zu führen. Das werde ich selbstverständlich auch in Kürze auf dieser Seite veröffentlichen.

Fallstricke

Zurück aber zu den Vorteilen und Fallstricken der Parallel-Programmierung. Stephen konnte anhand früherer Projekte sehr eindrucksvoll demonstrieren, dass der erste Schritt der Parallelisierung immer darin besteht, den vorhandenen Code zu verstehen und zu analysieren. Klingt banal, in der Praxis aber passieren genau hier die meisten Fehler. So verfallen auch erfahrene Programmierer der Verlockung, vorschnell neuen Code zu implementieren, anstatt frühere Schwachstellen zu korrigieren. Der Effekt: Trotz erfolgreicher Ausrichtung auf mehrere Prozessorkerne zeigen die Anwendungen keinen nennenswerten Geschwindigkeitsgewinn.

4-Stufen-Methode

Dann ist die Ursachenforschung kompliziert und sehr aufwändig. Stephen erklärte, dass mitunter sogar ein aktiver Virenscanner als Bremsklotz einer Parallel-Anwendung fungieren kann. Diese Dinge sollte man demnach schon beim Check des seriellen Codes im Auge behalten. Daraus ergibt sich für Programmierer eine 4-Stufen-Methode bei der Parallelisierung, die grundsätzlich eingehalten werden sollte:

1. Analyse des seriellen Codes hinsichtlich möglicher “Hotspots”
2. Implementierung von Parallelkonstrukten auf Basis passender Programmiermodelle
3. Fehlersuche mithilfe geeigneter Tools
4. Optimierung des neuen, parallelisierten Codes

Die für die Implementierung gewählten Programmiermodelle (Sprache, Bibliotheken, Methoden) sind dabei sowohl vom ursprünglichen Code als auch von der Zielsetzung des Projektes abhängig. Stephen konnte hier in unterschiedlichen Szenarien beispielsweise die Vorteile von Cilk und OpenMP erläutern und verdeutlichten, dass sowohl der Compiler als auch die Hardware eines Systems über die Performance der Anwendung entscheiden.

Am Ende des Vortrags ging Stephen auf ein Thema ein, das bei aller Begeisterung für Multicore gerne übersehen wird: Auch Parallel-Programmierung ist nicht immer der Weisheit letzter Schluss. In einigen Fällen reicht es aus, den seriellen Code zu optimieren. Aber diese Frage sollte eigentlich schon während der Analyse beantwortet werden.

In wenigen Tagen wird Intel während der CES in Las Vegas die neue Prozessorgeneration Sandy Bridge offiziell vorstellen. Vor Ort werden dann auch gleich ein paar Hardware-Hersteller erste Notebooks mit den neuen Recheneinheiten zeigen.

Die Prozessor-Architektur von Sandy Bridge wird vor allem in puncto Multimedia-Performance alle Vorgänger der Nehalem-Bauweise in den Schatten stellen. Sandy Bridge integriert den Grafikkern (GPU) in die CPU bei einer Strukturbreite von 32 Nanometern. Dank der integrierten Encoding-Einheit lassen sich Videos wesentlich schneller konvertieren als beispielsweise mit bekannten Core-i5-Prozessoren.

Die technologischen Neuerungen von Sandy Bridge und die daraus resultierenden, erweiterten Möglichkeiten für Parallel-Computing sind Anlass genug, dieses Blog wiederzubeleben. Ich werde Sie ab sofort regelmäßig mit News, technischem Background und Veranstaltungshinweisen versorgen, die Ihnen den Programmieralltag etwa erleichtern.

Zunächst aber darf ich Ihnen zwei neue, sehr nützlich Tools empfehlen, die Intel im Rahmen der Partnerprogramme veröffentlich hat und vor allem Entwickler von Media- und Videoanwendungen adressieren.

Das Intel Media Software Development Kit in der Version 1.5 ist ein plattformübergreifendes SDK, das Ihnen hilft, auf einfache Weise leistungsstarke und schnelle Videoanwendungen zu entwickeln.  Das Tool-Paket bietet Ihnen drei Highlights:

• Codecs für Hardwarebeschleunigung: Sie greifen auf Video-Codecs zu, die für Intel Multicore-Prozessoren und Intel HD Graphics optimiert wurden und bestmögliche Performance bieten
• Einheitliches API für unterschiedliche Plattformen: Weniger Code und weniger Komplexität durch ein universelles API, das viele PC-Plattformen unterstützt, darunter selbstverständlich auch die zukunftsträchtigen Intel Graphics- und Multicore-Architekturen.
• Support und Add-Ons: Schneller optimale Ergebnisse erzielen dank nützlicher Features wie Video-Pre-Processing, Decodieren und Encodieren

Sie können das Media Software Development Kit kostenlos laden und installieren. Sinnvoll ergänzt wird das SDK durch das Intel Media Checker Software Assessment Tool. Zugegeben, eine grauenhafte Bezeichnung, aber das Tool ist überaus nützlich. Denn damit stellen Sie beispielsweise sicher, dass Sie das SDK korrekt in die Anwendungen einbinden. Zudem fungiert es als Tutorial, indem es die Funktionen und Technologien des SDK erläutert. Also für die ersten Schritte mit dem SDK sicherlich genau richtig. Und kostenlos ist es natürlich auch. Viel Erfolg damit!

Nun ist es aber leider so, dass kaum ein Spiel den Zugriff auf diese Dienste implementiert hat, was jedoch mit ein paar Codezeilen an der richtigen Stelle im Quellcode des Spiels problemlos zu machen ist. Sagt zumindest Mitchell Lum von Intel, der in seinem Blogpost anhand eines C#-Beispiels zeigt, wie man aus dem laufenden Spiel heraus twittern kann. Das ist übrigens nicht nur für Multiplayer ein echter Mehrwert, sondern auch für Spieleentwickler, die auf diesem Weg den Bekanntheitsgrad ihrer Titel mithilfe von Twitter erhöhen können.

Dann schaut euch den Blogbeitrag samt Codebeispiel einfach mal in Ruhe an.

Nur so viel: Ct soll noch in diesem Jahr als Beta verfügbar sein und Software-Entwicklern dabei helfen, ihre Anwendungen noch eleganter zu parallelisieren als bisher. Und genau dieses Bestreben verfolgen auch die Jungs von Rapidmind. Das dürfte wohl der wesentliche Grund gewesen sein, warum Intel und Rapidmind seit Ende August gemeinsame Sache machen.

Aber am besten lassen wir Stefeanus, Michal und Anwar selbst zu Wort kommen …

Die erste Aufgabe beschäftigt sich übrigens mit der Matrizen-Multiplikation, und zwar auf Basis des Strassen-Algorithmus. Hierfür muss ein kleines parallelisiertes Programm geschrieben werden, das auf einer vorgegebenen seriellen Lösung des Problemes basiert. Mithilfe des Strassen-Algorithmus ist also die parallele Version der seriellen Anwendung zu programmieren. Dabei müssen bestimmte Dinge wie Rumpf der Hauptfunktion erhalten bleiben, andere Dinge wie das Reservieren von notwendigem Speicher dürfen (und müssen) angepasst werden.

Zur Berurteilung der Güte der eingereichten Lösung wird übrigens die Zeit herangezogen, die das kleine Programm für die Matrizenmultiplikation benötgit. Da heißt es also sich anstrengen, um eine möglichst kurze Laufzeit herauszubekommen. Mehr Infos dazu bekommt man auf der Wettbewerbsseite. Viel Spaß und Glück beim Programmieren!

Ach ja: Die Intel Threading Building Blocks könnten beim Lösen der Aufgabe helfen. Nur so als kleiner Tipp …

Damit wir hier nix Falsches erzählen, konnten wir Gino van den Bergen zu einem Interview überreden, damit er uns etwas über Duale Zahlen erzählt: Worum es in seinem Vortrag ging, warum Spieleentwickler auf Duale Zahlen setzen sollten und was das Ganze mit Larrabee zu tun hat.

Nur soviel: Es geht um “Clean Code”, um die Vereinfachung der Differentialrechnung, und andere schöne Dinge, mit denen vor allem Spieleprogrammierer zu tun haben.

Und jetzt: Film ab!

Im ersten Schritt wird beispielsweise vom Thread Manager ein Thread erzeugt und in den Bereit-Zustand versetzt (“ready”). Dort verharrt der Thread so lange, bis er eine Anweisung, eine Funktion oder ähnliches ausführen soll. Darum kümmern sich entsprechende Programmanweisungen wie zum Beispiel die Pragma-Methoden der OpenMP-basierten Programmierung.

Im zweiten Schritt kommt es zur Ausführung der entsprechenden Quellcodestelle. Währenddessen muss der betreffende Thread möglicherweise auf einen anderen Thread oder ein Datum eines parallel ablaufenden Threads warten. Dann begibt er sich in den Wartend-Modus, bis der benötigte Thread beendet ist oder dessen Ergebnis vorliegt. Anschließend wird der angehaltene Thread weiter ausgeführt oder wieder in den Bereit-Zustand versetzt, da der Thread zu einem späteren Zeitpunkt nochmals benötigt wird.

Ach ja: Gerade dieser Wartend-Modus bereitet vielen Programmierern erhebliche Probleme, da hierbei Dead Locks, Data Races oder andere unvorhersehbare Ereignisse auftreten können. Wie gut, dass es hierfür Tools wie den Thread Checker oder Parallel Inspector gibt, die solche Schwachstellen aufspüren können.

Natürlich ist es auch möglich, dass ein Thread ausgeführt wird, ohne in den Wartend-Zustand versetzt zu werden. Dann stehen zwei Folgemodi zur Auswahl: Bereit oder Beendet. “Bereit” tritt immer dann ein, wenn der Thread nicht nur einmal, sondern mehrmals benötigt wird, was schon beim Programmdesign berücksichtigt werden muss. Dies kann beispielsweise eine Schleife sein, die mehrfach ausgeführt werden muss. In diesem Fall empfiehlt es sich, den zugehörigen Thread nicht zu beenden, sondern ihn wieder auf “Bereit” zu setzen, da das Erzeugen eines Threads relativ viel Rechenzeit und Verwaltungsaufwand bedeutet.

Sobald ein Thread nicht mehr benötigt wird, kann er natürlich auch beendet werden. Er wird dann aus dem Thread-Pool entfernt, alle Variablen werden gelöscht und der Thread steht nicht mehr zur Verfügung. Was aber nicht heißt, dass er zu einem späteren Zeitpunkt nicht wieder erzeugt werden kann.

Übrigens: Zu Beginn einer parallelisierten Anwendung wird ein sogenannter Initial Thread initiert, der den sequeziellen Programmablauf steuert und der auch dafür zuständig ist, das Programm “am Leben zu erhalten”, während zur Laufzeit immer wieder neue, parallel ausfühbare Threads erzeugt werden. Sobald dieser Initialisierungsthread beendet wird, endet auch das komplette Programm.

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!

Und dieser “Krafttag” wird es wohl in sich haben. Es geht unter anderem um folgende Fragen:

• Wie nutze ich aktuelle und zukünftige Multicore-Prozessoren optimal für meine Anwendungen?

• Welche Konzepte und Werkzeuge der Parallelprogrammierung gibt es?

• Was ist die Concurrency Coordination Runtime und welche Aufgaben übernimmt sie?

• Welche Bedeutung haben die Parallel Extensions für das .NET-Framework und wie setze ich sie am besten ein?

• Wie erstelle mithilfe von F# parallel programmierte Anwendungen?

Diese und viele weitere Fragen werden auf der großen .NET-Konferenz beantwortet. Und zwar von bekannten Größen der Branche wie Ralf Westphal und Bernd Marquardt, beide ihres Zeichens Microsoft MVP.

Falls Sie also zu den .NET-Entwicklern gehören, die unbedingt mehr wissen wollen (oder müssen) zum Thema Multicore-Programmierung, sollten Sie den 23. April schon mal ganz fett und dick im Kalender markieren.

Spartipp: Geben Sie bei der Anmeldung zum Multicore-Powerday einfach den Gutscheincode PPMC9SDB ein und schon sparen Sie 100 Euro. Ist das nix?!

Update: Sodala, jetzt ist auch die zugehörige Webseite online.

Das ist sicherlich nicht ganz ernst gemeint, macht aber die Herausforderungen sehr anschaulich, vor der die Entwicklergemeinde stehen wird, sobald Windows 7 auf dem Markt ist und das Programmieren von neuer Software für maximal 256 Cores ansteht. Dann gibt es nämlich nur noch eins: die richtigen Tools kaufen und parallelisieren, was das Zeug hält. Andernfalls wird aus dem Multicore-Riesen ein lahmer Singlecore-Zwerg, der von der sequenziell programmierten Anwendung jämmerlich ausgebremst wird.

Wie gut, dass es hierfür schon einiges gibt und weitere Tools kommen werden. Die Rede ist beispielsweise von den Threading Building Blocks, Thread Checker, Parallel Studio, Visual Studio 2010 und weiteren nützlichen Hilfsmitteln, mit denen die Parallelprogrammierung zwar kein Klacks wird, vieles sich aber vereinfachen lässt.

Ach ja: Für das Problem mit dem unterdimensionierten Windows Taskmanager hat einer der Kommentatoren einen nützlichen Tipp parat: Virtualisierung. Soll heißen, dass sich einfach mehrere Prozessorkerne zu einem virtuellen Prozessor zusammenfassen lassen. Dann passt die Taskmanager-Anzeige auch wieder auf einen 19-Zöller und die Anschaffung eines 30-Zoll-Monitors kann noch einmal verschoben werden …

• 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 Buch ist unterteilt in elf Kapitel, die sich allesamt mit dem Thema Multicore-Programmierung und Multithreading beschäftigen. Im ersten Abschnitt geht es zunächst um die Grundzüge von Multicore-Architekturen und die Frage, was das Amdahlsche Gesetz mit dem Ganzen zu tun hat.

Kapitel Nummer 2 betrachtet Threads im Speziellen und zeigt, wo sie eine Rolle spielen und wie hier die Virtualisierung ins Spiel kommt. Der dritte Teil des Buches erläutert dann, wie ein Programm in Threads zerlegt werden sollte, um ein Höchstmaß an Parallelität in die Anwendung zu implementieren.

Anschließend geht es ans Eingemachte: Shameem und Jason betrachten die einzelnen Schritte, die bei der Multithread-Programmierung anfallen, also die Synchronisierung von Daten und Aufgaben, und erklären auch, wie Deadlocks entstehen und wie man diese vermeidet. Kapitel fünf und sechs widmen sich  den Threading-Modellen, also den Windows- und POSIX-Threads sowie OpenMP, die wir auch schon betrachtet haben.

Im siebten Kapitel wird es ein wenig schmerzhaft, denn hier zeigen die Autoren, welche Fehler man bei der Multicore-Programmierung machen kann. Die gute Nachricht: Zu jedem Problem gibt es eine passende Lösung, und so präsentiert das Verfasserduo die schönsten Klassiker der Parallelprogrammierung – zu viele Threads, Race Conditions, Deadlocks und Speicherprobleme – wie man sie in den Griff bekommt und welche Tools hierfür taugen.

Abschnitt Numero acht macht kurzen Prozess mit dem siebten, indem es die Fehlerbehebung, also das Debugging näher betrachtet. Beim neunten Kapitel scheint ein Bruch im Buchkonzept vorzuliegen, denn es geht auf einmal um Single-Core-Prozessoren. Dafür haben die Autoren allerdings eine passende Erklärung parat: Nur wer die Funktionsweisen der Einkern-CPUs kennt, versteht die Multicore-Prozessoren richtig. Zumal es ja keinen 100-Prozent-Parallelcode gibt. Daher ist dieses Thema nicht ganz unbedeutend, wenngleich man es nicht unbedingt an dieser Stelle erwartet.

Anhand des zehnten und elften Abschnitts merkt man dann doch noch, dass es sich bei dem Multicore-Buch um ein Intel-Produkt handelt: Die Parallelprogrammierung wird am Beispiel der Intel Multicore-Prozessoren besprochen. Und auch die Programmiertools wie der Thread Checker, die Intel MKL, die Intel IPP und natürlich der VTune Performance Analyzer entstammen alle derselben Schmiede.

Fazit: Für alle, die mehr wissen wollen zum Thema Multicore-Programmierung, sei dieses Buch wärmsten empfohlen. Denn es ist gespickt mit fundiertem Fachwissen, hilfreichen Beispielen und nützlichen Tipps.

Zunächst einmal helfen unsere fünf Multicore-Regeln, die wir Ende letzten Monats aufgestellt haben. Die wichtigste davon lautet beim Software-Design: Denke parallel! Denn nur so hält man am Schluss eine Anwendung in den Händen, die sich mithilfe der passenden Tools bestmöglich parallelisieren lässt.

Eine beliebte Fehlerquelle ist ein Überangebot an Threads, vor allem dann, wenn Sie diese “manuell” programmieren, so wie im Falle von Pthreads. Daher sollte man durchaus sparsam mit dem Erstellen von Threads umgehen, denn nur eine ausgewogene Balance von parallelem und seriellem Quellcode bringt die erwünschten Leistungsschübe. Oder man bedient sich nützlicher Tools wie Intel TBB, die Threads automatisch generieren.

Ebenfalls sehr wichtig ist die optimale Granularität der zum Einsatz kommenden Locks und Unlocks, denn jedes Sperren und Entsperren von parallelem Programmcode erfordert einen hohen Verwaltungsaufwand. Werden Locks zu lange ausgeführt, können sie andere Threads unnötig blockieren, was die Anwendung insgesamt ausbremst. Und auch die gemeinsam genutzten Speicherressourcen müssen bestmöglich aufeinander abgestimmt sein, denn ein übertriebener Synchronisierungsaufwand macht sich negativ bemerkbar.

Ein weiterer Hemmschuh parallel programmierter Software ist die schlechte Verteilung der notwendigen Tasks auf die vorhandenen Prozessorkerne beziehungsweise Threads. Denn nur wenn Sie diese optimal ausnutzen, indem Sie Leerlaufzeiten einzelner Cores vermeiden, skaliert die Anwendung auf einem Multicore-System in entsprechender Weise.

All diese Fehler können Sie übrigens von Anfang an vermeiden, indem Sie Tools wie den VTune Performance Analyzer einsetzen, der Ihnen genau die Stellen zeigt, die man am besten parallelisieren kann. Aber auch das Laufzeitverhalten einer fertigen Anwendung kann mit VTune erforscht werden. Und wenn Sie dann mal ein parallel programmiertes Programm vorliegen haben, hilft der Thread Checker dabei, mögliche Fehler aufzuspüren. Hierbei sind Dead Locks und Race Conditions eine häufig auftretende Fehlerquelle, die sich mithilfe des Tools lokalisieren lassen.

J, ja, es ist schon ein paar Tage her, dass Mac OS X 10.5, auch bekannt als Leopard, das Licht der Welt erblickt hat. Aber ich habe gerade ein paar sehr interessante Details bezüglich der Multicore-Affinität des Apple-Betriebssystems entdeckt. Und so richtig viel darüber habe ich im Web nicht gefunden.

Hardware-seitig bietet Apple ja mit dem Mac Pro die volle Mehrkerntechnik von Intel: Acht Prozessorkerne beschleunigen vor allem die Bild- und Videobearbeitung, aber auch für Apple-eigene Anwendungen ist der Intel Xeon Prozessor, eine Quadcore-CPU mit maximal 3,2 GHz, nützlich.

Von dieser Mehrkern-Architektur profitieren unter anderem Programme wie Mail, das Adressbuch und die Verwaltung der Schriftensammlung, indem anfallende Aufgaben auf die vorhandenen Ressourcen möglichst optimal verteilt werden. Darum kümmert sich übrigens die neu programmierte Ablaufsteuerung von Leopard.

In Sachen Netzwerk hat sich Apple ebenfalls Gedanken gemacht: So wurde ein multithreading-fähiger Netzwerkstapel implementiert, der die Ein- und Ausgabeanfragen des LANs schneller verarbeiten kann. Außerdem wurde die indizierte Suchfunktion Spotlight beschleunigt, genauso wie die Wörterbuchfunktion von Mac OS X 10.5. Dies hat vor allem mit der objektorientierten API Cocoa zu tun, die ebenfalls für den Multicore-Betrieb optimiert wurde.

Um all diese Verbesserungen hinsichtlich der parallelen Datenverarbeitung zu erzielen, hat Apple seinem Betriebssystem eine ganz neue Klasse an APIs spendiert, die sogenannten NSOperationen. Dabei werden unabhängig voneinander berechenbare Operationen einer Warteschleife hinzugefügt, die automatisch und sehr dynamisch die Verarbeitung der Befehle oder Operationen steuert, je nach Auslastung der vorhandenen Prozessorkerne.

Interessant daran ist auch die Tatsache, dass man als Entwickler die erforderlichen Threads nicht selbst erstellen und wieder schließen muss. Dies erledigt Cocoa automatisch, indem es die Operationen selbstständig auf die Ressourcen effizient verteilt.

Darüber hinaus lassen sich Leopard-basierte Macs (vor allem der bereits erwähnte Mac Pro) für wissenschaftliche Zwecke einsetzen, da Apple auch hier auf die Multicore-Fähigkeiten seiner Rechner setzt. Das Zauberwort heißt OpenMPI, was eine Vernetzung mehrerer Rechner ermöglicht. Dabei kommen mediumseitig IP-Verbindungen wie LAN oder WLAN zum Einsatz, die Software für den eigenen Mac-Cluster nennt sich Xgrid und stammt ebenfalls von Apple. Selbst in der Entwicklerumgebung Xcode steckt eine Menge Multicore-Potenzial, wie wir ja bereits in einem früheren Beitrag gezeigt haben. Parallel Computing aus dem Hause Apple von A bis Z eben …

Wie aber sieht es mit den fundamentalen Tools aus, die bei der Programmierung an erster Stelle stehen, also etwa den Compilern, mit denen sich der Quellcode in eine ausführbare Anwendung verwandeln lässt? Nun, auch hierfür gibt es multicore-optimierte Lösungen, die sich vor allem an C++- und Fortran-Programmierer richten. Das Ganze gibt es sogar als komplettes Entwicklerpaket, das neben dem C++-Compiler die TBB-Suite umfasst, die Integrated Performance Primitives und die Math Kernel Library.

Praktisch an dem Intel C++-Compiler für Windows sind vor allem zwei Dinge: Zum einen lässt er sich direkt in Visual Studio einbinden, was das Kompilieren innerhalb der gewohnten Umgebung ermöglicht. Und zum anderen ist der Compiler für Multicore-Plattformen optimiert. Das bedeutet, dass der Quellcode auf mögliche Parallelitäten hin untersucht wird. Findet der Compiler entsprechende Programmabschnitte, fügt er automatisch die passenden Konstrukte und Funktionen ein, die den seriell programmierten Abschnitt parallelisieren.

Neu an der Version 11 des Intel C++-Compilers sind übrigens unter anderem die eingebauten Lambda-Funktionen, OpenMP 3.0 und die Unterstützung von dezimalen Fließpunktoperatoren und -registern. Und natürlich gibt es die Intel Compiler auch für Linux (inklusive Eclipse-Unterstützung) und für Mac OS X (in Verbindung mit XCode).

Mit der Einführung neuer Betriebssysteme wie Microsoft Windows und besserer Prozessoren wie dem Intel Pentium MMX standen auf einmal im Desktop-Segment ganz neue Möglichkeiten zur Verfügung: Mit Multitasking konnten zeitversetzt von einem Prozessor mehrere Aufgaben anscheinend gleichzeitig erledigt werden. Und das Multithreading erlaubte es dank neuer Befehlssätze (SSE), Daten gleichzeitig zu verarbeiten, wenn diese keine Abhängigkeit zueinander aufwiesen. Dazu gehört auch die SIMD-Architektur, die beispielsweise gleichartige Operationen in großen Integer-Registern parallel ausführen kann.

Dann wurde mit dem Intel Pentium 4 HT der erste Prozessor für den Verbrauchermarkt vorgestellt, der auf Basis der Hyperthreading-Technik zwei Aufgaben gleichzeitig in einem Prozessorkern ausführen konnte. Dies ermöglichte ganz neue Anwendungen, da deutlich mehr Rechenleistung auf Standard-PCs zur Verfügung stand. Die HT-Technik wird auch als simultanes Multithreading bezeichnet.

Mit dem Aufkommen von Dual- und Quadcore-Prozessoren im Massenmarkt ließen sich erstmals Anwendungen zur Laufzeit in unterschiedliche Aufgaben zerlegen, die dann auf mehreren CPU-Cores gleichzeitig, also parallel, verarbeitet werden können. Dies erfordert allerdings von den Software-Entwicklern sehr viel mehr Denkarbeit, um ein Programm von Haus aus parallel zu entwickeln. Zudem sollte er auf Software-Tools setzen, die ihn bei der parallelen Programmierung so gut wie nötig und möglich unterstützen.

So wie die TU München, die schon seit längeren mit Intel in Sachen Multicore-Programmierung zusammenarbeitet. Hierzu habe ich auf Blip.tv ein sehenswertes Video mit Professor Doktor Arndt Bode gefunden, dem Vizepräsidenten der Technischen Uni zu München.

In diesem sechsminütigen Videochat erfährt man diverse aufschlussreiche Dinge:

• Nicht nur Informatikstudenten sollten sich mit dem Thema Multiprozessor-Architektur beschäftigen, sondern auch die anderen Fakultäten. Und klar, programmieren für mehrere CPU-Kerne sollten sie auch können.

• Steigerungsraten in Sachen Rechenleistung lassen sich nur noch mithilfe mehrerer Prozessorkerne erzielen und der damit einhergehenden Threads, die parallel verarbeitet werden können. Denn die Zeiten der Gigahertz-Mania sind endgültig vorbei (sic!).

• Sämtliche Kurse zum Thema Paralleles Programmieren werden sukzessive ausgebaut, und zwar nicht nur für angehende Informatiker, sondern auch für Chemiker, Physiker, Elektrotechniker und einige andere. Denn gerade in diesen Bereichen profitieren Anwendungen in hohem Maße von der Multicore-Programmierung, wie das anhand des Beispiels Hochleistungsbibliotheken deutlich wird.

• Die Grundlagen der parallelen Programmierung werden mittlerweile schon während des Grundstudiums gelehrt und die dazu passenden Praxisübungen gibt es gleich dazu. Nur so lernen die Studenten den richtigen Umgang mit den vorhandenen Tools, die das Entwickeln von Software für Mehrkern-Systeme erleichtern sollen.

• Es geht aber auch darum, sich mit künftigen Technologien, Plattformen und Architekturen zu beschäftigen. Dazu zählt beispielsweise die Frage, wie sich in Zukunft Prozessoren entwickeln werden, aber auch die künftigen Cache-Techniken sind bei der Wahl der richtigen Programmiermethode von entscheidender Bedeutung. Daher ist es äußerst wichtig, dass sich Prozessorhersteller wie Intel permanent mit der akademischen Elite austauschen, um so gemeinsam neue Ideen und Ansätze im Bereich Prozessorarchitekturen zu entwickeln.

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?

Forget everything you thought you knew about multi-threaded programming (and, as it turns out, most developers didn’t know much anyway).

The kernel is the only one who really knows the right mix of cores and power states to use at any given time – this can’t be a pure app-driven decision.

We need new APIs and mechanisms for dealing with this incoming meteor.

Wie gut, dass sich Intel über Letzteres bereits Gedanken macht und Tools wie Intel TBB und Intel Parallel Studio bietet, mit deren Hilfe die Multicore-Programmierung deutlich erleichtert werden kann.

Weniger schlau während seines Vortrags war allerdings die Folie Nummer 5, auf der er (ganz inoffiziell natürlich) den Erscheinungszeitraum der nächsten OS-X-Version 10.6 aka Snow Leopard bekannt gegeben hat, nämlich das erste Quartal 2009. Anfang Juni während der Apple-Entwicklerkonferenz WWDC’08 war noch von ungefähr einem Jahr die Rede, bis Mac OS X 10.6 in die Läden kommt. Tja, dumm gelaufen!

Und was hat das alles mit Multicore-Programmierung zu tun? Nun, in der nächsten Version des Apple-Betriebssystems wird ganz viel Multicore-Unterstützung stecken. Leider gibt Apple noch nichts Konkretes raus (und John leider auch nicht), aber einige grundsätzliche Dinge sind heute schon klar:

Die Multicore-Technik in Snow Leopard trägt den Codenamen „Grand Central“ und soll laut Apple den Umgang mit Multicore-Systemen erheblich erleichtern. Das soll sowohl die Software-Entwickler betreffen als auch die Anwendungen und deren Ausführung. Es geht also um die Zuordnung von Tasks auf vorhandene Prozessorkerne und eine verbesserte Multicore-Programmierung unter Mac OS X 10.6. Das ist so überraschend nicht, schließlich weiß Apple seit vielen Jahren ganz genau, wie man Software und Hardware optimal aufeinander abstimmt.

Übrigens: Auch John Hubbards Chef, Mister Steve Jobs, kann gelegentlich nicht ganz so schlaue Dinge sagen. In einem Interview mit dem Bits Blog der News York Times sprach er nämlich folgenden Satz:

The way the processor industry is going is to add more and more cores, but nobody knows how to program those things. I mean, two,, [processor cores], yeah; four, not really; eight, forget it!

So, so, niemand weiß, wie man Software für vier, acht oder mehr Prozessorkerne programmiert. Na, Steve, frag mal bei Intel und seinen Partnern nach, wie das geht …

Multicore-Regel Nummer 1: Denke parallel! Am allerbesten ist ein paralleles Konzept von Anfang an. Dies vermeidet ein nachträgliches Implementieren parallelen Quellcodes, wie das beispielsweise mit den Intel Threading Building Blocks möglich ist. Optimalerweise legen Sie sich eine Strategie zurecht, wie Sie Schritt für Schritt zu einer multicore-optimierten Anwendung kommen.

Multicore-Regel Nummer 2: Entwickle task-orientiert! Parallel programmierter Code skaliert am besten, wenn er nicht für eine bestimmte Zahl an Prozessoren programmiert wurde, sondern sich an der bestmöglichen Zahl an parallel ausführbaren Aufgaben orientiert. Denken Sie daher nicht in Threads, dass erledigen Tools wie die Intel TBB für Sie. Deren Scheduler verteilt die auszuführenden Aufgaben auf die vorhandenen Prozessorkerne. Und je mehr davon zur Verfügung stehen, desto paralleler läuft die Anwendung.

Multicore-Regel Nummer 3: Auf die Tools kommt es an! Parallele Threads auf Basis von POSIX oder Windows-APIs programmieren zu wollen, ist ein hartes Brot, denn Sie müssen sich selbst um die Parallelisierung des Quellcodes kümmern. Viel einfacher ist es, mit den richtigen Tools der Anwendung paralleles Leben einzuhauchen.

Sie entwickeln bevorzugt mathematisch-orientierte Software? Dann werfen Sie mal einen Blick auf die Intel Math Kernel Library. Sie programmieren MPEG-Encoder? Fein, dann kommen am ehesten die Integrated Performance Primitives in Frage, die mithilfe der vorhandenen Funktionen das Parallelisieren von Multimediaanwendungen erleichtern. Und die Intel TBB habe ich ja bereits erwähnt, die dank ihrer eingebauten Multithread-Funktionen vor allem Schleifenkonstrukte mit wenigen Programmzeilen parallelisieren.

Multicore-Regel Nummer 4: Multithread-Code muss sequenziell laufen! Das klingt zunächst einmal kontraproduktiv, stellt sich aber gerade beim Debuggen als großer Vorteil heraus, da die Fehlersuche im sequenziellen Quellcode wesentlich einfacher ist. Stellen Sie also sicher, dass Ihre Anwendung auf einem Thread fehlerfrei läuft. Wenn Sie dann beim Umstellen auf zwei, vier oder mehr Threads Fehler feststellen (zum Beispiel mithilfe des Thread Checkers), können Sie sich ziemlich sicher sein, dass im Parallel-Code etwas nicht stimmt. Übrigens: Ein vollständig parallelisiertes Programm ist keine gute Idee!

Multicore-Regel Nummer 5: Denke an die Speicherverwaltung! Die Zuweisung von benötigtem Speicher ist vor allem bei parallel ausführbaren Programmen eine echte Herausforderung, da je nach Anzahl der verfügbaren Prozessoren und der damit maximalen Anzahl von Threads der richtigen Speicherverwaltung zur Laufzeit eine enorm wichtige Bedeutung zukommt. Daher sollten Sie beim Entwickeln von Multithread-Code unbedingt auf einen skalierenden Memory Allocator setzen, der den notwendigen Speicher automatisch verwaltet. Die Intel TBB setzen solch einen dynamischen Speicherzuweiser ein …