Soll heißen, dass Sie als Entwickler nicht mehr in Threads denken müssen (was viel zu fehleranfällig und umständlich und wenig skalierend ist), sondern nur noch in Tasks, also in Aufgaben. Und diese Aufgaben werden möglichst automatisch auf die vorhandenen Ressourcen, sprich Prozessoren beziehungsweise Prozessorkerne beziehungsweise Threads, von den zugrunde liegenden Mechanismen verteilt.

Diese Herangehensweise hat zahlreiche Vorteile, von denen ich die vier wichtigsten herausgepickt habe und Sie mit Ihnen teilen möchte.

1. In die Zukunft gerichtet: Auf Basis eines task-basierten Designs ist der zugrunde liegende Algorithmus so aufgebaut, dass er auch in Zukunft bestmöglich skaliert, da sich sämtliche Aufgaben beliebig auf 4, 8, 16, 32, etc. Prozessorkerne verteilen lassen. Falls Sie also zum Beispiel eine Bildbearbeitungssoftware entwickeln, die task-basiert arbeitet, können Sie sicher sein, dass ein sehr großes Bild von einer größeren Anzahl von Tasks manipuliert wird. Und die hierfür zuständige Bibliothek kümmert sich dann um eine ausgewogene Berechnung auf allen verfügbaren Ressourcen.

2. Minimaler Overhead: Alle erwähnten Bibliotheken haben eines gemeinsam: sie arbeiten mithilfe von Threadpools, in denen sämtliche Threads erzeugt, verwaltet und gelöscht werden. Das Gute am zugehörigen Thread Manager ist dessen Flexibilität: er lässt sich so einstellen, dass nicht ständig neue Threads erzeugt und wieder gelöscht werden, wenn es viel sinnvoller und effizienter ist, die Threads “am Leben” zu halten und bei Bedarf wieder aufzuwecken. Das sorgt nämlich für den geringsten Overhead.

3. “Lokale” Cache-Inhalte: Intel TBB und Konsorten verfügen über einen Mechanismus, der es zumindest teilweise ermöglicht, jeden Task genau auf dem Prozessorkern laufen zu lassen, wo sich die lokalen Task-Cache-Daten befinden. Dies gelingt zwar nicht vollständig, aber gerade Intel TBB und Intel Cilk Plus sind in dieser Disziplin ziemlich gut.

4. Dynamischer Scheduler: Was ist der Tod eines ausgewogenen Multicore-Systems? Genau, es gibt Ressourcen, die wegen Unterbeschäftigung brach liegen, und andere, die die ganze Arbeit verrichten müssen. Das Zauberwort hierfür nennt sich dymanisches Schedulen der Threads, was von Intel TBB und Co. zur Laufzeit vorgenommen wird. Damit können Sie sich sein, dass Ihre Software auf einem Mehrkernsystem optimal skaliert.

Sollten Sie Fragen zu Cilk Plus haben, auf Fehler oder Probleme bei der Bedienung stoßen, wenden Sie sich bitt an das Intel Cilk Plus Forum. Dort finden Sie auch Hinweise zu aktuellen Patches wie dem aktuellen Cilk Plus Patch for gcc 4.7 vom 31.8.2011.

Damit festigt Intel das Ziel, allen Programmierern auf Basis von C/C++ eine gleichermaßen einfache und effektive Programmiersprache beziehungsweise Extensions an die Hand zu geben, die dabei hilft, parallelen Code zu entwickeln. Seit 2009 hat Intel die Cilk-Technologie in eigene Produkte integriert und zu Cilk Plus weiterentwickelt, um sein Portfolio mit OpenMP und den Threading Building Blocks abzurunden.

Ähnlich wie bei OpenMP kennt Cilk Plus so genannte Keywords (spawn, sync, inlet, abort), mit deren Hilfe sich ein seriell programmierter Quellcodeabschnitt in ein parallel ablaufendes Konstrukt verwandelt. Ein beliebtes und oft verwendetes Beispiel ist die rekursive Berechnung von Fibonacci-Zahlen. Hier ein Code-Sample:

01 cilk int fib (int n)
02 {
03     if (n < 2) return n;
04     else
05     {
06             int x, y;
07
08             x = spawn fib (n-1);
09             y = spawn fib (n-2);
10
11              sync;
12
13              return (x+y);
14     }
15 }

