Darüber hinaus ist jetzt eine Audio-Schnittstelle an Bord, die über native Apps komprimierte Audio-Elemente in das PCM-Format umwandeln kann.
Die weiterführenden Erklärungen dazu können Sie hier nachschlagen.
Das neue NDK ist für alle Programmierer interessant, die sich nicht mit den Beschränkungen von Googles Java Virtual Machine abfinden möchten und in Verbindung mit dem Android SDK leistungsfähigere Apps schreiben möchten.

Hier gibt’s den Download des neuen NDK, und das SDK finden Sie auf dieser Seite.

Die Teilnahme ist kostenlos aber es sind nur 50 Plätze verfügbar!

Unter anderem erwarten Sie die folgenden Sessions:

Keynote: Visual Studio 11 and Windows – Powering the Next Wave of Innovation
Visual Studio C++ Program-Manager Boris Jabes und Visual Studio Architect Jean-Pierre Duplessis stellen die neuesten Entwicklungen und Ausblicke für C++ in Visual Studio und auf der Microsoft-Plattform vor.

Effective C++ Programming with Visual Studio 11 Ultimate
Programmer productivity in the era of agile development is no longer something we can count with lines of code. Visual Studio brings together a slew of lifecycle management tools—from architecture analysis to unit testing—that dramatically improve the productivity of C++ developers everywhere. Come learn how the next version Visual Studio will help you embrace agile methodologies like never before!

Unleash Parallel Performance with C++ in Visual Studio 11
Parallelism is everywhere. The upcoming version of Visual C++ enables native developers to remain the kings of performance across all form-factors. With new compiler technology, we will show how every developer can take advantage of multi-core CPUs. With C++ AMP, we bring the cheap & awesome power of GPUs to every C++ programmer. Finally, we bring it all together with enhancements to the debugging and profiling experiences across VS.

Graphics & Game development tools in Visual Studio 11
Visual Studio 11 brings the most significant set of improvements for developing graphics-intensive apps in over a decade. Whether you are just getting started with 2D/3D games or a self-proclaimed “Guru”, there’s something for you in this talk. We will walkthrough a slew of new tools integrated into Visual Studio that will make your life better.

Für Intel ist Bev Bachmayer am Start, Senior Software Engineer der Software and Solutions Gruppe. Nutzen Sie die Gelegenheit, mit einer erfahrenen Entwicklerin über aktuelle Trends und Herausfoderungen der C++-Programmierung zu diskutieren.

Melden Sie sich umgehend an, um das Event nicht zu versäumen.

In einer Demonstration zeigte Sutter, dass vor allem grafisch anspruchsvolle Anwendungen wie Simulationen oder Spiele mit Hilfe des neuen Befehlssatzes besser auf die Leistungsressourcen der Hardware ausgerichtet werden können.

Das Video zur Keynote von Sutter können Sie auf dieser Seite abrufen. Zudem empfehlen wir Ihnen das Video von Daniel Moth.

AMP soll ab der nächsten Version Bestandteil von Visual C++ werden. Auch für C# und .NET sind AMP-Extensions angedacht. Das ist aber nur der erste Schritt: AMP will sich künftig auch auf virtuellen Maschinen und Cloud-Anwendungen als nützlich erweisen. Microsoft wird zudem die Spezifikationen offenlegen, so dass AMP auch in andere Compiler integriert werden kann.

Weitere Informationen lesen Sie im The Moth-Blog.

Kleiner Exkurs: Lambda-Ausdrücke kommen bisher nur in funktionalen Programmiersprachen vor, also in Haskell oder Scala. Da aber solch eine “anonyme Funktion” viele Vorteile mit sich bringt (einfacher Aufruf, weniger fehleranfällig wegen falsch eingesetzter Variablen, etc.), werden in C++ 2011 Lambda-Ausdrücke Teil der imperativen Programmiersprache C++ sein. Wer mehr zum Thema Lambda-Ausdrücke erfahren will, sollte sich mit diesem Artikel beschäftigen.

Zurück zum ISN-Beitrag. Dieser zeigt sehr anschaulich anhand eines Code-Beispiels, wie in Zukunft parallel_for-Konstrukte der Intel Threading Building Blocks von den Lambda-Ausdrücken des künftigen C++-Standards profitieren werden. Unterstützt werden dabei die Compiler GNU g++ Version 4.5, Intel C++ Compiler V12 und Microsoft C++ Compiler V16.

Ohne Lambda-Expression und parallel_for sieht ein möglicher Funktionsaufruf wie folgt aus:

class ChangeArray{
...int* array;
public:
...ChangeArray (int* a): array(a) {}
...void operator()( const blocked_range& r ) const{
......for (int i=r.begin(); i!=r.end(); i++ ){
.........foo (array[i]);
......}
...}
};

Derselbe Funktionsaufruf mithilfe von parallel_for und einem Lambda-Ausdruck stellt sich folgendermaßen dar:

void ChangeArrayParallel (int* a, int n )
{
...parallel_for (0, n, 1,
......[=](int i) {
.........Foo (a[i]);
......});

}

Was man anhand dieses sehr kleinen Beispiels gut erkennen kann, sind zweierlei Dinge: das parallel_for-Konstrukt ist zum einen wesentlich kompakter und damit effizienter, und zum anderen kommen ausschließlich lokale Variablen zum Einsatz, was zu thread-sicherem Code führt.

Innerhalb des Blogbeitrags auf ISN ist übrigens ein kurzes Video eingebettet, das die gesamte Geschichte anschaulich zusammenfasst.

Natürlich werden die Grundzüge von C++ mit C++ 2011 weitgehend erhalten bleiben, allerdings werden Teile so zusammengefasst sein, dass sich das Ganze als verbesserte Einheit darstellt und sich auf höherer Programmierebene natürlicher und effizienter verhalten wird. Wichtigstes neues Feature für Entwickler ist die nebenläufige Programmierung, mit der sich parallel ablaufende Programmabschnitte effizienter programmieren lassen. So können beispielsweise mit Lambda-Funktionen Variablen von Thread zu Thread übergeben werden, was zu verbesserten Parallelkonstrukten führen wird.

Aber auch die direkte Datenfeld-Initialisierung und eine verbesserte Bibliothek werden Teil des neuen C++-Standards sein. Wir werden uns das Ganze zu gegebener Zeit noch ein wenig genauer ansehen und hier veröffentlichen.

Für ISVs und Software-Entwickler ist dieser Termin eine gute Gelegenheit, sich vor Ort detailliert über aktuelle Entwickler-Tools zu informieren, in Trainings, Workshops und Schulungen das eigene Wissen zu erweitern und Lösungen für typische Programmierprobleme zu finden. Und da das Ganze in einer der der schönsten Regionen Deutschlands stattfindet, lässt sich der Termin prima mit einem Kurzurlaub in die bayerischen Alpen verbinden.

Die Advanced Developers Conference bietet 20 (zumeist deutsche) Vorträge hochkarätiger C++-Experten von Intel, Microsoft und weiteren Firmen. Das Motto der Veranstaltung lautet “aus der Praxis für die Praxis“ und verknüpft die traditionellen Vorteile von C++ mit den heutigen Anforderungen in Entwicklungsprojekten.

Zu den Topthemen zählen das Erstellen leistungsstarker Software mit nativem C++-Code, Performancesteigerung sowie Möglichkeiten der Fehlersuche und -behebung in C++-Programmen. Weitere Schwerpunkte bilden Design und Einsatz von MFC-Anwendungen und die Frage, wie sich durch die Ausnutzung der seriellen und parallelen Prozessoreigenschaften eine maximale Leistung erzielen lässt. Ein Highlight wird dabei sicherlich die Session “Parallelprogrammierung mit native C++ und OpenMP 3.0” von und mit Bernd Marquardt sein.

Übrigens: Am Vortag der Veranstaltung (4.5.) vermittelt Dr. Michael Klemm von Intel in dem ganztägigen Hands-on-Training  “C/C++ Code-Performanceoptimierung für Intel-Prozessoren“ tiefgreifendes Wissen mit praktischen Beispielen an bereitgestellten PCs mit Multicore-CPUs.

Hier die weiteren Infos zur Veranstaltung:

• Überblick der Workshops

• Überblick der Sessions

• Überblick der Speaker

Sichern Sie sich bis 8. April Ihre Teilnahme und sparen Sie dabei bis zu 250 Euro, indem sie sich den Frühbucherrabatt mit dem Promocode „Cpp-i0411X“ sichern. Bei gleichzeitiger Anmeldung zur Konferenz mit zwei weiteren Kollegen bekommen Sie auch noch einen 10-prozentigen Kollegenrabatt on top!

Und hier geht es zur Anmeldung. Wir sehen uns…

Pythons GIL war für die Parallelisierung auf Multicore-Systemen zuständig. Das klappte aber nicht zuverlässig. So bemängelten viele Entwickler bei Python-Anwendungen Zugriffsprobleme der Threads bei Nutzung mehrere Kerne und eine Verlangsamung der Prozesse.

Das Problem war seit über einem Jahr ungelöst und hat zu heftiger Kritik an der Sprache CPython geführt. Programmierer behalfen sich damit, statt Threads mehrere, miteinander kommunizierende Prozesse zu verwenden. Das war natürlich nicht im Sinne des Erfinders.

Jython (Java) und IronPython (.NET) sind übrigens nicht betroffen, da dort kein GIL implementiert ist. Das Problem tritt also ausnahmslos bei Programmen im Python C-Code auf.

Gelöst wird der Konflikt nun durch ein neues, so genanntes „concurrent.futures“-Modul, das eine einheitliche Schnittstelle zur Verwaltung paralleler Threads bietet. Details und technische Spezifikationen zu dem PEP 3148 können Sie hier abrufen. Den kostenlosen Download erhalten Sie auf der Python-Seite.

Für C++-Programmierer ist Python vor allem als Skriptsprache interessant. Hierbei spielt die Boost.Python-Bibliothek eine wichtige Rolle. Dahinter verbirgt sich eine kostenlose C++-Bibliothek inklusive zahlreicher Unterbibliotheken. Boost-Bibliotheken werden von boost.org laufend erweitert.

Und noch ein Software-Geschenk an Entwickler:

Windows Azure kostenlos nutzen

Microsoft bietet Entwicklern seine Cloud-Plattform Windows Azure für 750 Stunden zur kostenlosen Nutzung an. Wer es nicht so mit dem Kopfrechnen hat: das entspricht gut 31 Tagen.

Im Zuge des Angebots stehen 500 MByte Online-Speicherplatz und 500 MByte für Datentransfers zur Verfügung sowie die Nutzung einer SQL-Azure-Datenbank mit bis zu 1 GByte (auf 90 Tage begrenzt). Wenn Sie das Testangebot nutzen wollen und sich anmelden, lesen Sie bitte auch das Kleingedruckte: Wer das Angebot über den kostenlosen Testzeitraum hinaus nutzt, muss automatisch für die Nutzung der Vollversion zahlen.

Mit Intel Composer XE verhält es sich wie mit einem Schweizer Taschenmesser: Man bekommt für jeden Job das richtige Tool an die Hand. Will man beispielsweise C++-Projekte unter Windows oder Linux oder Mac OS X kompilieren, ist die neue Intel-Entwicklersuite das richtige Tool für Sie. Oder sind Sie eher Fortran-Entwickler und sind auf der Suche nach dem passenden Compiler, egal ob für Windows, Linux oder Mac OS X? Dann ist der Composer XE 2011 ebenfalls eine gute Entscheidung.

Doch nicht nur die plattform-übergreifende Kompilierung macht aus dem Intel Composer XE ein mächtiges Tool. Denn neben der Optimierung für AVX- und SIMD-Befehle zeichnet sich das Entwicklerwerkzeug durch weitere Bausteine aus:

