platzierung von openmp-programmen auf hierarchischen ... · rheinisch-westfÄlische technische...

RHEINISCH-WESTFÄLISCHE TECHNISCHE HOCHSCHULE AACHEN(RWTH AACHEN)

Lehrstuhl für HochleistungsrechnenProf. C. Bischof, Ph.D.

Platzierung von OpenMP-Programmenauf hierarchischen Speicherarchitekturen

Diplomarbeit

Dirk SchmidlMatr.-Nr. 245163

22. Juni 2009

Erstgutachter: Priv.-Doz. Dr.-Ing. H. Martin Bücker

Zweitgutachter: Prof. Dr. Barbara Chapman

Betreuer: Dipl.-Inform. Christian Terboven

ErklärungIch versichere hiermit, die vorliegende Arbeit selbständig und ohne Verwendung an-derer als der angegebenen Hilfsmittel angefertigt zu haben. Alle Stellen, die wörtlichoder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommensind, habe ich als solche kenntlich gemacht.

Aachen, im Juni 2009

_______________________________________(Dirk Schmidl)

1

INHALTSVERZEICHNIS

Inhaltsverzeichnis1 Einleitung 4

2 Grundlagen 62.1 Multicoreprozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Shared-Memory Systeme . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 SMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 COMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Distributed-Memory Systeme . . . . . . . . . . . . . . . . . . . . . . 92.4 Verwendete Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Fujitsu-Siemens RX600 (Tigerton) . . . . . . . . . . . . . . . 102.4.2 IBM eServer LS42 (Barcelona) . . . . . . . . . . . . . . . . 102.4.3 Sun Fire X4170 Server (Nehalem) . . . . . . . . . . . . . . . 102.4.4 ScaleMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.1 Ausführungsmodell . . . . . . . . . . . . . . . . . . . . . . . 112.5.2 Verteilung der Arbeit auf Threads . . . . . . . . . . . . . . . 122.5.3 Geschachtelte parallele Regionen . . . . . . . . . . . . . . . 132.5.4 OpenMP 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Opari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Thread-/Prozessbinding unter Linux . . . . . . . . . . . . . . . . . . 15

2.7.1 taskset / numactl . . . . . . . . . . . . . . . . . . . . . . . . 162.7.2 Compilerspezifische Umgebungsvariablen . . . . . . . . . . . 162.7.3 sched_setaffinity . . . . . . . . . . . . . . . . . . . . . . . . 17

2.8 Probleme bei geschachtelter Parallelisierung . . . . . . . . . . . . . . 17

3 Verwendete Codes 183.1 TFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 SHEMAT-Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 OpenMP Threadbinding Bibliothek 204.1 Instrumentierung des Codes . . . . . . . . . . . . . . . . . . . . . . 204.2 Hardwareinformationen . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Auslesen der Hardwareinformationen . . . . . . . . . . . . . . . . . 23

4.3.1 /proc/cpuinfo . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.2 OMP_CORE_LIST . . . . . . . . . . . . . . . . . . . . . . . 254.3.3 Linux affinity mask . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Erstellen der Threadhierarchie . . . . . . . . . . . . . . . . . . . . . 284.4.1 OMP_NESTING_TEAM_SIZE . . . . . . . . . . . . . . . . 284.4.2 omp_set_nesting_info() . . . . . . . . . . . . . . . . . . . . 28

4.5 Zuordnung von Threads auf Cores . . . . . . . . . . . . . . . . . . . 30

2

INHALTSVERZEICHNIS

4.5.1 Binden von Threads . . . . . . . . . . . . . . . . . . . . . . 32

5 Kernelbenchmarks 335.1 “nested Stream” Benchmark . . . . . . . . . . . . . . . . . . . . . . 335.2 “nested EPCC” Microbenchmarks . . . . . . . . . . . . . . . . . . . 43

6 Ergebnisse für Nutzercodes 496.1 TFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1 Instrumentierung mit Opari . . . . . . . . . . . . . . . . . . . 496.1.2 Codeänderungen . . . . . . . . . . . . . . . . . . . . . . . . 496.1.3 Barcelona . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.4 Nehalem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.5 Tigerton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.1.6 ScaleMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2 SHEMAT-Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.2.1 Verwendung der Threadbinding Bibliothek . . . . . . . . . . 596.2.2 Barcelona und Nehalem . . . . . . . . . . . . . . . . . . . . 596.2.3 Tigerton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2.4 ScaleMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Zusammenfassung 66

Abbildungs- und Tabellenverzeichnis 67

Literatur 69

3

1 EINLEITUNG

1 EinleitungIn der Mikroprozessorbranche ist in den letzten Jahren ganz klar ein Trend hin zuMulticore-Prozessoren zu erkennen. Nahezu alle Hardwarehersteller sind dazu überge-gangen Prozessoren herzustellen, welche aus mehreren Recheneinheiten, sogenanntenCores, bestehen. Auf der anderen Seite hat sich die Taktrate der Prozessoren seid 2002nur geringfügig erhöht. Der Grund hierfür ist, dass mit steigender Taktrate die Wär-meabgabe der Chips extrem ansteigt und ein Abführung der Wärme irgendwann nichtmehr möglich ist. Um dieses Problem zu umgehen, werden mehrere Recheneinheitenauf einem Prozessorchip aufgebracht, ohne dabei die Taktrate der Chips zu erhöhen.Dadurch erhöht sich die Gesamtrechenleistung, ohne dass die Wärmeabgabe zu extremansteigt. Aus diesen Tatsachen ergibt sich eine immer größere Notwendigkeit, paral-lele Programme zu schreiben. Hierbei gewinnt die Shared-Memory-Parallelisierung,insbesondere mit OpenMP, immer mehr an Bedeutung, da sich hiermit für viele Pro-bleme effiziente Lösungen mit vergleichsweise moderatem Aufwand finden lassen.

Durch diese neue Entwicklung treten aber auch einige neue Schwierigkeiten auf.Die verwendete Hardware wird komplizierter, es gibt z.B. immer mehr Stufen in derCachehierarchie und manche Caches werden nur zwischen bestimmten Cores geteilt,wohingegen andere Cores, obwohl sie auf einem Prozessor liegen, über ein Bussystemsynchron gehalten werden müssen.

Auf Mehrsockelsystemen kommt dann noch hinzu, dass der Zugriff der Cores aufden Hauptspeicher symmetrisch (SMP) erfolgen kann, oder dass der Hauptspeicherpartitioniert ist (NUMA). Die Berücksichtigung dieser Besonderheiten bestimmt ent-scheidend die erreichbare Performance. Untersuchungen zu dieser Problematik sindbeispielsweise in [Terboven & an Mey+ 08] zu finden.

Außerdem gibt es noch Systeme, wie die im Weiteren auch betrachtete Maschinevon ScaleMP, die mehrere Mehrsockel-Boards über ein Netzwerk zu einem SingleSystem Image koppeln.

Das Problem ist nun, dass sich die Laufzeit eines Programms stark unterscheidenkann, je nachdem wie das Programm auf der Hardware platziert wird. Die Platzierungwird vom Betriebssystemscheduler bestimmt und ist in den wenigsten Fällen optimalfür HPC-Anwendungen.

Es ist für den Programmierer möglich, aus dem Programmcode heraus die Platzie-rung vorzunehmen. Hiermit lassen sich die Laufzeiten dann in vielen Fällen verbes-sern. Allerdings ist dies erstens recht aufwendig für den Programmierer, zweitens mussder Programmierer auf einer neuen Maschine jedes Mal sein Programm anpassen, umeine gute Platzierung zu erreichen. Drittens kann es sein, dass der Programmierer garnicht genug Kenntnisse über seine Hardware hat, um die Platzierung selbst vorzuneh-men.

Ziel dieser Arbeit ist es, eine Bibliothek zu entwickeln, um auf einfache Weise eine

4

1 EINLEITUNG

Möglichkeit zu bieten, die Platzierung von Threads vorzunehmen. Hierbei ist eine au-tomatische Instrumentierung des Nutzercodes wünschenswert, um die Anwendung aufApplikationscodes möglichst komfortabel zu erlauben. Der Nutzer soll die Möglich-keit bekommen, die Platzierung zu verbessern, indem er weitere Informationen übersein Programm durch Funktionsaufrufe übermittelt.

Hauptaugenmerk soll in dieser Arbeit auf OpenMP Programme mit geschachtelterParallelisierung gelegt werden. Bei nicht geschachtelten Programmen gibt es bereitsvon den meisten Compilerherstellern Lösungen, die gut funktionieren. Daher bestehthier kein besonderer Bedarf für eine Verbesserung.

Zudem soll auch evaluiert werden, ob diese Strategie wirklich zu einer Verbes-serung der Laufzeit führt. Hierzu werden zuerst zwei kleine Benchmark Programmeangeschaut, in dem einen wird die Speicherbandbreite einzelner Maschinen betrachtet,in dem Anderen der Overhead, welcher durch die geschachtelten OpenMP Konstrukteentsteht. Weiter werden zwei Applikationen untersucht, um zu überprüfen, ob sich dievon der Bibliothek gemachte Platzierung positiv auf die Laufzeit auswirkt. Der ersteCode ist der SHEMAT-Suite Code vom Institut für angewandte Geophysik der RWTHAachen. Hierbei handelt es sich um eine numerische Simulation von Strömung, Wär-meausbreitung, Speziestransport und chemischen Reaktionen und deren Bezug zu tek-tonischen Deformationsprozessen und Geodynamik. Als zweite Anwendung wird eineVersion des TFS-Codes betrachtet. Dieses Programm simuliert die Luftströmungen inder menschlichen Nase. Beide Codes sind in Fortran geschrieben und verwenden ge-schachteltes OpenMP zur Parallelisierung.

5

2 GRUNDLAGEN

2 GrundlagenEinige Grundbegriffe sollen in diesem Kapitel kurz erklärt werden, da sie im Weiterenvon Bedeutung sind. Außerdem werden die verwendeten Systeme genauer vorgestellt.

2.1 MulticoreprozessorenUnter einem Multicoreprozessor versteht man einen Prozessor, der auf einem Chipmehrere vollständige Rechenkerne (Cores) enthält. Verschiedene Cores haben eigeneRegister und eigene Recheneinheiten. Sie können aber auch einige Ressourcen mit an-deren Cores teilen, wie z.B. Caches oder die Busanbindung.Alle Details von verschiedenen Multicore Prozessoren anzuschauen wäre an dieserStelle zu umfangreich, daher soll hier nur kurz auf die Cachehierarchie und die Bu-sanbindung eingegangen werden, da dies später von Interesse für die Platzierung derProgramme sein wird. Umfangreichere allgemeine Informationen zu Multicore Pro-zessoren sind in [Hennessy & Patterson 06] zu finden.

Harpertown (Intel Xeon E5450 @ 3GHz)Bei dem Harpertown Prozessor von Intel handelt es sich um einen Quadcoreprozes-sor. Die Besonderheit hier ist, das im Wesentlichen zwei Dualcores auf einen Sockelgebracht wurden, wie in Abbildung 1 zu sehen ist. Dies führt dazu, dass sich je zweiCores einen L2 Cache teilen, während die beiden L2 Caches nur über den Frontside-bus (FSB) miteinander verbunden sind. Dies hat vom Gesichtspunkt der Platzierungher zwei Auswirkungen:

1. Threads, die Zugriff auf denselben L2 Cache haben, können untereinander schnel-ler kommunizieren. Zum einen kann schneller auf gemeinsame Daten zugegrif-fen werden, zum anderen sind auch Synchronisationen, wie zum Beispiel Bar-rieren oder kritische Regionen, billiger zwischen solchen Threads.

2. Teilen sich die Threads keinen L2 Cache hat das den Vorteil, dass sie insgesamtmehr Daten in den Cache laden können. Außerdem wird eine höhere Bandbreitebei der Speicheranbindung erreicht, da man dadurch zwei Zugänge zum FSBnutzen kann.

Barcelona (AMD Opteron Processor 8356)Auch die Barcelona Opteron Prozessoren von AMD sind Quadcoreprozessoren. Aller-dings hat hier, wie in Abbildung 2 zu sehen, jeder Core einen separaten L2 Cache undalle Cores teilen einen L3 Cache. Zudem sind alle Cores über einen HyperTransportLink (HT) an den Speicher angeschlossen.

Für die Platzierung von Threads ergibt sich hieraus, dass es auf diesem Prozessorunwichtig ist, welche Cores verwendet werden, da alle Cores gleich miteinander undmit dem Speicher verbunden sind.

6

2 GRUNDLAGEN

Core 0

Core 2

Core 1

Core 3

6 MB L2 Cache

6 MB L2 Cache

FSB

Abbildung 1: Intel Xeon E5450

Core 0

Core 2

Core 1

Core 3

8 MB L3 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

HT

Abbildung 2: AMD Opteron Processor8356

2.2 Shared-Memory SystemeBei Shared-Memory Systemen haben alle verwendeten Prozessoren denselben physi-kalischen Adressraum. Jeder Prozessor kann auf den gesamten Hauptspeicher der Ma-schine zugreifen. Hierbei lässt sich noch zwischen zwei Arten von Shared-MemorySystemen unterscheiden.

2.2.1 SMP

Symmetrische Multiprozessor Systeme (SMPs) zeichnen sich dadurch aus, dass al-le Prozessoren auf dieselbe Weise auf den Hauptspeicher zugreifen. Ein Beispiel fürsolche Systeme sind die schon erwähnten Harpertowns von Intel, bei denen zwei Pro-zessoren über den FSB auf den Hauptspeicher zugreifen, siehe Abbildung 3.

Der Vorteil von SMPs ist, dass es hierbei keine Probleme bezüglich der Datenloka-lität gibt, da alle Daten im selben Speicher liegen. Klarer Nachteil ist jedoch, dass fürspeicherintensive Anwendungen der Bus schnell zum Flaschenhals wird. Aus demsel-ben Grund ist die Skalierbarkeit solcher Systeme begrenzt.

2.2.2 NUMA

NUMA steht für “non uniform memory access”. Der Hauptspeicher in NUMA Sy-stemen besteht physisch aus mehreren Partitionen. Meist ist jeder Prozessor direkt aneinen Teil des Hauptspeichers angeschlossen, wie etwa bei den Barcelona Opterons,siehe Abbildung 4.

Es kann in einem NUMA System jeder Prozessor direkt den Speicher jedes an-deren Prozessors verwenden. Einen solchen Zugriff auf den Speicher eines anderenProzessors nennt man remote Zugriff. Remote Zugriffe sind langsamer als Zugriffeauf den eigenen Speicher.

Der Vorteil bei einem NUMA System im Vergleich zu einem SMP System ist,dass mit neu hinzukommenden Prozessoren auch weitere Speicheranbindungen dazu-

7

2 GRUNDLAGEN

Core 0

Core 2

Core 1

Core 3

6 MB L2 Cache

6 MB L2 Cache

Core 0

Core 2

Core 1

Core 3

6 MB L2 Cache

6 MB L2 Cache

Hauptspeicher

FSB

Abbildung 3: symmetrischer Multiprozessor (Harpertown)

kommen. Dieser Ansatz kann also auch verwendet werden, um große Shared-MemorySysteme zu bauen. Der Nachteil hier ist aber, dass die Laufzeit der Programme starkdavon abhängt, in welchem physikalischen Speicher die Daten abgespeichert werden.Es ist wünschenswert die Daten möglichst im eigenen Speicher des Prozessors zu ha-ben, da bei vielen Zugriffen auf fremde Hauptspeicher die Performance stark abfällt.

Man unterscheidet weiter zwischen NUMA Systemen die Cache-kohärent sind undsolchen, die es nicht sind. Als Cache-kohärent bezeichnet man Systeme bei denen dieHardware garantiert, dass eine Änderung an einem Datum im lokalen Cache eines Pro-zessors allen weiteren Prozessoren bekannt gemacht wird. Hierdurch wird vermieden,dass andere Prozessoren mit dem veralteten Datum weiter rechnen.

Hat ein NUMA System diese Eigenschaft, spricht man von einem ccNUMA Sy-stem (cache coherent NUMA). Alle hier verwendeten Systeme sind cache-kohärent.

2.2.3 COMA

In einem COMA (cache only memory architecture) System fungiert der gesamte Haupt-speicher als großer Cache. Vom Aufbau her hat jeder Prozessor eigenen Hauptspeicher,wie bei einem NUMA System. Der Unterschied ist, dass es für eine Speicherseite kei-nen festen Platz im Hauptspeicher gibt. Das System kann nach Bedarf die Speicher-seiten von einem physikalischen Hauptspeicher in einen Anderen verschieben. Manspricht dabei von Migration der Speicherseiten. Es gibt allerdings, soweit mir bekanntist, keine Maschinen, die nach diesem Vorbild gebaut wurden. Vorteil einer solchenMaschine wäre, dass die Migration von Seiten von der Hardware übernommen würde.Man bräuchte als Programmierer nicht darauf zu achten wo Seiten angelegt werden,

8

2 GRUNDLAGEN

Core 0

Core 2

Core 1

Core 3

8 MB L3 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

Core 0

Core 2

Core 1

Core 3

8 MB L3 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

512 KB L2 Cache

Hypertransport Link

Haupt-speicher

Haupt-speicher

Abbildung 4: ccNUMA Architektur (Barcelona)

da diese, je nach Zugriffsmuster, im Nachhinein migriert werden könnten.

2.3 Distributed-Memory SystemeAls Distributed-Memory Systeme bezeichnet man Rechner, in denen nicht alle Prozes-soren denselben physischen Adressraum haben. Hier hat jeder Prozessor seinen eige-nen Speicher, auf den ohne weiteres kein anderer Prozessor zugreifen kann. Verbundensind die einzelnen Prozessoren über ein Netzwerk.

Programme für diese Systeme müssen explizit die Daten austauschen, die von an-deren Prozessen verwendet werden sollen. Meistens wird hierfür eine MPI Bibliothekverwendet. Der MPI Standard [Forum 95] und sein Erweiterung [Forum 03] bieten ei-ne genaue Beschreibung der Funktionen, welche MPI zu diesem Zweck bereitstellt.Für eine Einführung in MPI gibt es einige gute Werke, wie etwa [Gropp & Lusk+ 94].

Um ein Programm mit Hilfe von MPI zu parallelisieren sind allerdings oft rechtumfangreiche Codeänderungen notwendig.

2.4 Verwendete HardwareAlle Experimente und Messungen für die Diplomarbeit wurden auf den Rechnern desRechenzentrums der RWTH durchgeführt. [an Mey & Sarholz+ 09] liefert eine Ein-führung in die Verwendung dieser Systeme, ebenso wie eine detailliertere Beschrei-bung der Hardware. Die verwendeten Systeme sind:

9

2 GRUNDLAGEN

2.4.1 Fujitsu-Siemens RX600 (Tigerton)

Bei dieser Maschine handelt es sich um eine vier Sockel Maschine, welche mit Quad-coreprozessoren des Typs “Intel Xeon X7350” (Tigerton) bestückt ist. Die Prozesso-ren haben eine Taktrate von 2,93 GHz und insgesamt verfügt die Maschine über 64 GBHauptspeicher. Alle vier Prozessoren sind über den Frontsidebus an den Hauptspeicherangeschlossen. Es handelt sich bei dieser Maschine also um ein SMP System.

2.4.2 IBM eServer LS42 (Barcelona)

In diesen Systemen werden vier Quadcore Prozessoren des Typs “AMD Opteron Pro-cessor 8356” (Barcelona) mit 2,3 GHz Taktrate und 32 GB Hauptspeicher verwen-det. Jeder Prozessor verfügt über 8 GB lokalen Hauptspeicher. Die anderen Prozes-soren können aber auch auf diesen Speicher zugreifen. Es handelt sich hier um eineccNUMA Architektur.

2.4.3 Sun Fire X4170 Server (Nehalem)

Bei diesem System handelt es sich ebenso um ein ccNUMA System. Es werden zweiProzessoren des Typs “Xeon X5570”(Nehalem) von Intel verwendet. Die Prozesso-ren sind mit 2,93 GHz getaktet und an jeden Prozessor sind 18 GB Hauptspeicherangeschlossen. Insgesamt verfügt die Maschine also über 36 GB Hauptspeicher. DieMaschinen verwenden ein neues Bussystem, den sogenannten “Intel Quickpath Inter-connect”. Diese sind seid langem die ersten Prozessoren von Intel die keinen Frontsi-tebus verwenden. Hiermit geht Intel den Schritt von SMP Systemen hin zu ccNUMASystemen. Auch daran wird noch mal deutlich, dass solche Systeme an Bedeutunggewinnen und in Zukunft nicht zu vernachlässigen sein werden.