Die entscheidenden Schlüsselwörter lauten spawn (Zeile 8 und 9) und sync (Zeile 11). Diese Keywords sorgen dafür, dass die Funktion parallel auf zwei oder mehreren Prozessorkernen ausgeführt wird. Den Rest übernimmt die Runtime von Cilk Plus, die sich um das Erstellen von Threads kümmert, um das Synchronisieren derselben und um das richtige Beenden der parallel laufenden Threads. Dies ist auch der große Unterschied zu OpenMP.

Einen sehr guten Grundlagenartikel zu den Unterschieden zwischen OpenMP und Cilk liefert Michaels Beitrag vom Juli 2010: Infos aus erster Hand zu Cilk.

Zudem empfehle ich James Reinders’ Blog-Beitrag Parallelism as a First Class Citizen in C and C++, the time has come, in dem er die Bedeutung von Task-Parallelisierung und Daten-Parallelisierung verdeutlicht und zeigt, wie sich beide Programmieraufgaben mit Cilk Plus realisieren lassen.

min / max: Mit diesen beiden neuen Operatoren sind Entwickler nicht mehr dazu gezwungen, eigene Workarounds zu bauen, um zugehörige parallele Reduktionskonstrukte zu entwerfen. Solche Konstrukte sind beispielsweise beim Ermitteln der Kreiszahl Pi von großem Vorteil. Zumal, wenn mit min-max-Operatoren die Unter- und Obergrenzen sehr einfach begrenzt werden können.

atomic: Mit dem erweiterten atomic-Konstrukt ist in Zukunft die Übergabe von Variablenwerten möglich, die beispielsweise mittels #omp pragma atomic während der Ausführung einer Schleife automatisch aktualisiert werden. Dies soll dynamische Scheduler ermöglichen, und zwar ohne den Einsatz zeitaufwändiger Locks und Kritischer Abschnitte (critical regions). Darüber hinaus ermöglicht das aktualisierte atomic-Konstrukt das explizite Speichern und Lesen von einzelnen Speicherzellen, die mit solch einem Konstrukt in Zusammenhang stehen.

Task-Konstrukte: Auch das Task-Modell von OpenMP wurde optimiert. So sollen Entwickler mit dem neuen Konstrukt taskyield eigene Scheduler-Zeitpunkte definieren können. Damit kann man der OpenMP-Runtime mitteilen, dass ein bestimmter Task zugunsten eines anderen angehalten wird, um ihn später fortzusetzen.

Darüber hinaus lassen sich die Gültigkeitsbereiche der Daten innerhalb paralleler Task-Konstrukte noch genauer spezifizieren. Dazu wurden die neuen Attribute final und mergeable eingeführt. So kann mit Hilfe des Konstrukts #pragma omp task [final (ausdruck)] im Falle von ausdruck=true ein Task unmittelbar beendet werden. Das gilt dann auch für sämtliche Child-Tasks. Dies soll in Kombination mit dem Attribut mergeable zu feiner granulierten Parallelkonstrukten führen und zudem für einen geringeren Thread-Overhead sorgen

Falls Sie an der gesamten OpenMP-Spezifikation 3.1 interessiert sind: Hier finden Sie das passende PDF-Dokument dazu.

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.

Die Idee von Cilk ist recht einfach: Man erhält ein serielles Programm, wie man das schon von OpenMP kennt. Allerdings kann das mit OpenMP “unterwandert” werden, indem man Abhängigkeiten in den Code einbaut. Bei Cilk hingegen werden die zu parallelisierenden Codeteile einfach mithilfe bestimmter Spawn-Konstrukte ausgelagert. Zudem können die so parallelisierten Abschnitte wieder serialisiert werden, indem man die Spawn-Befehle einfach wieder aus dem Code herausnimmt. Daneben gibt es ein weiteres Cilk-Konstrukt, das mittels einer for-Methode Schleifen parallelisiert.

Das Tolle an Cilk ist der zugeghörige Scheduler, der sehr schlau ist und task-orientiert arbeitet, und nicht wie bei OpenMP thread-basiert. Dabei werden stets möglichst viele Tasks an den Scheduler übergeben, der diese mit einem intelligenten Algorithmus auf die vorhandenen Thread-Ressourcen verteilt. Der Scheduler ist übrigens derart skalierend, dass auch große Rechensysteme optimal ausgenutzt werden.

