18% mehr Erstsemester in der Informatik – Berufsaussichten weiterhin exzellent

Im Studienjahr 2011 (Sommer- und Wintersemester 2011) haben sich laut Mitteilung des Statistischen Bundesamtes 48.400 Studierende für den Studienbereich Informatik eingeschrieben. Dies entspricht einer Steigerung von 18 % im Vergleich zum Vorjahreszeitraum.

Diese Meldung stammt von der Gesellschaft für Informatik, die verständlicherweise über diese Entwicklung sehr erfreut ist, denn:

“Durch diesen Anstieg werden wir auch deutlich mehr Absolventinnen und Absolventen bekommen, die in Wirtschaft, Wissenschaft und Verwaltung dringend gebraucht werden. Denn nach wie vor ist der Bedarf an gut qualifizierten Informatikerinnen und Informatikern sehr hoch.”

Das sagt GI-Präsident Stefan Jänichen höchstpersönlich, und der wird es ja wohl wissen. Dabei muss allerdings die Frage erlaubt sein, ob die Fachhochschulen und Universitäten dieses Landes auf solch einen Zustrom an Erstsemestlern auch richtig eingestellt sind. Und zwar in Sachen Ausstattung und Lehrinhalte. Zu ersterem können wir natürlich nichts beitragen, zu Punkt zwei aber schon.

Daher folgt an dieser Stelle unser ultimativer Erstsemester-Survival-Kit in Sachen Multicore-Programmierung. Auf dass die Software-Anwendungen der Zukunft auf Rechnersystemen mit 4, 6, 8 und mehr Prozessorkernen verteilt und superskalar laufen. Viel Spaß beim Schmökern!

Grundwissen Multicore-Programmierung

Wie man sich die parallele Datenverarbeitung/Programmierung vorstellen kann

Von Single-Threading bis zur Multicore-Programmierung

In der Parallelprogrammierung steckt die Zukunft!

12 Thesen und Antithesen zur Multicore-Programmierung

Stephen Blair-Chappell über Chancen und Grenzen der Parallel-Programmierung

Know-how: Von Deadlocks und Live locks

Know-how und Programmiertipps: Data Races

Multithreading-Konzepte: OpenMP, APIs und Intel TBB

Tutorials & Regeln

Workshops und Tutorials für Parallelprogrammierer

Beliebte Fehler bei der Parallelprogrammierung

Einsteiger-Kurs: So programmiere ich für Multicore-Systeme unter Microsoft . NET (Teil 1, Teil 2, Teil 3)

Workshop: Alles über .NET-Threads (Teil 1, Teil 2, Teil 3, Teil 4)

Programmiermethoden: Daten- und Aufgabenparallelität

Vier Schritte zum optimierten Multicore-Quellcode

Fünf Multicore-Programmierregeln auf einen Blick

Acht nützliche Tipps zum Parallelisieren 

Mögliche Thread-Modi und deren Folgen

OpenMP-Workshops

Workshop: parallel Programmieren mit OpenMP

OpenMP: fünf Bedingungen für parallele Schleifen

OpenMP: Schleifen anpassen für Multithreading-Ausführung

Buchtipp

Buchtipp: Multicore-Programmierung lernen mit Intel

Teil 1 der virtuellen Kurse beschäftigt sich vor allem mit der Frage, wie sich Anwendungen, die auf den aktuellen Prozessoren von Intel (Stichwort: Sandy Bridge) laufen, so optimiert werden können, damit sie noch besser und performanter auf dem Rechner ausgeführt werden. Hierzu bietet VTune Amplifier XE eine eigene Funktion, mit der sich die Anwendung analysieren und auf Hotspots und ähnliche Bremsklötze untersuchen lässt.

Teil 2 der Webinar-Reihe zeigt, welche Hemmschuhe in einer Anwendung vorkommen können und wie sie mit Hilfe von Sandy-Bridge-Funktionen wie AVX behoben werden können. Natürlich lernen Sie auch, wie sich diese Funktionen optimal einsetzen lassen und weiter optimiert werden können.

Und wem das noch nicht genügt, dem möchte ich die zwei Videos ans Herz legen, die sich mit dem Thema Performance-Analyse ausführlich beschäftigen. Für das Abspielen der Videoclips müssen Sie sich übrigens nicht anmelden.

Alle Infos und den Anmeldelink finden Sie auf der zugehörigen Webseite auf dem Intel Software Network.

Zunächst einmal muss man festhalten, dass es drei verschiedene Go-Compiler gibt: einen für AMD-Prozessoren, einen für die x86-Plattform von Intel und eine Variante für ARM-CPUs, die derzeit vor allem in Smartphones und Tablets verbaut werden. Die erstgenannten sind laut goloang.org fertig und bieten sogar diverse Möglichkeiten zu automatisierten Code-Optimierung auf Registerbasis. Der ARM-Compiler ist offenkundig noch in einer frühen Beta-Phase, zumindest werden bis dato nur Linux-Binaries unterstützt, der Optimizer ist noch nicht fertig und Floating-Point-Berechnungen werden derzeit nur auf Basis der VFP-Unit durchgeführt.

Aus Sicht dieses Blogs ist natürlich das Konzept der Nebenläufigkeiten von ganz besonderem Interesse, das Go mit neuen Ansätzen optimal unterstützen will. Hierzu gehören folgenden Dinge:

• “Share by Communication”: Im Gegensatz zu anderen Programmiersprachen, bei denen die meisten Probleme aus dem konkurrierenden Zugriff auf Daten resultieren, verfolgt Go einen  neuen Weg: Daten werden mithilfe von Kanälen “herumgereicht”, was dazu führt, dass jede Go-Routine immer nur auf genau einen Wert zugreift, nämlich den aktuell ermittelten. Um das in einem Satz zu verdeutlichen, haben die Macher von Go sich den Slogan “Do not communicate by sharing memory, instead share memory by communicating” ausgedacht.

• Go-Routinen: Diese Ansammlung von Funktionen laufen parallel zu anderen Go-Routinen im selben Adressraum ab. Zudem benötigt solch eine Routine nur wenig Speicher, da sie lediglich ein wenig Stack in Anspruch nimmt. Solch eine Funktion oder Methode wird mit dem Schlüsselwort go aufgerufen. Endet die Funktion oder Methode, wird auch die Go-Routine beendet.

• Channels (Kanäle): Kanäle sind Referenztypen und sorgen dafür, dass zwei oder mehrere Go-Routinen in einem definierten Zustand bleiben. Channels werden mit dem Befehl make erzeugt.