2.4.4 ScaleMP

Bei der in dieser Arbeit hauptsächlich betrachteten Maschine handelt es sich um eineMaschine der Firma ScaleMP. Da diese Maschinen noch recht neu und auch nicht soweit verbreitet sind, werden an dieser Stelle die Besonderheiten kurz erläutert.

Es sind 13 Boards mit je zwei “Xeon E5420” Prozessoren über ein Infinibandnetz-werk zusammengeschlossen. Die Prozessoren haben eine Taktrate von 2,5 GHz unddie gesamte Maschine hat 208 GB Hauptspeicher.

Das Besondere an dieser Maschine ist, dass sie sich dem Nutzer als Shared-MemoryMaschine präsentiert. Um dies zu erreichen, wird eine Art virtuelle Maschine ver-wendet, die noch vor dem eigentlichen Betriebssystem gestartet wird. Diese virtuel-le Maschine verarbeitet dann alle Speicheranfragen und sorgt dafür, dass die Zugrif-fe auf Daten, die auf anderen Knoten liegen, über das Netzwerk passieren können.Um diese Zugriffe zu optimieren, werden verschiedene Strategien der Migration unddes Cachings verwendet. Es werden laut Angabe von ScaleMP etwa 10% des gesam-ten Hauptspeichers für diese Mechanismen verbraucht. Durch diese Methoden verhält

10

2 GRUNDLAGEN

parallel

end parallel

runt

ime

master thread

slave threads

Abbildung 5: Fork-join model

sich die Maschine ähnlich einer COMA Architektur, da automatisch Speicherseitenmigriert werden, um eine optimale Platzierung zu erreichen. Allerdings wird nicht dergesamte Hauptspeicher als Cache genutzt, daher handelt es sich nicht um eine COMAArchitektur im eigentlichen Sinne, sondern um eine Mischung aus COMA und NUMAArchitektur.

2.5 OpenMPOpenMP ist ein Standard zur Shared-Memory Parallelisierung von C/C++ und FortranProgrammen. Der Standard ist weit verbreitet und wird von allen gängigen Compiler-herstellern unterstützt.

Die Parallelisierung mit OpenMP erfolgt auf Threadebene, daher laufen die so par-allelisierten Programme nur auf Shared-Memory Maschinen.

In OpenMP werden dem Programm Compilerdirektiven hinzugefügt, um eine Par-allelisierung zu erreichen. In C/C++ beginnen diese mit #pragma omp und in Fortranmit !$omp, c$omp oder *$omp.

2.5.1 Ausführungsmodell

OpenMP arbeitet nach einem fork-join Modell. Das bedeutet, dass OpenMP Program-me mit einem Thread, dem Master-Thread, gestartet werden. Erreicht der Master Threadein “parallel” Konstrukt, wird ein Team von so genannten Slave Threads gestartet undbis zum Erreichen des zugehörigen “parallel end” Konstrukts arbeiteten die Threadsparallel, siehe Abbildung 5.

11

2 GRUNDLAGEN

Um ein Programm parallel laufen zu lassen, reicht es schon diese Konstrukte ein-zufügen, wie in Programmausschnitt 1 dargestellt. Außerdem muss noch der Compilerinstruiert werden OpenMP zu verwenden.

Programmausschnitt 1 Beispiel eines parallel Konstruktes

1 #pragma omp p a r a l l e l2 {3 f o r ( i n t i =0 ; i < 100 ; i ++)4 {5 a [ i ]= b [ i ]+ c [ i ] ;6 }7 } /∗ p a r a l l e l end ∗ /

“

2.5.2 Verteilung der Arbeit auf Threads

Der Code in der parallelen Region wird erstmal von allen Threads redundant ausge-führt. In dem Code aus Ausschnitt 1 führt das dazu, dass alle Threads die gesamtenFelder a,b und c durchlaufen und eine Addition durchführen. Meist ist es aber ge-wünscht, dass nicht alle Threads dasselbe durchführen, sondern sich die Arbeit teilen,um dadurch eine Verbesserung der Laufzeit zu erreichen. Dies geschieht in OpenMPam einfachsten über sogenannte “worksharing” Konstrukte.

Durch solche Konstrukte kann der Programmierer dann die Arbeit auf die einzel-nen Threads verteilen. Es gibt vier solcher Konstrukte:

• Loop Construct (omp for in C;omp do in Fortran): Hier werden die Iteratio-nen einer For bzw. Do Schleife auf die Threads verteilt.

• section: Mit Hilfe von Sections kann man verschiedene Blöcke angeben, dieunabhängig von einander von verschiedenen Threads ausgeführt werden können.Die Blöcke können, wenn genug Threads vorhanden sind, parallel ausgeführtwerden.

• single: Mit dem single Konstrukt wird ein Block angegeben, der nur von ei-nem Thread ausgeführt werden soll. Obwohl nur ein Thread an der Ausführungbeteiligt ist, zählt das Konstrukt zu den “worksharing” Konstrukten.

• workshare: Das workshare Konstrukt gibt es nur in Fortran. Bei diesem Kon-strukt werden Arrayoperationen in Fortran auf mehrere Threads verteilt. DieVerteilung erfolgt hier im Wesentlichen wie bei einer do Schleife, wobei hierkeine Schleifeniterationen verteilt werden, sondern Blöcke der verwendeten Ar-rays.

12

2 GRUNDLAGEN

Am Häufigsten tritt der Fall auf, in dem die Iterationen einer for bzw. do Schleifeauf die Threads mit einem omp for bzw. omp do Konstrukt verteilt werden. DurchEinfügen eines solchen Konstruktes wird in der vorherigen Vektoraddition erreicht,dass die Threads nicht alle die gesamten Felder durchlaufen, sondern sich die Felderaufteilen und so jeder Thread weniger Arbeit zu verrichten hat. Der geänderte Codesieht dann aus wie in Ausschnitt 2.

Programmausschnitt 2 Beispiel eines parallel Konstruktes mit worksharing

1 #pragma omp p a r a l l e l2 {3 #pragma omp f o r4 f o r ( i n t i =0 ; i < 100 ; i ++)5 {6 a [ i ]= b [ i ]+ c [ i ] ;7 }8 } /∗ p a r a l l e l end ∗ /

“

Wie bei diesen kleinen Beispielen schon zu sehen, verfolgt OpenMP einen Ansatz,welcher dem Programmierer einige Arbeiten abnimmt und so das Parallelisieren er-leichtert. Der Programmierer muss nicht selbst dafür sogen, dass die Threads gestartetund die Grenzen ausgerechnet werden, in denen jeder Thread arbeiten soll. Dieser An-satz ermöglicht es, durch relativ kleine Codeänderungen von einem seriellen zu einemparallelen Programm zu kommen.

2.5.3 Geschachtelte parallele Regionen

Es ist auch möglich parallele Regionen zu schachteln. Wenn ein Worker Thread eingeschachteltes parallel Konstrukt erreicht, wird ein neues Team an Threads gestartet,siehe Abbildung 6. Von diesem Team wird er dann der Master Thread.

2.5.4 OpenMP 3.0

Im Mai 2008 wurde eine neue Version des OpenMP Standards veröffentlicht, die Versi-on 3.0. OpenMP wurde um einige neue Konstrukte erweitert. Für diese Arbeit von be-sonderer Bedeutung sind die Funktionsaufrufe omp_get_ancestor_thread_num undomp_get_level, welche in den Standard aufgenommen wurden. omp_get_level lie-fert die aktuelle Schachtelungstiefe des aufrufenden Threads zurück. Mit Hilfe vonomp_get_ancestor_thread_num lässt sich abfragen welche Nummern die Parent-threads in den vorangegangenen Ebenen haben. Genauere Beschreibungen der Funk-tionen sind in [OpenMP 08] zu finden.

Durch diese beiden Funktionen wird es möglich, den aufrufenden Thread eindeu-tig zu bestimmen. Eine solche Bestimmung ist Grundvoraussetzung für die sinnvolle

13

2 GRUNDLAGEN

parallel

end parallel

runt

ime

master thread

slave threads erste Ebene

parallel

end parallel

slave threads zweite Ebene

Abbildung 6: Fork-join Modell im geschachtelten Fall

Platzierung von Threads. In [OpenMP 05], der Version 2.5 des OpenMP-Standards,war es nur möglich mit omp_get_thread_num die aktuelle Position in der umgebenenparallelen Region zu bestimmen. Hat man mehrere parallele Regionen, gibt es in je-dem Team einen Thread mit Threadnummer 0. Es ist wenig sinnvoll, alle Threads mitNummer 0 auf demselben Prozessorcore zu platzieren.

Dies sind nur einige Grundlagen von OpenMP und es gibt viele weiter Dinge,die von Bedeutung sind, um mit OpenMP zu arbeiten. Zum Verstehen der hier be-trachteten Problematik reichen diese Grundlagen aber aus. Eine umfangreiche Einfüh-rung und viele weitere Informationen im Bezug auf OpenMP liefert beispielsweise[Chapman & Jost+ 07].

2.6 OpariOpari ist ein Tool, welches entwickelt wurde, um eine Instrumentierung von OpenMPProgrammen vorzunehmen. Der Zweck, zu dem es entwickelt wurde, ist die Mög-lichkeit, ein einheitliches Interface zu haben, mit dem dann Performancetools arbei-ten können. In Tools wie Vampir, Scalasca und OMPP wird Opari für diese Zweckeverwendet. Nähere Informationen zu diesen Tools sind zu finden unter [VAMPIR],[SCALASCA] und [OMPP 05].

In [Mohr & Malony+ 02a] wurde ein Interface vorgestellt um OpenMP Program-me sinnvoll zu instrumentieren im Hinblick auf Performancemessungen. Dieses Inter-face wurde in Opari aufgegriffen und nach diesen Vorgaben werden alle Codes auto-matisch instrumentiert. Für viele Konstrukte sind außer den Funktionsaufrufen keine

14

2 GRUNDLAGEN

weiteren Änderungen notwendig. Ein Beispiel hierfür ist das critical Konstrukt. DieInstrumentierung ist in Codebeispiel 3 zu sehen.

Programmausschnitt 3 Instrumentierung eines critical Konstruktes mit Opari

1 !$OMP CRITICAL2 s t r u c t u r e d b l o c k3 !$OMP END CRITICAL

1 c a l l p o m p _ c r i t i c a l _ e n t e r ( d )2 !$OMP CRITICAL3 c a l l p o m p _ c r i t i c a l _ b e g i n ( d )4 s t r u c t u r e d b l o c k5 c a l l p o m p _ c r i t i c a l _ e n d ( d )6 !$OMP END CRITICAL7 c a l l p o m p _ c r i t i c a l _ e x i t ( d )

Bei anderen Konstrukten ist die Instrumentierung etwas schwieriger. Ein paralleldo Konstrukt beispielsweise wird in zwei Konstrukte zerlegt, einmal das parallelKonstrukt und das do Konstrukt. Hierdurch wird es möglich, nach dem Öffnen derparallelen Region noch einen Funktionsaufruf einzufügen. Bei dem unverändertenparallel do Konstrukt ist das nicht möglich, da sofort nach dem Konstrukt eine doSchleife beginnen muss. Würde man den Aufruf danach einfügen, würde er für je-de Schleifeniteration ausgeführt werden. Außerdem beinhaltet ein parallel Konstruktnoch eine implizite Barriere am Ende. Diese Barriere wird beim Instrumentieren zueiner expliziten Barriere gemacht, um nach der Barriere noch einen Funktionsaufrufeinfügen zu können. Die Instrumentierung eines parallel do Konstruktes ist in Co-debeispiel 4 zu sehen.

Im Rahmen dieser Arbeit wird Opari nicht für Performancemessungen verwendet,sondern um eigenen Code zur Platzierung von Threads in jeder parallelen Region aus-führen zu können. Hierzu wird eine eigene Bibliothek geschrieben, welche die POMPFunktionen bereitstellt und in diesen Funktionen den gewünschten Code ausführt. Wei-terführende Informationen zu Opari sind in [Mohr & Malony+ 02b] zu finden.

2.7 Thread-/Prozessbinding unter LinuxUnter Linux gibt es verschiedene Möglichkeiten, Threads und Prozesse an bestimmteProzessoren zu binden. Hierbei ist wichtig zu verstehen, was Linux als Prozessor sieht.Ein Quadcoreprozessor wird zum Beispiel als vier einzelne Prozessoren gesehen undsomit ist auch eine Platzierung auf einzelne Cores möglich.

Der Betriebssystemscheduler unterscheidet nicht zwischen Threads und Prozes-soren. Ein Programm mit vier Threads bekommt vom Scheduler also genau so vielProzessorzeit wie vier einzelne Programme, wenn diese nur einen Thread verwenden.

15

2 GRUNDLAGEN

Programmausschnitt 4 Instrumentierung eines parallel do Konstruktes mit Opari

1 !$OMP PARALLEL DO c l a u s e s2 do l oop3 !$OMP END PARALLEL DO

1 c a l l pomp p a r a l l e l f o r k ( d )2 !$OMP PARALLEL o t h e r−c l a u s e s . . .3 c a l l pomp p a r a l l e l b e g i n ( d )4 c a l l pomp do e n t e r ( d )5 !$OMP DO s c h e d u l e−c l a u s e s ,6 o r d e r e d−c l a u s e s ,7 l a s t p r i v a t e −c l a u s e s8 do l oop9 !$OMP END DO NOWAIT

10 c a l l pomp b a r r i e r e n t e r ( d )11 !$OMP BARRIER12 c a l l pomp b a r r i e r e x i t ( d )13 c a l l pomp do e x i t ( d )14 c a l l pomp p a r a l l e l end ( d )15 !$OMP END PARALLEL16 c a l l pomp p a r a l l e l j o i n ( d )

2.7.1 taskset / numactl

Eine einfache Möglichkeit zur Platzierung von Prozessen unter Linux sind tasksetund numactl. Beide Tools bieten in etwa dieselben Möglichkeiten, was Platzierungvon Prozessen angeht. Es ist möglich, die Prozessoren für ein bestimmtes Programmeinzugrenzen. Der folgende Aufruf würde zum Beispiel dazu führen, dass a.out nurauf den Prozessoren 0,2 und 4 ausgeführt wird. Hierbei werden aber keine einzelnenThreads gebunden. Angenommen a.out würde drei Threads starten, dann wäre nichtgarantiert, dass jeder Thread auf einem eigenen Prozessor läuft, sondern nur, dass eskeinen Thread gibt, der auf einem anderen als den drei genannten Prozessoren läuft.

taskset -c 0,2,4 a.out

numactl --physcpubind=0,2,4 a.out

2.7.2 Compilerspezifische Umgebungsvariablen

Bei vielen Compilern gibt es die Möglichkeit, Prozessorbinding über Umgebungsva-riablen zu steuern. Beispiele für solche Umgebungsvariablen sind KMP_AFFINITYfür den Intel Compiler, SUNW_MP_PROCBIND für den Sun Compiler oder beimGnu Compiler GOMP_CPU_AFFINITY. Mit diesen Variablen ist es möglich, die ein-zelnen Threads auf Prozessoren zu binden. Der folgende Aufruf führt also dazu, dassdie einzelnen Threads des Programms auf die Prozessoren 0,2 und 4 gebunden werden.

16

2 GRUNDLAGEN

Hierbei ist sichergestellt, dass der Thread mit Thread-Id 0 auf Prozessor 0 läuft, derThread mit Thread-Id 1 auf Prozessor 2 und so weiter.

$ export OMP_NUM_THREADS=4$ export GOMP_CPU_AFFINITY="0 2 4 6"$ a.out

Eine genauere Beschreibung der Variablen gibt es für den Gnu Compiler unter[FSF 09], für den Intel Compiler unter [Intel 09] und für den Sun Compiler unter[Sun 07].

2.7.3 sched_setaffinity

Eine weitere Möglichkeit, Threads und Prozesse zu platzieren, bietet der Systemcallsched_setaffinity. Hierdurch ist es möglich, aus dem Programmcode heraus ein-zelne Threads oder auch ganze Prozesse auf einzelne Prozessoren zu binden. Im Ge-gensatz zu den beiden oberen Möglichkeiten, kann man hier auch eine Migration vonThreads während des Programmlaufs vornehmen. Allerdings ist es für diese Methodenötig, den Sourcecode zu ändern, was bei den anderen beiden Möglichkeiten nicht derFall ist.

2.8 Probleme bei geschachtelter ParallelisierungProgramme, die geschachtelte Parallelisierung mit OpenMP verwenden, haben nochimmer Probleme beim Platzieren von Threads. Und zwar liegt die Ursache hierfür dar-in, wie die Threads auf die inneren Teams verteilt werden. Im OpenMP Standard stehthierzu nichts, daher kann sich jeder Compilerhersteller eine eigene Strategie überlegenund umsetzen.

Bei nicht geschachtelten parallelen Regionen ist in der Regel die Zuordnung vonThreads in verschiedenen parallelen Regionen gleich. Das heißt, der Thread, der in derersten parallelen Region die Nummer eins hatte, hat sie auch in der zweiten parallelenRegion und so weiter. Hierdurch ist es möglich, die Threads zu Beginn des Programmszu verteilen. Die Verteilung bleibt dann für den gesamten Lauf bestehen.

Bei geschachtelten OpenMP Programmen sieht das anders aus. Hier verwendenviele Herstellen einen Thread Pool, aus dem für die inneren parallelen Regionen Threadsherausgenommen werden. Die Zuordnung kann sich hier in verschiedenen paralle-len Regionen stark unterscheiden und tut es in der Regel auch. Eine Platzierung derThreads zu Beginn des Programms macht also wenig Sinn, da man nicht absehen kann,welche Threads später mal in einem Team sind. Die einzige Möglichkeit ist hier, beidem Öffnen einer parallelen Region immer abzufragen, wer in welchem Team ist, umdann die Platzierung neu vorzunehmen. Dies muss dann auch bei jeder parallelen Re-gion neu durchgeführt werden, da sich die Teams immer neu zusammenstellen.

17

3 VERWENDETE CODES

3 Verwendete CodesEs werden nachfolgend zwei komplexe Applikationen verwendet, um die Nutzbarkeitder im Rahmen dieser Arbeit entwickelten Bibliothek zu testen. Die Applikationensollen in diesem Kapitel kurz vorgestellt werden und es soll auf einige Besonderheitenaufmerksam gemacht werden.

3.1 TFSDie erste Applikation ist ein Navier-Stokes Löser, welcher am Aerodynamischen In-stitiut der RWTH Aachen entwickelt wurde. Die Applikation wird eingesetzt, um dieLuftströmung im Nasen-/Rachenraum des Menschen zu simulieren. Das Hauptziel istes hierbei, die Auswirkungen von chirurgischen Eingriffen vorauszuberechnen. VieleOperationen, die dazu dienen den Patienten mit Atemproblemen eine bessere Atmungzu ermöglichen, bringen nicht den erwünschten Erfolg. Ein Grund hierfür ist, dassder Chirurg schwer während der Operation erkennen kann, welche Auswirkungen ei-ne Veränderung der Nase auf die Luftströmungen hat. Durch CT Scans können Datenüber den Nasen-/Rachenraum des Patienten gewonnen werden und mit diesen Datenkann der TFS Code dann die Luftströmung berechnen. Verändert man nun diese Datenund berechnet die Luftströmung neu, lassen sich Auswirkungen besser erkennen undder Arzt kann sich vor der Operation ein besseres Bild von den nötigen Veränderungenmachen.

Der Code ist in Fortran77 geschrieben und mit geschachteltem OpenMP paralleli-siert worden. Bei der Parallelisierung wurde ParaWise verwendet, ein Tool zur halbau-tomatischen Parallelisierung. Es wurden aber auch von Hand Änderungen hinzugefügt,um die Parallelisierung zu verbessern. Genauere Informationen zur Parallelisierungdieses Codes sind in [Johnson & Leggett+ 08] und [an Mey & Sarholz+] zu finden.