• Intel Parallel Building Blocks (Intel PBB): Eine Toolsammlung, die Intel Threading Building Blocks, Intel Array Building Blocks und Intel Cilk Plus umfasst.
• hoch-optimierte Software-Bibliotheken: Dies sind Intel Math Kernel Library und Intel Integrated Performance Primitives.
• High-Performance Parallel Optimizer: Damit lassen sich vor allem verschachtelte Schleifenkonstrukte besser untersuchen.
• Interprocedural Optimization: hiermit lassen sich vor allem kleinere und mittlere Funktionen parallelisieren, die oft zum Einsatz kommen und in denen Funktionsaufrufe innerhalb von Schleifen vorkommen.
• Profile-Guided Optimization: verbessert die gesamte Laufzeit-Performance, indem unter anderem der Sourcecode neu arrangiert wird, die Code-Größe reduziert wird und fehlerhafte Sprungvorhersagen entfernt werden.

Weitere Infos zu Intel Composer XE 2011 gibt es entweder als PDF, auf der englischsprachigen Webseite oder in Videoform im Intel Learning Lab.

Den Anfang macht ein kleines, unscheinbares Tool, dass sich Intel Parallel Advisor nennt, Teil des Intel Parallel Studio 2011 ist und Software-Entwicklern dabei helfen soll, nativ programmierten Code schneller, effizienter und einfacher zu parallelisieren. Dabei geht der Advisor sehr systematisch vor, um die bestmöglichen Ergebnisse in Sachen parallelisierter Quellcode zu erreichen. Hierzu sind fünf Schritte notwendig:

1. Survey Target: Im ersten Schritt wird der Quellcode auf mögliche Hotspots untersucht und dabei festgestellt, welche Abschnitte innerhalb des Programms besonders für eine Parallelisierung in Frage kommen.

2. Annotate Sources: Anschließend fügt der Advisor in die identifizierten Quellcodestellen sogenannte Annotationen ein, also entsprechende Pseudo-Befehle, die das Parallelisieren ermöglichen sollen. Dieser Abschnitt ist als eine Art Experiment zu sehen, mit dessen Hilfe man die bestmöglichen Ansätze für Parallelcode finden soll.

3. Check Suitability: Nachdem man die Annotationen in den seriellen Quellcode eingefügt hat, macht sich der Parallel Advisor per Mausklick daran, die vorgenommenen Änderungen des Programms auf Machbarkeit hin zu überprüfen. Hierbei wird vor allem festgestellt, was die Veränderungen zur Laufzeit tatsächlich bringen, ob sich ein Parallelisieren an dieser Stelle also überhaupt lohnt.

4. Check Correctness: Der vierte Schritt hat vor allem mit möglichen Speicherproblemen zu tun. Dabei überprüft der Parallel Advisor wiederrum per Mausklick, welche Dead Locks, Data Races und andere möglichen Probleme anhand der vorgenommenen Änderungen des ursprünglich seriellen Quellcodes zu erwarten sind. Dies ist bei der Umstellung von seriell auf parallel ein kritischer Punkt, den man auf keinen Fall unterschätzen darf. Mögliche Speicherfehler lassen sich nämlich mit herkömmlichen Testverfahren oder Debuggern nur ganz schwer oder gar nicht aufspüren.

5. Add Parallel Framework: Sobald der Parallelcode keine Fehler mehr aufweist und sämtliche Speichertests ohne Probleme durchgeführt werden konnten, müssen nur noch sämtliche Annotationen durch entsprechende Konstrukte und Funktionsaufrufe ersetzt werden. Dabei kann man aus einer Reihe von unterstützten Programmiermodellen wie Intel Threading Building Blocks, Intel Cilk Plus und anderen auswählen – je nachdem, welches Modell besser zum ausgewählten Quellecodeabschnitt passt.

Ach ja: Bilder und weitere Erklärungen zum Intel Parallel Advisor bekommt ihr noch diese Woche auf dem Software Dev Blog. So, stay tuned…

Zur Erinnerung: das sogenannte “Damenproblem” stammt aus der Mathematik und beschäftigt sich mit der Frage, wie viele Damen auf einem Schachbrett so aufgebaut werden können, dass sie sich gemäß der Schachregeln nicht gegenseitig schlagen können. Auf einem 8×8-Schachbrett gibt es übrigens 12 eindeutige Lösungen.

Nur, wie lässt sich das für eine größere Zahl n berechnen, und wie geschieht das auf einem Parallelrechner möglichst schnell? Genau damit beschäftigt sich der pdf-Workshop, der sehr anschaulich und anhand vieler Codebeispiele mögliche Ansätze und Konzepte miteinander vergleicht und natürlich auch verrät, welche Lösung die beste ist, wenn man solche Probleme möglichst elegant und parallel lösen möchte.

Der Download ist kostenlos und jedem Einsteiger in die Parallelprogrammierung sehr zu empfehlen.

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?

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!

• Da die parallel arbeitenden Warteschlangen mit der Version 2.2 sowohl begrenzt (bounded) als auch unbegrenzt (unbounded) arbeiten, sollten Programmierer möglichst die begrenzten Warteschlangen benutzen.

• Da sich die Rückgabewerte der Vektor-Funktionen grow_by, grow_to_at_least und push_back geändert haben, ist der Funktionsaufruf ein wenig einfacher geworden. So wird aus std::copy(begin, end, x.begin()+x.grow_by(end-begin)); jetzt std::copy(begin, end, x.grow_by(end-begin));

• In Intel TBB 2.2 ist auto_partitioner() als Standard gesetzt und löst damit simple_partitioner() ab.

• Der Begriff der Task-Tiefe spielt in TBB 2.2 keine Rolle mehr. Daher sind depth_type und die Methoden depth(), set_depth() und add_to_depth().

Mehr Infos und weitere Codebeispiele sind im angegebenen Blogbeitrag erhältlich.

Das soll vor allem Software-Entwicklern die Möglichkeit geben, Intel TBB bei der Programmierung und Optimierung von Multithread-Sourcecode von Anfang an einsetzen zu können. So umfasst beispielsweise die Unreal Engine von Epic Games ab sofort eine kommerzielle Lizenz der Intel TBB, Autodesk stellt in Maya Intel TBB standardmäßig zur Verfügung.

Neben diesen Neuerungen gibt es weitere Dinge, die hinsichtlich mehr Leistung optimiert wurden:

• Der Taks-Scheduler wurde erheblich überarbeitet, sodass optimierte Anwendungen auf Multicore-Plattformen besser skalieren. Dazu gehören eine automatische Initialisierung bei paralleler Ausführung bestimmter Codeabschnitte und das Zusammenfassen mehrerer Tasks zu einer Gruppe.

• Der Memory Allocator wurde ebenfalls verbessert, was den standardmäßigen Allocator des Betriebssystems ersetzen kann. Folge: bessere Skalierbarkeit der vorhandenen Speicherressourcen und weniger Datenkollisionen.

• Darüber hinaus gibt es neue und verbesserte Konstrukte. Neu sind parallel_invoke and parallel_for_each, mit deren Hilfe sich parallele Konstrukte noch einfacher erstellen lassen. Zudem wurde das Erstellen der häufig benutzten parallel_for-Konstrukts vereinfacht.

Ach ja: Für ein besseres Verständnis, was es mit den optimierten Lambda-Funktionen auf sich hat, empfehle ich zwei Blogposts (Nummer 1 und Nummer 2) des Kollegen Reinders, in denen er sehr anschaulich erklärt, was es bringt und was sich dadurch ändert.

Cilk is a general-purpose programming language designed for multithreaded parallel computing.

Hey, dachte ich, das ist doch ein prima Thema für mein Blog. Also, dann schnell mal geguckt, was Cilk und Intel gemein haben (neben der Absicht, die parallele Programmierung unter C/C++ zu vereinfachen:

If you’ve visited cilk.com today, you see that the Cilk engineering team has joined Intel.

Das heißt also, Intel und Cilk machen jetzt gemeinsame Sache?! Sieht ganz danach aus. Denn wie sagt James zusammenfassend:

Cilk technology will complement other methods we have had great success with – including OpenMP and Intel Threading Building Blocks.

Aha, das bedeutet, dass Cilk++ eine prima Ergänzung zu den Intel-Tools wie Parallel Studio oder Intel TBB bedeutet? Soll wohl so sein. Doch was steckt hinter Cilk++ und was sind die Merkmale dieser Programmiersprache?

Nun, ähnlich wie bei OpenMP gibt es sogenannte Keywords (bei OpenMP heißen diese “Pragmas”), 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, mit deren Hilfe der Mathematiker 1202 n. Chr. das Wachstum einer Kaninchenpopulation beschreiben wollte:

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). Dies Keywords sorgen dafür, dass die Funktion parallel auf zwei oder mehreren Prozessorkernen ausgeführt wird. Den Rest übernimmt die Runtime von Cilk++, 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.

Darüber hinaus verfügt Cilk++ über zwei weitere Keywords: inlet und abort. Inlets sind einfache Funktionen innerhalb einer Cilk-Prozedur, die den Rückgabewert einer parallelisierten Funktion übergeben. Der Witz an Inlets ist deren atomare Struktur: Soll heißen, dass diese Funktionen vom Scheduler nicht synchronisiert werden müssen, was die Fehleranfälligkeit einer derart parallelisierten Funktion minimiert. Abort beendet diese inlet-Funktionen.

Cilk gibt es übrigens schon ziemlich lange: Enstanden am ehrwürdigen MIT Laboratory for Computer Science, wurde es bereits 1994 zum ersten Mal erwähnt. Kein Wunder also, dass sich Intel der Dienste von Cilk Arts bedient und Cilk++ ins eigene Portfolio aufnehmen wird, um beispielsweise Parallel Studio weiter voranzubringen.

Ach ja: Wer mehr Insider-Wissen zu Cilk haben will. sollte auf jeden Fall deren Multicore-Blog besuchen.

Um Cinema 4D multicore-tauglich zu machen, unternimmt Maxon schon seit vielen Jahren größte Anstrengungen. Das geschieht bereits seit Mitte der 90er Jahre, lange bevor die die ersten Prozessoren mit Hyperthreading auf den Markt kamen. Schon damals galt die Parallelprogrammierung als eine nicht ganz triviale Disziplin, da man vor allem die gemeinsamen Speicherzugriffe und die daraus resultierenden Probleme wie Dead Locks und Data Races in den Griff bekommen musste. Mit Erfolg, wie man an Cinema 4D gut sehen kann.

Doch was hat Maxon alles im Laufe der Jahre getan, damit die Anwendungen auf einem Multicore-System optimal skalieren? Dazu hat Tilo Kühn, Senior Software Developer bei Maxon, eine recht einfache Erklärung parat: Man muss als Entwickler vor allem dafür sorgen, dass die Datenstrukturen von Anfang an so angelegt werden, dass beim parallelen Ausführen der Anwendung die Anzahl der Synchronisation so gering wie möglich ausfällt und es nicht zu Data Races oder ähnlichen Verklemmungen kommen kann. Denn jede Datensynchronisation bedeutet einen Mehraufwand, der den Programmablauf unnötig stört und behindert.

Das gilt zumindest für Systeme mit bis zu acht Prozessorkernen. Darüber hinaus weiß Maxon bereits heute, dass de Programmiertechniken weiter verbessert werden müssen, um in Zukunft auch auf Systemen zu skalieren, die mehr als acht Cores bieten. Allerdings sind die Leute bei Maxon schon eine ganze Weile an dem Thema dran, sodass möglicherweise mit der nächsten Version von Cinema 4D ein neues Framework zum Einsatz kommen wird. Das Ganze wird dann wohl auf Basis des Intel-C++-Compilers Version 11.1 geschehen.

Interessant ist übrigens auch die Aufwandseinschätzung, was das Parallelisieren von Schleifen betrifft, wie sie beim Rendern von 3D-Gebilden häufig angewandt werden: So benötigt man für das Umstellen von sequenziellen auf parallele For-Schleifen mit Bordmitteln (APIs, Pthreads) rund einen Tag, mithilfe von OpenMP-Pragmas ist dieselbe Arbeit innerhalb von gut einer Stunde erledigt – zumindest für einen ersten aussagekräftigen Test. Daher setzt Maxon bei der Anwendungsentwicklung an dedizierten Stellen auf OpenMP.