• Kanäle von Kanälen: Channels sind Werte “erster Klasse”, können also beliebig herumgereicht werden. Das erlaubt ein thread-sicheres, paralleles Verarbeiten mehrerer Kanäle, so genannter Channel Bundles. Der englische Fachbegriff hierfür nennt sich De-Multiplexing. Daraus entsteht ein quotiertes, paralleles, nicht-blockierendes RPC-System – und das ganz ohne Mutexe.

• Parallelisieren: Das asynchrone Berechnen eines Vektors ist eines der Anwendungsbeispiele von Go-Routinen mithilfe von Kanälen. Dabei werden die Elemente eines Vektors auf die Anzahl der vorhandenen Kerne verteilt, und das völlig unabhängig voneinander. Sobald sämtliche Vektorberechnungen durchgeführt worden sind, werden die zugeghörigen Kanäle gelöscht und das Ergbnis ermittelt.

Wer Go mal ausprobieren möchte: auf golang.org steht eine genaue Installationsanleitung bereit. Und ein Blick in die umfangreiche Online-Dokumentation kann sicherlich auch nicht schaden. Und besonders schick: einen sehr übersichtlichen Programmierleitfaden gibt es sogar in Deutsch!

Aber der Reihe nach: Data Races (auch: “Dataraces”) gehören zur Klasse der Race Conditions. Der Begriff „race“ deutet bereits an, dass es sich hierbei um einen Wettlauf handelt: Eine Gesamtprozess soll das Endergebnis zweier oder mehrerer Teilprozesse darstellen, wobei die Teilprozesse aufeinander aufbauen, fälschlicherweise aber parallel gestartet werden und somit zu einem falschen Resultat führen.

Eine kleine Analogie, die das verdeutlicht: Bei einem Staffellauf übergibt Läufer 1 das Hölzchen an Läufer 2 und so fort. So ergibt sich eine funktionale Kette, wobei ein Läufer erst dann starten darf, wenn er den Stab vom heraneilenden Partner erhalten hat. Diese funktionale Kette würde unterbrochen, wenn Läufer 2 nicht wartet, sondern sich ein eigenes Hölzchen schnappt und – warum auch immer – vor dem vereinbarten Kommando losläuft. Dann würde Läufer 3 von 2 Teamkollegen und 2 Hölzern bedient. Das führt in der Leichtathletik zur Disqualifikation.

Nun etwas technischer: Bei Data Races beschreibt beispielsweise ein Thread einen Speicherbereich, während ein zweiter Thread auf einen überlappenden Bereich zugreift. Bislang war die Analyse dieser Fehler sehr aufwändig, weil die Auswirkungen nicht immer sofort sichtbar sind oder keine klaren Rückschlüsse auf einzelne Code-Phrasen zulassen.

Ist die Ursache aber gefunden, lässt sich die Panne über eine neue Anordnung  korrigieren: der erste Thread muss exklusiven Zugriff auf Ressourcen (etwa den Speicherbereich) erhalten und diesen Zugriff erst nach Abschluss seiner Aufgabe zugunsten des zweiten Threads lösen – also eine sequentielle Abfolge der Threads. Praktisch wird das meist über Semaphore erledigt. Semaphore sind Datenstrukturen, die – vereinfacht ausgedrückt – dazu dienen, bei der parallelen Ausführung die Threads in eine sinnvolle Reihenfolge zu bringen.

Das klingt kompliziert – und das ist es auch. Aber nur, wenn Sie auf den Einsatz des Intel Inspector XE 2011 verzichten. Der kümmert sich selbstständig um das Fixing.  Zunächst aber prüft das Tool gewissenhaft die Threads und die Speicherbelegung. Dafür können Sie übrigens anhand der integrierten Tutorials vorgehen. Memoryleaks werden dabei sofort aufgespürt und im Quellcode lokalisiert. Das gilt auch für Data Races, die Sie in einem Zug gemeinsam mit Deadlocks ermitteln.

Wie einfach und hilfreich das mitunter in der Praxis ist, schildert dieses sehr gute Video mit Anwendungsbeispielen aus der Parallelprogrammierung:

Szenario I: Videokodierung/-dekodierung

Bei der Kodierung und Dekodierung von Videodaten kommen vor allem zwei mathematische Funktionen häufig zum Einsatz, nämlich die Diskrete Kosinus-Transformation und die zugehörige Inverse Transformation. Hierfür steht eine eigene AVX-optimierte Funktion zur Verfügung, die im Vergleich zu der entsprechenden SSE-Floating-Point-Operation solch eine Transformation mit dem Faktor 1,78 schneller  berechnet. Mehr Infos dazu

Szenario II: Bildbearbeitung

In der Bildbearbeitung sind vor allem Filter häufig angewandte Funktionen, und auch hier können AVX-basierte Operationen die Anwendung erheblich beschleunigen – und das ohne größere Veränderungen am Sourcecode. Beispiel hierfür ist der Gauß’sche Weichzeichner, der vor allem für das Entfernen von Bildrauschen verwendet wird. Da sich Pixel meist völlig unabhängig voneinander analysieren und manipulieren lassen, existiert hier ein großes Parallelisierungspotenzial auf AVX-Basis. Für den Gauß’schen Filter kommt übrigens OpenMP zum Einsatz, und die benötige Rechenzeit halbiert sich nahezu im Vergleich zu SSE-Operationen bei einem Bild der Größe 2048*2048. Mehr Infos dazu.

Szenario III: 3D-Anwendungen

Häufig in 3D-Anwendungen vorkommende mathematische Operationen sind Matrizenberechnungen, die zur Darstellungen von Vektoren notwendig sind. Die wichtigsten Berechnungen hierbei sind die Addition (mm256_add_ps), die Multiplikation (mm256_mul_ps) und die Berechnung der Matrix-Determinanten, die ja rein mathematisch betrachtet eine Kombination aus Matrizen-Addition, -Multiplikation und -Subtraktion darstellt, also mm256_add_ps(), mm256_mul_ps() und mm256_sub_ps(). Die zur Verfügung stehenden AVX-Operationen beschleunigen die Berechnungen kleiner Matrizen um den Faktor 1,8 (Addition) bis 1,56 (Determinante). Mehr Infos dazu

Zunächst aber die Übersicht der wesentlichen Grafik- und Power-Technologien, die Sandy Bridge auf den Core-Chips bietet. Bislang habe ich diese Funktionen eher tröpfchenweise beschrieben, hier nun der Gesamtüberblick.