So skalierte ein cilk-optimiertes Schachprogramm auf einem Rechner mit 512 Kernen so gut, dass es den dritten Platz in einem großen Schachturniert belegte. Der Trick des Cilk-Schedulers besteht übrigens darin, dass die Tasks per Zufall auf die Threads verteilt werden und nicht nach “menschlichen” Kriterien. Ach ja: Das Work Stealing hat seinen Ursprung im Cilk-Scheduler und wurde sukzessive in die Microsoft-Scheduler eingebaut.

Daneben muss mit Cilk nicht darauf geachtet werden, dass die zu parallelisierenden Aufgaben (Tasks) logisch angeordnet sind. Einzige Voraussetzung für eine cilk-basierte Parallelisierung ist die Unabhängigkeit der Tasks zueinander, so dass jeder Task eine Spawn-Methode zugewiesen werden kann. Darüber hinaus dürfen die jeweiligen Codeabschnitte nicht von globalen Variablen abhängen beziehungsweise diese nicht modifizieren. Ansonsten bekommt man es ganz leicht mit Data Races zu tun.

Allerdings ist zu berücksichtigen, dass es mit Cilk wie bei OpenMP, TPL und PPL vor allem um eine Lastverteilung geht, und nicht um eine Verteilung von Funktionalitäten auf die vorhandenen Ressourcen.

Schön an Cilk ist auch die einfache Handhabung: Außer den beiden Spawn- und For-Konstrukten muss man nichts lernen, sodass selbst ungeübte C- und C++-Entwickler Cilk ziemlich schnell einsetzen können. Das Gute an Cilk ist auch seine Vorhersehbarkeit: Sobald das cilk-optimierte Programm vorliegt, kann man anhand der gegebenen Parameter genau berechnen, was die Parallelisierung in Sachen Rechenleistung bringen wird.

Eine Besonderheit an Cilk sind die sogenannten Hyperobjects, mit denen ein parallelisierter Codeabschnitt seine eigene Sicht auf globale Variablen bekommt. Soll heißen, dass jeder Thread seinen eigenen Zugriff auf die globalen Variablen erhält, ohne diese zu verändern, so dass es nicht zu Data Races kommen kann. Dabei wird das Ganze lock-frei realisiert, da für jeden Thread eine eigene Speicherzelle angelegt wird, deren Inhalte am Schluss wieder zusammen geführt werden, so dass das richtige Ergebnis in der globalen Variable steht. Praktisch an Hyperobjects ist auch die Tatsache, dass man eigene anlegen kann. Damit ist Cilk ein ganzes Stück flexibler als OpenMP oder TBB.

• 75 Prozent aller teilnehmenden Entwickler konnten bereits nach 15 Minuten sinnvolle und nachvollziehbare Ergebnisse produzieren.

• Ebenfalls 75 Prozent haben Parallel Studio als “empfehlenswert” eingestuft (8 von 10 Sternen im Mittel).

• 86 Prozent der teilnehmenden Betatester glauben, dass die Threading-Methoden von Parallel Studio (OpenMP, Intel TBB, etc.) für ihre Zwecke völlig ausreichend sind.

• 71 Prozent der Betatest-Entwickler konnten einen Geschwindigkeitszuwachs bei ihren Anwendungen messen, und das nur wegen des Umstiegs auf den integrierten Intel-C++-Compiler, der natürlich äußerst multithreading-tauglich ist.

Und es gibt sogar schon erste Referenzgeschichten, die den Einsatz von Parallel Studio in ein bestehendes Projekt verdeutlichen sollen. Dazu gehört beispielsweise die in Paris ansässige Firma Open Cascade, die die gleichnamige Opensource-Software entwickelt hat und für Kunden in deren Anwendungen integriert. Mit Open Cascade lassen sich komplexe und sehr aufwendige 3D-Modelle erstellen, wie sie beim Produktdesign, in der Simulationstechnik und in anderen Bereichen verwendet werden.

Da die Berechnung und grafische Umsetzung solcher 3D-Modelle sehr rechenintensiv und Open Cascade zudem C++-basiert ist, kam für mehr Leistung und schnellere Berechnungen Parallel Studio zum Einsatz. Schnell zeigte sich, dass der Parallel Amplifier typische Hotspots mit wenig Aufwand entdecken konnte. So ließ sich beispielsweise die Berechnung von geometrischen Flächen drastisch beschleunigen, indem dem betreffenden Algorithmus ein eigener Thread zugewiesen werden konnte, der bei Bedarf immer wieder parallel ausgeführt werden kann.