Der Nutzer kann verschiedene Versionen der Parallelisierung verwenden, diesesind:

1. NESTEDIn dieser Strategie, wie auch in allen Anderen, gibt es zwei Ebenen der Paralleli-sierung. Zuerst kann das Gebiet in Blöcke zerlegt werden, die getrennt berechnetwerden können, wobei zwischenzeitlich auch der Austausch von Randdaten nö-tig ist. Die Anzahl der Blöcke hängt vom Datensatz ab und ist nicht beliebigvergrößerbar. In dem verwendeten Datensatz gab es 16 Blöcke. Eine Paralleli-sierung mit mehr als 16 Threads ist auf dieser Ebene also nicht möglich. Außer-dem sind die Blöcke nicht alle gleich groß und beinhalten unterschiedlich vielArbeit. Diese Ebene der Parallelisierung hat also eine Lastinbalance. In der NE-STED Strategie wird hier ein dynamic Schedule eingesetzt um die Lastinbalancein den Griff zu bekommen.

18

3 VERWENDETE CODES

Auf der zweiten Ebene wird bei allen Strategien noch über die Schleifen inner-halb der Blöcke parallelisiert.

2. SORTED_BLOCKSDiese Strategie ist eine Verbesserung der NESTED Strategie. Die Blöcke werdenvor dem Start der Größe nach sortiert. Hierdurch soll vermieden werden, dass amEnde nur noch große Blöcke bleiben, bei denen dann die Lastinbalance stärkerins Gewicht fällt. Ansonsten läuft alles wie bei der NESTED Strategie.

3. BALANCED_BLOCKSDiese Strategie verwendet eine Optimierung für ccNUMA Architekturen. Durchden dynamic Schedule kommt es dazu, dass die Threads immer verschiedeneBlöcke bearbeiten. Je nachdem in welcher Reihenfolge die Arbeit abgeschlossenwird, werden die noch fehlenden Blöcke verteilt. Diese Verteilung kann sichin jeder Iteration unterscheiden. Hierdurch ist es nicht möglich, die Daten inder Nähe der Threads zu platzieren, die mit den Daten rechnen müssen. Umdiese Problem zu umgehen wird eine Vorberechnung vorgenommen, in der dieArbeit der Blöcke bestimmt wird. Dann werden die Blöcke fest auf die Threadsin der äußeren parallelen Region verteilt und zwar so, dass möglichst alle gleichviel Arbeit bekommen. Hierdurch können die Daten in der Nähe der Threadsgespeichert werden und trotzdem ist das Problem der Lastinbalance so geringwie möglich.

Im weiteren Verlauf dieser Arbeit wird nur die BALANCED_BLOCKS Strategiebetrachtet, da hauptsächlich ccNUMA Maschinen untersucht wurden.

3.2 SHEMAT-SuiteSHEMAT-Suite ist ein Programm Paket für geothermale Simulationen. Es kann ver-wendet werden, um beispielsweise Grundwasserbewegungen, Wärmetransport oderStofftransport in porösen Medien zu simulieren. Eine umfangreichere Beschreibungder Funktionen ist in [Pruess & Xu 04] zu finden.

Der Code ist in Fortran geschrieben und mit OpenMP geschachtelt parallelisiertworden. Hierbei werden zwei Ebenen der Parallelisierung verwendet.

Auf der äußeren Ebene werden verschiedene Richtungsableitungen getrennt voneinander berechnet. Auf der inneren Ebene wird ein lineares Gleichungssystem aufge-stellt und gelöst. Beide Schritte laufen parallel ab. Nähere Informationen zu der Paral-lelisierung dieses Codes sind in [A. Wolf & Bücker 08] und [Bücker & Rasch+ 09] zufinden.

Eine Besonderheit dieses Codes ist es, dass schon eine Möglichkeit implementiertwurde, die Threads zu binden, auch im Fall von geschachteltem OpenMP. Hier wurdevon Hand in jeder parallelen Region ein Funktionsaufruf eingebaut, der das Bindenübernimmt. Durch dieses Vorgehen lässt sich eine gute Platzierung der Threads errei-chen. Ein kleiner Nachteil ist allerdings, dass man Dateien anlegen muss, die beschrei-

19

4 OPENMP THREADBINDING BIBLIOTHEK

ben, wie die Threads verteilt werden müssen. Hierbei verwendet man die CoreIDs, dieauch Linux verwendet. Es ist also für eine gute Platzierung nötig, sich die Hardwaregenau anzuschauen und für jede Maschine und jede Threadkombination auf äußererund innerer Ebene eine eigene Datei anzulegen.

Für dieses Programm lässt sich so eine gute Platzierung erreichen. Da es aber inerster Linie im Rahmen dieser Arbeit darum geht, die Funktionalität der entwickeltenBibliothek zu testen, wird im Folgenden diese Möglichkeit Threads zu Platzieren nichtverwendet.

Der Vorteil der Bibliothek ist dann, dass die Verwendung einfacher ist und dassman keine genauen Tabellen mit CoreIDs anlegen muss, wozu man die Maschine ge-nau kennen muss. Ein Vorteil in der Performance ist natürlich nicht zu erreichen, wenndie Platzierung schon gut gewählt war. Um zu prüfen ob die Platzierung überhaupt re-levant ist, werden im Folgenden Vergleichsmessungen gemacht, in denen das Bindennicht verwendet wird und die Threads nur vom Betriebssystem verteilt werden.

4 OpenMP Threadbinding BibliothekIn diesem Kapitel soll die erstellte Bibliothek vorgestellt werden, welche das Thread-binding übernimmt. Die Bibliothek dient dazu, das Binding für vorhandene OpenMPProgramme zu übernehmen und besonders im Falle von geschachtelten OpenMP Pro-grammen wesentlich zu vereinfachen.

4.1 Instrumentierung des CodesWie schon in der Einleitung beschrieben, ist es mit den meisten Compilern nicht mög-lich ein einfaches Binding der Threads zu Beginn des Programms vorzunehmen. Linuxbietet nur die Möglichkeit Threads aus Sicht des Betriebssystems zu binden und leidergibt es keine eindeutige Zuordnung von OpenMP-Threads zu Betriebssystemthreads.Mit Hilfe eines kleinen Testprogramms soll gezeigt werden, dass dieses Problem wirk-lich auftritt und das Binden der ersten Threadteams nicht zu einem brauchbaren Ergeb-nis führen würde. Im Wesentlichen besteht das Testprogramm aus der in Codebeispiel5 dargestellten Schleife. Das Programm startet fünfmal hintereinander eine geschach-telte parallele Region mit zwei Threads auf der äußeren und zwei Threads auf der inne-ren Ebene. Ausgegeben wird dann die ThreadID, die vom Betriebssystem verwendetwird und die jeweilige Threadnummer der inneren und äußeren parallelen Region ausSicht von OpenMP. Filtert man jetzt die Ausgabe so, dass nur ein OpenMP Threaduntersucht wird, kann man sehen, ob sich die ThreadID unterscheidet.

Ein Testlauf lieferte die folgende Ausgabe:

outer 0 inner 1 systemthread id 28724outer 0 inner 1 systemthread id 28726outer 0 inner 1 systemthread id 28728

20


Programmausschnitt 5 Schleife zum Testen der ThreadID