• Verbesserte Grafikleistung durch Integration von GPU und CPU auf einem einzigen Chip (Die). Per Intel Switchable Graphics können Notebook-Anwender bei sehr grafikintensiven Spielen wie FIFA 11 ohne Neustart des Computers auf die vorhandene diskrete Grafikkarte umschalten. Allerdings muss der jeweilige Rechner dieses Feature explizit unterstützen.

• Turbo Boost 2.0: Turbo Boost wurde von Intel für Sandy Bridge optimiert und beschleunigt serielle Anwendungen, indem sie die Taktfrequenz einzelner Kerne anhebt und damit die Geschwindigkeit um bis zu 75 Prozent steigert. Turbo Boost funktioniert auch bei der GPU und prüft automatisch, ob die Prozessorkerne oder die Grafik beschleunigt werden soll. Sie geht dabei auch bis zu 25 Sekunden lang über das TDP-Limit hinaus. So können einzelne oder alle CPU-Kerne kurzfristig um bis zu 700 MHz “übertaktet” werden.

• Gemeinsamer Last Level Cache: Die Grafik-Engine ist nun direkt an den Cache des Prozessors angebunden. Deswegen auch die neue Bezeichnung Last Level Cache statt L3-Cache. Der Cache steht sowohl den Kernen als auch der Grafikeinheit zur Verfügung. Die Grafikleistung profitiert dabei von einem 64-fach höheren Durchsatz als beim bisherigen Speicherzugriff.

• Intel QuickSync Video: Videos lassen sich deutlich schneller für mobile Geräte wie iPhone und iPad konvertieren. So zeigen Intel-interne Tests, dass mit QuickSync Video nur noch vier Minuten Konvertierungszeit für eine Minute Video anfallen. Das ist schneller als mit der schnellsten diskreten Grafikkarte, die derzeit erhältlich ist.

• Intel InTru 3D: Stereoskopische 3D-Blu-ray-Wiedergabe in Full HD 1080p-Auflösung über HDMI 1.4.

• Intel Clear-Video-HD: Qualität und Farbdarstellung bei der HD-Wiedergabe wurde nochmals deutlich verbessert.

• Advanced Vector Extensions (AVX) : Neuer Befehlssatz für Video- und Bildbearbeitung, Gaming. 3D-Modellierung, wissenschaftliche Simulationen und Finanzanalysen. AVX beschleunigt die anfallenden Berechnungen mit einer Verdoppelung der Registerbreite von 128 auf 256 Bit. Hierbei wurde auf volle Komptabilität zu den bisherigen Befehlssätzen wie beispielsweise SSE4 geachtet.

• Intel HD Graphics 3000: Mehr 3D-Leistung für Highend-Games wie Shooter. Die dynamische Grafikfrequenz liegt bei maximal 1350 MHz. Unterstützt werden DirectX 10.1 und OpenGL 3.0.

Und nun zu den Ressourcen, die Ihnen diese neuen Grafik-Technologien aus Entwicklersicht näher bringen, Code-Beispiele nennen und auch den einen oder anderen Insider-Tipp verraten:

• Intel Integrated Graphics Performance Developer’s Guide für Intel HD Graphics: Eine Leitfaden für Spiele-Entwickler, die ihren Code konsequent auf die neuen Funktionen von Sandy Bridge ausrichten möchten. Natürlich steht dabei Intel HD Graphics im Vordergrund. Es geht aber auch um den älteren Intel Graphics Media Accelerator mit Fokus auf das Thema Leistungsanalyse unter DirectX.

• AVX Cloth ist ein Beispiel, das die Möglichkeiten der Vektorprogrammierung mit 256 Bit breiten Registern verdeutlicht. Dazu gibt es Screenshots, ein Video und natürlich den Source Code und die Binaries zum Download.

• Onloaded Shadows ist eine Technik, mit der Shadow Maps asynchron auf der CPU berechnet werden. Erfahren Sie hier, wie Sie mit Hilfe von Cascades einen optimalen Lastenausgleich zwischen CPU und GPU herstellen.

• Sample Tweaker beschreibt, wie die Grafikdemo Ocean Fog mit Hilfe von Intel Integrated Graphics optimiert wurde. Dabei konnte die vierfache Geschwindigkeit (von 40 FPS auf 160 FPS) gemessen werden, indem neue Technologien angewendet wurden, die beispielsweise die Texturgröße oder die Schärfe verringert haben – ohne nennenswerte Auswirkungen auf die Qualität.

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!

• das richtige Speicher-Management beim Threaden von Anwendungen

und

• der richtige Einsatz der bestehenden Intel-Tools wie Integrated Performance Primitives und Parallel Inspector, Parallel Amplifier und Parallel Composer.

Toll an diesem Programmier-Leitfaden ist die sehr ausführlich Darstellung möglicher Szenarien und wie sich diese richtig behandeln lassen. Dazu gibt es eine Menge nützlicher Diagramme und Code-Beispiele.

Allerdings hat Intel vor den Download dieser digitalen Broschüre eine kleine Registrierung gestellt, die aber nur aus einem Namen und einer E-Mail-Adresse besteht. Anschließend könnt ihr sogar auswählen, welche Themen und Broschüren euch besonders interessieren. Im Falle der Multithreading-Anleitungen solltet ihr “Intel Software Dispatch” anklicken. Viel Spaß beim Lesen!

In dem ausführlichen Beitrag wird gezeigt, wie das Intel-Tool dabei helfen kann, serielle Codeabschnitte zu parallelisieren. Ach ja: Das betrifft ausschließlich C++-Programmierer. Toll an Advisor Lite ist sein schrittweises Herantasten an den möglichen Multithread-Code: Anstatt alles auf einmal umzustellen, erlaubt das Tool ein sukzessives Optimieren des seriellen Quellcodes. Hierzu setzt es vorhandene Debugger-Tools ein, mit denen der parallelisierte Quellcode sofort getestet und mögliche Fehler identifiziert und eliminiert werden können. Dazu zählen unter anderem Data-Sharing-Probleme, die sich beim Synchronisieren von Threads ergeben können.

Interessant an Edmunds Artikel ist übrigens die Vorgehensweise des Advisor Lite:

1. Leistungsengpässe (Hotspots) identifizieren
2. Annotationen in den seriellen Quellcode einfügen (eine Art von C-/C++-Makros)
3. die  annotierten Quellcodes verifizieren
4. parallele Datenzugriffe untersuchen
5. Datenkonflikte auflösen, die unter Schritt 4 aufgespürt wurden
6. Quellcodeänderungen testen