Daneben verwendet Maxon schon seit langem VTune Performance Analyzer, um bestimmte Aspekte des Programmablaufs besser verstehen zu können. Hier kommt unter anderem der CallGraph zum Einsatz, um die Zusammenhänge des objektorientierten Programmierens transparenter und damit greifbarer zu machen. VTune würde bei Maxon sogar noch öfter genutzt, wenn der Overhead, der beim Sampling des Sourcecodes entsteht, geringer wäre. Wie gut, dass sich Intel dieser Herausforderung in Form des Parallel Studios und des darin enthaltenen Parallel Inspectors erfolgreich gestellt hat. Der Inspector basiert nämlich auf VTune, allerdings in einer schlanken Fassung, die deutlich weniger Overhead produziert.

Ebenfalls zum Einsatz kommt bei Maxon der Thread Profiler. Was Tilo Kühn an dem Tool besonders mag ist die sehr anschauliche, grafische Darstellung der zeitbasierten Thread-Abhängigkeiten. Auf diesem Weg lassen sich ganz spezielle Codeabschnitte untersuchen, indem man dem Profiler mitteilt, an welcher Stelle mehrere Theads parallel ausgeführt werden. Damit lassen sich relativ einfach mögliche Verklemmungen während des Programmablaufs aufspüren. Aber auch gegenseitige Abhängigkeiten von Threads kann man mit dem Thread Checker grafisch darstellen.

Das verlangt doch geradezu nach einem Einsatz des Parallel Studio bei Maxon, oder?! Was auch passieren wird, wie mir Tilo Kühn glaubhaft versicherte. Na dann: Go parallel!

Für aufmerksame Leser des Software Dev Blogs werden sich nicht sonderlich viele Neuigkeiten aus dem Beitrag ableiten lassen, aber in seiner Abgeschlossenheit trägt der Artikel doch sehr zum Verständnis von Parallel Studio bei. Zudem handelt es sich um ein PDF-Dokument, das sich sogar ausdrucken lässt. Für die analogen Zeitgenossen unter uns.

Der Artikel umfasst drei Seiten und geht recht detailliert auf die einzelnen Komponenten ein, also Parallel Composer, Parallel Inspector und Parallel Amplifier. Lustigerweise beginnt der Beitrag mit dem Parallel Advisor. Dieses Tool wird erst in der nächsten Version zum Parallel Studio gehören, kann allerdings heute schon als eine Art Techdemo kostenlos ausprobiert werden.

Schön an dem Parallel-Studio-Beitrag sind die praxisorientierten Einblicke, die man anhand der eingefügten Bilder gewinnen kann. Schade ist allerdings, dass diese teilweise recht klein geraten sind. Und ein, zwei Codebeispiele hätten dem Artikel zu ein wenig mehr Pfiff verholfen. Na ja, beim nächsten Mal dann, ok?!

Klar, dass es dabei vor allem um Visual Studio 2010 samt .NET 4 gehen wird, aber natürlich auch um Parallel Studio mit Parallel Composer, Parallel Inspector und Parallel Amplifier. Ich bin schon sehr gespannt, wer alles dort zugegen sein wird, um sich höchstpersönlich die Infos aus erster Hand zu holen.

Am übernächsten Wochenende folgt dann das GameCamp Munich 2009, auf dem ich ebenfalls anwesend sein werde, um vor Ort zu bloggen, zu netzwerken und das ein oder andere Video zu drehen. Doch ich werde nicht allein sein: Intel wird sich als Sponsor betätigen und wohl am Sonntag eine eigene Session zum Thema Visual Computing und Multicore abhalten. Das wird bestimmt sehr spannend. Außerdem wird der Kollege hoffentlich einen Demo-PC dabei haben, mit dessen Hilfe er das Thema Multicore-Programmierung für 3D-Spiele anschaulich vorführen kann.

Ach ja: Das GameCamp Munich 2009 findet in Unterschleißheim bei Microsoft statt, die ihre Räumlichkeiten für die Konferenz zur Verfügung stellen. Und was ich so gehört habe, sind noch Plätze frei. Also, worauf wartet ihr noch mit der Anmeldung?!

• 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).

Dabei geht es im Gegensatz zur dynamischen Fehlersuche um das Aufspüren potenzieller Fehler im Sourcecode selbst und nicht um Bugs, die erst zur Laufzeit auftreten. Damit lassen sich unter anderem Speicherprobleme, fehlerhafte Variablendefinitionen, Fehler bei den OpenMP-Deklarationen und vieles mehr aufspüren.

Und, interessiert? Dann solltet ihr ganz schnell auf die Intel-Webinar-Seite gehen und euch flugs für das Online-Seminar anmelden. Es findet nämlich in gut vier Stunden statt.

Zunächst einmal: Mit dem Parallel Advisor stellt Intel ein Tool zur Verfügung, das Entwicklern und Programmierern dabei helfen soll, Parallelisierungspotenzial ihrer Anwendungen zu identifizieren. Und das nicht per Trial-and-Error, sondern mit erprobten Messverfahren, die diejenigen Codeabschnitte ermitteln, bei denen sich das Multithreaden am ehesten lohnt. Hierfür unterstützt Parallel Advisor Lite diverse Ansätze:

Flexible Handhabung: Der Advisor kann zu jedem beliebigen Zeitpunkt der Anwendungsentwicklung laufen. Entscheidend ist nur, dass Microsoft Visual Studio 2005 oder 2008 samt einer C++-Entwicklungsumgebung und Parallel Studio zum Einsatz kommen.

Eingebaute Skalierbarkeit: Der Parallel Advisor sorgt für skalierende Anwendungen, die auf den kommenden Intel-Plattformen “mitwachsen”.

Einsatz von Industriestandards: Dank des Einsatzes von OpenMP und anderer Techniken orientiert sich Parallel Studio und damit auch der Parallel Advisor an anerkannten Industriestandards, was die Software-Entwicklung mit diesen Tools zukunftssicher macht.

Vereinfachte Parallelprogrammierung: Der Parallel Advisor erfordert laut Intel relativ wenig Vorwissen in Sachen Parallelprogrammierung. Gleichzeitig soll sich das Erfolgserlebnis recht schnell einstellen.

Bekannte Programmiermethoden: Parallel Advisor unterstützt sowohl Daten- als auch Aufgabenparallelismus.

Um eine sequenziell programmierte Software-Anwendung effizient und ohne größere Kopfschmerzen zu parallelisieren, sind mithilfe des Parallel Advisors folgende Schritte notwendig:

• Die laufende Anwendung wird auf mögliche parallelisierbare Abschnitte hin untersucht. Hierbei handelt es sich um eine Hotspot-Analyse, die potenzielle Konstrukte wie Schleifen für die Parallelisierung identifiziert.

• In Frage kommende Abschnitte der Anwendung werden entsprechend markiert, sodass ein späteres Einfügen von Parallelkonstrukten mithilfe von OpenMP, Intel TBB und Co. möglichst einfach vonstatten geht.

• Anschließend werden diejenigen Programmabschnitte identifiziert, die Dead Locks und ähnliche Probleme verursachen können.

• Es werden an denjenigen Sourcecode-Stellen entsprechende Programmierzeilen eingefügt, die dabei helfen sollen, Datenprobleme mithilfe passender Konstrukte zu beseitigen.

• Nach ausführlichen Tests des seriellen Quellcodes werden abschließend alle markierten Stellen durch Multithread-Konstrukte ersetzt. Das macht aus dem sequenziell programmierten Software-Titel eine parallel ablaufende Anwendung, die die vorhandenen Multicore-Ressourcen hoffentlich optimal nutzt.

Zugegeben, ganz unvorbereitet bin ich nicht auf das gestrige Ereignis. So findet Parallel Studio auf dem Software Dev Blog schon seit dem 24. Oktober statt. Damals habe ich das Parallelisierungstool in einem Nebensatz zum ersten Mal erwähnt. Die erste echte Erwähnung fand das C++-Werkzeug am vorletzten Tag des Oktobers 2008, und zwar in Vorbereitung auf die Microsoft-Entwicklerkonferenz TechEd im schönen Barcelona. Tja, und einen Tag später habe ich dann ein wenig mehr verraten über Parallel Studio und habe es ziemlich kühn “Multicore-Turbo” genannt.

Seitdem folgten diverse Beiträge rund um das Entwicklertool, das sich nahtlos in Visual Studio 2005 und 2008 von Microsoft einbetten lässt. Highlights waren zweifellos zwei Interviews mit Steve Teixeira und Dariusz Parys von Microsoft, ein Vierteiler zu Parallel Studio mit ersten Einblicken in die Toolsuite (Teil 1, Teil 2, Teil 3 und Teil 4) und die Liveberichterstattung von der Intel Software Conference 2009 aus Salzburg.

Unerwähnt sollten aber auch nicht die zahlreichen Onlineseminare bleiben, die Intel rund um Parallel Studio im Angebot hatte bzw. noch hat.

Ach ja: Teil des Parallel Studio wird ein viertes Tool sein, der Parallel Advisor. Mit diesem Parallel-Studio-Add-On soll Software-Entwicklern dabei geholfen werden, ihre Anwendungen schneller, effizienter und mit weniger Aufwand zu parallelisieren. Da der Advisor erst mit der nächsten Version des Parallel Studio Teil der Suite wird, stellt Intel registrierten Mitgliedern des ISN den Advisor Lite als TechPreview auf Whatif.com zum kostenlosen Download zur Verfügung. Damit alle interessierten Entwickler und Programmierer schon mal damit herumspielen und ihr Feedback an Intel weiterleiten können. Mehr Infos zum Advisor gibt es morgen auf diesem Sender!

Eric Moore wird auf die bekanntesten Fehler eingehen, die man bei der Parallelisierung von Software machen kann, und zeigt, wie sich diese vermeiden oder auch eliminieren lassen. Hierzu zieht er bekannte und unbekannte Software-Titel zu Rate, anhand derer die Optimierung von Multithread-Code demonstriert werden soll.

Falls das also interessant scheint, solltet ihr euch möglichst schnell für das kostenlose Webinar anmelden und den Worten Erics lauschen. Viel Spaß dabei!

Auf der Konferenz habe ich auch James Reinders zum ersten Mal live erlebt, und in Echt ist er noch authentischer als in seinen Videos. Zu erzählen hat er sowieso eine ganze Menge über Parallel Studio, das übrigens am 26. Mai 2009 auf den Markt kommen soll. Zunächst zwar ohne Parallel Advisor, aber dafür inklusive Parallel Composer, Parallel Inspector und Parallel Amplifier. Und was es mit dem ominösen Ct-Projekt auf sich hat, haben wir von James ebenfalls erfahren.

Ansonsten gab es detaillierte Infos zu den Tools (samt Demos, die ich hoffentlich noch nachliefern kann) sowie eine kleine Einführung in Visual Studio 2010. Und warum Nero pro Jahr rund 50 Millionen Software-Titel verkauft, haben wir ebenfalls gelernt.

Ach ja: Nicht, dass es mir langweilig würde diese Woche. Am morgigen Donnerstag findet hier in München der prio.powerday zum Thema Multicore-Programmierung im .NET-Umfeld statt. Ich werde auch von dort Livebloggen und bin schon sehr gespannt, was Rami, Don, Bernd und Ralf zu erzählen haben. So, stay tuned …

Status quo aus Intel-Sicht sind die HPC-basierten Tools der Gegenwart, die permanent weiterentwickelt werden. Daneben wird es sehr bald (wohl im Mai) Parallel Studio geben für den Mainstream-Entwickler. Und drittens sind die vorhandenen Tools einer ständigen Evolution unterworfen (so kommt ein verbesserter Compiler irgendwann im Juni auf den Markt).

Die Evolution des Parallel Studio umfasst folgende Dinge:

• der Parallel Advisor wird wichtiger Bestandteil der Suite
• beste Kompatibilität mit Windows 7 und Visual Studio
• Unterstützung der nächsten Microsoft Concurrency Runtime
• Ergänzungen (was immer das bedeutet)