1 f o r ( i =0 ; i < 5 ; i ++){2 #pragma omp p a r a l l e l num_th reads ( 2 )3 {4 #pragma omp p a r a l l e l num_th reads ( 2 )5 {6 p r i n t _ t h r e a d _ i n f o ( ) ;7 }8 }9 }

outer 0 inner 1 systemthread id 28730outer 0 inner 1 systemthread id 28732

Man sieht, dass der Thread immer eine neue ThreadID vom Betriebssystem be-kommt. Aus Sicht von OpenMP handelt es sich aber immer um denselben Thread.Da man nur Betriebssystemthreads binden kann und es nicht möglich ist, vor der par-allelen Region zu sagen, welcher Betriebssystemthread verwendet wird, ist die einzigeMöglichkeit, die Threads in der parallelen Region zu Beginn zu binden.

Hieraus ergibt sich die Notwendigkeit den Code zu modifizieren und zu Beginneiner jeden parallelen Region das Binding vorzunehmen. Um für den Nutzer die Ver-wendung möglichst einfach zu halten, ist es wünschenswert diese Modifizierung au-tomatisch vornehmen zu können. Eine einfach Möglichkeit OpenMP Codes zu instru-mentieren bietet das in den Grundlagen schon kurz vorgestellte Werkzeug Opari. Hier-mit sind nur einige Änderungen beim Kompilieren und Linken notwendig und nichteine Modifizierung der eigentlichen Codedateien.

Für das Binding reicht es aus, eine Funktion nach dem Öffnen der parallelen Regio-nen aufzurufen. Opari ruft an dieser Stelle die Funktion pomp_parallel_begin auf,wie im Codebeispiel 4 zu sehen ist. Alle weiteren instrumentierten Funktionen sindhier nicht von Nutzen. Für diese Funktionen werden Dummy Funktionen angelegt, diekeinen Code enthalten. Der Compiler sollte dann in der Lage sein diese Funktionenwieder zu entfernen.

Es kann aber leider auch passieren, dass die Optimierung an anderen Stellen nichtmehr so funktioniert wie ohne die Instrumentierung. Sieht der Compiler einen Funk-tionsaufruf muss er erstmal davon ausgehen, dass in der Funktion alle globalen Datengeändert werden können. Hierdurch kann es dazu kommen, dass einige Optimierungenausgelassen werden, die ohne die Instrumentierung noch gemacht worden wären.

Eine Möglichkeit dies zu umgehen wäre, die Funktionsaufrufe in die OpenMPBibliotheken der Compiler zu integrieren. Die OpenMP Bibliothek muss auf jedenFall aufgerufen werden, um die parallele Region zu öffnen. Würde man hier einenFunktionsaufruf einfügen, wäre dies kein Problem für die Optimierung. Eine weitereMöglichkeit wäre die Instrumentierung der Binärdateien. Da die Optimierung vorher

21


stattfindet, hätte diese Form der Instrumentierung keinen Einfluss auf die Optimierungdes Codes. Die Möglichkeit OpenMP Code auf diese Weise zu instrumentieren wirdaktuell am Lehrstuhl für Betriebssysteme der RWTH Aachen im Rahmen der Bache-lorarbeit von Johannes Thiele untersucht. Sollte dieses Vorgehen erfolgreich sein, lässtsich dieser Mechanismus sicherlich auch für die hier erstellte Bibliothek verwenden.

Im Rahmen dieser Arbeit wurde nur die Instrumentierung mit Opari untersucht.

4.2 HardwareinformationenDie erstellte Bibliothek soll dem Nutzer ermöglichen, eine Platzierung nach gewissenStrategien anzulegen, ohne sich zu genau mit der Hardware auskennen zu müssen. Fürdie Bibliothek sind die Hardwareinformationen natürlich notwendig, um diese Strate-gien umzusetzen.

Natürlich lassen sich nicht alle Merkmale der Hardware erfassen und berücksich-tigen, da es einfach zu viele Punkte gibt, welche unter Umständen die Performancebeeinflussen können. Da es um Platzierung von Threads geht, ist es naheliegend, sol-che Einheiten zu berücksichtigen, auf die Threads gebunden werden können. Dies sindProzessoren aus Sicht des Betriebssystems. In der Hardware können dies Cores sein,oder noch kleinere Einheiten, wenn die Cores Multithreading unterstützen.

Interessant für das Binding ist das Verhältnis zwischen diesen Einheiten. FolgendeFragen sind etwa relevant, wenn man Threads platzieren möchte:

• Laufen zwei Threads auf einem Core oder auf getrennten Cores?

• Gehören zwei Cores zum selben Prozessor oder nicht?

• Gehören zwei Prozessoren zum selben Board oder sind sie auf zwei verschiede-nen Boards angebracht?

Eine gute Möglichkeit solche Verbindungen darzustellen, ist eine Baumstrukturzu. Die Blätter sind dann die kleinsten betrachteten Recheneinheiten und die Wurzelist die gesamte Maschine. In den Knoten werden dann immer die jeweils zusammen-gehörenden kleineren Einheiten zusammengefasst.

• Ein Core fasst alle verwendeten Multithreads zusammen.

• Ein Prozessor fasst alle internen Cores zusammen.

• Ein Board fasst alle darauf aufgebrachten Prozessoren zusammen.

Für eines der verwendeten Nehalem Boards ergibt sich daraus ein Baum, wie in Ab-bildung 7 dargestellt.

Auf der ScaleMP Maschine gibt es noch eine weitere Ebene nach oben hin, da hiernoch mehrere Boards zu einer Maschine zusammengefasst werden.

Es ist auch möglich, die Aufteilung genauer vorzunehmen, um etwa zu berücksich-tigen, dass sich einige Cores eines Prozessors noch bestimmte Caches teilen. Hierzu

22


BoardProzessorCoreHyperthread

Abbildung 7: Hardwarehierarchie des Nehalemsystems

werden dann nicht alle Cores eines Prozessors in einer Baumebene zusammengefasst,sondern im ersten Schritt alle, die den Cache teilen und im zweiten Schritt die zusam-mengefassten Knoten. Dadurch wird der Baum dann eine Ebene höher und es könnendie Cores noch genauer unterschieden werden.

4.3 Auslesen der HardwareinformationenDas Gewinnen der Hardwareinformationen muss nur einmal zu Beginn des Programm-laufs geschehen. Da sich die Hardware voraussichtlich nicht während des Programm-laufs ändert, macht es keinen Sinn vor jedem Binding der Threads die Informationenneu zu bestimmen. Außerdem wäre eine solche Herangehensweise sehr zeitaufwendigund würde eine große Menge Overhead erzeugen.

Zu diesem Zweck ist es mit den meisten Compilern möglich in einer BibliothekFunktionen zum Initialisieren von Daten anzulegen. Für den Sun Compiler geht diesüber ein pragma, bei dem Gnu Compiler und dem Intel Compiler über ein Attribut.Durch die folgenden Zeilen wird dann erreicht, dass die Funktion ct_init beim Pro-grammstart einmal ausgeführt wird. In dieser Funktion kann dann die Baumstrukturangelegt und im weiteren Ablauf verwendet werden.

#ifdef sun#pragma init (ct_init)#elsevoid ct_init() __attribute__((constructor));#endif

23


processor : 7vendor_id : GenuineIntelcpu family : 6model : 26model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHzstepping : 4cpu MHz : 2933.433cache size : 8192 KBphysical id : 0siblings : 8core id : 3cpu cores : 4apicid : 7initial apicid : 7fpu : yesfpu_exception : yescpuid level : 11wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflushdts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs btsrep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca sse4_1 sse4_2 popcnt lahf_lm idabogomips : 5865.87clflush size : 64cache_alignment : 64address sizes : 40 bits physical, 48 bits virtualpower management:

Abbildung 8: Ausschnitt aus der /proc/cpuinfo Datei auf einem der verwendeten Neha-lem Systeme

Hierdurch wird vermieden, dass Funktionsaufrufe zu Beginn des Programms inden Code eingefügt werden müssen, da das Ziel ja war, nur mit der automatischenInstrumentierung auszukommen und so den Code unverändert zu lassen.

Die Bibliothek bietet zwei Möglichkeiten die Hardwareinformationen einzulesen.Zum einen durch das Parsen der Linux Systeminformationen in /proc/cpuinfo, zumanderen aus einer vom Nutzer anzulegenden Datei.

4.3.1 /proc/cpuinfo

In /proc/cpuinfo stellt Linux dem Benutzer einige Hardwareinformationen bereit.Für jede Einheit, die Linux als Prozessor sieht, gibt es ein Bündel an Informationen.Ein Ausschnitt aus diesen Informationen für den Nehalem Prozessor ist in Abbildung8 zu sehen. Von diesen Blöcken gibt es insgesamt 16 Stück, für jeden Core bzw. Hard-warethread einen.

Die relevanten Informationen im Bezug auf die Hardwarehierarchie die aufgebautwird sind hier:

1. processor : 7

2. physical id : 0

24


3. core id : 3

Die erste Nummer gibt an, wie das Betriebssystem diese Einheit bezeichnet. Dadiese Nummer später für das Binding gebraucht wird, werden die Blätter des Baumesdamit beschriftet. Die “physical id” gibt an, auf welchem Sockel sich die Rechenein-heit befindet und “core id” gibt an auf welchem Core dieses Sockels. Multithreadslassen sich nur dadurch erkennen, dass mehrere Einheiten die gleiche “physical id”und die gleiche “core id” haben. Ein Problem bei dieser Herangehensweise ist es, dasshier ein Sockel die kleinste Unterscheidung ist. Für die ScaleMP Maschine ist das Pro-blem, dass es aber noch ein Stufe über den Sockeln geben müsste, nämlich Boards.Verwendet man die Informationen aus /proc/cpuinfo auf der ScaleMP Maschinebekommt man in der ersten Ebene eine Aufteilung auf 26 Sockel. Besser wäre es abereine Aufteilung auf 13 Boards zu haben und dann eine weitere Ebene, in der jedesBoard noch mal in zwei Sockel unterteilt wird.

4.3.2 OMP_CORE_LIST

Um die Hardware der ScaleMP Maschine detaillierter beschreiben zu können, gibt esnoch die Möglichkeit die Hardwarehierarchie in einer Datei zu speichern. Es gäbe auchdie Möglichkeit aus NUMA Informationen im /sys Verzeichnis herauszubekommen,auf welchen Boards welche Sockel auf der ScaleMP Maschine sind, aber die Lösungmit der Datei ist allgemeiner und ermöglicht dem Nutzer mehr Freiheiten. Wenn es inder Zukunft aus irgendeinem Grund nötig wird eine weitere Ebene in die Hardware-hierarchie einzuziehen, ist es mit einer einfachen Änderung in einer Datei möglichdies zu berücksichtigen. Es ist hiermit auch möglich feiner zu unterscheiden, als mit/proc/cpuinfo. Wie in Abbildung 1 zu sehen ist, sind nicht alle Cores auf den Har-pertown Maschinen über einen Cache miteinander verbunden, sondern nur paarweiseje zwei Cores. Mithilfe von /proc/cpuinfo werden einfach vier Cores erkannt. Legtman selber eine Datei an, kann man in einer Ebene jeweils zwei Cores, welche sicheinen Cache teilen, zusammenfassen und in einer zweiten Ebene zwischen diesen Co-res dann unterscheiden. Der Unterschied in den Darstellungen ist in Abbildung 9 zusehen.

Natürlich ist es notwendig zum Erstellen einer solchen Datei die Hardware genauzu kennen. Gerade das sollte nach Möglichkeit nicht vom Nutzer verlangt werden, dadie Hardware womöglich zu kompliziert ist. Es ist aber kein Problem für den Admini-strator eine solche Datei zu erstellen und auf der Maschine zur Verfügung zu stellen.Die Datei wird sich nicht im Laufe der Zeit ändern und muss daher nur beim Einrichtender Maschine einmal angelegt werden. Um dem Nutzer dennoch die Möglichkeit zugeben auch eine eigene Datei zu verwenden, falls er das möchte, wird der Dateiname inder Umgebungsvariable OMP_CORE_LIST angegeben. Ist die Variable nicht gesetzt,wird /proc/cpuinfo verwendet. Möchte der Administrator andere Informationen ver-wenden, weil diese Informationen zu ungenau sind, kann er im Profil für alle Nutzereine Datei angeben. Wenn der Anwender nun für sein Programm wieder eine andere

25


BoardProzessorCore

BoardProzessorCore with shared L2 cacheCore

Abbildung 9: Hardwaredarstellung eines Harpertownknotens, links mithilfe von/proc/cpuinfo erstellt, rechts eine bessere Darstellung mit einer eigenen Informations-datei

Hardwarehierarchie verwenden will, hat er immer noch die Möglichkeit die Variablezu überschreiben.

Aufbau einer Datei zur Angabe der HardwarehierarchieJede Einheit, auf die ein Thread gebunden werden kann, also Core oder Hardware-

thread, bekommt eine eigene Zeile in der Datei. Eine jede Zeile gibt dann den Pfad an,der zu dem entsprechenden Knoten führt. Jede Zeile beginnt mit der Prozessornum-mer, die das Betriebssystem verwendet. Danach folgt eine Liste von Nummern, dieangibt, welcher Kindknoten in der Baumdarstellung gewählt werden muss, um einenPfad von der Wurzel aus zum entsprechenden Blatt zu bekommen.

Betrachtet man noch mal die Hardwarehierarchie des Harpertown in Abbildung 10,sieht man, dass zum Beispiel für den Prozessor 6 aus Betriebssystemsicht zweimal dererste Kindknoten gewählt werden muss und dann einmal der Nullte, um von der Wur-zel zu diesem Knoten zu gelangen. Die entsprechende Zeile enthält also die folgendenEinträge:

6 1 1 0

4.3.3 Linux affinity mask

Es kann passieren, dass der Nutzer nicht möchte, dass die gesamte Maschine verwen-det wird, um darauf das Binding vorzunehmen. Es mag etwa sein, dass auf einer großenShared-Memory-Maschine mehrere Prozesse gleichzeitig abgearbeitet werden. In ei-nem solchen Fall sollte es möglich sein, dass nur die angegebenen Prozessoren verwen-det werden. Unter Linux wird für den Prozess mitgespeichert, auf welche Prozessorender Betriebssystemscheduler den Prozess und alle enthaltenen Threads schedulen darf.Diese Informationen werden in der “affinity mask” gespeichert. Hierbei handelt es sichum eine Bitmaske, die für jeden Prozessor in einem Bit die Information speichert, ob

26


0 1

0

0

0 1

1

0 1 0 1 0 1 0 1

0 1 2 3 4 5 6 7

Abbildung 10: Darstellung der Hardwarehierarchie eines Harpertownsystems

der Prozessor verwendet werden darf, oder nicht. Die “affinity mask” kann für den Pro-zess mit Programmen wie taskset oder numactl gesetzt werden. Beim Speichern derHardwareinformationen werden diese Informationen ausgelesen und nur solche CPUsverwendet, welche auch der Betriebssystemscheduler verwenden darf. Die nicht er-laubten CPUs werden gar nicht in die Baumstruktur aufgenommen.

Es ist mit taskset möglich die “affinity mask” eines Prozesses auch zur Laufzeitnoch zu ändern. Um dies zu berücksichtigen, wäre es notwendig für jede paralleleRegion zu testen, ob sich an der “affinity mask” etwas geändert hat. Dies ist ohneProbleme möglich, erzeugt aber einigen Overhead. Alle Startupmechanismen, welcheeinmal zu Beginn des Programms ausgeführt werden, müssen nicht unbedingt schnellsein, für das Binding ist es aber ratsam, den Overhead so gering wie möglich zu halten.Um für den Normalfall eine gute Performance zu erreichen wird eine Änderung der“affinity mask” zur Laufzeit von der Shell aus nicht berücksichtigt.

Durch diese Möglichkeit von außen die verwendeten Prozessoren einzuschränken,erhält man sich die Möglichkeit mit anderen Mechanismen zusammen zu arbeiten. Eingutes Beispiel hierfür ist die ScaleMP Maschine und deren Einbindung in das Batchsy-stem. Da die Maschine 104 Cores beinhaltet, macht es Sinn, auch mehrere Programmegleichzeitig zu starten. Passiert dies, wird ein Script gestartet, welches jedem Batchjobbestimmte Cores zuteilt. Dies geschied unter Verwendung von taskset. An dieserStelle ist es also nötig, um die Threadbinding Bibliothek sinnvoll nutzen zu können,dass aus diesem Prozessorset nicht ausgebrochen wird.

27


4.4 Erstellen der ThreadhierarchieNeben den Hardwareinformationen ist es für das Platzieren der Threads auch nochwichtig, die Anzahl der Threads aus den verschiedenen Ebenen zu kennen. Des Weite-ren muss vom Nutzer noch eine Strategie mit angegeben werden, nach der die Threadsverteilt werden sollen.

4.4.1 OMP_NESTING_TEAM_SIZE

In vielen Fällen reicht es aus, eine Threadhierarchie einmal anzugeben und diese dannfür den gesamten Programmlauf zu verwenden. OpenMP arbeitet an vielen Stellen mitUmgebungsvariablen, um dem Nutzer eine einfache Möglichkeit zu geben Rahmen-bedingungen für den Programmlauf festzulegen und diese auch einfach von Lauf zuLauf zu ändern. Um in dieses Schema zu passen, wird auch für die Bindingbibliothekeine solche Umgebungsvariable verwendet, um die Threadhierarchie zu beschreiben.Diese Variable heißt OMP_NESTING_TEAM_SIZE. Um die Verwendung dieser Va-riable überschaubar zu halten, ist sie nur für Threadhierarchien geeignet, in denen alleTeams einer Ebene die gleiche Größe haben. Fälle mit ungleichen Teamgrößen lassensich nur recht kompliziert in einem kurzen String beschreiben und sind auch eher Aus-nahmefälle. Wichtiger erschien es, den Normalfall einfach darstellen zu können, umdie Nutzung für die allermeisten Fälle problemlos zu gewährleisten.

Der Nutzer muss angeben, wie viele Threads er in welcher Ebene seines Pro-gramms verwenden möchte. Für jede dieser Ebenen muss auch noch eine Strategieangegeben werden, nach der die Threads dann verteilt werden sollen. Die Strategi-en sind “compact”,“scatter”,“subcompact” und “subscatter”. Was genau die Strategienbedeuten, wird noch im Kapitel 4.5 erklärt. In OMP_NESTING_TEAM_SIZE wirddann einfach die Threadanzahl und die Strategie der verschiedenen Ebenen aufgelistetund mit Komma getrennt. Ein Beispiel sieht wie folgt aus:

OMP_NESTING_TEAM_SIZE=4,scatter,2,subcompact

4.4.2 omp_set_nesting_info()

Das Festlegen der Threadhierarchie über die Umgebungsvariable ist eine gute Mög-lichkeit, eine einfache Einstellung vorzunehmen. Es gibt aber einige Fälle, in denenreicht diese Möglichkeit nicht aus:

1. Es kann sein, dass sich die Threadhierarchie im Programmlauf ändert.

2. Verwendet das Programm unterschiedlich große Teams auf einer Ebene, lässtsich das nicht über die Umgebungsvariable abbilden.

3. Wenn die Threadverteilung von den Eingabedaten abhängig ist, kann die Umge-bungsvariable nicht vor dem Programmstart gesetzt werden.

28


Die Funktion omp_set_nesting_info wird bereitgestellt, um diese Fälle abzu-decken. Als Parameter wird ein String nach dem gleichen Muster übergeben, wie erauch für OMP_NESTING_TEAM_SIZE verwendet wurde. Ein Beispiel für einen sol-chen Funktionsaufruf sieht also wie folgt aus:

omp_set_nesting_info("4,scatter,2,scatter");

CALL OMP_SET_NESTING_INFO("4,scatter,2,scatter")

In der Funktion wird überprüft, welcher Thread die Funktion aufgerufen hat. Eswird dann ein neuer Baum nach den Angaben im Funktionsparameter aufgebaut undals Teilbaum an den aufrufenden Thread angehängt. Hierdurch wird es möglich, auchBäume zu erzeugen, in denen nicht alle Teams auf einer Ebene die gleiche Threadan-zahl haben. Programmausschnitt 6 zeigt den Aufbau eines unsymmetrischen Thread-baumes. Der genaue Aufbau des Baumes ist in Abbildung 11 zu sehen.

Mithilfe dieser Funktionsaufrufe lassen sich beliebige Bäume erzeugen. Es ist zwarfür kompliziertere Baumstrukturen notwendig, die Funktion mehrmals aufzurufen undzwischendurch neue Threads zu starten, dafür ist der einzelne Funktionsaufruf rechteinfach. Es wäre schwierig, eine beliebige Baumstruktur in einem String zu beschrei-ben. Man kann zwar eine Baumstruktur als String übergeben, allerdings wäre das Er-stellen des Strings so komplex, das es eine unnötige Hürde für den Nutzer darstellenwürde.

Programmausschnitt 6 Code zum Aufbau einer unsymmetrischen Threadhierarchie

1 o m p _ s e t _ n e s t i n g _ i n f o ( " 2 , s c a t t e r " ) ;2 #pragma omp p a r a l l e l num_th reads ( 2 )3 {4 i f ( omp_get_thread_num ( ) = = 0 ) {5 o m p _ s e t _ n e s t i n g _ i n f o ( " 4 , compact " ) ;6 } e l s e {7 o m p _ s e t _ n e s t i n g _ i n f o ( " 2 , s u b s c a t t e r , 2 , compact " ) ;8 }9 }

Insbesondere da das Starten der Threads im Programm auch in derselben Reihen-folge geschehen muss, kann davon ausgegangen werden, dass ein Möglichkeit im-plementiert wurde, genau die gewünschten Threadanzahlen zu starten. Eine andereÜberlegung war es, einen fertigen Baum als Übergabeparameter an die Funktion zuübergeben. Gegen diese Überlegung sprechen zwei Aspekte:

1. In Fortran77 gibt es keine Pointer, daher ist es nicht möglich, einen Baum auf-zubauen.

29


scatter

compact subscatter

compact

Abbildung 11: Darstellung einer unsymmetrischen Threadhierarchie

2. Das Aufbauen eines Baumes, selbst wenn Funktionen dazu bereitgestellt wer-den, erschien mir komplizierter, als die jetzt verwendete Darstellung und somitfür den Nutzer als die unkomfortablere Lösung.

4.5 Zuordnung von Threads auf CoresNachdem die Threadhierarchie und die Hardware erkannt wurden, ist es im Weiterennötig, eine Zuordnung zwischen beiden herzustellen. Diese Zuordnung ist solange gül-tig, bis sich die Threadhierarchie ändert. Eine Konsequenz hieraus ist, dass man nur zuBeginn des Programms und beim Ändern der Threadhierarchie diese Zuordnung be-stimmen muss. Beim eigentlichen Binding braucht die Zuordnung nur ausgelesen undverwendet zu werden. Da das Binding beim Start einer jeden parallelen Region statt-findet, ist es gut, hier den Aufwand so gering wie möglich zu halten, um den Overheadgering zu halten.

Der Nutzer gibt beim Anlegen der Threadhierarchie eine Strategie an, welche ver-wendet werden soll, um die Threads zu verteilen. Hierbei sind die folgenden Strategiengültig:

1. scatterDiese Strategie gibt an, dass die Threads möglichst weit voneinander entferntplatziert werden sollen. Besteht das System aus mehreren Boards, wie die Ma-schine von ScaleMP, dann wird nach Möglichkeit nur ein Thread pro Boardgestartet. Hat das System nur ein Board, dann wird möglichst nur ein Thread aufeinem Sockel gestartet. Sind nicht genug Boards oder Sockel vorhanden, wer-den natürlich mehrere Threads auf einem Board oder Sockel verwendet. Eine

30


solche Verteilung von Threads hat im Allgemeinen den Vorteil, die vorhande-ne Speicherbandbreite der Maschine schon mit wenigen Threads voll nutzen zukönnen.

2. compactBei dieser Strategie ist genau das Gegenteil zur scatter Strategie gewünscht. DieThreads werden hier so eng wie möglich zusammen gepackt. Es wird also zuerstein Core oder ein Sockel aufgefüllt, bevor ein neuer angefangen wird. Der Nach-teil einer solchen Verteilung ist, dass man die Speicherbandbreite der Maschinenur schlecht ausnutzt. Der Vorteil ist aber, dass die Kommunikation zwischenden Threads schneller vonstatten geht. Zwei Threads, die einen Cache teilen,können wesentlich schneller Daten austauschen, als zwei Threads, die auf unter-schiedlichen Boards laufen.

3. subcompact / subscatterDie Strategien subcompact und subscatter bedeuten im Wesentlichen dasselbewie compact und scatter, mit einer Ausnahme: Bei diesen Strategien sollen alleThreads in der Hardwarehierarchie unterhalb des Vaterthreads erzeugt werden.Die Verteilung auf der unteren Ebene erfolgt dann nach der scatter oder compactStrategie, je nachdem ob subscatter oder subcompact gewählt wurde. Abbildung12 zeigt den Unterschied einer Verteilung mit scatter und subscatter. Im erstenFall, wo die Verteilung nach der Strategie “2,scatter,4,subscatter” durchgeführtwird, werden die Threads in der äußeren parallelen Region auf zwei Sockel ver-teilt. Die inneren Teams werden dann darunter verteilt, bleiben also auf densel-ben Sockeln, so das insgesamt nur zwei Sockel verwendet werden. Im zweitenFall, wo die Strategie “2,scatter,4,scatter” verwendet wird, werden die erstenbeiden Threads genauso verteilt, wie zuvor. Die geschachtelten Teams werdendann aber auf die gesamte Maschine verteilt, so dass insgesamt alle vier Sockelverwendet werden.

Der Sinn dieser Strategien ist der Folgende: Verteilt man in der ersten Ebene bei-spielsweise vier Threads auf vier verschiedene Sockel einer Maschine und jederdieser Threads startet dann wieder ein neues Team mit vier Threads, dann machtes unter Umständen Sinn, diese Teams auf demselben Sockel zu starten, wiedie entsprechenden Masterthreads. Ein inneres Team kann dann schneller kom-munizieren, weil es auf einem Sockel läuft und so nicht über den externen Buskommunizieren muss. Außerdem kann es auf einer ccNUMA Maschine sein, dasder Masterthread Daten angelegt hat, die im Speicher dieses Sockels gespeichertwurden. Laufen nun alle Threads dieses Teams auf diesem Sockel, so könnenalle auf diese Daten schnell zugreifen, ohne dass remote Zugriffe nötig werden.

31


verwendeter Core

freier core

verwendeter Core

freier core

Abbildung 12: Darstellung der verwendeten Cores auf einem vier Sockel Barcelo-na Opteron, mit verschiedenen Strategien. links: 2,scatter,4,subscatter rechts: 2,scat-ter,4,scatter

4.5.1 Binden von Threads

Am Beginn einer jeden parallelen Region muss nun das Binding vorgenommen wer-den. Dies kann relativ häufig vorkommen, wenn das Programm oft parallele Regio-nen öffnet. Daher ist es wichtig, möglichst wenig Overhead zu erzeugen. Das Bindingfunktioniert über den in Kapitel 2.7.3 beschriebenen systemcall sched_setaffinity.Ein Problem, welches vor dem Aufruf von sched_setaffinity noch zu lösen ist,ist das Herausfinden der eigenen Threadposition in der Threadhierarchie. Hierfür kön-nen die in Kapitel 2.5.4 vorgestellten Funktionen omp_get_ancestor_thread_numund omp_get_level verwendet werden. Leider muss trotzdem noch auf jedem Le-vel omp_get_ancestor_thread_num aufgerufen werden. Ohne die Threadnummernder Vorgänger in ihren Teams zu kennen ist es aber unmöglich herauszufinden, wohinsich der aktuelle Thread binden muss, daher ist dieser Overhead unvermeidlich. Hatman die Position einmal gefunden, muss nur noch aus der Threadhierarchie, welche imVorab schon angelegt wurde, der Knoten herausgesucht werden. Beim Mapping wurdean diesem Knoten schon eine Prozessorid gespeichert, wie sie sched_setaffinityverwendet. Diese wird genommen und damit der Thread gebunden.

32

5 KERNELBENCHMARKS

5 KernelbenchmarksUm zu prüfen, ob die implementierten Strategien auch die gewünschten Effekte ha-ben, wurden einfache Testprogramme verwendet. An großen Programmen ist es oftschwierig zu verstehen, was genau alles die Performance beeinflusst. Daher gibt eskleine Benchmarktests, die sich auf ein besonderes Kriterium beschränken und hier-mit lassen sich diese Kriterien dann gut untersuchen.

Es ist natürlich keine Garantie, dass auch große Programme wie gewünscht laufen,wenn alle Benchmarks funktionieren, aber wenn man bei den Benchmarks schon Pro-bleme sieht, kann man hier nach einer Lösung suchen, bevor man sich an komplexeAnwendungen wagt.

Im Folgenden werden zwei Benchmarks betrachtet, beide Benchmarks sind eigent-lich nicht für geschachtelt parallele Programme gedacht und mussten daher modifi-ziert werden. Der erste Benchmark ist an einen Streambenchmark zu Messung derSpeicherbandbreite angelehnt, genauere Informationen zum Stream Benchmark sindunter [Mccalpin 95] zu finden. Der zweite Benchmark ist an die EPCC OpenMP Mi-crobenchmarks zur Messung der Performance bestimmter OpenMP Konstrukte an-gelehnt. Eine genaue Beschreibung der EPCC OpenMP Microbenchmarks ist unter[Bull 99] zu finden.

Im Weiteren werden die Benchmarks als “nested Stream” Benchmark und “nestedEPCC” Benchmark bezeichnet.

5.1 “nested Stream” BenchmarkseriellDer normale Stream Benchmark dient zur Messung der Speicherbandbreite eines Sy-stems. Es werden Felder angelegt die double Variablen enthalten. Auf diesen Feldernwerden dann verschiedene Operationen durchgeführt. In der verwendeten Version wa-ren dies die folgenden Operationen:

• copy: c(j) = a(j)

• scale: b(j) = scalar*c(j)

• add: c(j) = a(j) + b(j)

• Triad: a(j) = b(j) + scalar*c(j)

In einer do-Schleife wird über das gesamte Feld gelaufen und dabei die Operationauf jedes Element angewendet. Für den vierten Fall zum Beispiel sieht die Schleifewie folgt aus.

DO 60 j = 1,na(j) = b(j) + scalar*c(j)

60 CONTINUE

33

5 KERNELBENCHMARKS

Sind die Felder groß genug, so das sie nicht in den Cache passen, müssen die Ele-mente immer aus dem Speicher geladen und auch zurückgeschrieben werden. Außerbei der copy Operation wird mit den Daten zwar auch gerechnet, allerdings dauertdas Laden von Daten aus dem Speicher so lange, dass eine Addition oder Multiplika-tion nicht ins Gewicht fällt. Die Grenze für das Ausführen der Schleifen ist klar dieSpeicherbandbreite.

Der Benchmark misst die Zeit, die es braucht, um die Operation auf allen Elemen-ten auszuführen. Mithilfe der Ausführungszeit und dem Wissen über die Feldgrößewird dann die erreichte Speicherbandbreite ermittelt und ausgegeben.

OpenMP ParallelisierungMan kann das Benchmark Programm seriell verwenden, um die Speicherbandbreiteeinzelner Cores zu messen. Bei Singelcoresystemen mit einem Prozessor reicht dasvollkommen aus. Für größere Systeme macht es aber Sinn das Programm mit mehrerenThreads zu starten. Mit einem Thread kann man auf normalen Mehrsockelsystemennicht die volle Speicherbandbreite nutzen. Besonders auf ccNUMA Maschinen wirdnur der Speicher eines Prozessors verwendet, daher lassen sich auch nur Aussagenüber einen Prozessor machen und nicht über die Bandbreite des Gesamtsystems.

Die verwendeten Schleifen in dem Benchmark Programm sind natürlich unabhän-gig voneinander, da alle verwendeten Arrayelemente über den Schleifenzähler j indi-ziert werden. Es ist also einfach möglich die Schleifen mit OpenMP zu parallelisieren.

!$OMP PARALLEL DODO 60 j = 1,n

a(j) = b(j) + scalar*c(j)60 CONTINUE

!$OMP END PARALLEL DO

Verwendet man das Programm in dieser Form, lässt sich die gesamte Speicherband-breite des Systems ermitteln, indem man auf jedem Core einen Thread startet. Zu be-achten ist noch, dass man für eine optimale Speichernutzung auf ccNUMA Systemendie Daten auch parallel anlegen muss. Linux verwendet zum Allozieren des Speicherseine sogenannte “first touch” Strategie. Hierbei geht es darum, in welchem physischenSpeicher die Daten abgelegt werden. Bei einer “first touch” Strategie werden die Sei-ten in dem Hauptspeicher angelegt, der dem Prozessor am nächsten ist, der als erstesauf die Daten zugreift. Diese Strategie lässt sich nutzen, um die Speicherseiten gün-stig zu platzieren. Parallelisiert man das Anlegen der Speicherseiten in gleicher Artund Weise wie den späteren Zugriff, liegen die Seiten beim Zugriff im lokalen Spei-cher und man bekommt die beste Speicherbandbreite. Eine solche Parallelisierung desProgramms gibt einem Auskunft darüber, welche Speicherbandbreite man maximal ineinem OpenMP Programm erreichen kann.

Geschachteltes OpenMPIm Falle von geschachtelten OpenMP Programmen ist das Anlegen der Daten schwie-

34

5 KERNELBENCHMARKS

riger, wenn es sich um ein ccNUMA System handelt. Betrachtet man ein Programmmit zwei Ebenen der Parallelisierung, gibt es drei Möglichkeiten die Daten anzulegen.

1. im seriellen TeilHier werden alle Daten nach Möglichkeit in dem Hauptspeicher abgelegt, aufdem der Masterthread läuft. Der Nachteil ist offensichtlich, das Threads, diespäter auf die Daten zugreifen wollen, alle auf den gleichen Speicher zugreifen.Diese Speicherzugriffe werden schnell zum Flaschenhals. Diese Möglichkeit dieDaten anzulegen sollte für Anwendungen, deren Performance durch die Spei-cheranbindung bestimmt ist, möglichst vermieden werden. Dies ist aber mei-stens kein Problem. Man kann die Felder einfach vor dem ersten Benutzen ein-mal in einer parallelen Region mit einem beliebigen Wert vorbelegen und die-sen Wert dann in der seriellen Einleseroutine überschreiben. Der Zugriff musshierdurch nicht optimal werden, da das spätere Zugriffsmuster ganz anders aus-sehen kann, als die einfache parallele Region beim Anlegen. Es ist aber in derRegel auch bei zufälligem Zugriff besser, die Daten auf alle Speicher zu vertei-len. Dann treten zwar immer noch viele remote Zugriffe auf, aber wenigstensnicht alle in einen Speicher.

2. in der ersten parallelen RegionHat man die Möglichkeit die Daten in der ersten parallelen Region anzulegen, istdies auf jeden Fall vorzuziehen. Hierdurch erreicht man schon, dass die Datenverteilt in den verschiedenen physischen Speichern liegen. Wenn das Programmnicht zufällig auf die Daten zugreift, sondern etwa jedes innere Team auf ei-nem Bereich arbeitet, lässt sich hiermit schon erreichen, dass wenigstens dieMasterthreads der inneren Teams immer auf lokalen Daten arbeiten können.

Die äußeren Threads lassen sich über die in Kapitel 2.7.2 beschriebenen Um-gebungsvariablen platzieren. Hierdurch lässt sich auf einfache Weise erreichen,dass diese Threads auf verschiedenen Sockeln laufen und so auch mehrere ver-schiedenen physische Speicher genutzt werden.

Ein Problem ist, dass im Normalfall die Daten auch von den anderen Threadsder inneren Teams verwendet werden müssen. Da die Teams zufällig zusam-mengestellt werden, kann nicht garantiert werden, dass die Daten auch für dieseThreads im lokalen Speicher liegen. An diesem Punkt sollte sich die erstellteThreadbinding Bibliothek als vorteilhaft erweisen. Kann man erreichen, dassalle Threads eines inneren Teams auf einem Sockel laufen, haben auch die-se Threads lokale Speicherzugriffe und die erreichte Speicherbandbreite erhöhtsich.

3. in der zweiten parallelen RegionKönnte garantiert werden, dass die inneren Teams immer aus denselben Threads

35

5 KERNELBENCHMARKS

zusammengesetzt würden, wäre dies eine gute Möglichkeit den Speicher anzule-gen. Jeder Thread würde die Daten anlegen, die er benötigt und könnte auf dieseDaten dann später lokal zugreifen. Leider wechseln aber die Threads in einer ge-schachtelten parallelen Region. Legen die Threads also die Daten in der innerenparallelen Region an, ist nicht garantiert, dass in der nächsten inneren parallelenRegion die Daten noch im lokalen Speicher liegen, da es sich möglicherweiseum andere Threads handelt, die das Team bilden. Um diese Verteilung sinnvollzu nutzen, ist es also nötig, die Threads der einzelnen Teams immer gleich zuverteilen. Auch hierzu kann wieder die erstellte Bibliothek verwendet werden.

Um zu überprüfen, ob die Threadbinding Bibliothek auch die erwarteten Verbes-serungen im Bezug auf die Speicherbandbreite liefert, wurde eine abgewandelte Formdes Stream Benchmarks verwendet, die mit geschachteltem OpenMP arbeitet. Es wer-den hier in der ersten parallelen Region für jeden Thread eigene Felder A,B und C an-gelegt und initialisiert. Dann startet jeder Thread ein inneres Team, welches die obengenannten Operationen wie im einfachen OpenMP Fall ausführt. Der Benchmark ent-spricht also dem beschriebenen Fall 2.

Barcelona OpteronAls Beispiel für eine ccNUMA Maschine wurde die Barcelona Opteron Maschine ver-wendet. Dabei wurden verschiedene Kombinationen von Threads auf der inneren undäußeren Ebene betrachtet. Alle Läufe wurden einmal mit Hilfe der Threadbinding Bi-bliothek gemacht und einmal ohne Binding. Die Ergebnisse die die Messungen mit derThreadbinding Bibliothek ergeben haben sind in Abbildung 13 zu sehen, die Ergeb-nisse, die ohne Binding erreicht wurden in Abbildung 14. Zum Setzen der Strategiefür das Binding wurde die Umgebungsvariable OMP_NESTING_TEAM_SIZE auf“4,scatter,4,subscatter” gesetzt. Das Streuen der Threads auf der äußeren Ebene solldafür sorgen, dass jedes Team auf einem eigenen Sockel läuft und somit eine hoheSpeicherbandbreite erreicht werden kann. Die inneren Teams sollen dann immer aufdieselben Sockel gebunden werden wie der entsprechende Thread aus dem äußerenTeam, damit sie auch lokal auf denselben Speicher zugreifen können.

Zu sehen in den Diagrammen ist die erreichte Gesamtspeicherbandbreite. Auf derx-Achse ist die Anzahl der verwendeten Teams aufgetragen und auf der y-Achse dieerreichte Speicherbandbreite. Die Messungen wurden dann für unterschiedliche Threa-danzahlen in den inneren Teams durchgeführt. Für jede Threadanzahl wird eine neueDatenreihe verwendet. Betrachtet man die Ergebnisse für einen Thread pro inneremTeam, ist in beiden Fällen eine gute Skalierung zu erkennen. Beide Messreihen startenbei etwa 4400 MB/s für einen Thread. Der ungebundene Fall erreicht für vier Threads15031 MB/s und der Fall in dem die Threadbinding Bibliothek verwendet wurde er-reicht 15832 MB/s. Der Unterschied lässt sich dadurch erklären, dass im Falle dergebundenen Threads alle vier Sockel des Systems verwendet werden. Ungebunden

36

5 KERNELBENCHMARKS

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1 2 4

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket

2 threads per socket


Abbildung 13: Messergebnisse der “nested Stream” Benchmarks auf einem BarcelonaOpteron System unter Verwendung der Threadbinding Bibliothek

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

1 2 4

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket



Abbildung 14: Messergebnisse der “nested Stream” Benchmarks auf einem BarcelonaOpteron System ohne Binding der Threads

37

5 KERNELBENCHMARKS

kann es passieren, dass zwei Threads auf einem Sockel laufen. Allerdings ist der Un-terschied nur sehr gering, so dass es nicht unbedingt notwendig wäre die Threads fürdiesen Fall zu binden.

Verwendete man mehrere Threads in den inneren Teams wird der Vorteil der ge-bundenen Strategie größer. Betrachtet man den Fall mit vier Threads pro inneremTeam, sind folgende Dinge auffällig: Das Verwenden von vier Threads bringt bei ei-nem Sockel im gebundenen und im ungebundenen Fall eine Verbesserung der Speicher-bandbreite. Der Vorteil ist aber im gebundenen Fall größer. Es werden 4899 MB/s imungebundenen und 7602 MB/s im gebundenen Fall erreicht. Der Grund hierfür ist,dass im gebundene Fall alle Threads auf dem Sockel laufen, auf dem die Daten ange-legt wurden. Hierdurch lassen sich remote Zugriffe vermeiden, die im ungebundenenFall auftreten, da die Threads zufällig verteilt auf der Maschine laufen.

Schaut man sich das Verhalten für mehrere Sockel an, setzt es sich im Wesentlichenfort. Die gebundene Version erreicht auf vier Sockeln mit je vier Threads pro inneremTeam eine Speicherbandbreite von 13131 MB/s wohingegen die ungebundene Versionnur 10689 MB/s erreicht.

Weiterhin ist noch auffällig, dass bei der Verwendung aller vier Sockel die Speicher-bandbreite abnimmt, wenn man mehr Threads auf den Sockeln startet. Selbst im Fallmit gebundenen Threads, wo die remote Zugriffe so gut wie möglich minimiert sind,wird zum Erhalten der Cache Kohärenz ein gewisser Overhead erzeugt. Dieser Over-head steigt an, je mehr Threads verwendet werden und ist bei der Verwendung allervier Sockel höher, als der Vorteil, den die weiteren Threads bringen. Dadurch nimmtdie Speicherbandbreite hier ab.

Schaut man sich nur diese Ergebnisse an, sieht es so aus, als wenn auf dieserMaschine die geschachtelte Parallelisierung wenig Sinn macht, da mehr Threads zuschlechterer Speicherbandbreite führen. Dies ist für den Benchmark auch richtig. Ineiner normalen Anwendung werden im Normalfall aber viel mehr Rechnungen durch-geführt. Da haben mehr Threads natürlich den Vorteil, dass mehr Recheneinheitengleichzeitig verwendet werden können und so die Rechnungen schneller erledigt wer-den. Es gibt aber durchaus auch Anwendungen bei denen die Speicherbandbreite derFlaschenhals ist, dann macht es unter Umständen durchaus Sinn, weniger Threads zustarten, wie die Maschine Cores hat.

TigertonZum Vergleich wurden die Tests auch auf der Tigerton Maschine gemacht. Auch hierhandelt es sich um eine vier Sockel Quadcore Maschine, daher erschien es mir sinnvoll,OMP_NESTING_TEAM_SIZE wieder auf “4,scatter,4,subscatter” zu setzten. Die Er-gebnisse, zu sehen in Abbildung 15 und Abbildung 16, sehen auf dieser Maschine aberganz anders aus als auf dem Opteron System. Die Verwendung der Threadbinding Bi-bliothek hat keine positiven Auswirkungen auf die Bandbreite. In einigen Fällen ist dieVerteilung sogar schlechter. Der größte Unterschied ist bei der Verwendung von zweiSockeln und vier Threads pro Sockel zu sehen. Die ungebundene Version erreicht hiereine Speicherbandbreite von 9155 MB/s die gebundene Version nur 4983 MB/s. Der

38

5 KERNELBENCHMARKS

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1 2 4

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket



Abbildung 15: Messergebnisse der “nested Stream” Benchmarks auf der Tigerton Ma-schine unter Verwendung der Threadbinding Bibliothek

Grund für das unterschiedliche Verhalten der Maschine ist, dass es sich bei dieser Ma-schine um ein SMP System handelt und bei den Opterons um ein ccNUMA System.Auf dem ccNUMA System lies sich durch geschicktes Anlegen der Daten erreichen,dass die gebundenen Threads fast keine remote Zugriffe hatten. Auf dem SMP Systemist das Anlegen der Daten unwichtig, da es nur einen Speicher gibt. Das Platzierender Threads auf einem Sockel bewirkt nur, dass die Anbindung dieses Sockels an denSpeicher zum Flaschenhals wird, wohingegen noch andere Anbindungen an denselbenSpeicher frei bleiben. Bei ungebundenen Threads ist es unwahrscheinlich, dass alleThreads eines inneren Teams auf einem Sockel landen, daher wird hier eine bessereAnbindung an den Speicher erreicht.

Startet man aber 16 Threads insgesamt, gibt es in der gebundenen und der ungebun-dene Version fast keinen Unterschied in der Speicherbandbreite. Auf SMP Systemenist es für die Speicheranbindung daher nicht so wichtig, bei Verwendung des gesamtenSystems, wo welcher Thread liegt.

ScaleMPUm einen besseren Überblick über diese Maschine zu bekommen wurde zuerst eineinfacher Stream Benchmark, welcher nur auf einer Ebene parallelisiert wurde, ver-wendet, um die mögliche Speicherbandbreite zu untersuchen. Die Maschine starteterst alle Threads auf einem Board, danach werden die Threads verteilt. Dieser Vorgangkann einige Zeit in Anspruch nehmen, wodurch zu Beginn des Programmlaufes eine

39

5 KERNELBENCHMARKS

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

1 2 4

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket



Abbildung 16: Messergebnisse der “nested Stream” Benchmarks auf der Tigerton Ma-schine ohne Binding der Threads

schlechte Speicherbandbreite erreicht wird, die sich dann langsam verbessert, wenndie Threads verteilt werden. Der Streambenchmark wurde 200 Iterationen lang laufengelassen und für jede Iteration die erreichte Speicherbandbreite ausgegeben. Einmalwurde dies gemacht ohne die Threads zu binden und einmal unter Verwendung des In-tel Compilers und der in 2.7.2 beschriebenen Umgebungsvariable KMP_AFFINITY.Die Messergebnisse sind in Abbildung 17 zu sehen. Man sieht, dass im gebundenenFall schon von Beginn an eine gute Speicherbandbreite erreicht wird. Im ungebunde-nen Fall steigt die Speicherbandbreite langsam an. Der Grund für das Ansteigen istdie erwähnte Verteilung der Threads. Auffällig ist noch, dass die erreichte Speicher-bandbreite nicht so hoch wird, wie die Speicherbandbreite für den gebundenen Fall.Der Grund hierfür ist die Initialisierung der Daten. Jeder Thread legt zwar zu Beginndie Daten die er später verwendet an, aber zu Beginn laufen alle Threads noch auf ei-nem Board. Daher werden die Daten auch auf diesem Board angelegt. Durch CachingMechanismen der Maschine ist es möglich eine Speicherbandbreite zu erreichen, diedeutlich höher liegt als die Speicherbandbreite eines Boards. Allerdings zeigt der Fallin dem KMP_AFFINITY verwendet wird, dass die Speicherbandbreite noch verbes-sert werden kann. Da die Threads schon beim Starten der ersten parallelen Regionverteilt werden, werden hier die Daten auch auf den verschiedenen Boards initialisiertund so werden spätere remote Zugriffe vermieden.

Weiter wurde auch der “nested Stream” Benchmark auf der ScaleMP Maschine

40

5 KERNELBENCHMARKS

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

200000

0 20 40 60 80 100 120 140 160 180

Ban

dw

idth

in M

B/s

Iterations

KMP_AFFINITY=scatter

unbound

Abbildung 17: Vergleich einer ungebundenen und einer gebundenen Version desSTREAM Benchmarks über 200 Iterationen

getestet. Im Wesentlichen ist die Maschine wie eine ccNUMA Maschine aufgebaut.Man hat lokalen Speicher auf den Boards und kann auch auf den restlichen Speicherzugreifen. Da diese Zugriffe über das Netzwerk passieren müssen, ist zu erwarten,dass sie sehr teuer sind und sich die negativen Auswirkungen für remote Zugriffe nochstärker zeigen als auf dem Opteron System.

Für den “nested Stream” Benchmark treten dieselben Probleme auf, die schon beidem einfachen Stream Benchmark zu sehen wären. Die Verteilung der Threads erfolgtrelativ langsam und daher werden die Daten alle auf einem Board angelegt, wenn dieThreads nicht explizit verteilt werden.

Um eine schnellere Verteilung der Threads zu Erreichen wurde der Intel Com-piler verwendet und die Umgebungsvariable KMP_AFFINITY. Wie in Kapitel 2.7.2beschrieben, gibt es im Wesentlichen zwei Einstellungen: compact oder scatter. Vonbeiden Strategien wies scatter die besseren Ergebnisse auf, daher wurde die Threadbin-ding Bibliothek mit dieser Variante verglichen. Die Messergebnisse für die Bibliotheksind in Abbildung 18 und die unter Verwendung von KMP_AFFINITY entstandenenErgebnisse in Abbildung 19 zu sehen.

Betrachtet man zuerst wieder die Darstellung mit einem Thread pro Board, siehtman, dass sich beide Fälle nicht sonderlich unterscheiden. Wie zu erwarten war, steigtdie Speicherbandbreite an, die man erreichen kann, je mehr Threads man verwendet,da immer neue Boards hinzukommen. Jedes Board hat eine eigene Speicheranbindungund bei einem Thread in den inneren Teams greift jeder Thread nur auf die Daten

41

5 KERNELBENCHMARKS

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

1 2 4 6 8 10 12 13

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket




Abbildung 18: Messergebnisse der “nested Stream” Benchmarks auf der ScaleMP Ma-schine unter Verwendung der Threadbinding Bibliothek

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

1 2 4 6 8 10 12 13

Ban

dw

idth

in M

B/s

Sockets

1 thread per socket




Abbildung 19: Messergebnisse der “nested Stream” Benchmarks auf der ScaleMP Ma-schine unter Verwendung von KMP_AFFINITY

42

5 KERNELBENCHMARKS

zu, die er auch angelegt hat. KMP_AFFINITY kann Boards nicht unterscheiden, eswerden nur Sockel betrachtet. Startet man 10 Threads in der ersten parallelen Region,werden diese auf die ersten 10 Sockel verteilt. Da jedes Board zwei Sockel hat, wer-den also nur fünf Boards verwendet, wohingegen die Variante mit der Bibliothek 10Boards nutzt. Da sich die zwei Sockel auf einem Board eine Speicheranbindung teilen,schneiden die 10 Boards etwas besser ab und erreichen eine Speicherbandbreite von42992 MB/s im Vergleich zu 34297 MB/s.

Betrachtet man nun die Fälle mit mehreren Threads pro innerem Team, treten die-selben Effekte auf wie schon auf dem Barcelona Opteron System. Die Verwendungvon mehreren Threads ist ab einer gewissen Anzahl von Boards schlechter, als dieNutzung nur eines Threads pro Board, da der Overhead überhand nimmt. Man siehtaber auch, dass die Verwendung der Bibliothek diesen Overhead verringert und sobei großen Threadanzahlen die Speicherbandbreite nicht so extrem einbricht. Mit vierThreads pro Board erreicht man unter Verwendung aller 13 Boards noch ein Speicher-bandbreite von 27764 MB/s, wohingegen man ohne Verwendung der Bibliothek nur2353 MB/s erreicht.

Wie erwartet schlägt sich der Overhead von remote Zugriffen extrem in der erreich-ten Speicherbandbreite nieder. Auf den Opterons war es eher ein kleiner Performance-gewinn, wenn man die Bibliothek eingesetzt hat, auf der ScaleMP Maschine hingegenist die Version in der die Bibliothek verwendet wurde um einen Faktor von 11,8 besser.In diesem Punkt verhält sich die ScaleMP Maschine also wie eine extrem ausgeprägteccNUMA Architektur.

5.2 “nested EPCC” MicrobenchmarksEPCC MicrobenchmarksDer zweite verwendete Benchmarkcode basiert auf den EPCC Microbenchmarks. DieBenchmarks sind entwickelt worden, um den Overhead von OpenMP Konstrukten zuuntersuchen. Da die zu messenden Zeiten sehr kurz sind, werden die entsprechendenKonstrukte in einer Schleife viele Male ausgeführt und die Zeit gestoppt. Teilt mandie Zeit dann durch die Anzahl der Versuche, erhält man die verwendete Zeit für einKonstrukt. Der Code für eine Barriere ist im Codebeispiel 7 zu sehen.

Programmausschnitt 7 Schleife aus den EPCC Benchmark zum Messen des Over-head eines Barrier Konstruktes

1 f o r ( j =0 ; j < i n n e r r e p s ; j ++){2 d e l a y ( d e l a y l e n g t h ) ;3 #pragma omp b a r r i e r4 }

Der Funktionsaufruf an die Funktion delay ist an dieser Stelle nötig, um zu ver-hindern, dass die Compiler hier zu gut optimieren. Es wäre für den Compiler sonst

43

5 KERNELBENCHMARKS

unter Umständen möglich, die Barriere nur einmal aufzurufen und die Schleife weg-zukürzen. Natürlich macht es in echten Programmen auch keinen Sinn, zum Beispiel1000 Barrieren direkt hintereinander aufzurufen, da wäre es dann angebracht, dass derCompiler das Ganze zu einer Barriere kürzt. Allerdings erzeugt der Aufruf natürlichOverhead, den man nicht zum Barrier Konstrukt rechnen darf. Um diesen Overheadzu bestimmen wird die Schleife zu Beginn seriell durchlaufen, ohne das Barriere Kon-strukt. Den entsprechenden Code sieht man in Codebeispiel 8. Es wird die Zeit be-stimmt, für den Referenzcode und für den Code mit der Barriere, die Differenz istdann der Overhead der durch die Barriere entsteht.

Programmausschnitt 8 Schleife aus den EPCC Benchmarks zum Messen der Refe-renzzeit

1 f o r ( j =0 ; j < i n n e r r e p s ; j ++){2 d e l a y ( d e l a y l e n g t h ) ;3 }

“nested EPCC Microbenchmarks”In geschachtelt parallelen Programmen tritt die meiste Synchronisation in den innerengeschachtelten Regionen auf. Es ist mit Hilfe von OpenMP auch nicht möglich, wennman in der inneren parallelen Region ist, auf der äußeren Ebene zu synchronisieren.Um dieses Verhalten zu simulieren wurden die EPCC Microbenchmarks etwas erwei-tern. Im Wesentlichen wurde eine parallele Region um die Benchmarks herum auf-gemacht. Zusätzlich wurde die Eingabe erweitert, um die Anzahl der Threads für dieinnere und äußere Region festlegen zu können. OMP_NUM_THREADS eignet sichnicht mehr, da damit nur für die äußere parallele Region die Threads gesetzt werden.Alle parallelen Regionen mussten um die num_threads Klausel erweitert werden, umzu erreichen, dass die parallelen Regionen mit der richtigen Anzahl an Threads gest-artet werden. Es kann also sein, das sich die Laufzeiten des geänderten Benchmarksauch von dem originalen Benchmark unterscheiden, selbst wenn man nur eine äußereRegion startet. Besonders bei dem parallel und parallel for Konstrukt, da dieseum num_threads erweitert wurden.

Da diese Klausel aber auch für geschachtelt parallele Programme nötig ist, scheintes mir richtig, den Overhead mitzumessen, da der geschachtelt parallele Fall unter-sucht werden soll.

“Barcelona Opteron”Als erste Maschine wurde die Barcelona Opteron Maschine untersucht. Die Vermutungwar, dass es am günstigsten ist, wenn sich die inneren Teams auf einem Sockel befin-den. Hierdurch sollte es möglich sein, die Kommunikation zwischen den Sockeln zuverringern. Beispielsweise eine Reduktionsoperation kann die Reduktionsvariable dieganze Zeit im Level 3 Cache halten und alle Threads können hierauf arbeiten. Laufen

44

5 KERNELBENCHMARKS

Tabelle 1: Messergebnisse der “nested EPCC” Benchmarks auf Barcelona Opteron(Angaben in Mikrosekunden)

parallel for parallel for barrier single critical reduction1:2 Threadsgebunden 45,88 21,96 47,22 21,72 20,62 0,28 45,83ungebunden 19,25 18,64 19,46 18,12 16,94 0,2 19,84:4 Threadsgebunden 135,46 70,36 135,66 66,46 65,32 0,53 135,79ungebunden 117,9 108,48 118,82 100,27 107,33 0,42 119,35

die Threads auf mehreren Sockeln muss die Variable zwischen den Caches übertragenwerden.

Die Messungen wurden einmal gemacht, mit nur einem inneren Team mit zweiThreads und einmal mit vier Teams mit je vier Threads. Der erste Versuch ist dieminimale sinnvolle Threadanzahl und mit viermal vier Threads hat man die maximaleThreadanzahl erreicht, die auf der Maschine Sinn macht.

Zum Vergleich wurden die Tests einmal unter Zuhilfenahme der Bibliothek ge-macht und einmal ohne das die Threads gebunden wurden. Die Ergebnisse sind in Ta-belle 1 zu sehen. Die erreichten Messwerte sind etwas enttäuschend, da der gebundeneFall in mehreren Fällen deutlich schlechter abschneidet als der ungebundene Fall. Beidem parallel und parallel for Konstrukt könnte man dies ja noch erklären. DasBinding beim Öffnen einer parallelen Region erzeugt einen gewissen Overhead. Aberbei Konstrukten wie der “reduction” Operation war mit einer Verbesserung der Lauf-zeit zu rechnen. Durch Vergleichen der instrumentierten und nicht instrumentiertenVersion des Benchmarks ließen sich die Gründe für das unerwartete Verhalten unter-suchen. Die Unterschiede sind in Codebeispiel 9 zu sehen.

Auffällig an dem instrumentierten Code ist, dass am Ende der parallelen Regioneine Barriere eingefügt wird. Da die parallele Region am Ende eine implizite Barriereenthält, ist es unnötig, eine explizite Barriere einzufügen, aber es ist natürlich trotz-dem korrekt. Für den Fall, dass man die Instrumentierung für Performancemessungenverwendet, macht es Sinn die Barriere explizit zu machen. Durch das Einfügen derBarriere ist es möglich, die Zeit zu stoppen, die jeder einzelne Thread in der Barrie-re verbringt. Hierdurch lassen sich eventuelle Lastinbalancen zwischen den Threadsfinden.

Für das Binding ist dies aber nicht nötig, daher wurde die Barriere entfernt unddie Messungen wiederholt. Für das parallel und parallel for Konstrukt gab eseine gleichartige Barriere, welche auch entfernt wurde. Die neuen Ergebnisse sind inTabelle 2 zu sehen.

Die so erreichten Messergebnisse geben das erwartete Verhalten wieder. Für denFall in dem ein Team mit zwei Threads gestartet wird, sind die Messzahlen dicht bei-einander, allerdings ist die instrumentierte Version in einigen Fällen ein klein weniglangsamer. Für den Fall, dass man die Maschine voll ausnutzt, also vier Teams mit

45

5 KERNELBENCHMARKS

Programmausschnitt 9 Vergleich der reduction Operationen, oben: uninstrumentiert,unten: instrumentiert mit Opari

1 f o r ( j =0 ; j < i n n e r r e p s ; j ++){2 #pragma omp p a r a l l e l r e d u c t i o n ( + : aaaa ) num_th reads ( i n n e r )3 {4 d e l a y ( d e l a y l e n g t h ) ;5 aaaa += 1 ;6 }7 }

1 f o r ( j =0 ; j < i n n e r r e p s ; j ++){2 POMP_Para l l e l_ fo rk (&omp_rd_16 ) ;3 #pragma omp p a r a l l e l r e d u c t i o n ( + : aaaa ) num_th reads ( i n n e r )

POMP_DLIST_000164 { POMP_Para l l e l_beg in (&omp_rd_16 ) ;5 {6 d e l a y ( d e l a y l e n g t h ) ;7 aaaa += 1 ;8 }9 POMP_Bar r i e r_en te r (&omp_rd_16 ) ;

10 #pragma omp b a r r i e r11 POMP_Bar r i e r_ex i t (&omp_rd_16 ) ;12 POMP_Para l le l_end (&omp_rd_16 ) ; }13 P O M P _ P a r a l l e l _ j o i n (&omp_rd_16 ) ;1415 }

je vier Threads verwendet, sehen die Ergebnisse für die gebunden Version aber umeiniges besser aus. Alle Konstrukte bis auf das critical sind um 30 - 40 % schnellergeworden und das critical Konstrukt ist etwa gleich schnell geblieben. Für Operatio-nen wie die Reduktion oder die Barriere scheint es also tatsächlich von Vorteil zu sein,wenn alle Threads des Teams auf einem Sockel laufen.

TigertonAls nächstes wurden wieder Messungen auf der Tigerton Maschine gemacht, um dasVerhalten auf einer SMP Maschine zu untersuchen. Da die Synchronisationen im We-sentlichen nichts mit Speicherzugriffen zu tun haben, liegt die Vermutung nahe, dasssich das System ähnlich verhält wie das Opteron basierte System. Die verwendete Stra-tegie war wieder “4,scatter,4 subcompact”, um je ein inneres Team auf einen Sockelzu binden. Die erreichten Laufzeiten sind in Tabelle 3 zu sehen.

Man sieht, dass im Wesentlichen die Ergebnisse vergleichbar mit denen vom Opte-

46

5 KERNELBENCHMARKS

Tabelle 2: Messergebnisse der “nested EPCC” Benchmarks auf Barcelona Opteronohne unnötige Barrieren (Angaben in Mikrosekunden)


Tabelle 3: Messergebnisse der “nested EPCC” Benchmarks auf einem Tigerton (An-gaben in Mikrosekunden)


ronsystem sind. Startet man vier mal vier Threads ist es immer von Vorteil, die Thread-binding Bibliothek zu verwenden. Allerdings liegt der Gewinn hier etwas niedriger alsauf dem Opteron System. Man gewinnt etwa 20 - 30 % an Performance, wogegen manauf dem Opteron 30 -40 % gewinnen konnte. Die Gesamtzeiten sind aber auf demTigerton System immer noch etwas besser, was an dem etwas schnelleren Bussystemliegt.

Interessant ist noch der Fall, wenn nur eine Region mit zwei Threads im innerenTeam gestartet wird. Hier war auf dem Opteronsystem kein Vorteil durch die Biblio-thek zu erreichen, wohingegen auf dem Tigerton eine deutliche Verbesserung der Lauf-zeit zu beobachten ist. Die Synchronisationsoperationen laufen in etwa zwei bis dreimal schneller, wenn man das Binding nutzt. Der Grund hierfür liegt in dem geteiltenCache zwischen den Cores. Auf dem Tigerton System teilen sich zwei Cores einenLevel 2 Cache. Bindet man die Threads nun so, dass ein Cache geteilt wird, kann überden Cache die Synchronisation schneller abgewickelt werden, als wenn über den Buskommuniziert werden muss.

Unter dem Aspekt der Speicherbandbreite hat man gesehen, dass auf einem SMPSystem die Platzierung der Threads keine große Bedeutung hatte. Unter dem hierbetrachteten Aspekt der Kommunikation erscheint es aber auch auf SMP Systemendurchaus von Bedeutung zu sein, wie die Threads platziert werden. Weiterhin kannman auch sehen, dass das Binding an sich so gut wie keinen Overhead erzeugt, da es indem parallel und parallel for Konstrukt mitgemessen wird und im gebundenenFall trotzdem noch bessere Laufzeiten erreicht werden können als im ungebundenen

47

5 KERNELBENCHMARKS

Tabelle 4: Messergebnisse der “nested EPCC” Benchmarks auf der ScaleMP Maschine(Angaben in Mikrosekunden)

parallel for parallel for barrier single critical reduction1:2 Threadsgebunden 34,11 34,13 36,61 33,47 30,12 0,08 41,99ungebunden 63,53 67,98 67,44 65,13 44,49 0,21 42,741:8 Threadsgebunden 442,61 353,49 448,03 337,45 322,99 1,09 458,28ungebunden 565,23 350,77 455,91 356,65 365,35 1,16 505,862:8 Threadsgebunden 425,63 457,45 457,45 323,71 315,17 1,8 444,77ungebunden 2655,09 2302,35 2729,62 2197,42 2249,58 4,7 2642,0313:8 Threadsgebunden 490,05 328,67 526,4 339,72 369,19 1,14 453,4ungebunden 6161,09 4447,04 6172,07 4380,04 4444,6 7,52 6280,15

Fall.

ScaleMPAls dritte Maschine wurde wieder die ScaleMP Maschine betrachtet. Es schien sinn-voll die Kommunikation über das Netzwerk zu beschränken, indem man die innerenTeams auf einen Knoten bindet. Es wurden Messungen auf einem Knoten gemacht,auf zwei Knoten und auf allen 13 Knoten der Maschine. Tabelle 4 zeigt die Messer-gebnisse.

Die Ergebnisse für zwei Threads in einem inneren Team sind wie erwartet. DieMesswerte liegen etwas höher als für die beiden anderen Maschinen, aber da es sich umandere Prozessoren handelt, ist das nicht weiter überraschend. Wieder sieht man einenVorteil darin, wenn man zwei Threads dicht zusammen bindet. Der Grund ist auchhier, dass sich zwei Cores einen Level 2 Cache teilen und so schneller kommunizierenkönnen.

Interessanter ist es das Verhalten über mehrere Boards hinweg zu betrachten. Eswurde immer pro Board ein äußerer Thread gestartet und das Board dann in der inne-ren parallelen Region aufgefüllt mit acht Threads. Die Messungen wurden auf einemBoard, auf zwei Boards und auf allen 13 Boards gemacht. Man sieht große Unterschie-de zwischen dem gebundenen und dem ungebundenen Verhalten. Im gebundenen Fallnimmt die Laufzeit, wenn man mehrere Boards verwendet, nicht zu. Dies ist genaudas Verhalten, welches man erreichen will. Alle Kommunikation findet nur auf demlokalen Knoten statt und nicht über das Netzwerk.

Im ungebundenen Fall sieht man deutlich, dass die Threads schlechter verteilt wer-den. Mit einem äußeren Team braucht eine Reduktion zum Beispiel 505 Mikrosekun-den. Hier können noch alle Threads auf einem Board laufen. Bei zwei Teams brauchtdie Operation schon 2642 Mikrosekunden und wenn man 13 äußerer Threads startet,

48

6 ERGEBNISSE FÜR NUTZERCODES

also insgesamt die ganze Maschine nutzt, braucht die Operation schon 6280 Mikrose-kunden. Für Applikationen, welche häufige Synchronisation benötigen, kann der Un-terschied zwischen 453 Mikrosekunden im gebundenen Fall und 6280 Mikrosekundenim nicht gebundenen Fall durchaus einen großen Unterschied ausmachen.

6 Ergebnisse für NutzercodesDie Betrachtung der Benchmarkprogramme gibt einen Anhaltspunkt darüber, was mandurch das Platzieren der Threads im Bezug auf einzelne kleine Probleme erreichenkann. Betrachtet wurden zwei Probleme:

• Verbesserung der Nutzung der vorhandenen Speicherbandbreite

• Verringerung des Overheads für Synchronisationskonstrukte

Durch diese Betrachtungen konnte schon erkannt werden, dass die Platzierung derThreads funktioniert und sich auf diese speziellen Probleme positiv auswirkt. Natürlichgibt es viele Faktoren, welche die Laufzeit eines Programms beeinflussen können. DieSpeicherbandbreite und der Overhead, welcher bei Synchronisationen entsteht, sindwichtig, aber nicht alleine aussagekräftig um zu belegen, dass die Verwendung derThreadbinding Bibliothek sich auch für komplexe Applikationen lohnt. Um dies zuuntersuchen, wurde die Bibliothek auf zwei Applikationen angewendet und es wurdeuntersucht, ob sich eine Verbesserung der Laufzeit erreichen lässt.

6.1 TFS6.1.1 Instrumentierung mit Opari

Als erstes musste der Code mit Opari instrumentiert werden, um die Bibliothek ver-wenden zu können. Der Makefile stellte schon die Möglichkeit bereit, Opari zu ver-wenden zu Profilingzwecken. Durch ein Austauschen der Profiling Bibliothek mit derThreadbinding Bibliothek konnte also in sehr kurzer Zeit die Bibliothek verwendetwerden.

6.1.2 Codeänderungen

Die verwendete Parallelisierung nutzt nicht an allen Stellen geschachteltes OpenMP.An einigen Stellen wird nur eine einfache parallele Region verwendet. In diesen Re-gionen werden dann alle verfügbaren Threads auf einer Ebene eingesetzt. Läuft dasProgramm etwa mit vier Threads auf der äußeren und je vier Threads auf der innerenEbene, dann werden diese speziellen Regionen mit 16 Threads gestartet.

Für das Binden der Threads ergibt sich hieraus die Notwendigkeit zur Laufzeit desProgramms die Threadhierarchie neu anzulegen und immer an die aktuellen paralle-len Regionen anzupassen. Genau für diese Zwecke eignet sich die in Kapitel 4.4.2vorgestellte Funktion omp_set_nesting_info.

49


Um die verschiedenen Anzahlen an Threads zu starten wird in dem Programm eineFunktion aufgerufen, die überprüft, wie viele Threads in den nächsten Regionen gest-artet werden sollen. In dieser Funktion wird dann omp_set_num_threads aufgerufenum die Threadanzahl für die nächste parallele Region festzulegen.

Diese Funktion kann verwendet werden, um auch omp_set_nesting_info zu set-zen. In der Funktion wird überprüft, ob die nächste Region eine geschachtelte Regiondarstellt, oder ob es sich um eine einfache parallele Region handelt. Außerdem wer-den die Threadanzahlen festgelegt, mit denen die Regionen gestartet werden sollen.Nachdem dies geschehen ist, wird omp_set_nesting_info eingefügt. Als Parame-ter werden entweder die Strategie “scatter,<i>” verwendet, wobei <i> die maximaleThreadanzahl ist, die dem Programm zur Verfügung steht. Dies passiert in dem Fall,dass eine nicht geschachtelte Region geöffnet wird.

Falls eine geschachtelte parallele Region geöffnet werden soll, wird die Strate-gie auf “scatter,<i>,subscatter,<j>” gesetzt, wobei i und j die Threadanzahlen auf dennächsten Ebenen sind. Die Werte von <i> und <j> müssen nicht extra berechnet wer-den, da sie gebraucht werden um die parallelen Regionen zu starten, sind sie schonvorberechnet im originalen Programm.

6.1.3 Barcelona

Nach der Instrumentierung wurden die ersten Messungen auf der Barcelona OpteronMaschine gemacht. Leider zeigten die ersten Läufe, dass die Laufzeit im Vergleichzum uninstrumentierten Fall stark zugenommen hatte. Wurden vier Threads auf deräußeren und darunter je vier Threads auf der inneren Ebene gestartet, erreichte manunter Verwendung der Threadbinding Bibliothek eine Laufzeit von 70.87 sec. Der Fallohne das Binden der Threads lieferte eine Laufzeit von 23.87 sec.

Eine solch drastische Verschlechterung der Laufzeit kann nicht vom Overheadkommen, den die Bibliothek erzeugt. Der erzeugte Overhead wurde in den “nestedEPCC” Benchmarks schon untersucht und es war nicht zu Erkennen, dass das Öffneneiner parallelen Region unter Verwendung der Bibliothek wirklich länger dauert. Diesist aber der einzige Punkt, an dem die Bibliothek eingesetzt wird.

Schon bei den “nested EPCC” Microbenchmarks war zu sehen, dass die Instru-mentierung, welche Opari erreicht, nicht immer optimal unter den hier betrachtetenKriterien ist. Es ist möglich, dass durch die Instrumentierung auch an Stellen, an de-nen die Instrumentierung nicht nötig ist Overhead erzeugt wird. Außerdem kann essein, dass der Compiler, wenn neue Funktionsaufrufe eingefügt werden, nicht mehr inder Art und Weise optimieren kann, wie vor dem Einfügen. Da der Compiler bei ei-nem Funktionsaufruf nicht wissen kann, was in der Funktion passiert, muss er vorsich-tig sein und davon ausgehen, dass sich alle globalen Daten in der Funktion geänderthaben könnten. Dadurch können gewisse Optimierungen verhindert werden.

Um zu Überprüfen, ob dies der Grund für die schlechte Laufzeit ist, wurde Oparinäher betrachtet und leicht modifiziert. Die folgenden Änderungen wurden vorgenom-men:

50


1. alle Funktionsaufrufe außer POMP_Parallel_begin werden nicht mehr einge-fügt

2. es werden keine impliziten Barrieren in explizite Barrieren umgewandelt

Alles was entfernt wurde ist nötig für Performancemessungen, für das Binden derThreads aber nicht, daher kann es problemlos entfernt werden.

Nach diesen Änderungen wurde ein weiterer Testlauf gemacht und für den Fall von4x4 Threads wurde eine Laufzeit von 21,95 sec. erreicht.

Zu Beginn der Arbeit wurde darauf verzichtet, die überflüssigen Funktionsaufru-fe zu entfernen, da der Compiler die Funktionen vermutlich entfernen würde, wennman interprozedurale Optimierung einschaltet. Man sieht an diesem Beispiel, dass dieswohl nicht der Fall ist. Alle weiteren Messungen wurden daher mit der verändertenVersion von Opari gemacht.

Es wurden Messungen mit verschiedenen Kombinationen an Threadanzahlen aufder inneren und äußeren Ebene gemacht. Der Speedup für die Messungen unter Ver-wendung der Threadbinding Bibliothek ist in Abbildung 20 zu sehen, die Ergebnisseohne Binden der Threads in Abbildung 21, sowie die Differenzen der Ergebnisse inAbbildung 22.

Die Laufzeiten für einen Thread, welche als Basis für den Speedup verwendet wur-den waren fast identisch, daher bedeutet ein höherer Speedup im Diagramm auch wirk-lich eine bessere Laufzeit. Die ungebundene Version hatte eine Laufzeit von 122.68sec. und die gebundene Version eine Laufzeit von 122.20 sec.

Bei den Ergebnissen kann man in vielen Fällen eine Verbesserung der Laufzeitfeststellen, wenn man die Threadbinding Bibliothek verwendet. Für die Extremfälle,wenn nur eine parallele Ebene verwendet wird und auf der zweiten Ebene nur mit ei-nem Thread gearbeitet wird, ist der Vorteil nicht so hoch. Hierfür gibt es zwei Gründe:

1. Verwendet man auf der inneren Ebene immer nur einen Thread, hat man quasiden Fall der nicht geschachtelten Parallelisierung. In diesem Fall treten die inAbschnitt 2.8 beschriebenen Probleme gar nicht auf. Daher ist der Vorteil, denman hier gewinnen kann, geringer.

2. Verwendet man nur einen Thread auf der äußeren Region, werden hier alle Datenauf nur einem NUMA Knoten angelegt. Eine gute Platzierung der Threads würdebedeuten, die Threads möglichst nah an diese Daten zu binden. Mehr als vierThreads lassen sich aber nicht auf den einen Sockel binden, daher ist eine gutePlatzierung für acht und 16 Threads gar nicht möglich und auch der zufälligverteilte Fall, den man ohne explizites Binden erreicht ist nicht viel schlechter.

Für die Fälle, in denen auf jeder Ebene mehrere Threads eingesetzt werden, ist derGewinn größer. Um wirklich zu beurteilen, wie groß der Vorteil ist, macht es Sinn,sich für beide Möglichkeiten den besten Messwert zu nehmen und diese Werte zuvergleichen. Für den normalen Einsatz ist nur der beste Wert wichtig, da es keinen

51


0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up

number of inner threads

1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 20: Ergebnisse der Speedupmessungen des TFS Codes auf der BarcelonaMaschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit 122,20sec.)

0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 21: Ergebnisse der Speedupmessungen des TFS Codes auf der BarcelonaMaschine, ohne die Threads zu platzieren

-5

0

5

10

1 2 4 8 16dif

fere

nce

in

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 22: Differenz der Speedupmessungen mit und ohne Binden der Threads aufder Barcelona Maschine(serielle Laufzeit 122,68 sec.)

52


Sinn macht, eine andere Konfiguration zu verwenden, wenn man nur daran interessiertist, mit dem Programm schnell Ergebnisdaten zu bekommen. Für den ungebundenenFall war die beste Verteilung 16 Threads auf der äußeren Region zu starten und jeweilsnur einen auf der inneren Region. Damit wurde ein Speedup von 5.53 erreicht. DieVersion mit der Threadbinding Bibliothek erreichte einen Speedup von 6.27 mit achtThreads auf der äußeren Region und je zwei Threads auf der inneren Region. Man kannan diesen Zahlen sehen, dass für diesen Datensatz und diese Maschine geschachtelteParallelisierung überhaupt nur Sinn macht, wenn man die Threadbinding Bibliothekdazu verwendet. Im anderen Fall ist eine Ebene der Parallelisierung vorteilhafter.

Zusammenfassend kann man für diese Maschine sagen, dass eine Verbesserung derLaufzeit um ca. 14% erreichbar war, wenn die Bibliothek eingesetzt wurde.

6.1.4 Nehalem

Als weitere ccNUMA Maschine wurde die Nehalem Maschine betrachtet. Besondersinteressant ist das Verhalten dieser Maschine aus zwei Gründen:

1. Da es sich bei den Nehalem Prozessoren um die ersten ccNUMA Prozessorenvon Intel handelt, fehlen noch Erfahrungswerte, wie wichtig das richtige Anle-gen der Daten ist. Es kann durchaus sein, dass ein remote Zugriff nur unwesent-lich langsamer ist wie ein lokaler Zugriff. In de Fall braucht man kaum auf diePlatzierung zu achten. Andererseits kann der Unterschied auch sehr hoch sein.In diesem Fall wird man ein ähnliches Verhalten wie auf dem Barcelona Systemsehen, wo sich das richtige Binden ausgezahlt hat.

2. Diese Maschine ist mit zwei der neuen Prozessoren bestückt. Für die Zukunftsind aber auch Systeme mit vier oder acht Sockeln angekündigt. Man kann da-von ausgehen, das die Platzierung und das richtige Anlegen der Daten dann nochwesentlich wichtiger wird. Die Messergebnisse geben also einen Anhaltspunktfür die Bedeutung der Threadplatzierung auf den Maschinen, welche in dennächsten Jahren voraussichtlich verwendet werden. Damit lässt sich dann ent-scheiden, ob es sinnvoll erscheint, frühzeitig an Strategien weiter zu arbeiten,um mit solchen Systemen umzugehen.

Zum Vergleich wurden wieder Messungen durchgeführt, einmal unter Zuhilfenah-me der Bibliothek und einmal ohne. Die Ergebnisse der Messungen sind in Abbildung23 zu sehen für den Fall, dass die Threadbinding Bibliothek verwendet wird und inAbbildung 24 für den ungebundenen Fall.

Auf dieser Maschine unterscheiden sich die beiden Fälle nicht so stark wie aufdem Barcelona Opteron System. Es ist aber auch hier zu erkennen, dass es in fast allenFällen von Vorteil ist, die Threads zu binden, auch wenn der Gewinn in der Laufzeitetwas geringer ist, wie auf der zuvor betrachteten Maschine. Ein Grund hierfür ist na-türlich, dass dieses System nur zwei Sockel hat und das Barcelona System vier Sockel.

53


0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 23: Ergebnisse der Speedupmessungen des TFS Codes auf der NehalemMaschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit 111,19sec.)

0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 24: Ergebnisse der Speedupmessungen des TFS Codes auf der NehalemMaschine, ohne die Threads zu platzieren (serielle Laufzeit 111,00 sec.)

-2

-1

0

1

2

1 2 4 8 16

dif

fere

nce

in

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 25: Differenz der Speedupmessungen mit und ohne Binden der Threads aufder Nehalem Maschine

54


Bei schlechter Platzierung der Threads laufen immer noch im Schnitt die Hälfte allerThreads auf dem richtigen Sockel, auf dem Barcelona System nur ein Viertel.

Dennoch sieht man auch hier, dass die richtige Platzierung von Vorteil ist. Die besteungebundene Konfiguration erreicht einen Speedup von 4,8. Bindet man die Threads,erreicht man einen Speedup von 5,0. Dies ist immerhin ein Gewinn von 4,1%.

Ein weiterer Punkt, der während der Messungen auffällig war, ist eine recht starkeSchwankung in den Messergebnissen für den nicht gebundenen Fall. Tabelle 5 zeigtdie Ergebnisse für zehn Läufe, einmal mit gebundenen Threads und einmal für unge-bundene Threads, für vier Threads auf der inneren und vier Threads auf der äußerenEbene.

Tabelle 5: Laufzeiten für 10 Testläufe des TFS Codes (Angaben in sec.)4:4 Threadsgebunden 22,41 22,34 22,45 22,53 22,65 22,4 22,22 22,66 22,3 22,24ungebunden 26,5 23,69 24,02 26,16 26,49 26,6 22,72 24,92 25,02 23,93

Es ist klar zu sehen, dass die Ergebnisse im gebundenen Fall sehr stabil sind. Derschnellste Lauf dauerte 22,22 sec. und der längste Lauf brauchte 22,66 sec. Betrachtetman hingegen die ungebundenen Ergebnisse, so sieht man eine stärkere Abweichung.Hier ist der beste Wert 22,72 sec. , der schlechteste Wert aber 26,6 sec. Der schlech-teste Fall braucht also ca. 17% mehr Laufzeit als der beste Fall. In vielen Fällen ist essinnvoll, die Laufzeit eines Progammes abschätzen zu können. Wird beispielsweise einBatch System verwendet, um die Jobs auf dem Cluster zu managen, muss man einengewissen Zeitslot für den Programmlauf anfordern. Dieses Abschätzen der Laufzeitwird natürlich schwieriger, wenn die Laufzeiten stark schwanken, wie im ungebunde-nen Fall. Zusätzlich zu dem Gewinn an Performance bringt die Bibliothek also auchnoch ein gewisses Maß an Stabilität, was die Laufzeit angeht. Aus beiden Gründenlässt sich festhalten, dass auch auf diesem System durchaus von der Verwendung derBibliothek profitiert wird.

6.1.5 Tigerton

Zum Vergleich wurden dieselben Messungen auf der Tigerton Maschine gemacht. Wieschon zuvor wurden Messungen mit und ohne Binden der Threads durchgeführt. DieErgebnisse für den gebundenen Fall sind in Abbildung 26 und für die Vergleichsmes-sungen ohne Verwendung der Threadbinding Bibliothek in Abbildung 27 dargestellt.

Wieder einmal zeigt sich ein Unterschied im Verhalten der SMP Maschine im Ver-gleich zu den übrigen betrachteten Systemen. Während es auf dem Nehalem und demOpteron System von Vorteil war, die Threadbinding Bibliothek zu verwenden, ist esauf dieser Maschine offensichtlich ein Nachteil. Viele der gemachten Messungen lau-fen etwas schneller, wenn man die ungebundene Version verwendet. Der Unterschiedist zwar in den meisten Fällen recht gering, aber immerhin liegt der beste Speedup im

55


0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 26: Ergebnisse der Speedupmessungen des TFS Codes auf der TigertonMaschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit 100,30sec.)

0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 27: Ergebnisse der Speedupmessungen des TFS Codes auf der TigertonMaschine, ohne die Threads zu platzieren (serielle Laufzeit 100,28 sec.)

-2

0

2

1 2 4 8 16

dif

fere

nce

in

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 28: Differenz der Speedupmessungen mit und ohne Binden der Threads aufder Tigerton Maschine

56


ungebundenen Fall bei 6.22 und für den gebundenen Fall nur bei 6.08. Der Grund fürdieses Verhalten ist, dass auf dieser SMP Maschine alle Daten in einem physischenSpeicher abgelegt werden. Somit lässt sich durch eine gute Platzierung der Threadskeine bessere Zuordnung der Threads zu den Daten erreichen. Auf der anderen Seiteerzeugt das Platzieren der Threads und der Aufbau der Threadhierarchien einen klei-nen Overhead. Dadurch verliert man in der Summe noch einen kleinen Teil an Perfor-mance. Auf dieser Maschine und für diesen Code scheint eine Platzierung der Threadsalso nicht unbedingt sinnvoll zu sein.

6.1.6 ScaleMP

Die letzte Maschine auf der der TFS Code vermessen wurde, ist die ScaleMP Maschi-ne. Hierbei wurden nur zwei Boards der Maschine verwendet. Der Overhead, welcherdurch die spezielle Architektur der Maschine hinzukommt, ist für zwei Boards ge-ringer, als wenn die gesamte Maschine verwendet wird. Daher wurde zu Testzweckenerstmal mit einem kleinen Teil begonnen. Die Ergebnisse für den gebundenen Fall sindin Abbildung 29 und für den ungebundenen Fall in Abbildung 30 zu sehen.

Die Ergebnisse sind in beiden Fällen ziemlich enttäuschend. Erstmal ist zu sehen,dass die Ergebnisse sich stark voneinander unterscheiden. Für den ungebundenen Fallkann in ein paar Fällen noch etwas Speedup erreicht werden, in dem gebundenen Fallliegt der Speedup für alle Messungen unter eins.

Der Grund für dieses Verhalten ist einfach. Man sieht für den ungebundenen Fallschon, dass die Läufe, welche noch einiges an Speedup bringen, insgesamt nicht mehrals acht Threads verwenden. Das ist genau die Anzahl an Threads, die man noch aufeinem Board betreiben kann. Betrachtet man die Threads während des Laufes, siehtman, dass genau das auch der Fall ist. Werden mehr Threads verwendet, fällt der Spee-dup auch ab. Es scheint also der Fall zu sein, dass dieses Programm auf einem Boardam besten läuft.

Die Ergebnisse für den gebundenen Fall sehen daher viel schlechter aus, weil dieBibliothek die Threads verteilt. Werden nur zwei Threads gestartet, verteilt die Biblio-thek diese, wie angefordert nach der “scatter” Strategie. In diesem Fall werden immerbeide Boards verwendet, was bei dem ungebundenen Fall erst ab einer Anzahl vonmehr als acht Threads gemacht wurde.

Das Verwenden von zwei Boards erzeugt einen gewissen Overhead. Die Datenliegen nun verteilt auf beiden Boards und wenn Daten ausgetauscht werden müssen,muss dies über das Netzwerk passieren. Hinzu kommt, dass auch der Mechanismus,zur Gewährleistung der Cachekohärenz, einen gewissen Overhead erzeugt. Es scheinthier der Fall zu sein, dass der gesamte Overhead bei weitem den Vorteil der größerenCoreanzahl und der besseren Speicheranbindung auf zwei Boards übersteigt.

Natürlich ist es möglich, die Strategie so abzuändern, dass erst ein Board verwen-det wird und danach erst ein Zweites. Hierdurch wären bessere Ergebnisse zu errei-chen, solange acht oder weniger Threads verwendet werden. Die Besonderheit dieserMaschine ist aber gerade, dass man mehrere Boards verwenden kann und daher sind

57


0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 29: Ergebnisse der Speedupmessungen des TFS Codes auf der ScaleMPMaschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit 107,66sec.)

0

1

2

3

4

5

6

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 30: Ergebnisse der Speedupmessungen des TFS Codes auf der ScaleMPMaschine, ohne die Threads zu platzieren (serielle Laufzeit 102,69 sec.)

-4

-2

0

2

1 2 4 8 16

dif

fere

nce

in

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 31: Differenz der Speedupmessungen mit und ohne Binden der Threads aufder ScaleMP Maschine

58


Messungen, die nur ein Board verwenden, wenig interessant.Zusammenfassend kann man sagen, dass sich dieser Code nicht für die ScaleMP

Maschine eignet. Weder im gebundenen noch im ungebundenen Fall konnte von derBesonderheit der Hardware profitiert werden.

6.2 SHEMAT-SuiteDer zweite untersuchte Code ist der SHEMAT-Suite Code. Wie in Kapitel 3.2 beschrie-ben, verfügt der Code bereits über einen Mechanismus, die Threads zu platzieren.Dieser Ansatz funktioniert auch gut, allerdings ist er mit mehr Arbeit für den Nutzerverbunden und nicht ohne weiteres auf andere Programme übertragbar. Von der Perfor-mance her gibt es zwischen diesem Ansatz und der Threadbinding Bibliothek keinenUnterschied, wenn die Platzierung der Threads gleich gewählt wird. Im Folgendenwerden daher Messergebnisse verglichen, die mit der Threadbinding Bibliothek ge-macht wurden und solche, welche ohne die Platzierung von Threads vorgenommenwurden. Hierdurch soll geprüft werden, ob die Platzierung der Threads überhaupt vonVorteil ist.

6.2.1 Verwendung der Threadbinding Bibliothek

Dieses Projekt verfügt nicht wie der TFS Code über eine Möglichkeit den Code mitOpari zu instrumentieren. Um dies zu erreichen, mussten zwei kleine Änderungen imMakefile vorgenommen werden.

Als zweites musste auch wieder eine kleine Änderung im Code gemacht wer-den. Wird das Programm gestartet mit <n> Threads auf der äußeren Ebene und <m>Threads auf der inneren Ebene, dann wird auch im Normalfall erst eine äußere Ebenegestartet mit <n> Threads und dann eine innere Ebene mit <m> Threads.

Es gibt aber eine parallele Region, die eine nicht geschachtelte parallele Regionstartet, die <m> Threads verwendet.

Setzt man nur die Umgebungsvariable OMP_NESTING_TEAM_SIZE auf denWert <n>,scatter,<m>,subscatter, dann wird an dieser Stelle eine parallele Re-gion mit <n> Threads von der Bibliothek erwartet, aber eine Region mit <m> Threadsgestartet. Um dies zu vermeiden wird vor dieser Region omp_set_nesting_info()aufgerufen mit der Option <m>,scatter. Nach der Region wird der Wert dann wiederzurückgesetzt.

6.2.2 Barcelona und Nehalem

Die verwendeten ccNUMA Maschinen sind wieder die Barcelona Opteron Maschineund die Nehalem Maschine. Die Messergebnisse der Barcelona Maschine sind in denAbbildungen 32 für den gebundenen Fall und in Abbildung 33 für den ungebundenenFall dargestellt, für die Nehalem Maschine in den Abbildungen 35 und 36.

59


0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 32: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derBarcelona Opteron Maschine unter Verwendung der Threadbinding Bibliothek (seri-elle Laufzeit 916,86 sec.)

0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 33: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derBarcelona Opteron Maschine, ohne die Threads zu platzieren (serielle Laufzeit 914,86sec.)

-2

-1

0

1

2

3

1 2 4 6 8dif

fere

nce

insp

ee

du

p


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 34: Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Barcelona Opteron Maschine

60


Beide Ergebnisse sind ähnlich, daher werden sie hier zusammen vorgestellt. Esist zu sehen, dass bei fast allen Fällen der gebundene Fall besser skaliert als der un-gebundene Fall. Auf der Nehalem Maschine erreichen einige Fälle im ungebundenenFall einen Speedup zwischen vier und fünf. Im gebundenen Fall erreichen diese Fälleeinen Speedup zwischen fünf und sechs. Es ist also nicht nur ein Einzelfall, in dem dasBinden einen Vorteil bringt, sondern der Normalfall für diese Maschinen und diesenCode.

Auf der Barcelona Maschine wird insgesamt ein höherer Speedup erreicht. Dies istnicht überraschend, da diese Maschine vier Sockel und insgesamt 16 Cores hat. DieNehalem Maschine hingegen hat nur zwei Sockel und acht Cores, wobei jeder Corezwei Hardwarethreads aufweist.

Aber auch auf der Opteron Maschine wird im gebundenen Fall ein höherer Speeduperreicht als im ungebundenen Fall. Die beste erreichte Laufzeit im ungebundenen Fallbeträgt 110 Sekunden. Unter Verwendung der Threadbinding Bibliothek lässt sich eineLaufzeit von 98 Sekunden erreichen. Wie schon beim TFS Code sieht man wieder, dassdie Platzierung der Threads wichtig ist auf ccNUMA Maschinen.

6.2.3 Tigerton

Als Beispiel für eine SMP Maschine wurde wieder die Tigerton Maschine verwendet.Auch hier wurden wieder Messungen durchgeführt, bei denen die Threads gebundenwurden und Vergleichsmessungen mit ungebundenen Threads. Die Ergebnisse sind inAbbildung 38 für den Gebundenen und in Abbildung 39 für den ungebundenen Fall zusehen.

Es ist auch hier wieder ein klarer Unterschied zwischen dem Verhalten auf cc-NUMA und SMP Maschinen zu erkennen. Auf dieser Maschine gibt es zwar einigeMessungen, die etwas besser im gebundenen Fall laufen, aber für die meisten Messun-gen ist der Unterschied minimal. Die ungebundene Version erreicht einen maximalenSpeedup von 4,94 und die gebundene Version von 4,97. Eine Verwendung der Biblio-thek scheint aufgrund dieses Unterschiedes nicht zwingend nötig.

6.2.4 ScaleMP

Zuletzt wurden wieder Messungen auf der ScaleMP Maschine gemacht. Abbildung 41und 42 zeigen die Ergebnisse. Die ScaleMP Maschine zeigte bei den kleinen Bench-markprogrammen ein ähnliches Verhalten wie eine ccNUMA Maschine. Bei dem TFSCode war überhaupt kein sinnvoller Einsatz dieser Maschine möglich, da beide Ver-sionen über mehrere Boards langsamer liefen als auf einem Board.

Betrachtet man die Ergebnisse für den SHEMAT-Suite Code, fällt als erstes auf,dass der Code über mehrere Boards skaliert. Sowohl im gebundenen Fall, wie auch imungebundenen Fall, werden die besten Läufe mit mehr als acht Threads durchgeführt.Dies spricht dafür, dass auch mehrere Boards verwendet werden. Im gebundenen Fallkann dies auch genau angegeben werden. Die Verteilung von zehn Threads auf der

61


0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 35: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derNehalem Maschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit470,23 sec.)