Ach ja: Wer noch nicht wissen sollte, was Annotationen sind: Sogar hierzu hält Edmund die passenden Antworten parat. Also alles in allem eine wirklich gelungene Abhandlung in Sachen Parallel Advisor Lite. Und, worauf wartet ihr noch?

Ich war auf der Veranstaltung in München und konnte mich selbst davon überzeugen: der Raum war proppenvoll, da das Thema wohl für viele sehr spannend ist. Der Bedarf nach mehr Wissen zum Thema Parallelprogrammierung ist sehr groß, und mindestens genauso groß sind die Lücken, die sich dazu bei vielen Entwicklern auftun.

Nun, diese Defizite konnten Intel und Microsoft hoffentlich ein wenig beheben. Und wer selbst nicht die Gelegenheit hatte, sich vor Ort ein eigenes Bild davon zu machen, was es mit der parallelen Programmierung auf sich hat, dem seien die drei Videoclips empfohlen, die Microsoft online gestellt hat.

Allerdings sollte man sich viel Zeit nehmen, denn die Videokollektion umfasst mehr als drei Stunden Anschauungsmaterial zu diversen Themen:

• Warum wird Parallel Computing immer wichtiger?

• Was genau verbirgt sich hinter Parallel Studio?

• Was kommt alles auf Entwickler mit Visual Studio 2010 und .NET 4 zu?

• Wer braucht Intel Threading Building Blocks?

Deshalb: Popcorn und Coke bereitstellen, Füße hochlegen und Videos gucken. Und zwar welche der lehrreichen Sorte, Powerpoint-Folien inklusive.

>> Los ging es mit den bekannten Multithreading-Konzepten OpenMP, APIs und Intel Threading Building Blocks und der Frage, welche der drei Methoden sich zum Threaden am besten eignet.

>> Dann folgten fünf Multicore-Programmierregeln, die zeigen sollen, mit welchen Anforderungen Programmierer und Software-Entwickler konfrontiert werden, wenn sie sequenziellen Code in parallele Anwendungen überführen wollen. Ich sage nur: Denke parallel!

>> Ein wichtiges, weil fundamentales Konzept der Multicore-Programmierung ist der Unterschied zwischen Daten- und Aufgabenparallelität. Diesen zu verstehen ist die erste Programmiererpflicht, wenn es darum geht, skalierbare Multithread-Anwendungen zu erstellen.

>> Wie viele Schritte muss man gehen, um aus seriellem Quellcode parallel ablaufenden zu machen? Genau vier. Rein abstrakt betrachtet zumindest. Auch hierfür habe ich den passenden Workshop parat, der die vier Stufen der Parallelprogrammierung genauer beleuchtet.

>> Was aber, wenn ich zwar weiß, wie ich parallel programmieren soll, ich aber keinen Schimmer davon habe, welche Stolperfallen dabei auf mich warten? Da heißt es dann meinen Beitrag lesen, welche Fehler bei der Parallelprogrammierung der Entwicklergemeinde drohen und wie sich diese (die Fehler, nicht die Entwickler) umgehen lassen.

>> Von OpenMP war hier zwar schon mal die Rede, aber nur ganz oberflächlich. Wie gut, dass der Kollege Preiss einen kompletten Artikel zu dem Thema verfasst hat, den ich freundlicherweise aufgreifen und in Teilen online stellen durfte. Das Ergebnis: der Workshop “Parallel Programmieren mit OpenMP”. Sehr anschaulich, sehr lehrreich, sehr beispielhaft.

>> Was ist eigentlich ein Threadmodus und welche Zustände kann dieser annehmen? Mit dieser Frage beschäftigt sich ein Workshop, den ich Ende Februar veröffentlicht habe. Nur mal so vorab: Bereit, Wartend, Beendet.

>> Von der OOP 2009 und dem Vortrag Klaus Bodes von Microsoft inspiriert, wagte ich mich Anfang März an einen Vierteiler, der den Titel “”Alles über .NET-Threads” trägt. Genauer gesagt: Unter .NET 4. Im ersten Teil geht es um das Erzeugen von Threads, der zweite beschäftigt sich mit der Thread-Verwaltung, der dritte steht ganz im Zeichen von Threadpools und der vierte handelt vom Synchronisieren mehrerer Threads und atomarer Aktionen.

Dann folgten Mitte April zwei weitere, detaillierte Workshops zum Thema OpenMP: fünf Bedingungen für parallele Schleifen und Schleifen anpassen für Multithreading-Ausführung. Beide Tutorials sind randvoll mit nützlichen Infos und praktischen Tipps. Eben ganz nach meinem Geschmack …

Zunächst einmal: Das Threaden von Schleifenkonstrukten bedeutet nichts anderes, als dass unabhängige Schleifeniterationen auf mehreren Threads gleichzeitig ausgeführt werden können, was natürlich Rechenzeit pro Takt spart. Hierzu wird die Schleife in eine neue Form gebracht, die das Parallelisieren derselben überhaupt erst ermöglicht. Dies ist aber nur umsetzbar, wenn die Schleife keine Abhängigkeiten aufweist.

Daher muss man als Entwickler zunächst einmal mit einem passenden Tool wie VTune Performance Analyzer diejenige Schleife finden, die insgesamt die meiste Rechenzeit verschlingt. Anschließend wird diese umstrukturiert, um festzustellen, dass keine iterationsübergreifenden Abhängigkeiten bestehen. Erst dann sollte diese Schleife mithilfe eines OpenMP-Pragmas parallelisiert werden.

Dabei geht es um bereits dargestellte Datenabhängigkeiten, die in Data Race Conditions oder Dead Locks münden können. Man unterscheidet zwischen drei wesentlichen Abhängigkeiten:

Flussabhängigkeit (Schreiben-vor-Lesen): Eine Anweisung ist von einer anderen abhängig, wenn der erste Befehl ein Datum speichert, das der nachfolgende lesen will.

Ausgabeabhängigkeit: Zwei Befehle speichern in dieselbe Speicherzelle ihre Daten.

Antiabhängigkeit (Lesen-vor-Schreiben): Ein Befehl liest ein Datum, bevor dieses überhaupt gespeichert wird.

Um zu zeigen, wie sich das Umstellen von Schleifencode auf die richtige Ausführung des gesamten Programms auswirkt, folgen an dieser Stelle zwei Beispiele: ein nicht-funktionierendes und ein OpenMP-taugliches.