Den dritten Teil seines Vortrags leitet James mit einem Traum ein:

If you focused on “data parallel programming”, could you make it easier for the program to be deterministic and scale?

Die Antwort lautet natürlich “Yes” und mündet in der Vorstellung des Ct-Projekts, das Ende 2009 eine Beta-Version eines neuen Produkts gebären soll. Das Thema ist die datenbasierte Parallelprogrammierung unter C++. Die Hauptmerkmale sehen wie folgt aus:

• eine höchst abstrahierte, beschreibende Programmiersprache, die nicht mehr in Aufgaben “denkt”
• hoch skalierend
• C++ wird um neue Templates erweitert (vergleichbar mit Intel TBB). Es sind keinerlei Änderungen an den bekannten Compilern erforderlich.

Ct wird beispielsweise die Programmierung von Bild- und Videobearbeitungstools erheblich vereinfachen, da nicht mehr sämtliche Varianten der datenorientierten Programmierung berücksichtigt werden müssen (Threading auf SSE- und einer höheren Ebene). Die Beschleunigung mittels Ct geschieht quasi im Hintergrund und entlastet den Programmierer bei seiner Arbeit.

Ct wird also die parallele Programmierung von datenbasierten Anwendungen deutlich vereinfachen und eines Tages in sämtlichen Intel-Softwaretools integriert sein.

Ein sehr schöner Einstieg in das Thema Tuning ist folgendes Zitat: “Ich weiß, wie ich vier Pferde dazu bringe, einen Wagen zu ziehen. Wie aber geht das mit 1024 Hühnern?” Das ist eine wirklich passende Analogie zur Optimierungsarbeit beim parallelen Programmieren. Denn es gibt so viele Fallen, in die man beim Multithreading tappen kann: nicht-skalierender Code, Deadlocks oder Data Races zur Laufzeit und vieles mehr.

Dafür gibt es den Parallel Amplifier, der Flaschenhälse findet, die Skalierbarkeit der Anwendung ermittelt und mehr. Es hilft also Entwicklern und Programmierern, die parallele Struktur und das parallele Verhalten ihrer Anwendung besser zu verstehen.

Wie schon der Composer und Inspector, integriert sich Parallel Amplifier in Visual Studio und findet folgende Probleme:

• Wo verbraucht meine Anwendung die meiste Zeit?

• Wann gehen die Prozessoren in den Idle-Modus?

• Wo gibt es ungewollte Wartezeiten?

Sobald Amplifier die möglichen Fehler gefunden hat, lassen sich die entsprechenden Quellcode-Stellen per Mausklick öffnen und auf die Fehler hin überprüfen.

Parallel Amplifier findet aber auch Unter- und Überschäftigung der vorhandenen Prozesorkerne, zeigt also sehr anschaulich, in welchem Umfang die Ressourcen genutzt werden.

Praktisch ist auch die Vergleichsfunktion, die es ermöglicht, die Ergebnisse zweier Durchläufe grafisch darstellen zu lassen. Also vor und nach der Optimierung und deren Auswirkung auf die Ausnutzung der Ressourcen.

Jetzt folgt eine Livedemo, die den Amplifier präsentiert. Und auch hier muss ich leider sagen, dass sich das geschriebene Wort nicht dafür eignet, das Gesehehene vernünftig zu beschreiben. Aber ich versuche auch in diesem Fall, etwas Anschauliches nachzuliefern. Interessant dabei ist die Tatsache, dass der Amplifier die EXE-Datei zur Laufzeit analysiert und anschließend innerhalb von Visual Studio die Ergebnisse darstellt. Das macht das Aufspüren der betreffenden Quellcodestellen ziemlich einfach.

Überraschend war übrigens der Wechsel des Compilers, um in diesem Anwendungsfall eine spezielle Bibliothek nutzen zu können. Die Laufzeit reduzierte sich von 15 Sekunden auf unter eine Sekunde. Dies ist auf den Intel-C++-Compiler zurückzuführen, der diese Bibliothek bereithält und die Laufzeit dramatisch verringert.

Parallel Inspector ist, einfach gesagt, eine Kombination aus Threading- und Speicher-Checktool, und das sogar “proaktiv”. Proaktiv bedeutet in diesem Zusammenhang eine Fehlersuche zur Laufzeit der Anwendung. Darüber hinaus integriert sich der Inspector in Visual Studio und macht damit die Bedienung ziemlich einfach. Der Programmierer muss sich nur für eine der beiden Optionen entscheiden: Finde Threadfehler oder Speicherfehler.

Speicherfehler: Hier geht es um so unschöne Dinge wie Memory Leaks, Speicherüberläufe und Zeigerprobleme. Schön daran ist die Möglichkeit, irrelevante gefundene Probleme auszublenden. Dies macht das Aufspüren der wichtigen Fehler einfacher.

Threading-Fehler: Stichworte sind Deadlocks, Data Races und andere Synchronisationsprobleme, und das zur Laufzeit der Anwendung. Auch hier lassen sich unwichtige Probleme direkt ausblenden.

Ein schöner Nebenaspekt des Parallel Inspector ist dessen Compiler-Unabhängigkeit: Man kann also sowohl den Intel-C++- als auch den Microsoft-Compiler oder jeden anderen kompatiblen Compiler verwenden.

Sehr hübsch: Je nach gewünschter Intensität lässt sich der Inspector-Test (Speicher oder Threading) mithilfe eines virtuellen Zeigers einstellen. Das macht die Wahl des passenden Tests sehr intuitiv.

Die abschließende Demo ist wirklich sehr anschaulich und zeigt die einfache Handhabung des Inspectors aus Visual Studio heraus. Leider lässt sich das an dieser Stelle nur schlecht darstellen. Ich überlege mir aber etwas, wie ich das nachträglich zeigen kann. Versprochen!

Fazit: Parallel Inspector ist ein wirkliche gutes Tool, mit dem sich mögliche Threading- und Speicherprobleme identifizieren lassen, und das mit wenigen Mausklicks. Zudem geschieht dies aus der gewohnten Visual-Studio-Umgebung heraus.

Den Anfang macht eine Demo mithilfe einer Mandelbrot-Berechnung, die auf einem Prozessor und auf 24 Prozessorkernen läuft – und das signifikant schneller! Das überrascht nicht wirklich …

Eines der Hauptprobleme beim parallelen Programmieren ist laut Eric – und das ist nicht nur seine Ansicht – die bestehende Ausbildung der aktuellen Studentengeneration, da diese nicht entsprechend ausgebildet werden.

Die Integration von Intel Parallel Studio in Visual Studio 2010 hat laut Eric diverse Vorteile: Load Balancing und Task Scheduling geschehen sehr ausgewogen. Außerdem werden die vorhandenen Ressourcen wie Intel TBB und Microsoft PPL optimal gemeinsam genutzt.

Eine weitere Demo zeigt den Unterschied zwischen LINQ und PLINQ, mit deren Hilfe ein Datensatz in einer Datenbank gefunden werden kann. Überraschung: Dank der Parallelisierung von PLING wird derselbe Datensatz in vier Sekunden identifiziert anstatt in 27 Sekunden auf LINQ-Basis.

Interessante Aussage: “The manycore is a disruption for developers but also a high opportunity!”

Eric stellt jetzt letztlich dieselbe Fragen wie James Reinders: Wie können Entwickler parallel entwickeln? Wie können sie dabei unterstützt werden, dies effizient und skalierend zu tun? Und wie können Entwickler möglichst einfach Programme erstellen und testen?

So, jetzt geht es um Visual Studio 2010. Eric stellt PLINQ im Detail vor.

Ein weitere Demo zeigt die Lösung des Monte-Carlo-Problems mithilfe einer parallelen Anweisung, die sich in wenigen Sekunden in den Sourcecode einfügen lässt. Und tatsächlich: Dank der Parallelisierung steht die Lösung auf einer Dualcore-Maschine nach knapp sieben Sekunden zur Verfügung (im Vergleich: Im seriellen Modus dauerte die Berechnung rund zwölf Sekunden).

Die Concurrency Runtime zeichnet sich durch zwei Hauptmerkmale aus: Load Balancing Scheduler (LBS) und Dynamic Resource Management (DRM).

Ohne große Umschweife kommt James auf Parallel Studio zu sprechen. Das Feedback der Beta-Tester ist wohl sehr gut. Gleichzeitig ist es aber wichtig, so Reinders, dass die Segmentierung der Tools klar ist: Parallel Studio wird in Zukunft den Mainstream der C++-Programmierer adressieren, während sich die anderen Softwarewerkzeuge eher an Highend-Entwickler wenden – unter anderem an diejenigen, die nicht in C++ unter Windows programmieren.

Klar, dass James auch über geplante Produkte redet. Zum einen über die nächsten Multicore-Prozessoren, die ein Vielfaches an Threads wie die aktuellen CPUs parallel verarbeiten können. Aber auch Larrabee kommt kurz ins Gespräch.

Jetzt liegt gerade eine interessante Folie auf, die das ganze Dilemma vieler Programmierer aufzeigt: Mehr Prozessorkerne bedeuten nicht zwangsläufig mehr Leistung, da die Taktraten nicht weiter nach oben gehen und aus diesem Grund die Anwendungen für parallel ablaufende Threads optimiert werden müssen. Und zwar so, dass die Software auch dann skaliert, wernn die Hardware nicht nur vier Prozessorkerne bietet, sondern 8, 16, 32 oder mehr.

Auf die Bühne kommt – Intel Threading Building Blocks, übrigens Teil des Parallel Studio.

“Tools must help” – sowohl in vergangenen Zeiten als Hilfsmittel als auch heute und morgen für korrekt und skalierend programmierte Anwendungen.

Ok, jetzt wird’s parallel: James spricht über Parallel Studio und stellt die vier Stufen der parallelen Programmierung vor: Design, Programmierung/Testen, Verifizierung, Tuning.

Design: Hiefür wird es eines schönen Tages den Parallel Advisor geben, der aber zunächst nicht Bestandteil von Parallel Studio sein wird.

Programmierung/Testen: Hierfür gibt es Parallel Composer, der verschiedene Tools in sich vereint: OpenMP 3.0, C++-Compiler, Parallel Debugger Plug-in, Integrated Performance Primitives, Threading Building Blocks, Lambda-Funktionen etc.

Verifizierung: Parallel Inspector kümmert sich um die Fehler und Bugs, die sich bei der parallelen Programmierung eingeschlichen haben. Letztlich ist der Inspector eine verbesserte Variante des Thread Checker, den es ja schon eine ganze Weile gibt. Was der Inspector besser macht ist das Aufspüren von Speicherproblemen, und das natürlich zur Laufzeit. Daneben findet Inspector Fehler in Multithreading-Segementen wie Dead Locks Data Races – und gleich die passenden Programmzeilen dazu.

Tuning: Parallel Amplifier spürt ähnlich wie VTune und Thread Profiler Flaschenhälse und Hotspots innerhalb einer parallel programmierten Anwendungen auf. Hierfür kann man sich beispielsweise seine Software benchmarken, indem man die vorhandenen Funktionen unterschiedlich anordnet und mithilfe des Amplifier herausfindet, welche Anordnung am besten ist.

Jetzt kommt James doch noch mal auf Parallel Advisor zu sprechen, der im Laufe des Jahres allen Studio-Anwendern zur Verfügung stehen wird. Dieses Tool wird Entwicklern dabei helfen, den besten Ansatz für die Parallelisierung seiner Anwendung zu finden.

Auch ein wichtiges Thema ist die geplante Version von Microsoft Visual Studio 2010, die eine Menge an Parallelismus eingebaut haben wird. Interssant an der Folie ist der Hinweis, dass Intel die Microsoft Concurrency Runtime in Zukunft unterstützen wird. Bisher ist es nämlich vor allem für .NET-Entwickler recht schwierig, Multithread-Code zu “überwachen”. Das betrifft hauptsächlich den Task Scheduler, der sich um das Verteilen der anfallenden Threads auf die vorhandenen Prozessoren kümmert.