0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 36: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derNehalem Maschine, ohne die Threads zu platzieren (serielle Laufzeit 368,49 sec.)

0

1

1

2

2

1 2 4 6 8

dif

fere

nce

insp

ee

du

p


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 37: Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Nehalem Maschine

62


0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 38: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derTigerton Maschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit831,83 sec.)

0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 39: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derTigerton Maschine, ohne die Threads zu platzieren(serielle Laufzeit 830,90 sec.)

-1

0

1

2

3

1 2 4 6 8

dif

fere

nce

insp

ee

du

p


1 outer Thread

2 outer Threads

4 outer Threads

8 outer Threads

16 outer Threads

Abbildung 40: Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Tigerton Maschine

63


äußeren und zwei Threads auf den inneren Regionen erreichte hier das beste Ergeb-nis. Die verwendete Strategie war dabei “10,scatter,2,subscatter”. Es wurden also zehnBoards verwendet für diesen Lauf.

Weiterhin sieht man, dass die ungebundene Version für viele Läufe ein deutlichschlechteres Ergebnis liefert als die Version, welche die Threadbinding Bibliothek ver-wendet. Der beste erreichte Speedup ohne Binden der Threads ist 6,48. Verwendet mandie Threadbinding Bibliothek lässt sich ein Speedup von 8,04 erreichen. Dies ist im-merhin ein Gewinn von rund 24%. Bei diesem Code kann man also wieder sagen, dasssich die ScaleMP Maschine wie eine ccNUMA Maschine verhält. Die Verwendungder Bibliothek ist also auf jeden Fall auch auf dieser Maschine ratsam.