Nicht-funktionierende OpenMP-Schleife wegen einer iterationsübergreifenden Abhängigkeit!

x[0] = 0;
y[0] = 1;
#pragma omp parallel for private(k)

……for ( k = 1; k < 100; k++ ) {
……….x[k] = y[k-1] + 1; // Operation 1
……….y[k] = x[k-1] + 2; // Operation 2

….. }

OpenMP-basiertes Threading mittels einer Strip-Mining-Transformation

x[0] = 0;
y[0] = 1;
x[49] = 74; // abgeleitet von der Gleichung x(k)=x(k-2)+3
y[49] = 74; // abgeleitet von der Gleichung y(k)=y(k-2)+3

#pragma omp parallel for private(m, k)

…..for ( m=0; m<2; m++ ) {
……….for ( k = M*49+1; k < m*50+50; k++) {

……….….x[k] = y[k-1] + 1; // Operation 1
…………..y[k] = x[k-1] + 2; // Operation 2
……..}
….}

Daher starten wir heute mit einer Serie, die sich mit kleineren und größeren Aspekten der OpenMP-basierten Programmierung beschäftigt. Also mit solchen Fragen wie:

• Welche Bedingungen müssen erfüllt sein, damit OpenMP-basierende Schleifen überhaupt in parallelen Threads ausgeführt werden können?
• Welche Dinge sind zu beachten, damit eine Schleife ordnungsgemäß in mehrere Threads aufgeteilt werden kann?
• Wie lässt sich möglicher Threading-Overhead vermeiden?
• Wie kann man das Optimum aus OpenMP herausholen?
• Wie lassen sich sinnvoll OpenMP-Bibliotheksfunktionen und -Umgebungsvariablen einsetzen?
• Wie geschieht das Kompilieren und Debuggen mithilfe von OpenMP?
• Wovon hängt eine maximale Multithread-Leistung auf OpenMP-Basis ab?

Welche Bedingungen müssen erfüllt sein, damit OpenMP-basierende Schleifen überhaupt in parallelen Threads ausgeführt werden können?

1. In der Version 2.5 müssen Schleifenvariablen vom Typ vorzeichenbehafteter Integer sein. Mit der OpenMP-Spezifikation 3.0 ist diese Beschränkung weggefallen.

2. Die Vergleichsoperation muss in der Form loop_variable <, <= oder >= loop_invariant_integer sein.

3. Der Inkrementteil (z.B. i++) der for-Schleife muss additiv oder substraktiv sein, und zwar mit einem schleifeninvarianten Wert.

4. Ist die Vergleichsoperation vom Typ < oder <=, muss die die Schleifenvariable bei jeder Iteration erhöht werden. Umgekehrt muss die Variable dekrementiert werden (also bei > oder >=).

5. Die Schleife muss zwingend einen Eintritt und einen Austritt haben. Daher sind nicht erlaubt: Sprünge aus der Schleife heraus bzw. von außen in die Schleife hinein. Das gilt beispielsweise für goto- oder break-Anweisungen oder für Ausnahmebehandlungen. Eine Ausnahme dieser Regel stellt die exit-Anweisung dar, die die komplette Anwendung beendet.

Diese Bedingungen müssen aus Kompilierungsgründen eingehalten werden. Andernfalls kann keine automatische Parallelisierung erfolgen.

Zunächst einmal kann man festhalten, dass die Thread-Synchronisierung im .NET-Framework ähnlich funktioniert wie im Win32- oder Pthreads-Umfeld. Es geht also um den gegenseitigen Ausschluss sowie um atomare Aktionen auf spezielle Variablen. Wie bei der von C# bekannten Methode lock wird ein Codeabschnitt mithilfe der geschweiften Klammern geblockt, sodass zu dieser Zeit nur ein einziger Thread darauf zugreifen kann. Hierfür bietet das .NET-Framework eine ähnliche Konstrukte:

Monitor.Enter ( this )
try
{
……. shared_var = other_shared_var +1;
……. other_shared_var = 0;
}
finally
{
…… Monitor.Exit ( this )
}

Mit der Klasse Monitor wird der entsprechende Codeabschnitt blockiert. Mit Enter() wird der Abschnitt gesperrt und mit Exit() wieder freigegeben. Praktisch an Monitor ist auch dessen Möglichkeit, Datenstrukturen als Parameter zu übergeben.

Bei Monitor.Enter() geschehen übrigens zwei Dinge: Erstens wird eine Warteschlange eingerichtet, die auf diejenigen Threads verweist, die gesperrt werden sollen und eine zweite Queue mit Threads, die darüber informiert werden wollen, wenn eine Speere verfügbar ist. Monitor.Exit() sorgt dafür, dass der erste verfügbare Thread in Warteschlange #1 gesperrt wird.

Darüber hinaus hält die Klasse Monitor eine weitere Methode bereit: So lässt sich mit Monitor.Wait() die Sperre eines Threads auf einen anderen Thread übertragen, um die Sperre später wieder zurückzuverlangen. Ein Impuls benachrichtigt hierbei den ursprünglichen Thread darüber, dass die Sperre wieder aufgehoben wurde.

Neben den Monitor-Methoden lassen sich unter .NET auch Mutexe für das Sperren und Freigeben von Threads verwenden. Im Gegensatz zu der Monitor-Klasse werden Mutexe in Verbindung mit Handles eingesetzt und können zudem zudem für mehrere Sperren eingesetzt werden, die dann natürlich genauso oft wieder freigegeben werden.

private static Mutex mutx = new Mutex();
…

private static void UseResource()
{
……//Warten, um in den Sperrcode einzutreten
……mutx.WaitOne();

……Console.WriteLine( ” im gesperrten Modus “);

……Thread.Sleep( 100 ); // 100 Millisekunden warten

……Console.WriteLine( ” den gesperrten Modus wieder verlassen “);

……// Mutex wieder freigeben
……mutx.ReleaseMutex();

}

Atomare Aktionen
Unter atomaren Aktionen versteht man landläufig unteilbare Maschinenanweisungen, wie sie beispielsweise für Datenbankoperationen eingesetzt werden. Dabei ist es von essenzieller Wichtigkeit, dass mehrere dieser Teilschritte zurückgenommen werden können, falls der gesamte Schritt nicht beendet werden kann. Bei Threads verhält es sich ganz ähnlich: Variablen werden verändert und gleichzeitig geht beim Programmablauf etwas schief. Die Folge: Das System ist im schlimmsten Fall beschädigt oder Daten korrupt.