Interessanter Einwurf eines anwesenden Teilnehmers: Warum sollte man nicht einfach auf Visual Studio 2010 warten, anstatt Parallel Studio einzusetzen? Antwort von James Reinders: Parallel Studio setzt auf OpenMP und hat vor allem mit dem Parallel Inspector ein Debugger-Tool “onboard”, das zur Laufzeit Data Races und Deadlocks finden kann!

Und jetzt noch zwei schöne Schlussworte:

C- und C++-Entwickler benötigen ALLE Parallel Studio!

Parallel Studio ist das absolut beste Tool für die parallel Programmierung!

• Was ist Parallel Studio?
• Intels zukünftige Pläne

Das erinnert mich gerade ein wenig an die Verleihung der bekannten Hollywood-Statue: Anwesende werden begrüßt, Special Guests werden erwähnt und kleine Geschichten werden ausgetauscht. Ein sehr launiger Auftakt für solch eine Veranstaltung …

Dann wird’s aber doch technisch und die geplanten Redner werden vorgestellt: Microsoft, Nero und Intel werden den heutigen Tag inhaltlich gestalten. Daneben wird das Intel Software Network vorgestellt, die Plattform für technische Informationen rund um Intel-Softwareprodukte. Goparallel.com wird kurz erwähnt sowie die MSDN-Verlinkung, die geplante Microsoft-Intel-Roadshow und diverse Veranstaltungen.

Jetzt gibt Christian ein kurzes Update in Sachen Parallel Studio und dass es sogar auf der weltweiten Marketing- und Sales-Konference im Januar Erwähnungen gefunden hat. Weitere Tools werden im Juni vorgestellt, die vor allem für Apple- und Linux-Entwickler interessant sein werden.

Ein Video lässt verschiedene Menschen zu Wort kommen (Citrix, Microsoft, Novell, Red Hat, Autodesk etc.), die Intel-Tools wie VTune Performance und Intel Compiler Analyzer in den höchsten Tönen loben.

Und jetzt heißt es: Bühne frei für James Reinders!

Für alle, die bisher noch nicht mitbekommen haben, was hier am morgigen Dienstag in der Geburtsstadt Mozarts im Namen von Intel stattfinden wird, folgt jetzt die ultimative Stichwortsammlung:

James Reinders, Obersoftwareguru bei Intel, wird zeigen, dass sich Multicore-Plattformen vom Nischendasein emanzipiert haben und im Massengeschäft angekommen sind. Und dass es für Softwareentwickler noch ein Menge zu tun gibt, um ihre oftmals sequenziell programmierten Anwendungen an die aktuellen und zukünftigen Prozessorgenerationen anzupassen, die es gerne parallel mögen.

Eric Vernié, Softwarevordenker bei Microsoft in Frankreich, macht sich dann daran, die gemeinsamen Anstrengungen von Intel und Microsoft in Sachen Multicore-Programmierung vorzustellen. Stichworte sind Visual Studio 2010 samt .NET 4.0 einerseits und Parallel Studio andererseits. Es wird aber auch um künftige Programmiersprachen wie F# gehen, die für noch mehr automatischen Parallelismus in Anwendungen sorgen sollen.

Charly Lippoth, Chefstratege der Nero AG, kommt anschließend zu Wort und wird über die Erfolgsgeschichte referieren, warum Nero-Software und Intel-Multicore-Plattformen wie der Core i7 so gut harmonieren und was seine Programmierer und Entwickler alles dafür tun mussten. Stichworte in diesem Zusammenhang sind VTune Performance Analyzer und Intel Compiler.

Nach soviel Übersichtsinfos geht es dann ans Eingemachte: Heinz Bast und Levent Akyil nehmen sich im Detail des Parallel Studios an. Stichworte hierbei sind Parallel Composer, Parallel Inspector und Parallel Amplifier. Da sollten eine ganze Menge Einblicke dabei sein.

Und was ist sehr beliebt am Ende solch einer Konferenz? Genau, ein Blick in die Glaskugel: Was kommt, was können wir noch alles erwarten, was wird in Zukunft benötigt. Das erledigt natürlich der Chef selbst: James Reinders wird also noch einmal die Bühne erklimmen und einen kurzen Ausblick verschaffen, was Parallel Studio noch alles zu bieten haben wird und was es mit dem Forschungsprojekt Ct auf sich hat.

Jetzt fehlt nur noch der Hinweis, den RSS-Feed des Software Dev Blogs zu abonnieren, oder?!

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.

Los geht das Ganze um 9 Uhr kalifornischer Zeit (PDT), also um 18:00 unserer Sommerzeit. Hoffen wir mal, dass das so stimmt, da bisher die Webinars bereits um 17:00 MEZ losgingen. Kann also nicht schaden, schon mal um fünf Uhr vorbeizuschauen. Und zwar per Mausklick auf diesen Link.

Ach ja: Wer den Inspector schon mal live und in Farbe sehen will, sollte sich das dazu passende Video ansehen, das die Kollegen während der GDC’09 gedreht haben.

Interessant an dem Video sind mehrere Sachen: Zum einen kann man gut sehen, wie sich der Testrechner konfigurieren lässt. Zum anderen kann man sogar kompilierte Dateien testen, die in C# programmiert worden sind. Da soll noch einer sagen, in die Executables der Microsoft Concurrency Runtime könne man nicht “hineinschauen”. Concurrency Checker kann. Und wie.

Denn wie das Video sehr anschaulich zeigt, sieht man nicht nur die Skalierbarkeit des gestesteten Tools, sondern kann auch die einzelnen Threads ansehen und wie diese auf die vorhandenen Prozessorkerne verteilt werden. Wenn man jetzt noch weiß, welche Programmabschnitte der Anwendung in welche Threads zerlegt werden, kann man die weniger gut performenden Programmabschnitte entsprechend “tunen” und damit bessere Multithread-Ergebnisse erzielen.

Und das Tollste daran: Concurrency Checker kostet keinen Cent. Also los, macht doch mal die Probe aufs Exempel und überprüft mithilfe des Tools, wie gut euer selbst Programmiertes auf Intel-Plattformen läuft. Die Ergebisse dürft ihr natürlich hier als Kommentar hinterlassen – oder auch nicht.

Damit ihr euch schon mal einen ersten lebendigen Eindruck vom Parallel Conposer verschaffen könnt, ist die Teilnahme an dem kostenlosen Webinar sicherlich eine gute Idee. Also, hierher klicken, anmelden und um 17:00 MEZ einwählen. Viel Spaß dabei!

Der Morgen beginnt ganz gemütlich mit ein paar einleitenden Worten des Gastgebers. Anschließend macht sich James Reinders, Oberchef der Software Developer Group bei Intel, ein paar Gedanken zu der Frage, wie es Programmierer und Entwickler schaffen können, ihren Anwendungen paralleles Leben einzuhauchen. Denn in Zeiten fallender Taktraten pro CPU und steigender Prozessorkerne pro System wird es immer wichtiger, sich mit dem Thema Multithreading und Multicore-Optimierung zu beschäftigen. Wie dies am Beispiel Parallel Studio funktioniert, verrät er auch schon mal ein wenig.

Nach der ersten kurzen Pause geht es dann interessant weiter. Eric Vernié, einer der führenden Software-Evangelisten bei Microsoft, wird sich mit Visual Studio 2010 und .NET 4.0 beschäftigen und anhand dieser zukünftigen Entwicklungsumgebung zeigen, wie sich Redmond das Thema Parallelprogrammierung vorstellt. Wer wissen will, wie Erics Vortrag in etwa aussehen könnte, sollte sich das Interview zu Gemüte führen, das ich mit Dariusz Parys anlässlich der OOP 2009 geführt und hier veröffentlicht habe.

Anschließend wird es praxisorientierter: Charly Lippoth, Chief Technology and Strategy Officer der Nero AG, plaudert aus dem Nähkästchen und wird den Anwesenden verraten, wie die Zusammenarbeit zwischen Intel und Nero funktioniert und wie es möglich ist, dass die Multimedia-Suite Nero 9 derart gut auf Multicore-Plattformen wie dem Core i7 von Intel skaliert. Dass so etwas nicht automatisch geschieht, dürfte klar sein. Klar ist auch, dass Nero unter anderem VTune und die aktuellen Intel Compiler eingesetzt hat, um ein Optimum bei der Multicore-Programmierung zu erzielen. Ach ja, und Beta-Tester von Parallel Studio ist Nero auch.

Heinz Bast, mit dem ich selbst schon sprechen durfte, verschafft dann einen – alles andere als oberflächlichen – Einblick in den Parallel Composer. Mit diesem Tool soll es selbst weniger erfahrenen Parallelprogrammierern gelingen, Multithread-Quellcode zu erzeugen und damit bestehenden oder neuen Software-Titeln den Turbo zu verpassen. Heinz wird im Detail über OpenMP, Intel TBB, Intel Parallel Debugger Extension und einiges mehr reden.

Was Heinz kann, beherrscht Levent Akyil natürlich genauso: technische Zusammenhänge so aufzubereiten, dass diese auch von weniger erfahrenen Zuhörern im Kopf zu einer Geschichte zusammengesetzt werden können. Levent bekommt zu diesem Zweck sogar zwei Sessions zur Verfügung gestellt, in denen er sowohl über den Parallel Inspector als auch den Parallel Amplifier reden wird.

Der Inspector überprüft parallelisierten Quellcode und findet kleinere und größere Bugs zur Laufzeit, was mit herkömmlichen Testtools kaum oder nur mit großem Aufwand möglich ist. Der Amplifier hingegen ist das Tuning-Tool des Parallel Studio, mit dem sich Hotspots aufspüren lassen, der Anteil des Multithread-Codes erhöhen lässt und überflüssige Wartezeiten gefunden werden können.

Nach so viel “tough stuff” können wir dann ab vier Uhr wieder etwas verschnaufen und erneut den Worten von James Reinders lauschen, wenn er kurzzeitig die Gegenwart verlässt, um über die Zukunft der Parallelprogrammierung zu reden. Dabei geht es natürlich um die Weiterentwicklung des Parallel Studio dank des Parallel Advisor, eines fast schon revolutionär anmutenden Tools, das Entwicklern bei der Parallelisierung helfen soll. Und was es mit “Ct” auf sich hat, werden wir ebenfalls lernen.

Tja, und zu all diesen Themen werde ich am 22. April live und exklusiv bloggen. Also, am besten schon mal den RSS-Feed abonnieren oder mir via Twitter folgen.

Der wesentliche Tag ist der Dienstag (21.4.), an dem es eine Menge Infos rund um Multithreading, Multicore-Tools und mehr geben wird. Die Agenda sieht unter anderem Vorträge vor von James Reinders (Intel), Eric Vernié (Microsoft), Charly Lippoth (Nero), Heinz Bast (Intel) und Levent Akyil (Intel). Dabei geht es vor allem um Parallel Studio, die brandneue Toolsuite von Intel, mit deren Hilfe in Zukunft Software-Parallelität einfacher implementiert werden kann.

Was im Detail alles auf der Entwicklerkonferenz passieren wird, gibt es demnächst hier nachzulesen. Versprochen!

Ach ja: Ich werde natürlich nicht nur zu meinem Vergnügen nach Salzburg reisen. So will und werde ich den ganzen Tag von der Intel Software Conference 2009 live und exklusiv auf diesem Sender bloggen. So wahr mir Wifi helfe …

Mein erster Gedanke zur neuen Webseite rund um die parallele Programmierung: sehr aufgeräumt. Denn die Seite besteht lediglich aus einer Handvoll von Verweisen auf Informationen, die sich mit den unterschiedlichen Aspekten des Parallel Computing befassen.

Dazu gehören nützliche Infos zu Parallel Studio, die nur einen Mausklick entfernt sind. Dort könnt ihr euch über die einzelnen Tools der Suite informieren (Composer, Inspector und Amplifier). Ihr könnt euch aber auch für das Beta-Programm eintragen oder sogar bei QT software oder der SOS Software Service GmbH bereits heute ein Paket von Parallel Studio vorbestellen. Oder seht euch einfach mal das Video an, dass Intel mit dem Parallel-Guru James Reinders gedreht hat.