Aber auch der Parallel Inspector half dabei, Open Cascade zu verbessern und schneller zu machen. Das führte insgesamt zu einer doppelt so schnellen Rechengeschwindigkeit und einer Reduzierung von Speicherproblemen (Meomory Leaks).

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: 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.

Schon seinerzeit habe ich dagegen gesprochen, da sehr wohl Software-Werkzeuge existieren wie die Integrated Performance Primitives (IPP), die vor allem Entwickler von Multimedia-Software bei ihrer Arbeit unterstützen sollen. So basieren zahlreiche MP3- und AAC-Encoder/-Decoder auf Teilen der IPP-Bibliotheken, in denen übrigens viele Mannjahre Entwicklungsarbeit stecken.

Mit den IPP lassen sich einzelne Funktionen für das Encoden von Audio- und Videostreams mehr oder weniger per Drag & Drop für eigene Anwendungen nutzen, die dann bestimmte Aufgaben hochparallelisiert ausführen – ohne dass der Programmierer sich darüber Gedanken machen muss, wie dies funktioniert. Bekannte Beispiele hierfür sind H.264-, MPEG-4- und AAC-basierte Encoder.

Aber auch im medizinischen Bereich für die rechenintensive Auswertung von Ultraschallbildern kommen IPP-Bibliotheken zum Einsatz. Damit lassen sich hochkomplexe 3D-Bilder deutlich schneller analysieren, da die vorhandenen Prozessoren simultan die Berechnungen durchführen können. Somit spart der Einsatz der IPP im günstigsten Fall drei bis vier Mannjahre Entwicklungszeit, die das Programmieren solcher Parallel-Bibliotheken resp. der zugehörigen Anwendung in Anspruch nähmen.

Ein weiteres bekanntes Beispiel ist auch der Winzip-Codec, der mithilfe von IPP parallelisiert wurde und damit eine erheblich beschleunigte Kompression und Dekompression von Daten auf Multicore-Systemen ermöglicht. Hierbei kümmert sich IPP auf Basis von OpenMP (also mithilfe spezieller Pragma-Konstrukte) sogar um die Skalierung von Winzip, indem die einzelnen Threads möglichst gleichmäßig auf die vorhandenen Prozessorkerne verteilt werden.

Das Tolle an den IPPs sind auch die Anschaffungskosten: Es werden nämlich umgerechnet gerade mal 200 Dollar pro Entwickler fällig, dem für diesen geringen Betrag sämtliche vorgefertigte Funktionen zur Verfügung stehen. Unterstützt werden Window, Linux und Mac OS X, zudem gehört eine 30-Tage-Testversion zum Angebot und für nicht-kommerzielle Linux-Anwendungen kosten die Integrated Performance Primitives keinen einzigen Cent.

Mit dem Parallel Inspector lassen sich Multithread-Anwendungen in vielfältiger Weise debuggen. Es  geht allerdings um weit mehr als das bloße Aufspüren von Quellcode-Fehlern:

• Es spielt keine Rolle, welche Programmiermethode eingesetzt wird. Parallel Inspector unterstützt nämlich OpenMP (besser: er basiert darauf), kommt aber auch mit Intel TBB und Windows Threads klar.

• Fehler wie Dead Locks und Race Conditions werden zur Laufzeit gefunden, bevor sie der Kunde findet.

• Das Laufzeitverhalten wird vollständig aufgezeichnet, um so nachträglich und detailliert mögliche Fehler und Probleme innerhalb der parallelisierten Anwendung zu identifizieren.

• Im Gegensatz zu anderen Testtools können schwer auffindbare, nicht-deterministische Fehler mit Parallel Inspector aufgespürt werden.

• Pate des Parallel-Debuggers ist der Thread Checker. Damit bekommt man ein zuverlässiges, weil erprobtes Tool an die Hand zum Debuggen seiner Anwendungen.

• Parallel Inspector fügt sich nahtlos in Visual Studio ein.

Sobald die parallelisierte Anwendung auf Fehler hin überprüft und von denselben befreit werden konnte, schlägt die Stunde des Parallel Amplifier. Mit diesem Optimierungstool lassen sich folgende Dinge anstellen:

• Es bildet die zu optimierenden Quellcode-Bereiche grafisch so ab, dass sich das Skalierungspotenzial mit wenigen Blicken erfassen lässt.

• Kein Trail-and-Error mehr, da das Laufzeitverhalten zuverlässig vermessen und bewertet werden kann.