Um so etwas auszuschließen, hat Microsoft in das .NET-Framework die Klasse Interlock eingebaut, die drei wesentliche Methoden vorsieht: Decrement, Increment und Exchange. Diese sollten vor allem dann eingesetzt werden, wenn eine bestimmte Variable von mehreren Threads parallel genutzt wird:

int intCounter = 0;
…

Interlocked.Exchange( ref usingResource, 6 ); // Setze den Wert von intCounter auf 6

Interloced.Decrement( ref intCounter ); // Reduziere den Wert von intCounter auf 5

Interlocked.Increment( ref intCounter ); // Erhöhe den Wert von intCounter wieder auf 6

Beachtenswert ist die Tatsache, dass mit Increment und Decrement nicht die Variable selbst, sondern nur der Verweis darauf verändert wird (da es sich dank des Zusatzes ref um eine Art Zeiger handelt). Und Exchange ändert nicht die Werte, sondern initialisiert lediglich einen Wert mit einem anderen.

Zunächst einmal sollte man sich klar machen, dass das Erzeugen und Verwalten von .NET-Threads mit einem immensen administrativen Aufwand verbunden ist: Lokaler Thread-Speicher muss angelegt und die Systemstrukturen für die Thread-Verwaltung müssen eingerichtet werden. Darüber hinaus nimmt die Komplexität des Quellcodes deutlich zu, sobald mehrere Threads mit Bordmitteln verwaltet werden sollen.

Aus diesem Grund hat Microsoft dem .NET-Framework ein Ressource spendiert, die sich ThreadPool nennt. Dabei wird zunächst eine bestimmte Anzahl von Threads generiert, außerdem wird eine Art Arbeitswarteschlange erstellt. Sobald eine auszuführende Aufgabe in diese Warteschlange befördert wird, wird ein Thread für diesen Task aktiviert und ihm die Aufgabe zugewiesen. Dies erledigt das .NET-Framework automatisch. Allerdings ist dabei zu beachten, dass der ThreadPool nur dann sinnvoll eingesetzt werden kann, wenn ein Programm aus mehreren Threads besteht, die immer wieder benötigt werden.

Der Pool wird mithilfe der Anweisung ThreadPool.QueueUserWorkItem (new WaitCallback ( DELEGAT ) ) erzeugt, sobald die erste Aufgabe an die Warteschlange übergeben wird. Die Anzahl der im Pool erzeugbaren Threads ist unter .NET auf 25 pro Hardware-Prozessor begrenzt. Allerdings kann man mithilfe der Methoden GetMinThreads() und SetMinThreads() die minimale Anzahl von Threads abfragen bzw. erzwingen. Mit GetMaxThreads() lässt sich die maximale Anzahl von Threads bestimmen.

Mit den ThreadPools in .NET lassen sich aber nicht nur Aufgaben parallel ausführen, sondern auch asynchrones Warten erzwingen. So kann beispielsweise auf einen Datenanfrage innerhalb des Netzwerks reagiert werden. Hierfür ist eine sogenannte Callback-Funktion erforderlich, die beim Eintreten eines zu erwartenden Ereignisses aufgerufen wird. Eine dieser Funktionen nennt sich RegisterWaitForSingleObjekct(), die die Angabe einer maximalen Wartezeit erlaubt. Die Callback-Funktion wird aufgerufen, wenn das Ereignis eintritt oder die definierte Wartezeit abgelaufen ist.

Aber nicht nur einzelne Ereignisse können Threads starten, sondern auch eine ganze Reihe davon. Hierfür existieren die Methoden WaitHandle.WaitAll() und WaitHandle.WaitAny(), die ausgeführt werden, wenn alle Ereignisse oder irgendein Ereignis eintreten. Zudem lassen sich diese manuell mithilfe der Methode ManualResetEvent() zurücksetzen.

Beenden von Threads: Dies geschieht am einfachsten, indem ein Thread ganz regulär während des Programmablaufs verlassen wird und die Anwendung wieder zum Masterthread zurückkehrt. Dies gibt der Common Language Runtime (CLR) die Möglichkeit, die notwendigen Aufräumarbeiten durchzuführen. Allerdings muss manchmal ein anderer als der gerade laufende Thread beendet werden. Daher hat Microsoft den .NET-Thread-APIs eine Methode spendiert, die sich Abort() nennt, mit deren Hilfe ein laufender Thread abgebrochen werden kann. Beim Aufruf von Abort() wird automatisch eine ThreadAbortException ausgelöst.

Der Aufruf von Abort() zieht übrigens eine Reihe verschiedener Dinge nach sich. Dazu gehört die Fähigkeit des Threads, den eigenen Abbruch zu vereiteln, indem er innerhalb des Exception-Handlers die Methode System.Threading.Thread.ResetAbort aufruft. Daneben besteht die Möglichkeit, innerhalb eines Codeblocks mithilfe von finally weiteren Quellcode ausführen zu lassen, was im ungünstigsten Fall eine beachtliche Verzögerung des Thread-Abbruchs nach sich zieht. Aus diesen beiden Gründen sollte man zur Laufzeit überprüfen, ob ein bestimmter Thread auch vollständig abgebrochen wurde. Hierfür steht die Join-Methode zur Verfügung.

Auf einen Thread warten: Die parallele Ausführung mehrerer Threads innerhalb eines Programmes bringt es zwangsläufig mit sich, dass Threads immer wieder aufeinander warten müssen. Um dies zu erreichen, hat Microsoft dem .NET-Framework die Thread-Methode Join() verpasst, was ein Zusammenführen zweier Threads bedeutet. In der Konsequenz heißt das, dass ein Thread mit seiner Fortsetzung so lange wartet, bis ein vorhergehender Thread fertig ist. Da dies zu unliebsamen Nebeneffekten führen kann (Stichwort: Dead Lock), besteht die Möglichkeit, Join() einen Parameter zu übergeben, der einen Integerwert darstellt. Dieser Wert besagt, wie lange gewartet werden soll, bis der Vorgänger-Thread (voraussichtlich) beendet wird. Das Ergebnis von Join() ist ein boolscher Wert, der true (Thread beendet) oder false (Thread nicht beendet) annehmen kann.

Threads anhalten und fortsetzen: Im Gegensatz zur Methode Sleep(), mit der ein Thread für eine festgelegte Zeitdauer angehalten und automatisch fortgesetzt wird, besteht eine weitere Möglichkeit, einen Thread auf unbestimmte Zeit zu stoppen und zu einem späteren Zeitpunkt wieder aufzunehmen. Die hierfür zuständigen Methoden nennen sich Suspend() und Resume(). Beiden Methoden kann kein Argument übergeben werden und beide liefern auch keinen Rückgabewert.