Aber die Webseite hält auch eine Menge an Informationen für alle HPC-Enthusiasten (High Performance Computing) bereit. Hier geht es primär um die ganzen anderen Tools, die Intel für das Multithreaden und Optimieren von Hochleistungsanwendungen bietet. Die Rede ist also von Compilern, Threading Building Blocks, Integrated Performance Primitives, Math Kernel Library, Thread Checker und anderen Tools.

Übrigens: All diese Produkte können ausprobiert und auch gekauft werden. Und einige dieser Software-Pakete kann man sogar kostenlos nutzen, solange man damit keine kommerzielle Anwendungen baut.

Besonders bemerkenswert daran fand ich übrigens die Seite, die den Beitrag verlinkt hat: Es handelt sich um niemand geringeres als MSDN, also das Entwicklerportal von Microsoft, die dem Thema Parallele Programmierung eine eigene Webseite spendiert haben. Und genau dort findet man den Link auf meinen OpenMP-Beitrag. Daneben gibt es noch weitere interessante Einstiege in die Welt der Multithreading-Entwicklung. Da erfährt man eine Menge über die Grundlagen der Parallelprogrammierung, aber auch Tools und Downloads werden dort vorgestellt.

Des Weiteren können interessierte Entwickler nützliche Artikel abgreifen, Webcasts und Videos angucken und Blogs lesen. Und klar, dass es auf der Webseite auch um die Themen Paralleles Programmieren mit .NET geht. Besonders bemerkenswert finde ich auch die Tatsache, dass MSDN für Intel eine eigene Sektion mit Namen “Intel Developer Network” spendiert hat. Dort findet man Wissenswertes zum Parallel Studio und zu anderen Themen.

Fazit: Parallel Computing auf MSDN ist eine bookmark-taugliche Webseite, wenn man in Sachen Parallele Programmierung auf dem Laufenden bleiben will.

So erfährt der interessierte Entwickler in Video Nummer 1 alles über die zur Disposition stehenden Fachbegriffe und wie diese in den fünf anderen Videoclips verwendet werden. Es geht also um so Dinge wie Multicores, Manycores, Threads und andere Begrifflichkeiten, mit denen man sich zunächst beschäftigen sollte, um die anderen vier Videos besser zu verstehen.

Video Nummer 2 verschafft einen guten Überblick, was das in der Beta-Phase befindliche Entwicklertool Parallel Studio alles leistet und welche Funktionen es umfasst. Also Inspector, Composer und Advisor. Wobei dieser derzeit noch nicht Teil von Parallel Studio ist. Kommt aber noch …

Übrigens: Die ins Deutsche transkribierten Trainingsvideos gibt es voraussichtlich ab nächster Woche auf zdnet.de!

Der Thread Profiler ist ein Analysetool, mit dem sich Schwachstellen in parallelisierten Anwendungen grafisch darstellen lassen. Hierzu ist kein Quellcode notwendig, da der Thread Profiler das ausführbare Programm, also die Exe-Datei, untersucht. Dabei können folgende Dinge aufgespürt werden:

• Unter- und überbeschäftigte Ressourcen werden grafisch dargestellt. Damit kann der Programmierer sofort sehen, an welchen Stellen das Programm auf der Multicore-Plattform optimal, ein wenig oder gar nicht skaliert.

• Der Programmablauf wird visualisiert. Es lässt sich auf diesem Weg also feststellen, wo die kritischen Pfade sind, welche Abschnitte der Anwendung sequenziell ausgeführt werden und an welchen Stellen die einzelnen Threads aktiv oder inaktiv waren bzw. wann sie warten mussten.

• Es werden beide Zustände des Programmablaufs grafisch dargestellt: die Ausführung der parallelen Threads und der chronologische Ablauf der Software.

• Mittels Doppelklick auf eine bestimmte Stelle innerhalb des Ablaufplans der Anwendung verzweigt der Entwickler genau an die Stelle innerhalb des Quellcodes, an der die Probleme auftauchen. Damit kann er die kritischen Abschnitte im Sourcecode verifizieren und mit viel Know-how und Erfahrung die Fehler eliminieren.

• Synchronisationsprobleme zwischen den einzelnen Threads lassen sich lokalisieren und beheben. Aber auch ein ungleichgewichtiges Verteilen auf die vorhandenen Threads bzw. Prozessorkerne spürt der Thread Profiler auf.

• Eine OpenMP-basierte Testmethode ermöglicht das Überprüfen unterschiedlicher Programmdesigns, um somit den besten Optimierungsansatz herauszufinden.

Den Thread Profiler gibt es in einer Standalone-Variante oder als Teil des VTune Performance Analyzer. Darüber hinaus fügt er sich nahtlos in Visual Studio 2003, 2005 und 2008 ein und ist für C++ sowie Fortan-Projekte unter Windows konzipiert. Zudem ist er kompatibel mit den Threading Building Blocks und OpenMP. Den Thread Profiler gibt es 30 Tage lang zu Evaluierungszwecken, und das natürlich gratis. Allerdings muss man sich einmalig registrieren, um in diesem Genuss zu kommen.

• Es stellt die Anzahl der vorhandenen CPU-Ressourcen fest, also Prozessoren und Prozessorkerne (und sogar virtuelle CPUs).
• Es stellt fest, wie viele Threads jeweils parallel ausgeführt werden und wie lange dies insgesamt dauert.
• Es berechnet den prozentualen Anteil des parallelisierten Quellcodes.

Der Concurrency Checker kann aber noch mehr: So stellt er fest, ob die Multithread-Anwendung anhand der vorhandenen Prozessorkerne skaliert, diese also vollständig ausnutzt. Dies geschieht übrigens zur Laufzeit der Software. Schön an dem Tool ist aber auch die Tatsache, dass es nicht erst aufwendig installiert werden muss und damit sofort zur Verfügung steht. Und zwar mittels einer grafischen Bedieneroberfläche oder im simplen Zeileneditormodus.

Das Werkzeug kann aber auch auch zu Vergleichszwecken eingesetzt werden: Zunächst lässt man sein serielles Programm einmal mit dem Tool durchlaufen, um so die benötigte Laufzeit herauszufinden. Nach der Parallelisierung geschieht das Ganze noch einmal, womit man einen guten Indikator dafür erhält, wie gut das Multithreaden der Anwendung geklappt hat.

Was der Concurrency Checker allerdings nicht kann ist zweierlei: Es gibt keine Hinweise darauf, welche Stellen der sequenziell programmierten Anwendung das höchste Parallelisierungspotenzial aufweisen. Und zum anderen lassen sich Hotspots und andere Probleme der parallelisierten Software mit dem Tool nicht herausfinden. Wie gut aber, dass es hierfür Werkzeuge wie den VTune Performance Analyzer und den Thread Checker gibt.

Ach ja: Den Concurrency Checker bekommt ihr auf dieser Webseite, und das gratis!

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.

Wie ich ja schon berichtet habe, sucht der Parallel Amplifier nach Optimierungspotenzial in Multithread-Anwendungen. Für eine optimale Performance also. Hierfür leistet das Tuningtool eine ganze Menge:

Aufspüren von Hotspots: An welchen Stellen verbrät die Anwendung besonders viel Zeit und was kann ich dagegen tun? Hierzu werden die kritischen Bereiche grafisch dargestellt und können so schneller identifiziert werden. Zudem liefern die Stack-Aufrufe wichtige Infos über das Laufzeitverhalten der Anwendung.

Parallelität verbessern: Wo klappt es mit der Parallelisierung noch nicht so gut und welche Quellcode-Abschnitte könnte man noch weiter simultan schalten? Um diese Fragen beantworten zu können, erhält der Anwendungsentwickler grafisch aufbereitete Hinweise darauf, welche Programmabschnitte die vorhandenen CPU-Ressourcen über- bzw. unterbeanspruchen. Genau an diesen Stellen lässt sich dann der Quellcode tunen.

Wartezeiten finden: Wo muss die Anwendung zu lange warten, weil bestimmte Abhängigkeiten existieren? Wie kann ich diese Hotspots identifizieren und möglichst auflösen? Auch hierfür stellt der Parallel Amplifier die betreffenden Quellcode-Abschnitte grafisch dar und zeigt in Balkenform die Auslastung der Prozessoren an. So lassen sich Idle-Zustände relativ einfach herausfinden.

Eine weitere praktische Eigenschaft des Parallel Amplifier ist dessen Transparenz in Sachen Laufzeitverhalten. So lässt sich jede Funktion, jeder Callaufruf und jede Prozedur bis auf jede einzelne Quellcode-Zeile herunterbrechen und analysieren. Das gibt dem Programmierer ein gutes Gefühl dafür, wo es klemmt und wo er noch mehr machen muss.

Und es lassen sich mehrere Testläufte aufzeichnen und die Ergebnisse miteinander vergleichen. Auch das sorgt im Problemfall für zusätzliche Hinsweise darauf, dass die parallelisierte Anwendung weiter optimiert werden muss – oder sich gar Fehler eingeschlichen haben.

Im Parallel Inspector steckt ein erprobtes Tool, und zwar der Thread Checker. Daher ist der Inspector primär für das Auffinden von Fehlern zuständig, die sich in Multithread-Code eingeschlichen haben. Um dies alles erledigen zu können, beherrscht das Debug-Tool eine Menge Dinge:

• Es entdeckt Speicherprobleme und -fehler, findet also fehlerhafte Speicherzuweisungen und korrupte Speicherdaten, die möglicherweise zu schwerwiegenden Fehlern während der Laufzeit führen würden.

• Die bekannten Threading-Fehler wie Deadlocks und Race Conditions spürt der Inspector zuverlässig auf. Gerade diese nicht-deterministischen Laufzeitprobleme können mit herkömmlichen Debug-Tools kaum oder nur mit größtem Aufwand gefunden werden.

• Der gesamte Multithread-Code wird nach Fehlern durchforstet. Vor allem die zur Laufzeit auftretenden Probleme erkennt der Inspector und führt den Programmierer direkt zu der betroffenenen Stelle. Dabei wird auch der zugehörige Call Stack angezeigt und die betroffenen Speicherstellen. Warnhinweise und Fehlermarkierungen helfen dabei, die aufgetretenen Probleme besser und schneller zu verstehen.

• Das alles findet dank der Integration in Visual Studio unter einer einheitlichen und vertrauten Entwicklerumgebung statt. Damit lassen sich Fehler schneller erkennen, verifizieren und eliminieren. Das Gute daran: Es muss nicht jedesmal ein “Rebuild” des Quellcodes durchgeführt werden.

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 …

10. März 2009: Go-Parallelism! Ease the Onramp for C/C++ Windows Development Hier erfährt man alles Wissenswerte über Parallel Studio aus erster Hand von einem der Parallelexperten aus dem Hause Intel, nämlich James Reinders persönlich. Dieses Webinar ist ein erster, guter Überblick für alle angehenden Parallelentwickler.

17. März 2009: Solve Parallelism with Intel Parallel Studio In seinem Webinar weiht Joe Wolf künftige Multithread-Entwickler in das mathematische Damenproblem (N-Queens) ein und zeigt, wie es sich mithilfe von Parallel Studio lösen lässt. Hierzu sollte man das Entwicklertool am besten schon auf seinem Rechner installiert haben, um die notwendigen Programmierschritte während der Session durchführen zu können.

31. März 2009: Parallel Implementation Methods with Intel Parallel Composer Intel-Mann Ganesh Rao wird eine Menge über Programmiermethoden wie OpenMP und Intel TBB erzählen, die sich in Parallel Studio einbinden und nutzen lassen. Es geht aber auch um multithread-optimierte Bibliotheken wie Intel IPP und Debugger-Tools wie Intel Parallel Debugger Extension und den Parallel Inspector, der ja Teil von Parallel Studio ist.