Es sollte aber noch beachtet werden, dass die Maschine immer noch einen schlech-teren Speedup liefert als die Opteron Maschine. Da die Xeon Prozessoren aber schnel-ler sind als die Opteron Maschinen, ist die beste Gesamtlaufzeit von 90,07 Sekun-den immer noch etwas niedriger als auf der Opteron Maschine, wo eine Laufzeit von98,04 Sekunden das beste Ergebnis war. Allerdings darf man nicht vergessen, das dieScaleMP Maschine bei diesem Lauf zehn Boards mit je zwei Prozessoren verwendet,also insgesamt 20 Prozessoren. Die Opteron Maschine hingegen verwendet nur vierProzessoren. Für diesen großen Unterschied in der Prozessoranzahl fällt der Vorteil inder Laufzeit recht gering aus.

64


0

1

2

3

4

5

6

7

8

9

10

1 2 4 6 8

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

6 outer Threads

8 outer Threads

10 outer Threads

13 outer Threads

Abbildung 41: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derScaleMP Maschine unter Verwendung der Threadbinding Bibliothek (serielle Laufzeit724,22 sec.)

0

1

2

3

4

5

6

7

8

9

10

1 2 4 6 8

spe

ed

up


1 outer Thread

2 outer Threads

4 outer Threads

