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?!