14. April 2009: Find Errors in Windows C++ Parallel Applications Mitte April geht’s ans Eingemachte: So lernt man anhand entsprechender Beispiele, wie man mithilfe des Tools Parallel Debugger Extension Programmierfehler im C++-Quellcode aufspürt, um diese bereinigen zu können.

28. April 2009: The Good, the Bad, and the Ugly: Improve Parallel Application Quality and Performance Am Anfang war die Konzeption und das Software-Design, und genau darum geht es im Webinar von Eric Moore. Denn nur mit den richtigen Ansätzen lassen sich parallel programmierbare Anwendungen realisieren. Außerdem gibt es diverse Fallbeispiele bekannter (und unbekannter) Software-Entwickler, die Multithread-Tools erfolgreich einsetzen.

12. Mai 2009: Identify and Address Threading Opportunities Caroline Davidson zeigt, wie sich mit Parallel Studio multithread-taugliche Programmabschnitte identifizieren lassen, wie man anhand virtueller Tests mögliche Schwachstellen im Quellcode aufspürt und wie man diese elegant behebt. Darüber hinaus werden OpenMP und Intel TBB ein Thema in Carolines Webinar sein.

26. Mai 2009: Simplifying Parallelism Implementation with Intel Threading Building Blocks In seinem Webinar gewährt Mike D’Mello tiefe Einblicke in die parallele Programmierung mithilfe der Intell TBB, des Parallel Composers und deren Lambda-Funktionen. Daneben geht es um weitere Themen wie Daten- und Aufgabenparallelität, Pipelining und parallele Warteschlangen.

2. Juni 2009: Static Analysis and Intel C++ Compilers Anfang Juni geht es um das Thema Statische Fehlersuche und darum, wie man damit Laufzeitfehler, Ressourcenprobleme und Sicherheitsmängel aufspürt. Und zwar mit den Tools Parallel Composer und Source Checker.

Darüber hinaus gibt es viele weitere Online-Seminare zu Themen rund um Parallel Studio. Hierfür ist allerdings eine bestimmte Anzahl an Anmeldungen notwendig. Also, worauf wartet ihr noch: Seite ansurfen, Webinar(s) mit der Maus aussuchen, registrieren – fertig. Die Anmeldebestätigung  gibt dann weitere Details zum Webinar preis: Uhrzeit (9:00 am PDT, was 18:00 Uhr unserer Zeitrechnung entspricht), Dauer (eine Stunde) und den Link, mit dem man das Online-Training starten kann.

Ach ja: Um herauszufinden, ob die eigene Plattform Intel-Webinar-tauglich ist, sollte man vorher am besten mal die zugehörige Sektion “System Setup & Compatibility Check” aufsuchen. Nicht, dass man kurz vor Trainigsbeginn sein graues Wunder erlebt …

Wie unterstützt das .NET Framework 4.0 die parallele Programmierung?
Hierfür gibt es diverse Komponenten. Es wird sowohl für den Bereich “Managed Applications” – also C# und Konsorten – als auch für native Programmiersprachen (Fortran, C++ etc.) Bibliotheken und ähnliche Dinge geben. Für beide Programmiermodelle wurde die Concurrency Runtime entsprechend aufgebohrt.

Für die .NET-Entwickler gibt es dann zwei neue Modelle, und zwar die Task Parallel Library (TPL) und PLING. Mit der TPL lassen sich Aufgaben abstrahieren, was unter der Oberfläche und mithilfe der Concurrency Runtime zu Threads führt, um deren Verteilung auf die einzelnen Prozessorkerne sich der Entwickler nicht mehr kümmern muss. PLINQ stellt eine parallelisierte Erweiterung von LINQ dar. Und LINQ wiederum ist “eine Komponente von Microsofts .NET-Framework, mit der SQL-, XLink- und XQuery-Anfragen direkt in .NET-Programmiersprachen wie C# 3.0 oder VB.Net 9.0 als Code statt als String eingebunden werden können” (Quelle: Wikipedia).

Aber auch bei den nativen Sprachen gibt es neue Ansätze bezüglich der Concurrency Runtime: Dies ist zum einen die Parallel Pattern Library, die sich mit den Intel Threading Building Blocks vergleichen lässt. Zum anderen bietet Visual Studio 2010 eine Agent Library für C++ und Co, die bestimmte Aufgaben verwalten und ausführen kann.

Was sagen Sie Entwicklern, wenn Sie mit ihnen über die parallele Programmierung reden?
Das hängt davon ab, mit wem ich spreche. Entwickler, die sich zum Beispiel schon länger mit serviceorientierten Anwendungen beschäftigen, in denen separate Aufgaben durch Dienste erledigt werden, verstehen das Konzept der parallelen Programmierung oft schneller als Programmierer, die nur die rein serielle Entwicklung kennen. Wichtig dabei ist die Erkenntnis, dass es in den meisten Anwendungen Programmteile gibt, die man loslösen kann von der restlichen Programmlogik. Ein Beispiel hierfür ist die parallele Speicherung von Daten.

Für viele Entwickler stellt aber die Parallelisierung von Bedieneroberflächen ein großes Problem dar, da hier vieles noch vom Betriebssystem mithilfe von Nachrichtenschlangen verwaltet wird. Hierfür wird es in .NET 4.0 entsprechende Bibliotheken geben, die diese Aufgaben automatisch übernehmen.

Welche Anwendungsgruppen werden von der Parallelisierung hauptsächlich profitieren?
Da sind zum einen die algorithmus-basierten Anwendungen zu nennen (Bildbearbeitung, Encoder etc.), aber auch klassische Geschäftsanwendungen wie CRM-Systeme bergen viel paralleles Potenzial. Hier können beispielsweise Anfragen an das Backend simultan ausgeführt werden, was die Wartezeiten auf das Ergebnis verkürzt. Allerdings liegt allen parallelisierten Anwendungen eine bestimmte Arbeit vor dem eigentlichen Kodieren zugrunde: Welche Programmbereiche kann ich logisch zusammenfassen und daraus einzelne Aufgaben machen, die als Tasks abstrahiert werden können und sich dann von der Concurrency Runtime als separate Threads ausführen lassen.

Wie unterstützt Microsoft die Community in Sachen Visual Studio 2010, .NET 4.0 und Parallelprogrammierung?
Neben den kommerziellen Konferenzen wie der Microsoft Tech-Ed oder dem Tech Summit gibt es beispielsweise die Möglichkeit, über Microsoft in ein Early-Adopter-Programm hineinzukommen, um auf diesem Weg Betatester zu werden. Darüber hinaus kann man uns auch direkt auf gewünschte Workshops und ähnliche Dinge ansprechen. Und natürlich nutzen wir die gesamte Online-Vielfalt wie Webcasts und Blogs, um unsere Themen zu kommunizieren. Aber auch viele Microsoft-nahe Communities stehen derlei Themen offen gegenüber. Dort trägt Microsoft an und ab selbst zur Aufklärung in Sachen Multicore und ähnlichen Dingen bei.

Tja, und ab sofort steht das komplette Paket Parallel Studio zum Beta-Testen bereit. Das Tool besteht aus den drei Programmteilen Composer, Inspector und Amplifier. Was der Composer kann, muss ich nicht noch mal erklären. Der Inspector untersucht ähnlich wie der Thread Checker parallelisierten Code auf mögliche Fehler hin. Das sind vor allem schlimme Dinge wie Deadlocks und Race Conditions, die sich meist erst zur Laufzeit erkennen geben und mit herkömmlichen Testmethoden oder Debuggern kaum aufspürbar sind.

Der Amplifier schließlich ist für das Finetuning der parallelisierten Anwendung zuständig. So findet er beispielsweise selbstständig seriellen Quellcode, der noch parallelisiert werden könnte. Aber auch Engstellen im Programmablauf, die sich durch die Parallelisierung ergeben haben, stöbert der Amplifier auf.

Um am Betaprogramm von Parallel Studio teilnehmen zu können, sollte man Microsoft Visual Studio 2005 oder 2008 einsetzen (außer Express), in C oder C++ programmieren, und das unter Windows XP, Vista, Windows Server 2003 oder 2008. Mac- und Linux-Anwender bleiben leider (erst mal) außen vor.

Und hier geht es zur Teilnahme am Betaprogramm (für die Anmeldung ist lediglich eine gültige E-Mail-Adresse erforderlich). Viel Spaß beim Testen!

Daher steckt eine ganze Menge Multicore-Potenzial in der Manipulation von Bildern, vor allem dann, wenn es sich um große Digitalfotos handelt. Dabei ist die Parallelisierbarkeit völlig unabhängig vom Format, so dass Bilder im sogenannten RAW-Format genauso von parallelisierten Algorithmen profitieren wie JPEG- oder TIFF-Dateien.

Wie wichtig in solch einem Fall das optimale Zusammenspiel von Hard- und Software ist, hat unter anderem Nik Software erkannt, ein Anbieter von Bildbearbeitungstools, die sich an professionelle Fotografen und ähnliche Menschen richten. Eines der Highlight-Produkte von Nik Software nennt sich Silver Efex Pro. Dabei handelt es um einen Schwarzweiß-Filter für Adobe Photoshop und Apple Aperture, mit dem sich Farbbilder in S/W-Kunstwerke verwandeln lassen. Hierfür setzt Nik Software auf die eigene Manipulationstechnik U Point, die es erlaubt, anhand definierter Bildbereiche (sogenannter Kontrollpunkte) diese separat zu bearbeiten.

Für eine bestmögliche Skalierung von Silver Efex Pro auf Multicore-Plattformen musste Nik Software allerdings eine ganze Menge tun. Hierzu gehörte unter anderem eine gründliche Analyse des Quellcodes mit VTune Performance Analyzer, um die Hotspots, also die kritischen Programmstellen, zu identifizieren.

Anschließend haben die Software-Entwickler die verschiedenen technischen Möglichkeiten geprüft, mit welchen Methoden die vorhandene Datenparallelität optimal in entsprechende Algorithmen umgesetzt werden kann. In Frage kamen hierfür OpenMP, die Threading Building Blocks und eine selbst implementierte Lösung auf Basis von Boost und Posix Threads.

Die Wahl fiel am Ende auf die selbst implementierte Lösung, da sie ein Maximum an Kontrolle, Flexibilität und Portierbarkeit gewährleistet. Die fertige Implementation des Thread pool pattern erlaubt hierbei eine relativ problemlose Übersetzung der Algorithmen in eine parallele Formulierung sowohl unter Windows als auch auf dem Mac.

Und klar, anschließend musste noch auf Teufel komm raus debuggt werden, und zwar mit den passenden Tools wie dem Thread Checker und Thread Profiler. Damit der parallelisierte Quellcode auch wirklich optimal auf mehreren Threads sprich Prozessorkernen skaliert. Und die Mühe hat sich offensichtlich gelohnt: Das Fotomagazin “Foto Video Digital” aus dem Hause Chip hat Silver Efex Pro als eine der besten Bildbearbeitungsprogramme des Jahres 2008 gekürt. Na also!

In beiden Fällen wollten wir natürlich wissen, welche Anstrengungen unternommen wurden, um die Spieletitel zu parallelisieren. Tja, und heute haben wir Teil eins unserer Fragen zurückbekommen, und zwar von Crysis. Geantwortet hat der Director of Technology höchstpersönlich, Mister Mark Atkinson. Mark zeichnet übrigens verantwortlich für erfolgreiche Titel wie Burnout Revenge und Football Manager 2009, die er vor seiner Zeit bei Crytek mitentwickelt hat.

Software Dev Blog: Mit welchen Tools haben Sie Crysis für Multicore-Plattformen optimiert?
Mark Atkinson: Wir setzen im Wesentlichen eigene Tools ein, um den Quellcode unserer Spieletitel wie Crysis für Multicore-Plattformen zu optimieren. Aber auch externe Anwendungen wie der VTune Performance Analyzer kommen bei uns zum Einsatz. Dieser ist für uns vor allem wegen des Thread Profilers interessant, mit dessen Hilfe wir überprüfen können, in welchem Umfang und in welcher Qualität die Parallelisierung des Spieletitels gelungen ist.