6 outer Threads

8 outer Threads

10 outer Threads

13 outer Threads

Abbildung 42: Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derScaleMP Maschine, ohne die Threads zu platzieren (serielle Laufzeit 692,18 sec.)

-1

0

1

2

3

4

5

1 2 4 6 8

dif

fere

nce

insp

ee

du

p


1 outer Thread

2 outer Threads

4 outer Threads

6 outer Threads

8 outer Threads

10 outer Threads

13 outer Threads

Abbildung 43: Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der ScaleMP Maschine

65

7 ZUSAMMENFASSUNG

7 ZusammenfassungIn dieser Arbeit wurden Möglichkeiten vorgestellt, um unter Linux eine Platzierungvon Threads bei geschachtelter Parallelisierung vorzunehmen. Es war hierzu nötig, injeder parallelen Region die Platzierung neu vorzunehmen, da die Thread Teams sichständig ändern. Um dies möglichst einfach durchführen zu können, wurde die Instru-mentierung des Codes mit Opari vorgenommen und die Platzierung in einer eigenenBibliothek vorgenommen.

Es wurde die Möglichkeit implementiert, die Threadhierarchie des Programmsdurch Umgebungsvariablen bekannt zu geben, oder zur Laufzeit durch einen Funk-tionsaufruf zu ändern. Die Threadhierarchie besteht aus der Anzahl der Threads sowieeiner Strategie, welche angibt, wie die Threads verteilt werden sollen. Die Hardwarein-formationen können über eine Datei bekannt gemacht werden. Anderenfalls verwendetdie Bibliothek die vom Betriebssystem zur Verfügung gestellte Hardwareinformatio-nen aus /proc/cpuinfo. Hierbei ist es leider auf der verwendeten ScaleMP Maschinenicht möglich, zwischen den einzelnen Boards zu unterscheiden, daher sollte man hierauf die Möglichkeit zurückgreifen, eine Datei anzugeben.