Das alles werde ich ab heute in Form einer Miniserie mit der Überschrift “Alles über .NET Threads” nachholen. Der erste Teil beschäftigt sich mit dem Thema “Threads erzeugen”.

Da die .NET-APIs etwas “schlanker” sind als ihre Win32-Brüder und -Schwestern, gestaltet sich das Erzeugen eines .NET-Threads relativ einfach. Dies sieht wie folgt aus:

using System.Threading;

[Definition von Variablen]

Thread t = new Thread( new ThreadStart( ThreadFunc ));

Der Aufruf von ThreadStart() erzeugt einen neuen Thread. Der Parameter ist eine Delegat namens ThreadFunc. Übrigens: In C# ist ein Delegat identisch mit der Adresse einer Funktion in C. Der Thread endet dann an der Stelle, sobald ThreadFunc() endet. Doch damit nicht genug. Für eine fehlerfreie Ausführung des Threads muss weiterer Code implementiert werden:

t.Start() — Dies startet den Thread unter .NET explizit (was z. B. unter Win32 nicht erforderlich ist).

Thread.Sleep( 40 ) — Dies unterbricht den (seriellen) Hauptthread für die Dauer der Zeiteinheit in der Klammer, die in Millisekunden angegeben wird. Dies kann in der Praxis jedoch erheblich von der tatsächlich benötigten Zeit abweichen.

[aufzurufende Funktion] — Diese Funktion wird parallel auf den vorhandenen Prozessorkernen ausgeführt.

Thread.Sleep( 0 ) — Dies beendet den parallelen Thread und reaktiviert den “schlafenden” Hauptthread.

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.

Zunächst einmal: OpenMP liegt in der Version 3.0 vor und stellt eine standardisierte Programmierungsmethode dar. In Sachen Komplexität bewegt sie sich zwischen den herkömmlichen Threads – also API-Threads, PThreads oder WinThreads – und den höher entwickelten Intel TBB oder der geplanten Parallel Pattern Library (PPL), die von Microsoft kommen wird.

Daraus ergeben sich zwei wesentliche Aspekte: OpenMP ist weitaus einfacher zu verstehen, zu implementieren und zu testen als die Low-Level-Threads, bei denen sich der Programmierer um viele Dinge selbst kümmern muss, was das Ganze natürlich extrem fehleranfällig macht.

Die Kehrseite von OpenMP ergibt sich aus der geringeren Komplexität: Nicht alle Programmieraufgaben lassen sich mit OpenMP erledigen, was den Entwickler natürlich ein wenig einschränkt. OpenMP versteht sich vor allem sehr gut auf das Parallelisieren von rechenintensiven Schleifenkonstrukten.

Doch für welche Projekte eignet sich OpenMP am besten? Nun, hier ist vor allem der inkrementelle Ansatz zu nennen. Hierbei wird Stück für Stück ein bestehendes seriell programmiertes Programm mit einem geeigneten Tool wie dem VTune Performance Analyzer auf sein Parallelisierungspotenzial hin untersucht, um so schrittweise sequenziellen Programmcode in parallelen zu überführen. Das Gute dabei ist die Tatsache, dass es einen Masterthread gibt, der die sequenzielle Programmausführung steuert.

Sobald die Anwendung an einen Punkt kommt, wo es simultan werden kann, verzweigt die Ausführung in eine feste Anzahl von Threads. Wenn dieser Programmteil beendet ist, verzweigt die Anwendung wieder in den sequenziellen Masterthread. Ein weiterer Vorteil von OpenMP ist die Möglichkeit, bei der Programmausführung die parallelen Code-Abschnitte per “Schalter” zu deaktivieren, um somit aufgetretene Fehler im Seriellmodus zu debuggen. Das erleichtert das Auffinden vorhandener Bugs ungemein.

Die Implementierung von parallelem Code auf OpenMP-Basis ist übrigens recht einfach: Hierzu stehen dem Programmierer bestimmte Derektiven (Pragmas), die OpenMP-Bibliothek und Umgebungsvariablen zur Verfügung. Bei der Überführung von seriellem in parallelen Programmcode müssen dann nur ein paar Programmzeilen eingefügt werden. Das ist unter anderem die Bibliothek omp.h, die passende Anzahl von Threads sowie einer Umgebungsvariablen und die Pragma-Anweisung selbst, die sich um das Parallelisieren des vormals seriellen Programmcodes kümmert.

Das nachfolgende Beispiel berechnet mithilfe einer Integralfunktion die Kreiszahl Pi. Die blau eingefärbten Programmzeilen sind die hinzugefügten OpenMP-Variablen sowie das zugehörige Pragma. Übrigens: Nur der in den geschweiften Klammern stehende Programmteil wird parallel ausgeführt. In diesem Fall also die Formel, die iterativ Pi ermittelt.

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.

1. Untersuche! Und zwar den gesamt Quellcode auf potenzielle Parallelisierung hin. Hierfür eignen sich vor allem Schleifenkonstrukte, die beispielsweise eine große Menge an Daten berechnet, was oft simultan geschehen kann. Es geht aber auch um “Hotspots”, die es in jedem Programm gibt und die die Leistungsfähigkeit der Anwendung negativ beeinträchtigen können. Um diese Untersuchungen möglichst effizient durchzuführen, gibt es spezielle Tools wie den VTune Performance Analyzer, der genau für diese Aufgaben geschaffen worden ist.

2. Kodiere! Und zwar parallel. Nachdem die passenden Programmstellen identifiziert worden sind, beginnt die eigentliche Arbeit, nämlich die des Kodierens. Packen Sie also all den parallelen Code in Ihr Programm, von dem Sie glauben, dass er Ihre Anwendung schneller macht, da sie von den vorhandenen Prozessorkernen profitiert. Und Sie können es sich dabei ein wenig leichter machen, indem Sie auf Tools zurückgreifen, die Ihnen mithilfe vorgefertigter Routinen und Bibliotheken dabei helfen. Dies können einfache Anweisungen paralleler Schleifenkonstrukte sein, aber auch komplexe Funktionen für Multimedia- oder Wissenschaftsanwendungen.