Welche Hürden mussten Sie bei der Multicore-Optimierung überwinden?
Atkinson: Die wesentliche Arbeit bestand darin, die Game-Engine völlig umzukrempeln. Wir mussten nämlich große Teile des sequenziell programmierten Quellcodes parallelisieren, damit bestimmte Aufgaben wie die KI, Effekte etc. gleichzeitig ablaufen. Nur so konnten wir das optimale Spielerlebnis erreichen, das Crysis auszeichnet.

Welche Tipps würden Sie Entwicklern geben, wenn diese parallelen Programmcode schreiben wollen?
Atkinson: Die Hauptregel lautet: Erstelle fehlerfreien Sourcecode vom ersten Moment an. Denn parallel programmierte Anwendungen und Spiele lassen sich nur sehr aufwändig testen und debuggen. Daher sollte man von Anfang an darauf achten, dass sich erst gar keine Fehler in den Code einschleichen. Wir setzen hierfür erprobte Methoden, Bibliotheken und Hilfesysteme ein, die uns dabei unterstützen. Außerdem sorgen wir dafür, dass unsere Software-Entwickler bestens in Sachen Paralellprogrammierung ausgebildet sind. Denn nichts erfordert mehr Know-how als der Umstieg von der sequenziellen auf die parallele Programmierung.

We need languages that take full advantage of multicore processing

Genau darum geht es heute. Nicht die Hardware ist der Hemmschuh, sondern die Software, sprich die Programmiersprachen, die derzeit zur Verfügung stehen. Oder wie es der Autor passend formuliert:

Computer evolution, however, is now headed down an entirely new path: instead of simply becoming faster, our computer processors are being conjoined to work together. That new computer architecture requires a serious evolution in computer programming. Without it, we can only scratch the surface of what multicore computing can really do.

Das ist die Kernthese, mit der sich auch dieses Blog immer wieder beschäftigt, denn die Zeiten der GHz-Spirale sind endgültig vorbei, und eine neue Ära des “Parallel Computing” ist angebrochen – sogar im Mainstream-Markt. Denn was die HPC-Gemeinde seit Jahren vormacht, ist auf dem gemeinen Desktop-PC und Notebook jetzt auch möglich, wird nur zu selten richtig eingesetzt.

Eine weitere interessante These stellt der TR-Artikel in Sachen “Umdenken” auf: So wie seinerzeit diverse Software-Entwickler den Trend der objektorientierten Programmierung verschlafen haben, droht heute die Gefahr erneut, da das Schreiben von parallel-orientiertem Sourcecode ebenfalls einen völlig neuen Denkansatz erfordert. Dies betrifft vor allem den gemeinsamen Zugriff auf Daten, dessen Koordinierung in parallelen Systemen bedeutend anspruchsvoller ist als im seriellen Universum.

Aber es gibt laut Paul Tyma, dem Autor des zitierten Beitrags, auch gute Nachrichten: Denn Sprachen wie C++ und Java, die von ihrer Anlage her ja seriell sind, haben große Änderungen erfahren und sind mittlerweile durchaus in der Lage, in Multicore-Umgebungen zu skalieren. Dies machen Tools wie die Intel Threading Building Blocks oder die Intel C++ Compiler deutlich, in denen ein ganze Menge an Multithread-Potenzial steckt. Mit diesen Hilfsmitteln gelingt auch weniger erfahrenen Parallel-Programmierern der Einstieg in die Multicore-Welt. Was die Entwickler allerdings nicht davon abhalten sollte, ihre Software-Projekte in Zukunft akribisch vorzubereiten und über bestimmte Dinge gründlich nachzudenken.

Fazit: Mit den gegebenen Tools könnte der Wechsel von der seriellen zur parallelen Programmierung bald in großem Maßstab gelingen. Oder wie es Paul Tyma zusammenfasst:

With these new languages and programmers’ development of new skills, the acceleration of computing power that we’ve almost come to take for granted will soon be back on track.

Übrigens: Paul war früher bei Google, hat sich dort intensiv mit dem Thema Multicore-Programmierung beschäftigt. Er sollte also wissen, worüber er spricht …

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

Die Intel TBB lassen sich in sechs fundamentale Einzelteile zerlegen:

1. Algorithmen
2. Container
3. Memory Allocator
4. Mutual Exclusion
5. Timer
6. Task Scheduler

1. Die TBB-Algorithmen richten sich vor allem an parallel ausführbare Schleifenkonstrukte, aber auch Sortieralgorithmen lassen sich mithilfe der TBB recht problemlos parallelisieren. Die zugehörigen Funktionen nennen sich parallel_for, parallel_reduce, parallel_scan, parallel_while, parallel_pipeline und parallel_sort. Eine genauere Betrachtung dieser Funktionen findet auf dem Software Dev Blog in einem späteren Beitrag statt.

2. Die Intel TBB setzen sich aus drei Containern zusammen: queue, vector und hash table. Diese Container findet man zwar auch in den Standard Template Libraries von C++ und Fortran, diese sind allerdings weniger thread-sicher als die der Intel TBB.

3. Der Memory Allocator der Intel TBB ist äußerst skalierbar und daher in der Lage, gemeinsam genutzten Speicher auf mehrere Threads so zu verteilen, dass sich diese nicht gegenseitig behindern. Damit kümmert sich der Allocator der TBB um das gleichzeitige Ausführen der wichtigsten Funktionen wie malloc, new und delete.

4. Die Mutual Exclusions der Intel TBB kümmern sich um konsistente Daten bei der Ausführung paralleler Funktionen. Es geht also um das Sperren und Freigeben von Daten (Lock und Unlock) während der Ausführung verschiedener Threads. Somit ist gewährleistet, dass sich Threads bei der Manipulation von Daten nicht ins Gehege kommen, was zu richtigen Ergebnissen führen soll.

5. Die in den Intel TBB implementierte Timing-Funktion – also das Ermitteln der Programmdauer per Subtraktion zweier Uhrzeiten – ist für viele Entwickler ein wichtiger Aspekt. Von Bedeutung dabei ist aber auch ein Ergebnis, auf das man sich selbst dann verlassen kann, wenn der zugehörige Thread auf mehreren Prozessorkernen parallel ausgeführt wird.

6. Eine Kernfunktion der Intel TBB ist der Task Scheduler, der die Vielzahl unterschiedlicher Aufgaben, die mithilfe der Algorithmen aus Punkt 1 definiert werden, auf die vorhandenen Threads, also Prozessorkerne, optimal verteilt. Um dies zu garantieren, beherrscht der Task Scheduler das Load Balancing, was dazu führt, dass parallele Aufgaben möglichst effizient von den vorhandenen CPU-Cores ausgeführt werden. Folge: Maximale Performance der Anwendung!

Einer der vier Teilprogramme von Parallel Studio nennt sich Parallel Composer, der es Software-Entwicklern dank vorgefertigter Bibliotheken, Funktionen und Programmschnipseln relativ einfach machen soll, ihrem Quellcode paralleles Leben einzuhauchen. Und mit dem gestrigen Tag wurde das Beta-Programm für den Parallel Composer gestartet. Wer also unter C++ programmiert, hierfür Windows Visual Studio 2005 oder 2008 einsetzt und seine Anwendungen für Intel-Multicore-CPUs optimieren will, sollte sich eine Beta-Version des Parallel Composers besorgen.

Neben dem Beta-Programm für den Parallel Composer stellt Intel eine Menge Hilfe, Tipps und Tricks rund um das parallele Programmieren mit dem neuen Tool zur Verfügung. Ob das Hilfestellungen bei Installationsproblemen sind oder nützliche Tipps, wie sich der Intel C++-Compiler innerhalb des Microsoft Visual Studio Team Foundation Server einsetzen lässt – hier findet man eine Menge Antworten auf seine Fragen rund um den Intel Parallel Composer.

Hinweis: Ich muss noch eines klar stellen: Die Beta-Phase des Intel Parallel Studio hat entgegen früherer Ankündigungen noch nicht begonnen, was aber nur einen kurzen Aufschub bedeutet. Daher wird das Ganze mit einem Teilprogramm, dem Parallel Composer, gestartet.

Videotipp: Wer mehr in Bild und Ton zum Intel Parallel Studio im Speziellen und zum parallelen Programmieren unter Windows im Allgemeinen lernen will, sollte sich mal die Videochats mit Ralph de Wargny von Intel und Steve Teixeira, Parallel-Guru von Microsoft, ansehen.

Dazu zählt beispielsweise der C++-Compiler, den es in einer Professional und Standard Edition gibt. Vor allem die Profi-Variante hat es in sich: Volle Multithread-Unterstützung für paralleles Programmieren, was zum Beispiel automatisches Multithreading umfasst, aber auch Vektorisierung, OpenMP oder Loop Unrolling. Darüber hinaus bietet die Compiler-Suite leistungsstarke C++-Bibliotheken für noch mehr Parallelismus, mathematische Funktionen und Multimediaanwendungen.

Aber nicht nur den Mac-kompatiblen C++-Compiler hat Intel zu bieten, sondern auch Intel Threading Building Blocks, Intel Integrated Performance Primitives und Intel Math Kernel Library, die allesamt perfekt auf den Intel C++-Compiler für Mac OS X abgestimmt sind.

Das Beste daran ist jedoch die volle Integration der Intel-Tools in die Apple-eigene Entwicklerumgebung Xcode, mit der sich Mac-Programme sehr intuitiv und sehr elegant schreiben lassen. Darüber hinaus kann man sich als Entwickler sicher sein, dass die eigenen Anwendungen optimal auf Intel-basierten Apple-Rechnern laufen und das Multithread-Potenzial bestmöglich ausschöpfen.

Übrigens: Neben dem C++-Compiler bietet Intel auch einen Fortran-Compiler für die Mac-OS-X-Entwicklergemeinde. Damit diese nicht zu kurz kommt.

Falls Sie sich jetzt fragen, ob Sie das Ganze erst mal ausprobieren können, bevor Sie die Intel-Mac-Dev-Tools kaufen – ja, Sie können. Hierfür brauchen Sie sich lediglich für den kostenlosen Intel Premier Support anzumelden und können anschließend das entsprechende Tool aus dem Evaluation Center auf Ihren Mac laden und dort ausgiebig testen. Kommerzielle Anwendungen lassen sich damit aber nicht erstellen!

Intel Parallel Studio setzt sich aus vier einzelnen Programmen zusammen, die entweder als Komplettpaket genutzt werden können oder aber jedes Tool für sich alleine.

Der Parallel Advisor untersucht bestehenden Sourcecode auf mögliches Parallelisierungspotenzial und schlägt bestimmte Routinen und Funktionen vor, mit deren Hilfe aus einfachen Programmen parallelisierte Anwendungen werden, die optimal auf Intel-Multicore-Plattformen laufen. Darüber hinaus analysiert der Advisor mögliche Programmkonflikte und nennt passende Lösungen.

Der Parallel Composer erlaubt die schnelle und relativ einfache Implementierung paralleler Funktionen und Programmschnipsel, die der Entwickler mithilfe fertiger Routinen und Bibliotheken in seinen bestehenden Sourcecode integrieren kann. Damit kann der Programmierer die bestmöglichen Ansätze für sein Projekt herausfinden und einsetzen.

Der Parallel Inspector fungiert als eine Art Debugger, der anhand der implementierten Multithread-Routinen und -Funktionen einen zuverlässigen und fehlerfreien Sourcecode garantiert. Hierfür spürt das Tool Fehler im Multithread-Code auf, die mit herkömmlichen Werkzeugen nur schwer zu finden wären. Der Inspector betreibt unter anderem intensive Ursachenforschung in Sachen Endlosschleifen, Deadlocks und anderen Fehlern.

Der Parallel Amplifier schließlich hilft beim Finetuning der parallelisierten Anwendung, indem er ungewollten und unvorhergesehen Singlethread-Code ermittelt, der sich als echter Flaschenhals in einer Multithread-Anwendung erweisen kann.