Weiter wurde untersucht, ob die Threadplatzierung, die mit Hilfe der Bibliothekvorgenommen wurde, auch wirklich sinnvoll ist. Als erstes wurde am “nested Stream”Benchmark gezeigt, das sich die Ausnutzung der Bandbreite stark verbessern lässt,wenn die Platzierung nach einem verteilten Schema vorgenommen wird. Außerdemkonnte mit Hilfe des “nested EPCC” Benchmarks gezeigt werden, dass auch der Over-head von Barrieren und anderen Synchronisationskonstrukten geringer ist, wenn diePlatzierung sinnvoll vorgenommen wird.

Am Beispiel von TFS und SHEMAT wurde dann gezeigt, dass diese Änderungenauch wirklich die Laufzeit von echten Anwendungsprogrammen positiv beeinflussen.Es ließen sich durch die verwendeten Methoden Verbesserungen in der Laufzeit zwi-schen 10% und 25% erreichen. Besonders auf ccNUMA Maschinen war eine gutePlatzierung von Vorteil, da hier eine bessere Speicherlokalität erreicht werden konnte.

Zusammenfassend kann man sagen, dass eine gute Platzierung von Threads durch-aus zu einer erheblichen Verbesserung der Laufzeit führen kann. Für SMP Systemewar keine große Verbesserung zu erreichen. Da aber aktuell fast alle neuen Prozesso-ren der großen Prozessorhersteller, wie Intel, AMD und IBM, für ccNUMA Systemeverwendet werden, ist eine gute Unterstützung solcher Systeme sehr wichtig.

Die hier vorgestellte Lösung für dieses Problem ist brauchbar. Es wäre für denNutzer aber besser, wenn vom Compiler Möglichkeiten gegeben wären, um dasselbeProblem anzugehen. Hierdurch ließe sich sicher der Schritt mit der Instrumentierungdes Codes vermeiden und die Nutzung wäre für den Programmierer noch einfacher.Damit für den Nutzer die Verwendung einheitlich und compilerunabhängig möglichwäre, könnte der OpenMP Standard um eine Möglichkeit erweitert werden, die diePlatzierung von Threads für geschachtelt parallele Programme regelt. Diese Regelungwäre aus Nutzersicht sicher ideal, da alle verwendeten Funktionen einheitlich definiertwären und so eine Codeversion mit allen Compilern verwendet werden könnte.

66

ABBILDUNGSVERZEICHNIS

Abbildungsverzeichnis1 Intel Xeon E5450 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 AMD Opteron Processor 8356 . . . . . . . . . . . . . . . . . . . . . 73 symmetrischer Multiprozessor (Harpertown) . . . . . . . . . . . . . . 84 ccNUMA Architektur (Barcelona) . . . . . . . . . . . . . . . . . . . 95 Fork-join model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Fork-join Modell im geschachtelten Fall . . . . . . . . . . . . . . . . 147 Hardwarehierarchie des Nehalemsystems . . . . . . . . . . . . . . . 238 Ausschnitt aus der /proc/cpuinfo Datei auf einem der verwendeten

Nehalem Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Hardwaredarstellung eines Harpertownknotens, links mithilfe von /proc/c-

puinfo erstellt, rechts eine bessere Darstellung mit einer eigenen Infor-mationsdatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10 Darstellung der Hardwarehierarchie eines Harpertownsystems . . . . 2711 Darstellung einer unsymmetrischen Threadhierarchie . . . . . . . . . 3012 Darstellung der verwendeten Cores auf einem vier Sockel Barcelo-

na Opteron, mit verschiedenen Strategien. links: 2,scatter,4,subscatterrechts: 2,scatter,4,scatter . . . . . . . . . . . . . . . . . . . . . . . . 32

13 Messergebnisse der “nested Stream” Benchmarks auf einem BarcelonaOpteron System unter Verwendung der Threadbinding Bibliothek . . 37

14 Messergebnisse der “nested Stream” Benchmarks auf einem BarcelonaOpteron System ohne Binding der Threads . . . . . . . . . . . . . . . 37

15 Messergebnisse der “nested Stream” Benchmarks auf der Tigerton Ma-schine unter Verwendung der Threadbinding Bibliothek . . . . . . . . 39

16 Messergebnisse der “nested Stream” Benchmarks auf der Tigerton Ma-schine ohne Binding der Threads . . . . . . . . . . . . . . . . . . . . 40

17 Vergleich einer ungebundenen und einer gebundenen Version des STREAMBenchmarks über 200 Iterationen . . . . . . . . . . . . . . . . . . . . 41

18 Messergebnisse der “nested Stream” Benchmarks auf der ScaleMPMaschine unter Verwendung der Threadbinding Bibliothek . . . . . . 42

19 Messergebnisse der “nested Stream” Benchmarks auf der ScaleMPMaschine unter Verwendung von KMP_AFFINITY . . . . . . . . . . 42

20 Ergebnisse der Speedupmessungen des TFS Codes auf der BarcelonaMaschine unter Verwendung der Threadbinding Bibliothek (serielleLaufzeit 122,20 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . 52

21 Ergebnisse der Speedupmessungen des TFS Codes auf der BarcelonaMaschine, ohne die Threads zu platzieren . . . . . . . . . . . . . . . 52

22 Differenz der Speedupmessungen mit und ohne Binden der Threadsauf der Barcelona Maschine(serielle Laufzeit 122,68 sec.) . . . . . . . 52

23 Ergebnisse der Speedupmessungen des TFS Codes auf der NehalemMaschine unter Verwendung der Threadbinding Bibliothek (serielleLaufzeit 111,19 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . 54

67

ABBILDUNGSVERZEICHNIS

24 Ergebnisse der Speedupmessungen des TFS Codes auf der NehalemMaschine, ohne die Threads zu platzieren (serielle Laufzeit 111,00 sec.) 54

25 Differenz der Speedupmessungen mit und ohne Binden der Threadsauf der Nehalem Maschine . . . . . . . . . . . . . . . . . . . . . . . 54

26 Ergebnisse der Speedupmessungen des TFS Codes auf der TigertonMaschine unter Verwendung der Threadbinding Bibliothek (serielleLaufzeit 100,30 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . 56

27 Ergebnisse der Speedupmessungen des TFS Codes auf der TigertonMaschine, ohne die Threads zu platzieren (serielle Laufzeit 100,28 sec.) 56

28 Differenz der Speedupmessungen mit und ohne Binden der Threadsauf der Tigerton Maschine . . . . . . . . . . . . . . . . . . . . . . . 56

29 Ergebnisse der Speedupmessungen des TFS Codes auf der ScaleMPMaschine unter Verwendung der Threadbinding Bibliothek (serielleLaufzeit 107,66 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . 58

30 Ergebnisse der Speedupmessungen des TFS Codes auf der ScaleMPMaschine, ohne die Threads zu platzieren (serielle Laufzeit 102,69 sec.) 58

31 Differenz der Speedupmessungen mit und ohne Binden der Threadsauf der ScaleMP Maschine . . . . . . . . . . . . . . . . . . . . . . . 58

32 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derBarcelona Opteron Maschine unter Verwendung der ThreadbindingBibliothek (serielle Laufzeit 916,86 sec.) . . . . . . . . . . . . . . . . 60

33 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derBarcelona Opteron Maschine, ohne die Threads zu platzieren (serielleLaufzeit 914,86 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . 60

34 Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Barcelona Opteron Maschine . 60

35 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derNehalem Maschine unter Verwendung der Threadbinding Bibliothek(serielle Laufzeit 470,23 sec.) . . . . . . . . . . . . . . . . . . . . . . 62

36 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derNehalem Maschine, ohne die Threads zu platzieren (serielle Laufzeit368,49 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

37 Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Nehalem Maschine . . . . . . 62

38 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derTigerton Maschine unter Verwendung der Threadbinding Bibliothek(serielle Laufzeit 831,83 sec.) . . . . . . . . . . . . . . . . . . . . . . 63

39 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derTigerton Maschine, ohne die Threads zu platzieren(serielle Laufzeit830,90 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

40 Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der Tigerton Maschine . . . . . . 63

68

LITERATUR

41 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derScaleMP Maschine unter Verwendung der Threadbinding Bibliothek(serielle Laufzeit 724,22 sec.) . . . . . . . . . . . . . . . . . . . . . . 65

42 Ergebnisse der Speedupmessungen des SHEMAT-Suite Codes auf derScaleMP Maschine, ohne die Threads zu platzieren (serielle Laufzeit692,18 sec.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

43 Differenz der Speedupmessungen des SHEMAT-Suite Codes im unge-bundenen und gebundenen Fall auf der ScaleMP Maschine . . . . . . 65

Tabellenverzeichnis1 Messergebnisse der “nested EPCC” Benchmarks auf Barcelona Opte-

ron (Angaben in Mikrosekunden) . . . . . . . . . . . . . . . . . . . . 452 Messergebnisse der “nested EPCC” Benchmarks auf Barcelona Opte-

ron ohne unnötige Barrieren (Angaben in Mikrosekunden) . . . . . . 473 Messergebnisse der “nested EPCC” Benchmarks auf einem Tigerton

(Angaben in Mikrosekunden) . . . . . . . . . . . . . . . . . . . . . . 474 Messergebnisse der “nested EPCC” Benchmarks auf der ScaleMP Ma-

schine (Angaben in Mikrosekunden) . . . . . . . . . . . . . . . . . . 485 Laufzeiten für 10 Testläufe des TFS Codes (Angaben in sec.) . . . . . 55

Verzeichnis der Programmausschnitte1 Beispiel eines parallel Konstruktes . . . . . . . . . . . . . . . . . . . 122 Beispiel eines parallel Konstruktes mit worksharing . . . . . . . . . . 133 Instrumentierung eines critical Konstruktes mit Opari . . . . . . . . . 154 Instrumentierung eines parallel do Konstruktes mit Opari . . . . . . . 165 Schleife zum Testen der ThreadID . . . . . . . . . . . . . . . . . . . 216 Code zum Aufbau einer unsymmetrischen Threadhierarchie . . . . . 297 Schleife aus den EPCC Benchmark zum Messen des Overhead eines

Barrier Konstruktes . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 Schleife aus den EPCC Benchmarks zum Messen der Referenzzeit . . 449 Vergleich der reduction Operationen, oben: uninstrumentiert, unten:

instrumentiert mit Opari . . . . . . . . . . . . . . . . . . . . . . . . 46

Literatur[A. Wolf & Bücker 08] V. R. A. Wolf, H. M. Bücker. Parallelisation of a Geothermal

Simulation Package: A Case Study on Four Multicore Architectures. Proc. ParallelComputing: Architectures, Algorithms and Applications, pp. 451–458, 2008.

69

LITERATUR

[an Mey & Sarholz+] D. an Mey, S. Sarholz, C. Terboven. Nested Parallelization withOpenMP. International Journal of Parallel Programming, Vol. 35.

[an Mey & Sarholz+ 09] D. an Mey, S. Sarholz, C. Terboven, R. van der Pas, E. Loh.The RWTH HPC-Cluster User’s Guide. Center for Computing and Communication,RWTH Aachen University, 2009.

[Bücker & Rasch+ 09] H. M. Bücker, A. Rasch, V. Rath, A. Wolf. Semi-automaticparallelization of direct and inverse problems for geothermal simulation. Proc. SAC,pp. 971–975, 2009.

[Bull 99] J. M. Bull. Measuring Synchronisation and Scheduling Overheads inOpenMP. Proc. In Proceedings of First European Workshop on OpenMP, pp. 99–105, 1999.

[Chapman & Jost+ 07] B. Chapman, G. Jost, R. v. d. Pas. Using OpenMP: PortableShared Memory Parallel Programming (Scientific and Engineering Computation).The MIT Press, 2007.

[Forum 95] M. Forum. MPI: a Message-Passing Interface Standard. MPI Forum,1995.

[Forum 03] M. Forum. MPI-2: Extensions to the Message-Passing Interface. MPIForum, 2003.

[FSF 09] FSF. The GNU OpenMP Impletation. Free Software Foundation, 2009.

[Gropp & Lusk+ 94] W. Gropp, E. Lusk, A. Skjellum. Using MPI: Portable ParallelProgramming with the Message Passing Interface. MIT Press, 1994.

[Hennessy & Patterson 06] J. L. Hennessy, D. A. Patterson. Computer Architecture:A Quantitative Approach, Fourth Edition. Morgan Kaufmann, September 2006.

[Intel 09] Intel. Intel(R) Fortran Compiler User and Reference Guides. Intel Corpo-ration, 2009.

[Johnson & Leggett+ 08] S. Johnson, P. Leggett, C. Ierotheou, A. Spiegel, D. an Mey,I. Hörschler. Nested Parallelization of the Flow Solver TFS Using the ParaWise Par-allelization Environment. Proc. OpenMP Shared Memory Parallel Programming,pp. 217–229. Springer Berlin / Heidelberg, 2008.

[Mccalpin 95] J. D. Mccalpin. STREAM: Sustainable memory bandwidth in highperformance computers, 1995.

[Mohr & Malony+ 02a] B. Mohr, A. Malony, H.-C. Hoppe, F. Schlimbach, G. Haab,S. Shah. A performance monitoring interface for OpenMP, 2002.

70

LITERATUR

[Mohr & Malony+ 02b] B. Mohr, A. Malony, S. Shende, F. Wolf. Design and proto-type of a performance tool interface for OpenMP, 2002.

[OMPP 05] OMPP. The OpenMP Profiler: ompP. Technische Universitaet Muenchen,Germany, and the University of Tennessee, 2005.

[OpenMP 05] OpenMP. OpenMP Application Program Interface Version 2.5. http://www.openmp.org/mp-documents/spec25.pdf, 2005.

[OpenMP 08] OpenMP. OpenMP Application Program Interface Version 3.0. http://www.openmp.org/mp-documents/spec30.pdf, 2008.

[Pruess & Xu 04] K. Pruess, T. Xu. Numerical Simulation of Reactive Flow in HotAquifers - Christoph Clauser (Ed.); Springer-Verlag, Berlin, Heidelberg, New York,ISBN 3-540-43868-8, hard back, 332 pages. Geothermics, Vol. 33, pp. 213–215,February 2004.

[SCALASCA] SCALASCA. SCalable performance Analysis of LArge SCale Appli-cations. Forschungszentrum Juelich.

[Sun 07] Sun. Sun Studio 12: OpenMP API User’s Guide. Sun Microsystems, Inc.,2007.

[Terboven & an Mey+ 08] C. Terboven, D. an Mey, D. Schmidl, H. Jin, T. Reichstein.Data and thread affinity in openmp programs. Proc. MAW ’08: Proceedings of the2008 workshop on Memory access on future processors, pp. 377–384, New York,NY, USA, 2008. ACM.

[VAMPIR] VAMPIR. Vampir. Center for Applied Mathematics of Research CenterJülich and the Center for High Performance Computing of the Technische Univer-sität Dresden.

71

platzierung von openmp-programmen auf hierarchischen ... · rheinisch-westfÄlische technische...

Documents