OpenMP - PVS - Westfälische Wilhelms-Universität Münster

OpenMP
Prof. Sergei Gorlatch, Michel Steuwer
Sommersemester 2012
Gruppe PVS (Parallele und Verteilte Systeme)
Institut für Informatik
Westfälische Wilhelms-Universität Münster

Compiler-unterstützte
Parallelisierung mit OpenMP
• Bisher betrachtete Ansätze zur Parallelprogrammierung verlangen
vom Benutzer explizite Beschreibung der Parallelität
• Mehrere parallel ablaufende Prozesse, Threads oder Work-items
• Datenpartitionierung zwischen den Prozessen
• Kommunikation
• Synchronisation (Lock/Unlock, Barrier, etc.)
• Dies macht Parallelprogrammierung schwierig und fehleranfällig
• Wir werden heute einen populären Ansatz kennenlernen, wo die Last der
Parallelisierung teilweise vom Compiler übernommen wird:
• OpenMP (Open MultiProcessing)
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
2

OpenMP ist ...
OpenMP
• ein Standard zur Multithread-Programmierung auf Multiprozessoren mit
gemeinsamem Speicher
• spezifiziert für C/C++ und Fortran; verfügbar auf verschiedenen
Plattformen, z.B. Unix, Windows, ...
• von einer Gruppe führender Hard- und Software-Hersteller (u. a. AMD, IBM,
Intel, Microsoft, NVIDIA) gemeinsam definiert worden
• Version 1.0 erschien 1997 für Fortran und 1998 für C/C++
• Aktuell ist Version 3.0
• Quelle: http://www.openmp.org
OpenMP ist nicht ...
• notwendigerweise von allen Herstellern identisch implementiert
• geeignet für die Programmierung von GPUs (zumindest noch nicht)
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
3

Ziele von OpenMP
• Standard: einheitlich für verschiedene Architekturen/Plattformen, z.Zt. vor
allem für Multi-core CPUs verwendet
• Kurz und bündig: Wenige einfache Direktiven.
Ursprünglich: nur 2-3 Direktiven vorgesehen
Inzwischen: ziemlich groß geworden
• Einfach und vielseitig:
• Inkrementelles Parallelisieren: Einem sequentiellen Programm werden
schrittweise Direktiven hinzugefügt
• Im Gegensatz dazu: PThreads ist ein „Alles oder Nichts“ Ansatz
• Grob- und feinkörnige Parallelität ist möglich
• Portabilität : Fortran (77,90,95), C, C++
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
4

Programmiermodell:
Eigenschaften
• Parallelität wird ausschließlich über Compiler-Direktiven (sog. Pragmas)
spezifiziert
• Direktiven sind in C/C++ Code eingebettet
• Der Standard unterstützt verschachtelte Parallelität, die wird jedoch nicht
von jeder Implementierung garantiert
• Standard erlaubt dynamische Threads, d. h. die Anzahl benutzter Threads
kann variieren. Auch das wird nicht von jeder Implementierung unterstützt
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
5

# include
int main ( int argc , char * argv []) {
int var1 , var2 , var3 ;
}
/* sequential code */
...
Code-Struktur: Beispiel
/* beginning of parallel section :
fork a team of threads , specify variable scope */
# pragma omp parallel private (var1 , var2 ) shared ( var3 )
{
/* parallel section executed by all threads */
...
} /* all threads join master thread and disband */
/* resume sequential code */
...
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
6

• Mehrere Threads auf gemeinsamem Speicher
• Fork-Join Modell
master
thread
F
O
R
K
Programmiermodell: Illustration
{parallel region}
J F
J
O
O
O
I
R
I
N K
N
{parallel region}
• Der ursprüngliche Master-Thread läuft sequentiell bis zum parallelen Bereich
• Fork: Master-Thread erzeugt ein Team paralleler Threads, die Anweisungen
des parallelen Bereichs parallel verarbeiten
• Join: Synchronisation und Terminierung des Teams am Ende des parallelen
Bereiches. Nur der Master-Thread bleibt übrig
• Programmierer kann volle Kontrolle über Parallelität haben
⇒ Explizites (nicht vollautomatisches) Programmiermodell
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
7