3. Debugge! Nachdem der Quellcode Ihrer Anwendung möglichst gut für die parallele Ausführung optimiert worden ist, steht noch eine Menge Debug-Arbeit auf dem Plan. Auch hierfür gibt es die passenden Tools, denn nur schwer auffindbare Fehler wie Dead Locks oder unvorhersehbare Race Conditions lassen sich mit einfachen Testmethoden gar nicht oder nur sehr aufwendig identifizieren. Ziehen Sie hierzu am besten die passenden Tools zu Rate wie den Thread Checker, der genannte Fehlerquellen aufdeckt und Ihnen genau sagt, welche Quelltextstellen kritisch bzw. fehleranfällig sind.

4. Optimiere! Jetzt haben Sie es fast geschafft, aber noch können Sie sich nicht sicher sein, dass Ihre Multicore-Anwendung auch wirklich optimal läuft. Denn noch können einzelne Codeteile den gesamten Programmablauf ausbremsen, da beispielsweise die Speicherverwaltung nicht effizient erfolgt oder die Anwendung nicht richtig skaliert. Das bedeutet im schlimmsten Fall, dass Ihre Software zwar auf einem Dualcore-Rechner perfekt läuft, es auf einer Quadcore-Maschine aber permanent zu Wartezeiten kommt, da mehr Threads zur Laufzeit erzeugt werden als Prozessorkerne vorhanden sind. Auch für diese Zwecke gibt es die entsprechenden Tools: den schon erwähnte VTune Analyzer, aber auch den Intel Thread Profiler, der die Effizienz des parallelisierten Code grafisch darstellt und Ihnen so hilft, Schwachstellen schneller und leichter zu lokalisieren.

Die eine Form der parallelen Programmierung orientiert sich an den zu verarbeitenden Daten, die zur Laufzeit der Anwendung anfallen. Ein gutes Beispiel für die Datenparallelität ist das Rendern eines Bildes, das aus vielen tausend Bildpunkten besteht, die sich unabhängig voneinander berechnen, zeichnen oder mit einem Filter versehen lassen.

Darin steckt also eine Menge an Multicore-Potenzial, wofür sich der Einsatz von OpenMP oder Intel TBB empfiehlt. Ein weiteres gutes Beispiel ist die Rechtschreibprüfung eines Textverarbeitungsprogramms. Hier können sämtliche Wörter simultan überprüft werden, da sie zueinander in keiner Abhängigkeit stehen.

Auf der anderen Seite existiert der Aufgabenparallelismus, der voneinander getrennte Aufgaben betrachtet, die sich vortrefflich parallel ausführen lassen. Ein gutes Beispiel hierfür ist Outlook, das aus unterschiedlichen Modulen besteht (Adressen, Kalender, E-Mail etc.), die sich grundsätzlich unabhängig voneinander ausführen lassen und damit auf separaten Prozessorkernen laufen können.

Probleme treten hier vor allem dann auf, wenn die unterschiedlichen Programmteile auf denselben Datenbestand zugreifen, was zu ungewollten, falschen oder nicht vorhersagbaren Datenkonflikten führen kann. Gerade hier sind passende Tools wie die Intel Threading Building Blocks von großer Bedeutung, da diese zum einen Aufgaben in Threads verwandeln und sich zum anderen um die parallele Speicherverwaltung kümmern.

In der Praxis trifft man natürlich sehr häufig auf eine Mischform von Aufgaben- und Datenparallelismus, das so genannte Pipelining. Hierbei ist die Anwendung in viele unterschiedliche Aufgaben unterteilt, innerhalb derer Daten parallel verarbeitet werden können. Ein bekanntes Beispiel hierfür ist wieder die Bildbearbeitung: Ein Bild wird geöffnet, mit einem Filter versehen, in eine andere Auflösung skaliert und abschließend gespeichert.

In allen genannten Fällen werden jeweils viele tausend Pixel berechnet, und die Aufgaben können teilweise parallel, teilweise aber nur sequenziell ausgeführt werden. Außerdem ist die Gefahr von Datenkonflikten recht hoch. Gerade im Falle des Pipelining ist die Wahl der besten Programmiermethode von entscheidender Bedeutung. Denn in den allermeisten Fällen ist eine 100-Prozent-Parallelisierung von Software weder möglich noch sinnvoll.

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 …

OpenMP: Diese Threading-Methode ist relativ simpel zu handhaben, da in den Quellcode sogenannte Pragmas eingebaut werden, die der jeweilige Compiler richtig interpretieren kann – oder auch nicht. OpenMP eignet sich vor allem für die Parallelisierung einfacher Schleifenkonstrukte und prozeduraler Datenstrukturen. Aufgrund seiner Historie lässt sich OpenMP gut in nativen Programmierumgebungen (C++ und Fortran) einsetzen, dafür leider gar nicht in managed Code (C#, .NET).

Threading-APIs: Spezielle Threading-APIs wie Win32- oder POSIX eignen sich nicht so gut zum Implementieren von Parallel-Code. Dabei werden die Multithreading-Konstrukte in eigenen Funktionen verpackt. Die Ergebnisse werden dann als Pointer übergeben, und hier steckt die Schwierigkeit bei der Arbeit mit Threading-APIs: Funktionsprototypen und Datenstrukturen müssen aufwendig modifiziert werden, was häufig die Abstraktion des Codes und das Programmdesign zerstört. Außerdem muss man sich als Programmierer selbst um das Erzeugen, Verwalten und Synchronisieren der Threads kümmern, was sehr mühsam ist. Daneben unterstützen Threading-APIs C++ nur sehr schlecht und oft gar nicht.

Intel Threading Building Blocks: Hierbei handelt es sich um eine C++-Bibliothek, die ähnlich wie die Standard Template Library eines herkömmlichen Compilers aufgebaut ist. Die Intel TBB stellen hochentwickelte Abstraktionsmodelle zur Verfügung, um eine flexible Programmierung zu ermöglichen. Das bedeutet, dass beispielsweise Iteratoren, die in Container verpackt sind, mithilfe der Intel TBB relativ einfach parallelisiert werden können.

Die Idee hierbei ist recht simpel: Anstatt Threads spezifiziert man einzelne Aufgaben (Tasks), die der TBB Scheduler auf die vorhandenen Hardware-Threads abbildet. Man muss sich also nicht mehr um die Synchronisation der Threads und ähnliches kümmern. Außerdem skaliert eine mithilfe der Intel TBB parallelisierte Anwendung sehr gut, da je nach verfügbaren Prozessorkernen und damit verbundenen Threads die Software um ein Vielfaches schneller ausgeführt werden kann.