• Die Optimierungen finden auf einer abstrakten Ebene statt. Damit sind Kenntnisse über die zugrundeliegende Prozessorarchitektur oder des Assemblercodes überflüssig.

• Das Tool ist entstanden auf whatif.intel.com im Dialog zwischen Endanwendern und Intel-Ingenieuren.

• Parallel Inspector basiert auf dem Thread Profiler und VTune Performance Analyzer und steht damit für ein zuverlässiges Tool, das auf rund 15 Jahre Entwicklungsarbeit made by Intel zurückblickt.

• Vollständige Visual-Studio-Integration.

Und, immer noch wissenshungrig in Sachen Parallel Studio?! Dann solltet ihr morgen wieder vorbeischaun. Dann gibt es mehr dazu …

Der erste Teil handelt vom Parallel Composer, der mit einer Reihe nützlicher Tools die Parallelisierung serieller Anwendungen erleichtern soll. Hierfür bietet er

• vereinfachte Multithread-Funktionen, die allesamt auf OpenMP 3.0 basieren und als solche im Hintergrund eingesetzt werden

• Vektorisierungspragmas in Kombination mit den SSE2-/SSE3-/SSSE3- und SSE4-Befehlen

• OpenMP 3.0

• einfache Integration in die Entwicklungsumgebung von Microsoft Visual Studio

• Intel Parallel Debugger Extensions als Plugin für Visual Studio

• Intel Threading Building Blocks

• Lambda-Funktionen (nur C++) für den vereinfachten Austausch mit Intel TBB

• Intel Integrated Performance Primitives

• Unterstützung der Vektorschreibweise (arr[i])

• automatische Parallelisierung von Quellcode

• Diagnosetools, die beim Entwickeln von Multithread-Quellcode helfen

• zahlreiche Multithread-Beispiele mit dem entsprechenden Quellcode

Und am Montag gibt es dann mehr Infos zu Parallel Inspector und Parallel Amplifier ein anschauliches Beispiel, Infos zu OpenMP 3.0 und einiges mehr. Und die zusätzlichen Infos zu OpenMP und Co. gibt es am Dienstag …

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.

Diese Seite nennt sich go-parallel.com und berichtet in regelmäßigen Abständen über das parallele Multicore-Universum der Software-Entwicklung. Zu diesem Zweck ist die Seite in fünf Bereich unterteilt:  „Getting Started“, „Concurrent Programming“, „Community and Opinion“, „Tools and Tips“ und „Advanced Concepts“.

So findet man in „Getting Started“ hilfreiche Anleitungen, wie man beispielsweise eine komplette TBB-Umgebung unter Windows einrichtet und wie die Programmierung einer TBB-kompatiblen Anwendung funktioniert. Aber auch Themen wie OpenMP werden dort behandelt.

„Concurrent Programming“ führt dann das fort, was unter „Getting Started“ begonnen wurde. So lernt man Teile der Intel TBB besser kennen und wie man diese für seine eigenen Projekte schneller einsetzen kann. Wie zum Beispiel den Algorithmus „parallel_scan“, mit dessen Hilfe sich einzelne Programmabschnitte in ihre Einzelteile zerlegen lassen, damit diese parallel ausgeführt werden können, was natürlich die Leistung der Anwendung erhöht. Vor allem, wenn dies rekursiv geschieht.

Die Sektion „Community and Opinion“ lässt echte Profis zur Wort kommen. Wie Claire Cates, die für das Software-Unternehmen SAS arbeitet und die über ihre Erfahrung mit den Intel-Tools Thread Checker und Thread Profiler spricht, die ja beide Teil des VTune Performance Analyzer sind.

„Tools and Tips“ ist eine echte Fundgrube, wenn es um all die Intel-Tools geht, die Software-Entwicklern bei ihrer Arbeit helfen sollen. So erfährt man eine Menge über Intel Compiler und die Bibliothekssammlung Intel TBB, aber auch OpenMP ist Gegenstand dieses Abschnitts.

Mit „Advanced Concepts“ geht go-parallel.com noch einen Schritt weiter und stellt neue Technologien und Projekte vor, die Programmierer in der Zukunft unterstützen sollen. Aber auch von der Gegenwart ist die Rede: Wie man Software für Multicore-Plattformen schreibt, Programme auf Intel-Rechnern testet und wie sich bestehende Windows-Anwendungen auf Mac OS X migrieren lassen. All das und vieles mehr lernt man auf go-parallels.com.