• Format: #pragma omp Direktive [Klausel[[,] Klausel]...]
• #pragma omp: Identifizierung einer OpenMP-Direktive
• Direktive: Gültige OpenMP-Direktive
• Klausel: Gültige OpenMP-Klausel (optional).
Die Reihenfolge mehrerer Klauseln ist beliebig
• Zeilenumbruch am Ende ist zwingend erforderlich
• Generelle Regeln:
Direktiven-Format
• Die Syntax ist case-sensitive
• Nur ein Direktiven-Name je Pragma ist erlaubt (einige Kombinationen sind
zur Abkürzung erlaubt)
• Eine Direktive bezieht sich nur auf die nachfolgende Anweisung, die auch ein
Block sein kann, d. h. ein in { } eingeschlossener Abschnitt im Quellcode
• Zeilen können umgebrochen werden, wenn der Zeilenumbruch mit einem
Backslash („\“) maskiert wird.
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
8

# pragma omp parallel [ Klausel [[ ,] Klausel ]...]
structured_block
Direktive parallel
• Ein paralleler Bereich ist ein Code-Block, der von mehreren Threads
ausgeführt wird
• Master-Thread erzeugt ein Team von Threads, wobei er selbst zum ersten
Thread dieses Teams wird
• Wieviele Threads gestartet werden, d. h. wie groß das Team ist, wird von der
OpenMP Implementierung bestimmt
• Alle Threads führen ein Duplikat des folgenden Code-Blocks
(structured_block) aus
• Implizite Synchronisation (Barriere) passiert am Ende des Blockes
• Danach terminieren alle Threads außer dem Master-Thread
• Parallele Bereiche können ineinander verschachtelt werden (sog.
verschachtelte Parallelität)
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
9

Quellcode:
Beispiel: Hello World
int main ( int argc , char * argv []) {
/* fork a team of threads */
# pragma omp parallel
{ /* obtain and print Hello World */
printf (" Hello World from OpenMP \n");
} /* threads join master thread and terminate */
}
Compilieren mit: gcc -fopenmp main.c
Ausgabe auf einem Rechner mit 8 logischen Kernen:
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
Hello World from OpenMP
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
10

• Shared-Memory Programmiermodell:
die meisten Variablen sind shared by default
Variablen und Gültigkeitsbereiche
• Private Variablen: z.B. Indizes in Schleifen, Stack-Variablen (lokale Variablen
in Funktionen) sind private by default
Klausel shared(i)
• Auf Variable i kann in jedem Thread des Teams zugegriffen werden
Klausel private(i)
• Eine neue Variable desselben Typs wird in jedem Thread des Teams
deklariert, aber nicht initialisiert
• Alle Referenzen auf die ursprüngliche Variable werden ersetzt durch
Referenzen auf die neuen Variablen
Klausel firstprivate(i)
• Wie private, die neuen Variablen werden aber mit dem Wert der
ursprünglichen Variable initialisiert
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
11

• Arbeitsverteilung = engl. work-sharing
Direktiven zur Arbeitsverteilung
• Idee: Berechnungen von mehreren Bereichen auf ein Thread-Team verteilen
• Es werden keine neuen Threads erzeugt
• Implizite Barriere am Ende des Bereichs
• Klausel nowait hebt implizite Barriere am Ende eines Bereichs auf
• Work-sharing Konstrukte werden nur innerhalb von parallelen Bereichen
(#pragma omp parallel) verwendet
• Work-sharing Konstrukte müssen in allen Threads (oder keinem) eines Teams
und in gleicher Reihenfolge angegeben werden
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
12

F O R K
for
master thread
team
Direktiven zur Arbeitsverteilung:
Illustration
F O R K
F O R K
section team single
J O I N J O I N J O I N
master thread
for:
Iterationen einer Schleife
parallel ausführen
= Datenparallelität
master thread
master thread
sections:
mehrere, parallele
Bereiche, mit einem
Thread pro Bereich
= Taskparallelität
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
13
master thread
team
master thread
single:
Sequentialisierung eines
Code-Bereiches

# pragma omp for [ Klausel [[ ,] Klausel ]...]
for_loop
Direktive for
• Die Schleife, die dieser Direktive direkt folgt, parallel ausführen, d. h.
verschiedene Iterationen gleichzeitig ausführen
• Arbeit verteilen, ohne explizite Datenverteilung
• Wenn nicht innerhalb eines parallelen Bereichs, dann sequentiell
• Eine Klausel schedule beschreibt, wie die Iterationen auf die Threads
aufgeteilt werden (Standard: implementierungsabhängig):
# pragma omp for schedule ( Art [, chunk_size ])
Dabei kann Art static, dynamic, guided, runtime oder auto sein
(siehe nächste Folie)
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
14

Klausel schedule
• static: Iterationen in Blöcke der Größe chunk_size (Standard:
gleichförmig) aufteilen und statisch, d. h. einmal zu Beginn der Schleife, auf
Threads verteilen
• dynamic: Iterationen in Blöcke der Größe chunk_size (Standard: 1) aufteilen
und dynamisch, d. h. zur Laufzeit der Schleife, auf freie Threads verteilen
• guided: Iterationen in Blöcke aufteilen und dynamisch auf freie Threads
verteilen. Dabei exponentielles Reduzieren der Blockgröße bis zu einer Größe
von chunk_size (Standard: 1)
• runtime: Scheduling wird zur Laufzeit bestimmt, dazu muss die
Umgebungsvariable OMP_SCHEDULE als type [,chunk_size] definiert sein,
wobei type static, dynamic oder guided seien muss
• auto: Scheduling wird vom Compiler oder der Laufzeitumgebung gewählt
(ab OpenMP 3.0)
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
15

Beispiel: Vektoraddition
• Arrays a,b,c und Variable n global (shared)
• (Schleifen-) Variable i lokal (private) in allen Threads
• Aufteilung in Blöcke der Größe 100 und dynamisch auf Threads verteilen
# include
# define CHUNK 100
# define N 1000
int main ( int argc , char * argv []) {
int i, n, chunk ; float a[N], b[N], c[N];
for (i =0; i < N; i ++)
a[i] = b[i] = i * 1.0;
n = N; chunk = CHUNK ;
# pragma omp parallel shared (a,b,c,n, chunk ) private (i)
{
# pragma omp for schedule ( dynamic , chunk )
for (i =0; i < n; i ++)
c[i] = a[i] + b[i];
} /* end of parallel region */
}
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
16

# pragma omp sections [ Klausel [[ ,] Klausel ]...]
{
[# pragma omp section ]
structured_block
[# pragma omp section ]
structured_block
...
}
Direktive sections
• Enthält mehrere Bereiche, wobei jeder Bereich in genau einem Thread genau
einmal ausgeführt wird
• Bereiche werden mit der section Direktive angegeben
• Sprünge aus/in eine(r) section sind verboten.
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
17

Beispiel für sections
• Taskparallelität: ein Thread führt die Funktion foo, der andere bar
int main ( int argc , char * argv []) {
# pragma omp parallel
{
# pragma omp sections nowait
{
# pragma omp section
foo ();
# pragma omp section
bar ();
} /* end of sections */
} /* end of parallel region */
}
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
18

Syntaktische Abkürzungen
• Paralleler Bereich, der genau ein for oder sections enthält, kann mit
einem statt zwei Pragmas beschrieben werden
• Beispiel: Vektoraddition mit statischem Scheduling
# include
# define CHUNK 100
# define N 1000
int main ( int argc , char * argv []) {
int i, n, chunk ; float a[N], b[N], c[N];
for (i = 0; i < N; i ++)
a[i] = b[i] = i * 1.0;
n = N; chunk = CHUNK ;
# pragma omp parallel for shared (a,b,c,n) private (i) \
schedule ( static , chunk )
for (i = 0; i < n; i ++) c[i] = a[i] + b[i];
}
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
19

Klausel reduction
# pragma omp for reduction ( operator : var1 [[ , var2 ]...])
for_loop
• Reduziert alle Variablen, angegeben in einer Liste
• Jeder Thread erzeugt eine private Kopie aller Variablen der Liste
• Der Operator wird auf alle privaten Kopien einer shared Variable angewendet
und das Resultat in die globale shared Variable geschrieben
• Nur skalare Variablen sind in der Liste erlaubt
• Reduktionsvariablen dürfen nur in einfachen Anweisungen der Form
x++, --x, x += expr, x -= expr, etc. vorkommen
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
20

# include
int main ( int argc , char * argv []) {
int i, n, chunk ;
float a [100] , b [100] , result ;
/* some initializations */
n = 100; chunk = 10; result = 0.0;
}
Beispiel für Reduktion:
Skalarprodukt
for (i = 0, i < n; i ++) {
a[i] = i * 1.0;
b[i] = i * 2.0; }
# pragma omp parallel for default ( shared ) private (i) \
schedule ( static , chunk ) \
reduction (+: result )
for (i = 0; i < n; i ++)
result = result + (a[i] * b[i]);
printf (" Final result = %f\n" , result );
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
21

# pragma omp single [ Klausel [[ ,] Klausel ]...]
structured_block
Direktiven single und master
• Ein Bereich wird von nur einem (beliebigen) Thread ausgeführt, andere
Threads warten an einer impliziten Barriere
Direktive master
# pragma omp master
structured_block
• Ein Bereich wird nur vom Master-Thread ausgeführt, andere Threads
überspringen ihn
• Wie single, aber ohne implizite Barriere
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
22

Synchronisation
Motivierendes Beispiel:
Mehrere Threads modifizieren gleichzeitig eine Variable x (Initialwert = 0)
int main ( int argc , char * argv []) {
int x = 0;
# pragma omp parallel shared (x)
{
x = x + 1;
}
printf ("%d\n", x);
}
• Bei zwei Threads, welcher Wert wird für x ausgegeben? Antwort: 1 oder 2
• Race condition, da die Variable x als shared von allen Threads geteilt wird
• Lösung: Inkrementierung von x synchronisieren.
Es gibt mehrere Direktiven dafür
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
23

# pragma omp critical [( name )]
structured_block
Direktive critical
• Spezifiziert einen Bereich, der immer nur von einem Thread zur selben Zeit
ausgeführt werden darf
• Optionaler Name: critical-Bereiche mit gleichem Namen bzw. alle
unbenannten werden als ein Bereich behandelt
Beispiel: Dequeuing gleicher Task von zwei Threads vermeiden
# pragma omp parallel shared (x,y) private ( x_next , y_next )
{
# pragma omp critical ( xaxis )
x_next = dequeue (x);
work ( x_next );
# pragma omp critical ( yaxis )
y_next = dequeue (y);
work ( y_next ); } /* end of parallel region */
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
24

# pragma omp atomic
statement
Direktive atomic
• Spezifiziert, dass ein Speicherbereich nur atomar geändert werden darf
• Bezieht sich nur auf einen einfachen nachfolgenden Befehl
• Ein atomarer Befehl darf folgende Formen haben:
x++, ++x, x–, –x, x binop= expr
• x: Skalare Variable
• expr: skalarer Ausdruck, der keine Referenz auf x benutzt
• binop: einer der Operatoren (nicht überladen) +,*,-,/,&,^,|,>>,

Beispiel: Race conditions vermeiden
# pragma omp parallel for shared (x,y,index ,n)
for (i = 0; i < n; i ++) {
x[i] += work1 (i);
# pragma omp atomic
y[ index [i]] += work2 (i);
}
Beispiel für Direktive atomic
• Der Zugriff auf x muss nicht geschützt werden, da in jeder Iterationen
unterschiedliche Elemente von x zugegriffen wird
• Der Zugriff auf y muss geschützt werden, da durch index[i] nicht mehr
garantiert werden kann, dass in jeder Iteration auf unterschiedliche Elemente
von y zugegriffen wird
• In Vergleich zu critical können hier verschiedene Elemente von y
gleichzeitig geändert werden
• Beachte: Nur lesen und schreiben von y ist atomar, Berechnung in work2
ist nicht atomar
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
26

Task-Parallelität
(ab OpenMP 3.0)
• Jedes, mit #omp parallel, erzeugtes Thread-Team besitzt eigenen Pool von
Tasks, die von einem beliebigen Thread ausgeführt werden können
• Erlaubt die Parallelisierung einer größeren Menge von Anwendungen
Motivierendes Beispiel: Verkettete Liste
while ( elem != NULL ) {
work ( elem );
elem = elem -> next ;
} /* end of loop */
• Direkte Parallelisierung nicht möglich, stattdessen Lösung mit for:
1 Listenelemente zählen
2 Zeiger auf Anfänge von Iterationsblöcken speichern
3 while-Schleife in for-Schleife transformieren
• Besserer Lösung mit der Direktive task
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
27

# pragma omp task [ Klausel [[ ,] Klausel ]...]
structured_block
Direktive task
• Spezifiziert einen Bereich (Task), der von nur einem Thread ausgeführt wird
(ähnlich zu section)
• An einem task scheduling point kann ein Thread die Ausführung des
aktuellen Tasks unterbrechen und zu einem anderen Task wechseln
• Ein task scheduling point wird implizit von #pragma omp task, sowie am Ende
eines parallelen Bereichs erzeugt
• Wird als Klausel untied angegeben, so kann der Task an einem task
scheduling point von einem anderen Thread ausgeführt werden
• Sprünge aus/in einen task sind verboten
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
28

Beispiel: Verkettete Liste
elem = head ;
# pragma omp parallel
{
# pragma omp single nowait
{
while ( elem != NULL ) {
# pragma omp task firstprivate ( elem ) /* create one task */
{ work ( elem ); } /* per list element */
elem = elem -> next ;
} /* end of while loop */
} /* end of single , no implied barrier */
} /* end of parallel region , implicit task scheduling point ,
wait until all tasks are finished */
• Ein Thread erzeugt alle Tasks
• Alle Task warten am Ende des parallelen Bereichs und bearbeiten die
erzeugten Tasks
• Durch nowait warten die anderen Threads nicht am Ende des single
Blocks und beginnen zu arbeiten, sobald der erste Task erzeugt wird
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
29

# pragma omp taskwait
Direktive taskwait
• Wartet auf die Beendigung aller vom aktuellen Task bisher erzeugten
Kind-Tasks
• Die taskwait Direktive erzeugt einen impliziten task scheduling point, an
dem ein Taskwechsel stattfinden kann
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
30

* basic algorithm : f(n) = f(n -1) + f(n -2) */
long comp_fib_number ( int n) {
long fnm1 , fnm2 , fn;
}
if (n == 0 || n == 1) return n;
# pragma omp task shared ( fnm1 )
fnm1 = comp_fib_number (n -1) ;
# pragma omp task shared ( fnm2 )
fnm2 = comp_fib_number (n -2) ;
# pragma omp taskwait
fn = fnm1 + fnm2 ;
return fn;
Beispiel: Fibonacci-Zahlen
• Eine Fibonaccizahl kann erst berechnet werden, wenn ihre beiden Vorgänger
berechnet wurden
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
31

Beispiel: Matrix-Multiplikation
• In der gesamten Veranstaltung haben wir das Beispiel der
Matrix-Multiplikation behandelt
• Erinnerung: Matrix-Multiplikation mit PThreads:
• Es müssen manuell mehrere Threads gestartet werden
• Jeder Thread berechnet einen Teil der Ergebnis-Matrix, dazu wurde jedem
Thread ein Bereich übergeben, den dieser Thread berechnet
• Es muss auf die Beendigung aller Threads gewartet werden
• Die Parallelisierung mit PThreads erforderte eine Umstrukturierung des
sequentiellen Quellcodes
• Dafür haben wir auf einer Quad-core CPU einen guten Speedup von 3.28
gemessen
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
32

Matrix-Multiplikation in OpenMP
• Um die Matrix-Multiplikation in OpenMP umzusetzen, beginnen wir mit der
sequentiellen Version, in welche wir eine Direktive hinzufügen
• Wir parallelisieren hier die äußere Schleife
• Dies entspricht derselben Parallelisierung, welche wir mit PThreads manuell
programmiert haben
• Wir verwenden ein statisches Scheduling
void MatrixMul ( float *M, float * N, float * P, int Width ) {
# pragma omp parallel for schedule ( static )
for ( int i = 0; i < Width ; ++i)
for ( int j = 0; j < Width ; ++j) {
float sum = 0;
for ( int k = 0; k < Width ; ++k) {
sum += M[i * Width + k] * N[k * Width + j];
}
P[i * Width + j] = sum ;
}
}
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
33

• Die Laufzeit der Matrix-Multiplikation mit
Matrizen der Größe 1680 × 1680 auf einem
Intel i7 860 mit 4 Kernen und
Hyper-Threading
• Durch die verwendete Direktive
# pragma omp parallel for \
schedule ( static )
erhalten wir eine vergleichbare Performance
mit der PThread Variante
• Die Programmierung mit PThreads war
jedoch ungleich aufwendiger
Messungen Matrix-Multiplikation
Sekunden
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
35
30
25
20
15
10
Laufzeit Matrix Multiplikation
Sequentiell
PThreads (8 Threads)
OpenMP
34

OpenMP Matrix-Multiplikation
Varianten
• Wir testen die OpenMP Matrix-Multiplikation mit unterschiedlichen
Scheduling-Klauseln
• Des Weiteren testen wir eine Variante, in der die innere und nicht die äußere
Schleife der Matrix-Multiplikation parallelisiert wird
• Das dynamic und guided
Scheduling verteilt die Arbeit
besser als das static Scheduling
auf die Threads, so dass weniger
Wartezeiten entstehen
• Bei der Parallelisierung der
inneren Schleife kann der Cache
besser ausgenutzt werden, da alle
Threads zeitgleich auf den selben
Daten der Matrix M arbeiten, dies
ist bei der Parallelisierung der
äußeren Schleife nicht der Fall
Sekunden
10.5
9.5
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
11
10
9
Laufzeit Matrix Multiplikation
35
PThreads
OpenMP static
OpenMP dynamic
OpenMP guided
äußere Schleife innere Schleife

Vorteile
Vor- und Nachteile von OpenMP
• Einfacher zu programmieren als explizites Threading (Pthreads)
• Für daten- und taskparallele Anwendungen geeignet
• Das sequentielle Originalprogramm wird nicht umgeschrieben, sondern nur
(ggf. inkrementell) um Direktiven ergänzt
• Debuggen ist vereinfacht (Programm ist weiterhin sequentiell ausführbar)
Nachteile
• Abhängig von der Qualität des Compilers (z.B. Unterstützung für
verschachtelte Parallelität)
• Optimiert für Datenparallelität; Taskparallelität nur eingeschränkt unterstützt
Ausblick
• Für den nächsten großen Versionssprung zur Version OpenMP 4.0 wird unter
anderem an einer Unterstützung für GPUs gearbeitet
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
36

Zusammenfassung der
Veranstaltung
• In dieser Veranstaltung haben wir uns mit Mutli-core CPUs und GPUs
auseinander gesetzt
• Dabei haben wir sowhol die unterschiedlichen Hardware-Architekturen als
auch verschiedene Programmieransätze behandelt
• Multi-core CPUs und GPUs unterscheiden sich vor allem in der Anzahl der
Recheneinheiten, sowie der verfügbaren Speicherbandbreite
• GPUs bieten wesentlich höhere theoretische (Peask-) Leistung als Multi-core
CPUs
• GPUs können ihre volle Leistung jedoch nur bei geigneten datenparallelen
Aufgaben entfalten
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
37

Parallele Programmierung
• Es gibt mehrere Ansätze zur parallelen Programmierung
• Wir haben PThreads und OpenMP zur Programmierung von Multi-core
CPUs, sowie OpenCL und CUDA zur Programmierung von GPUs und
Multi-core CPUs behandelt
• In PThreads werden einzelne Threads explizit programmiert, während in
OpenMP parallele Code Bereiche annotiert werden
• OpenCL stellt hingegen ein komplexeres Programmiermodell dar:
• Ein Kernel wird parallel ausgeführt, wobei anzugeben ist, wie viele Instanzen
(Work-items) gestartet werden
• Work-items werden zusätzlich in Work-groups organisiert, welche die
Möglichkeit der Synchronisation einschränken
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
38

Optimierungen
• Um für ein OpenCL Programm auf einer GPU eine möglichst schnelle
Laufzeit zu erhalten, sind eine vielzahl von Optimierungen nötig
• Dabei wird versucht, die Möglichkeiten der Hardware (z. B. lokaler Speicher)
auszunutzen
• Eine besondere Rolle spielen dabei die unterschiedlichen Typen von Speicher
• Die effektivsten Optimierungen sind:
• Eine gut gewählte Work-group Größe (mit Berücksichtigung der Warp-Größe)
• Die Nutzung des lokalen Speichers und Reduzierung von Zugriffen auf den
globalen Speicher
• Weitere Optimierungen sind möglich, welche die Laufzeit nocheinmal
erheblich steigern können
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
39

• Parallele Programmierung ist aufwendiger als
sequentielle Programmierung
• Dafür können geeignete Anwendungen (wie die
Matrix-Multiplikation) erheblich beschleunigt
werden
• PThreads, OpenMP und OpenCL erreichen auf
Multi-core CPUs vergleichbare Leistung,
unterscheiden sich jedoch im
Programmier-Aufwand
• Die GPU entfaltet erst nach geeigneten
Optimierungen ihr Potenzial, übertrift die CPU
jedoch erheblich
Fazit: Parallele Programmierung
• Fazit: Programmierung der GPU ist aufwendig
und erfordert Optimierungen, dafür wird eine
sehr viel höhere Leistung erreicht Work-group 16 × 16
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
Sekunden
40
30
20
10
0
Laufzeit Matrix Multiplikation
40
Sequentiell
PThreads
OpenMP
OpenCL CPU
OpenCL GPU
lokaler Speicher

Aktuelle Hardware-Entwicklungen
• Trend: Neue Prozessoren enthalten immer mehr Kerne
• Die Bedeutung paralleler Programmierung wird daher weiter zunehmen
• Prozessoren in der Entwicklung:
• Intel: Knight’s Corner Parallelprozessor mit ca. 50 CPU Kernen
• AMD: Accelerated processing unit (APU), heterogener Prozessor: Multi-core
CPU mit integrierter GPU
• NVIDIA: GPU Architektur Kepler mit doppelter Leistung der aktuellen Fermi
Architektur
• Zur Programmierung dieser Systeme ist i. d. .R. OpenCL geeignet!
OpenMP SS 2012 Prof. Sergei Gorlatch, Michel Steuwer VL 9
41