Informatik im Fokus



Herausgeber:
Prof. Dr. O. Günther
Prof. Dr. W. Karl
Prof. Dr. R. Lienhart
Prof. Dr. K. Zeppenfeld
Informatik im Fokus



Rauber, T.; Rünger, G.
Multicore: Parallele
Programmierung. 2008

El Moussaoui, H.; Zeppenfeld, K.
...
Thomas Rauber · Gudula Rünger




Multicore:
Parallele Programmierung




123
Prof. Dr. Thomas Rauber                            Prof. Dr. Gudula Rünger
Universität Bayreuth                           ...
Vorwort




Nach vielen Jahren stetigen technologischen Fortschritts in
der Mikroprozessorentwicklung stellt die Multicore...
VI     Vorwort

entwickler also neue M¨glichkeiten, die in der Bereitstel-
                         o
lung zus¨tzlicher Fu...
Inhaltsverzeichnis




1   Kurz¨berblick Multicore-Prozessoren . . . . . . 1
        u
    1.1 Entwicklung der Mikroprozes...
VIII       Inhaltsverzeichnis

4      Programmierung mit Pthreads . . . . . . . . . . . .                               63...
1
Kurzuberblick
    ¨
Multicore-Prozessoren




Die Entwicklung der Mikroprozessoren hat in den letzten
Jahrzehnten durch ...
2      1 Kurz¨berblick Multicore-Prozessoren
             u

aus ca. 291 Millionen Transistoren, ein IBM Cell-Prozessor
au...
1.1 Entwicklung der Mikroprozessoren       3

•   die Vergr¨ßerung der prozessorlokalen Cachespeicher.
             o
    ...
4      1 Kurz¨berblick Multicore-Prozessoren
             u

    Entfernung von 0.33 ·10−9 s·0.3 · 109m/s ≈ 0.1m zur¨ ck-
...
1.2 Parallelit¨t auf Prozessorebene
                                 a                         5

Prozessor bezeichnet wir...
6      1 Kurz¨berblick Multicore-Prozessoren
             u

ringf¨ gige Vergr¨ßerung der Chipfl¨che. F¨ r zwei logische
  ...
1.2 Parallelit¨t auf Prozessorebene
                                 a                         7

ren als die vielversprec...
8          1 Kurz¨berblick Multicore-Prozessoren
                 u

m¨ ssen Techniken der parallelen Programmierung einge...
1.3 Architektur von Multicore-Prozessoren     9

dreistufige Hierarchie ergibt. Dieses Konzept kann auf meh-
rere Stufen er...
10     1 Kurz¨berblick Multicore-Prozessoren
             u

eine Variante des X10, enth¨lt z.B. 200 separate Prozes-
    ...
1.3 Architektur von Multicore-Prozessoren      11

seit 2005 bieten viele Hardwarehersteller Prozessoren mit
zwei oder meh...
12     1 Kurz¨berblick Multicore-Prozessoren
             u

dungsnetzwerk auf dem Prozessorchip, das an eine variable
Anz...
1.4 Beispiele     13

                ¨
Tabelle 1.1. Uberblick uber verschiedene Multicore-Prozessoren,
                  ...
14      1 Kurz¨berblick Multicore-Prozessoren
              u

•    eine drastische Verk¨ rzung der internen Pipelines (ma...
1.4 Beispiele          15

(Front Side Bus) werden uber einen Bus-Controller gesteu-
                        ¨
ert.

     ...
16      1 Kurz¨berblick Multicore-Prozessoren
              u

Daten, die Ausf¨ hrung von Integeroperationen (durch ei-
  ...
1.4 Beispiele    17

legt. F¨ r komplexere x86-Instruktionen werden die zu-
        u
geh¨rigen Mikroinstruktionen uber ei...
18     1 Kurz¨berblick Multicore-Prozessoren
             u

einfachem Design: der Prozessor kann pro Takt zwei In-
strukt...
1.4 Beispiele    19

Prozessor kann durch Zusammenlegen von Funktionseinhei-
ten auch 64-Bit Floating-Point-Zahlen verarbe...
20         1 Kurz¨berblick Multicore-Prozessoren
                 u

                       Synergetic Processing Elements...
2
Konzepte paralleler
Programmierung




Die Leistungsverbesserung der Generation der Multicore-
Prozessoren wird technolo...
22      2 Konzepte paralleler Programmierung

     Ein wesentlicher Schritt in der Programmierung von
Multicore-Prozessore...
2.1 Entwurf paralleler Programme     23

    Zur Erzeugung der Berechnungsstr¨me wird die aus-
                           ...
24      2 Konzepte paralleler Programmierung

                                                 Prozessor−
       Tasks    ...
2.1 Entwurf paralleler Programme      25

    der Abarbeitung mehrerer Tasks wird als Nebenl¨ufig-
                        ...
26       2 Konzepte paralleler Programmierung

moderne Programme bereits Multithreading verwenden,
gibt es doch Unterschie...
2.2 Klassifizierung paralleler Architekturen   27

entscheidungen der parallelen Programmierung eine erheb-
liche Rolle spi...
28      2 Konzepte paralleler Programmierung

•    Die MIMD (Multiple Instruction, Multiple Data) Rech-
     ner sind die ...
2.3 Parallele Programmiermodelle        29

parallelen Programms zugreifen und verarbeiten. Server-
Architekturen und insb...
30      2 Konzepte paralleler Programmierung

angehensweise an diese Vielfalt der Programmiermodelle
[59]:
•    Auf welche...
2.3 Parallele Programmiermodelle      31

•   Bei der Parallelit¨t auf Anweisungsebene werden
                         a
 ...
32       2 Konzepte paralleler Programmierung

     tion und Barrier-Anweisungen bei Modellen mit verteil-
     tem Adress...
2.3 Parallele Programmiermodelle       33

    Explizite Parallelit¨t mit impliziter Zerlegung liegt
                     ...
34     2 Konzepte paralleler Programmierung

tusinformationen des Prozessors oder einen Stack f¨ r loka-
                 ...
2.4 Parallele Leistungsmaße    35

der Informationsaustausch einfach uber gemeinsame Varia-
                              ...
36      2 Konzepte paralleler Programmierung

•    der Zeit f¨ r die Durchf¨ hrung von Berechnungen durch
               u...
2.4 Parallele Leistungsmaße    37

Implementierung durch den Einsatz von Parallelverarbei-
tung auf p Prozessoren entsteht...
38     2 Konzepte paralleler Programmierung

Speedup gilt damit

                         T ∗ (n)             1     1
    ...
3
Thread-Programmierung




Die Programmierung von Multicore-Prozessoren ist eng mit
der parallelen Programmierung eines g...
40     3 Thread-Programmierung

Prozesse

Ein Prozess ist ein sich in Ausf¨ hrung befindendes Pro-
                        ...
3.1 Threads und Prozesse      41

von dieser Prozessnummer andere Anweisungen als der El-
ternprozess ausf¨ hren, vgl. [46...
42     3 Thread-Programmierung

ten mit kooperierenden Prozessen, bietet aber die gleichen
Vorteile. Insbesondere ist es m...
3.1 Threads und Prozesse       43

     Der Nachteil von Threads auf Benutzerebene liegt darin,
dass das Betriebssystem ke...
44     3 Thread-Programmierung

                      Bibliotheks−    BT    Betriebssystem−
         T
                   ...
3.1 Threads und Prozesse                 45

ren. Die zweite M¨glichkeit ist die N:M-Abbildung, die
                  o
ei...
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Multicore Parallele Programmierung Kng617
Nächste SlideShare
Wird geladen in …5
×

Multicore Parallele Programmierung Kng617

1.871 Aufrufe

Veröffentlicht am

0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.871
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
26
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Multicore Parallele Programmierung Kng617

  1. 1. Informatik im Fokus Herausgeber: Prof. Dr. O. Günther Prof. Dr. W. Karl Prof. Dr. R. Lienhart Prof. Dr. K. Zeppenfeld
  2. 2. Informatik im Fokus Rauber, T.; Rünger, G. Multicore: Parallele Programmierung. 2008 El Moussaoui, H.; Zeppenfeld, K. AJAX. 2008 Behrendt, J.; Zeppenfeld, K. Web 2.0. 2008 Bode, A.; Karl, W. Multicore-Architekturen. 2008
  3. 3. Thomas Rauber · Gudula Rünger Multicore: Parallele Programmierung 123
  4. 4. Prof. Dr. Thomas Rauber Prof. Dr. Gudula Rünger Universität Bayreuth TU Chemnitz LS Angewandte Informatik II Fakultät für Informatik Universitätsstr. 30 Straße der Nationen 62 95447 Bayreuth 09107 Chemnitz rauber@uni-bayreuth.de ruenger@informatik.tu-chemnitz.de Herausgeber: Prof. Dr. O. Günther Prof. Dr. R. Lienhart Humboldt Universität zu Berlin Universität Augsburg Prof. Dr. W. Karl Prof. Dr. K. Zeppenfeld Universität Karlsruhe (TH) Fachhochschule Dortmund ISBN 978-3-540-73113-9 e-ISBN 978-3-540-73114-6 DOI 10.1007/978-3-540-73114-6 ISSN 1865-4452 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2008 Springer-Verlag Berlin Heidelberg Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funk- sendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Ver- vielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Einbandgestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 987654321 springer.com
  5. 5. Vorwort Nach vielen Jahren stetigen technologischen Fortschritts in der Mikroprozessorentwicklung stellt die Multicore-Techno- logie die neueste Entwickungsstufe dar. F¨ hrende Hard- u warehersteller wie Intel, AMD, Sun oder IBM liefern seit 2005 Mikroprozessoren mit mehreren unabh¨ngigen Pro- a zessorkernen auf einem einzelnen Prozessorchip. Im Jahr 2007 verwendet ein typischer Desktop-PC je nach Ausstat- tung einen Dualcore- oder Quadcore-Prozessor mit zwei bzw. vier Prozessorkernen. Die Ank¨ ndigungen der Prozes- u sorhersteller zeigen, dass dies erst der Anfang einer l¨nger a andauernden Entwicklung ist. Eine Studie von Intel prog- nostiziert, dass im Jahr 2015 ein typischer Prozessorchip aus Dutzenden bis Hunderten von Prozessorkernen be- steht, die zum Teil spezialisierte Aufgaben wie Verschl¨ sse- u lung, Grafikdarstellung oder Netzwerkmanagement wahr- nehmen. Ein Großteil der Prozessorkerne steht aber f¨ r u Anwendungsprogramme zur Verf¨ gung und kann z.B. f¨ r u u B¨ ro- oder Unterhaltungssoftware genutzt werden. u Die von der Hardwareindustrie vorgegebene Entwick- lung hin zu Multicore-Prozessoren bietet f¨ r die Software- u
  6. 6. VI Vorwort entwickler also neue M¨glichkeiten, die in der Bereitstel- o lung zus¨tzlicher Funktionalit¨ten der angebotenen Soft- a a ware liegen, die parallel zu den bisherigen Funktionalit¨ten a ausgef¨ hrt werden k¨nnen, ohne dass dies beim Nutzer zu u o Wartezeiten f¨ hrt. Diese Entwicklung stellt aber auch einen u Paradigmenwechsel in der Softwareentwicklung dar, weg von der herk¨mmlichen sequentiellen Programmierung hin o zur parallelen oder Multithreading-Programmierung. Bei- de Programmierformen sind nicht neu. Der Paradigmen- wechsel besteht eher darin, dass diese Programmiertechni- ken bisher nur in speziellen Bereichen eingesetzt wurden, nun aber durch die Einf¨ hrung von Multicore-Prozessoren u in alle Bereiche der Softwareentwicklung getragen werden und so f¨ r viele Softwareentwickler eine neue Herausforde- u rung entsteht. Das Ziel dieses Buches ist es, dem Leser einen ers- ten Einblick in die f¨ r Multicore-Prozessoren geeigneten u parallelen Programmiertechniken und -systeme zu geben. Programmierumgebungen wie Pthreads, Java-Threads und OpenMP werden vorgestellt. Die Darstellung geht dabei davon aus, dass der Leser mit Standardtechniken der Pro- grammierung vertraut ist. Das Buch enth¨lt zahlreiche Hin- a weise auf weiterf¨ hrende Literatur sowie neuere Entwick- u lungen wie etwa neue Programmiersprachen. F¨ r Hilfe bei u der Erstellung des Buches und Korrekturen danken wir J¨rg o D¨ mmler, Monika Glaser, Marco H¨bbel, Raphael Kunis u o und Michael Schwind. Dem Springer-Verlag danken wir f¨ r u die gute Zusammenarbeit. Bayreuth, Chemnitz, Thomas Rauber August 2007 Gudula R¨ nger u
  7. 7. Inhaltsverzeichnis 1 Kurz¨berblick Multicore-Prozessoren . . . . . . 1 u 1.1 Entwicklung der Mikroprozessoren . . . . . . . . . 1 1.2 Parallelit¨t auf Prozessorebene . . . . . . . . . . . . 4 a 1.3 Architektur von Multicore-Prozessoren . . . . . 8 1.4 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 Konzepte paralleler Programmierung . . . . . . 21 2.1 Entwurf paralleler Programme . . . . . . . . . . . . 22 2.2 Klassifizierung paralleler Architekturen . . . . . 27 2.3 Parallele Programmiermodelle . . . . . . . . . . . . . 29 2.4 Parallele Leistungsmaße . . . . . . . . . . . . . . . . . . 35 3 Thread-Programmierung . . . . . . . . . . . . . . . . . . 39 3.1 Threads und Prozesse . . . . . . . . . . . . . . . . . . . . 39 3.2 Synchronisations-Mechanismen . . . . . . . . . . . . 46 3.3 Effiziente und korrekte Thread-Programme . 51 3.4 Parallele Programmiermuster . . . . . . . . . . . . . 54 3.5 Parallele Programmierumgebungen . . . . . . . . 61
  8. 8. VIII Inhaltsverzeichnis 4 Programmierung mit Pthreads . . . . . . . . . . . . 63 4.1 Threaderzeugung und -verwaltung . . . . . . . . . 63 4.2 Koordination von Threads . . . . . . . . . . . . . . . . 66 4.3 Bedingungsvariablen . . . . . . . . . . . . . . . . . . . . . 70 4.4 Erweiterter Sperrmechanismus . . . . . . . . . . . . 75 4.5 Implementierung eines Taskpools . . . . . . . . . . 78 5 Java-Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1 Erzeugung von Threads in Java . . . . . . . . . . . 85 5.2 Synchronisation von Java-Threads . . . . . . . . . 91 5.3 Signalmechanismus in Java . . . . . . . . . . . . . . . 101 5.4 Erweiterte Synchronisationsmuster . . . . . . . . . 109 5.5 Thread-Scheduling in Java . . . . . . . . . . . . . . . . 113 5.6 Paket java.util.concurrent . . . . . . . . . . . . 115 6 OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.1 Programmiermodell . . . . . . . . . . . . . . . . . . . . . . 125 6.2 Spezifikation der Parallelit¨t . . . . . . . . . . . . . . 127 a 6.3 Koordination von Threads . . . . . . . . . . . . . . . . 139 7 Weitere Ans¨tze . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 a 7.1 Sprachans¨tze . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 a 7.2 Transaktionsspeicher . . . . . . . . . . . . . . . . . . . . . 150 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
  9. 9. 1 Kurzuberblick ¨ Multicore-Prozessoren Die Entwicklung der Mikroprozessoren hat in den letzten Jahrzehnten durch verschiedene technologische Innovatio- nen immer leistungsst¨rkere Prozessoren hervorgebracht. a Multicore-Prozessoren stellen einen weiteren Meilenstein in der Entwicklung dar. 1.1 Entwicklung der Mikroprozessoren Prozessorchips sind intern aus Transistoren aufgebaut, de- ren Anzahl ein ungef¨hres Maß f¨ r die Komplexit¨t und a u a Leistungsf¨higkeit des Prozessors ist. Das auf empirischen a Beobachtungen beruhende Gesetz von Moore besagt, dass die Anzahl der Transistoren eines Prozessorchips sich alle 18 bis 24 Monate verdoppelt. Diese Beobachtung wurde 1965 von Gordon Moore zum ersten Mal gemacht und gilt nun seit uber 40 Jahren. Ein typischer Prozessorchip aus ¨ dem Jahr 2007 besteht aus ca. 200-400 Millionen Transis- toren: beispielsweise besteht ein Intel Core 2 Duo Prozessor
  10. 10. 2 1 Kurz¨berblick Multicore-Prozessoren u aus ca. 291 Millionen Transistoren, ein IBM Cell-Prozessor aus ca. 250 Millionen Transistoren. Die Erh¨hung der Transistoranzahl ging in der Ver- o gangenheit mit einer Erh¨hung der Taktrate einher. Dies o steigerte die Verarbeitungsgeschwindigkeit der Prozesso- ren und die Taktrate eines Prozessors wurde oftmals als alleiniges Merkmal f¨ r dessen Leistungsf¨higkeit wahrge- u a nommen. Gemeinsam f¨ hrte die Steigerung der Taktrate u und der Transistoranzahl zu einer durchschnittlichen j¨hr- a lichen Leistungssteigerung der Prozessoren von ca. 55% (bei Integer-Operationen) bzw. 75% (bei Floating-Point- Operationen), was durch entsprechende Benchmark-Pro- gramme gemessen wurde, siehe [32] und www.spec.org f¨ r u eine Beschreibung der oft verwendeten SPEC-Benchmarks. Eine Erh¨hung der Taktrate im bisherigen Umfang ist je- o doch f¨ r die Zukunft nicht zu erwarten. Dies ist darin be- u gr¨ ndet, dass mit einer Erh¨hung der Taktrate auch die u o Leistungsaufnahme, also der Energieverbrauch des Prozes- sors, ansteigt, wobei ein Großteil des verbrauchten Stroms in W¨rme umgewandelt wird und uber L¨ fter abgef¨ hrt a u u ¨ werden muss. Das Gesetz von Moore scheint aber bis auf weiteres seine G¨ ltigkeit zu behalten. u Die steigende Anzahl verf¨ gbarer Transistoren wurde u in der Vergangenheit f¨ r eine Vielzahl weiterer architekto- u nischer Verbesserungen genutzt, die die Leistungsf¨higkeit a der Prozessoren erheblich gesteigert hat. Dazu geh¨ren u.a. o • die Erweiterung der internen Wortbreite auf 64 Bits, • die Verwendung interner Pipelineverarbeitung f¨ r die u ressourcenoptimierte Ausf¨ hrung aufeinanderfolgender u Maschinenbefehle, • die Verwendung mehrerer Funktionseinheiten, mit de- nen voneinander unabh¨ngige Maschinenbefehle paral- a lel zueinander abgearbeitet werden k¨nnen und o
  11. 11. 1.1 Entwicklung der Mikroprozessoren 3 • die Vergr¨ßerung der prozessorlokalen Cachespeicher. o Wesentliche Aspekte der Leistungssteigerung sind also die Erh¨hung der Taktrate und der interne Einsatz paralle- o ler Abarbeitung von Instruktionen, z.B. durch das Duplizie- ren von Funktionseinheiten. Die Grenzen beider Entwick- lungen sind jedoch abzusehen: Ein weiteres Duplizieren von Funktionseinheiten und Pipelinestufen ist zwar m¨glich, o bringt aber wegen vorhandener Abh¨ngigkeiten zwischen a den Instruktionen kaum eine weitere Leistungssteigerung. Gegen eine weitere Erh¨hung der prozessoreigenen Taktra- o te sprechen mehrere Gr¨ nde [36]: u • Ein Problem liegt darin, dass die Speicherzugriffsge- schwindigkeit nicht im gleichen Umfang wie die Pro- zessorgeschwindigkeit zunimmt, was zu einer Erh¨hung o der Zyklenanzahl pro Speicherzugriff f¨ hrt. So brauch- u te z.B. um 1990 ein Intel i486 f¨ r einen Zugriff auf u den Hauptspeicher zwischen 6 und 8 Maschinenzyklen, w¨hrend 2006 ein Intel Pentium Prozessor uber 220 Zy- a ¨ klen ben¨tigt. Die Speicherzugriffszeiten stellen daher o einen kritischen limitierenden Faktor f¨ r eine weitere u Leistungssteigerung dar. • Zum Zweiten wird die Erh¨hung der Transistoranzahl o durch eine erh¨hte Packungsdichte erreicht, mit der aber o auch eine gesteigerte W¨rmeentwicklung pro Fl¨chen- a a einheit verbunden ist. Diese wird zunehmend zum Pro- blem, da die notwendige K¨ hlung entsprechend aufwen- u diger wird. • Zum Dritten w¨chst mit der Anzahl der Transistoren a auch die prozessorinterne Leitungsl¨nge f¨ r den Signal- a u transport, so dass die Signallaufzeit eine wichtige Rolle spielt. Dies sieht man an folgender Berechnung: Ein mit 3GHz getakteter Prozessor hat eine Zykluszeit von 0.33 ns = 0.33 ·10−9 sec. In dieser Zeit kann ein Signal eine
  12. 12. 4 1 Kurz¨berblick Multicore-Prozessoren u Entfernung von 0.33 ·10−9 s·0.3 · 109m/s ≈ 0.1m zur¨ ck- u legen, wenn wir die Lichtgeschwindigkeit im Vakuum als ¨ Signalgeschwindigkeit ansetzen. Je nach Ubergangsme- dium ist die Signalgeschwindigkeit sogar deutlich nied- riger. Damit k¨nnen die Signale in einem Takt nur ei- o ne relativ geringe Entfernung zur¨ cklegen, so dass der u Layout-Entwurf der Prozessorchips entsprechend gestal- tet werden muss. Um eine weitere Leistungssteigerung der Prozessoren im bisherigen Umfang zu erreichen, setzen die Prozessor- hersteller auf eine explizite Parallelverarbeitung innerhalb eines Prozessors, indem mehrere logische Prozessoren von einem physikalischen Prozessor simuliert werden oder meh- rere vollst¨ndige, voneinander nahezu unabh¨ngige Prozes- a a sorkerne auf einen Prozessorchip platziert werden. Der Ein- satz expliziter Parallelverarbeitung innerhalb eines Prozes- sors hat weitreichende Konsequenzen f¨ r die Programmie- u rung: soll ein Programm von der verf¨ gbaren Leistung des u Multicore-Prozessors profitieren, so muss es die verf¨ gba- u ren Prozessorkerne entsprechend steuern und effizient aus- nutzen. Dazu werden Techniken der parallelen Program- mierung eingesetzt. Da die Prozessorkerne eines Prozes- sorchips ein gemeinsames Speichersystem nutzen, sind Pro- grammierans¨tze f¨ r gemeinsamen Adressraum geeignet. a u 1.2 Parallelit¨t auf Prozessorebene a Explizite Parallelit¨t auf Prozessorebene wird durch eine a entsprechende Architekturorganisation des Prozessorchips erreicht. Eine M¨glichkeit ist die oben erw¨hnte Platzierung o a mehrerer Prozessorkerne mit jeweils unabh¨ngigen Ausf¨ h- a u rungseinheiten auf einem Prozessorchip, was als Multicore-
  13. 13. 1.2 Parallelit¨t auf Prozessorebene a 5 Prozessor bezeichnet wird. Ein anderer Ansatz besteht darin, mehrere Kontrollfl¨ sse dadurch gleichzeitig auf ei- u nem Prozessor oder Prozessorkern auszuf¨ hren, dass der u Prozessor je nach Bedarf per Hardware zwischen den Kon- trollfl¨ ssen umschaltet. Dies wird als simultanes Multi- u threading (SMT) oder Hyperthreading (HT) bezeich- net [43]. Bei dieser Art der Parallelit¨t werden die Kontrollfl¨ sse a u oft als Threads bezeichnet. Dieser Begriff und die Unter- schiede zu Prozessen werden in den folgenden Abschnitten n¨her erl¨utert; zun¨chst reicht es aus, einen Thread als a a a Kontrollfluss anzusehen, der parallel zu anderen Threads desselben Programms ausgef¨ hrt werden kann. u Simultanes Multithreading (SMT) Simultanes Multithreading basiert auf dem Duplizieren des Prozessorbereiches zur Ablage des Prozessorzustandes auf der Chipfl¨che des Prozessors. Zum Prozessorzustand geh¨- a o ren die Benutzer- und Kontrollregister sowie der Interrupt- Controller mit seinen zugeh¨rigen Registern. Damit verh¨lt o a sich der physikalische Prozessor aus der Sicht des Be- triebssystems und des Benutzerprogramms wie zwei lo- gische Prozessoren, denen Prozesse oder Threads zur Ausf¨ hrung zugeordnet werden k¨nnen. Diese k¨nnen von u o o einem oder mehreren Anwendungsprogrammen stammen. Jeder logische Prozessor legt seinen Prozessorzustand in einem separaten Prozessorbereich ab, so dass beim Wech- sel zu einem anderen Thread kein aufwendiges Zwischen- speichern des Prozessorzustandes im Speichersystem erfor- derlich ist. Die logischen Prozessoren teilen sich fast al- le Ressourcen des physikalischen Prozessors wie Caches, Funktions- und Kontrolleinheiten oder Bussystem. Die Rea- lisierung der SMT-Technologie erfordert daher nur eine ge-
  14. 14. 6 1 Kurz¨berblick Multicore-Prozessoren u ringf¨ gige Vergr¨ßerung der Chipfl¨che. F¨ r zwei logische u o a u Prozessoren w¨chst z.B. f¨ r einen Intel Xeon Prozessor die a u erforderliche Chipfl¨che um weniger als 5% [44, 67]. Die a gemeinsamen Ressourcen des Prozessorchips werden den logischen Prozessoren reihum zugeteilt, so dass die logi- schen Prozessoren simultan zur Verf¨ gung stehen. Treten u bei einem logischen Prozessor Wartezeiten auf, k¨nnen die o Ausf¨ hrungs-Ressourcen dem anderen logischen Prozessor u zugeordnet werden, so dass aus der Sicht des physikali- schen Prozessors eine verbesserte Nutzung der Ressourcen gew¨hrleistet ist. a Untersuchungen zeigen, dass die verbesserte Nutzung der Ressourcen durch zwei logische Prozessoren je nach An- wendungsprogramm Laufzeitverbesserungen zwischen 15% und 30% bewirken kann [44]. Da alle Ressourcen des Chips von den logischen Prozessoren geteilt werden, ist beim Ein- satz von wesentlich mehr als zwei logischen Prozessoren f¨ r u die meisten Einsatzgebiete keine weitere signifikante Lauf- zeitverbesserung zu erwarten. Der Einsatz simultanen Mul- tithreadings wird daher voraussichtlich auf wenige logische Prozessoren beschr¨nkt bleiben. Zum Erreichen einer Leis- a tungsverbesserung durch den Einsatz der SMT-Technologie ist es erforderlich, dass das Betriebssystem in der Lage ist, die logischen Prozessoren anzusteuern. Aus Sicht eines Anwendungsprogramms ist es erforderlich, dass f¨ r jeden u logischen Prozessor ein separater Thread zur Ausf¨ hrung u bereitsteht, d.h. f¨ r die Implementierung des Programms u m¨ ssen Techniken der parallelen Programmierung einge- u setzt werden. Multicore-Prozessoren Neue Prozessorarchitekturen mit mehreren Prozessorker- nen auf einem Prozessorchip werden schon seit vielen Jah-
  15. 15. 1.2 Parallelit¨t auf Prozessorebene a 7 ren als die vielversprechendste Technik zur weiteren Leis- tungssteigerung angesehen. Die Idee besteht darin, anstatt eines Prozessorchips mit einer sehr komplexen internen Or- ganisation mehrere Prozessorkerne mit einfacherer Organi- sation auf dem Prozessorchip zu integrieren. Dies hat den zus¨tzlichen Vorteil, dass der Stromverbrauch des Prozes- a sorchips dadurch reduziert werden kann, dass vor¨ berge- u hend ungenutzte Prozessorkerne abgeschaltet werden [27]. Bei Multicore-Prozessoren werden mehrere Prozessor- kerne auf einem Prozessorchip integriert. Jeder Prozessor- kern stellt f¨ r das Betriebssystem einen separaten logischen u Prozessor mit separaten Ausf¨ hrungsressourcen dar, die u getrennt angesteuert werden m¨ ssen. Das Betriebssystem u kann damit verschiedene Anwendungsprogramme parallel zueinander zur Ausf¨ hrung bringen. So k¨nnen z.B. meh- u o rere Hintergrundanwendungen wie Viruserkennung, Ver- schl¨ sselung und Kompression parallel zu Anwendungs- u programmen des Nutzers ausgef¨ hrt werden [58]. Es ist u aber mit Techniken der parallelen Programmierung auch m¨glich, ein rechenzeitintensives Anwendungsprogramm (et- o wa aus dem Bereich der Computerspiele, der Bildverar- beitung oder naturwissenschaftlicher Simulationsprogram- me) auf mehreren Prozessorkernen parallel abzuarbeiten, so dass die Berechnungszeit im Vergleich zu einer Ausf¨ hrung u auf einem Prozessorkern reduziert werden kann. Damit k¨nnen auch Standardprogramme wie Textver- o arbeitungsprogramme oder Computerspiele zus¨tzliche, im a Hintergrund ablaufende Funktionalit¨ten zur Verf¨ gung a u stellen, die parallel zu den Haupt-Funktionalit¨ten auf ei- a nem separaten Prozessorkern durchgef¨ hrt werden und so- u mit f¨ r den Nutzer nicht zu wahrnehmbaren Verz¨gerun- u o gen f¨ hren. F¨ r die Koordination der innerhalb einer An- u u wendung ablaufenden unterschiedlichen Funktionalit¨ten a
  16. 16. 8 1 Kurz¨berblick Multicore-Prozessoren u m¨ ssen Techniken der parallelen Programmierung einge- u setzt werden. 1.3 Architektur von Multicore-Prozessoren F¨ r die Realisierung von Multicore-Prozessoren gibt es ver- u schiedene Implementierungsvarianten, die sich in der An- zahl der Prozessorkerne, der Gr¨ße und Anordnung der Ca- o ches, den Zugriffm¨glichkeiten der Prozessorkerne auf die o Caches und dem Einsatz von heterogenen Komponenten unterscheiden [37]. Dabei werden zur Zeit drei unterschied- liche Architekturmodelle eingesetzt, von denen auch Misch- formen auftreten k¨nnen. o Hierarchisches Design Bei einem hierarchischen De- sign teilen sich mehrere Pro- zessorkerne mehrere Caches, die in einer baumartigen Konfi- Cache/Speicher guration angeordnet sind, wo- bei die Gr¨ße der Caches von o den Bl¨ttern zur Wurzel steigt. a Cache Cache Die Wurzel repr¨sentiert die a Verbindung zum Hauptspei- cher. So kann z.B. jeder Pro- Kern Kern Kern Kern zessorkern einen separaten L1- Cache haben, sich aber mit hierarchisches Design anderen Prozessorkernen einen L2-Cache teilen. Alle Prozes- Abbildung 1.1. Hierarchi- sorkerne k¨nnen auf den ge- o sches Design. meinsamen externen Haupt- speicher zugreifen, was eine
  17. 17. 1.3 Architektur von Multicore-Prozessoren 9 dreistufige Hierarchie ergibt. Dieses Konzept kann auf meh- rere Stufen erweitert werden und ist in Abbildung 1.1 f¨ r drei Stufen veranschaulicht. Zus¨tzliche Untersyste- u a me k¨nnen die Caches einer Stufe miteinander verbinden. o Ein hierarchisches Design wird typischerweise f¨ r Server- u Konfigurationen verwendet. Ein Beispiel f¨ r ein hierarchisches Design ist der IBM u Power5 Prozessor, der zwei 64-Bit superskalare Prozessor- kerne enth¨lt, von denen jeder zwei logische Prozessoren a durch Einsatz von SMT simuliert. Jeder Prozessorkern hat einen separaten L1-Cache (f¨ r Daten und Programme ge- u trennt) und teilt sich mit dem anderen Prozessorkern einen L2-Cache (1.8 MB) sowie eine Schnittstelle zu einem ex- ternen 36 MB L3-Cache. Andere Prozessoren mit hierar- chischem Design sind die Intel Core 2 Prozessoren und die Sun UltraSPARC T1 (Niagara) Prozessoren. Pipeline-Design Bei einem Pipeline-Design werden die Daten durch meh- rere Prozessorkerne schrittwei- se weiterverarbeitet, bis sie vom letzten Prozessorkern im Speichersystem abgelegt wer- den, vgl. Abbildung 1.2. Hoch- spezialisierte Netzwerk-Prozes- soren und Grafikchips arbei- ten oft nach diesem Prinzip. Ein Beispiel sind die X10 und X11 Prozessoren von Xelera- tor zur Verarbeitung von Netz- Abbildung 1.2. Pipeline- werkpaketen in Hochleistungs- Design. Routern. Der Xelerator X10q,
  18. 18. 10 1 Kurz¨berblick Multicore-Prozessoren u eine Variante des X10, enth¨lt z.B. 200 separate Prozes- a sorkerne, die in einer logischen linearen Pipeline mitein- ander verbunden sind. Die Pakete werden dem Prozessor uber mehrere Netzwerkschnittstellen zugef¨ hrt und dann u ¨ durch die Prozessorkerne schrittweise verarbeitet, wobei je- der Prozessorkern einen Schritt ausf¨ hrt. Die X11 Netz- u werkprozessoren haben bis zu 800 Pipeline-Prozessorkerne. Netzwerkbasiertes Design Bei einem netzwerkbasier- ten Design sind die Pro- zessorkerne und ihre lokalen Caches oder Speicher uber ¨ ein Verbindungsnetzwerk mit den anderen Prozessorkernen des Chips verbunden, so dass der gesamte Datentransfer zwi- schen den Prozessorkernen uber ¨ das Verbindungsnetzwerk l¨uft, a vgl. Abbildung 1.3. Der Ein- satz eines prozessorinternen Netzwerkes ist insbesondere Abbildung 1.3. Netzwerk- dann sinnvoll, wenn eine Viel- basiertes Design. zahl von Prozessorkernen ver- wendet werden soll. Ein netz- werkorientiertes Design wird z.B. f¨ r den Intel Teraflop- u Prozessor verwendet, der im Rahmen der Intel Tera-Scale- Initiative entwickelt wurde, vgl. unten, und in dem 80 Pro- zessorkerne eingesetzt werden. Weitere Entwicklungen Das Potential der Multicore-Prozessoren wurde von vie- len Hardwareherstellern wie Intel und AMD erkannt und
  19. 19. 1.3 Architektur von Multicore-Prozessoren 11 seit 2005 bieten viele Hardwarehersteller Prozessoren mit zwei oder mehr Kernen an. Ab Ende 2006 liefert Intel Quadcore-Prozessoren und ab 2008 wird mit der Auslie- ferung von Octcore-Prozessoren gerechnet. IBM bietet mit der Cell-Architektur einen Prozessor mit acht spezialisier- ten Prozessorkernen, vgl. Abschnitt 1.4. Der seit Dezember 2005 ausgelieferte UltraSPARC T1 Niagara Prozessor von Sun hat bis zu acht Prozessorkerne, von denen jeder durch den Einsatz von simultanem Multithreading, das von Sun als CoolThreads-Technologie bezeichnet wird, vier Thre- ads simultan verarbeiten kann. Damit kann ein UltraS- PARC T1 bis zu 32 Threads simultan ausf¨ hren. Das f¨ r u u 2008 angek¨ ndigte Nachfolgemodell des Niagara-Prozessors u (ROCK) soll bis zu 16 Prozessorkerne enthalten. Intel Tera-Scale-Initiative Intel untersucht im Rahmen des Tera-scale Computing Pro- grams die Herausforderungen bei der Herstellung und Pro- grammierung von Prozessoren mit Dutzenden von Prozes- sorkernen [27]. Diese Initiative beinhaltet auch die Ent- wicklung eines Teraflop-Prozessors, der 80 Prozessorkerne enth¨lt, die als 8×10-Gitter organisiert sind. Jeder Prozes- a sorkern kann Floating-Point-Operationen verarbeiten und enth¨lt neben einem lokalen Cachespeicher auch einen Rou- a ter zur Realisierung des Datentransfers zwischen den Pro- zessorkernen und dem Hauptspeicher. Zus¨tzlich kann ein a solcher Prozessor spezialisierte Prozessorkerne f¨ r die Ver- u arbeitung von Videodaten, graphischen Berechnungen und zur Verschl¨ sselung von Daten enthalten. Je nach Einsatz- u gebiet kann die Anzahl der spezialisierten Prozessorkerne variiert werden. Ein wesentlicher Bestandteil eines Prozessors mit ei- ner Vielzahl von Prozessorkernen ist ein effizientes Verbin-
  20. 20. 12 1 Kurz¨berblick Multicore-Prozessoren u dungsnetzwerk auf dem Prozessorchip, das an eine variable Anzahl von Prozessorkernen angepasst werden kann, den Ausfall einzelner Prozessorkerne toleriert und bei Bedarf das Abschalten einzelner Prozessorkerne erlaubt, falls diese f¨ r die aktuelle Anwendung nicht ben¨tigt werden. Ein sol- u o ches Abschalten ist insbesondere zur Reduktion des Strom- verbrauchs sinnvoll. F¨ r eine effiziente Nutzung der Prozessorkerne ist ent- u scheidend, dass die zu verarbeitenden Daten schnell zu den Prozessorkernen transportiert werden k¨nnen, so dass diese o nicht auf die Bereitstellung der Daten warten m¨ ssen. Dazu u sind ein leistungsf¨higes Speichersystem und I/O-System a erforderlich. Das Speichersystem setzt private L1-Caches ein, auf die nur von jeweils einem Prozessorkern zugegriffen werden kann, sowie gemeinsame, evtl. aus mehreren Stufen bestehende L2-Caches ein, die Daten verschiedener Prozes- sorkerne enthalten. F¨ r einen Prozessorchip mit Dutzenden u von Prozessorkernen muss voraussichtlich eine weitere Stufe im Speichersystem eingesetzt werden [27]. Das I/O-System muss in der Lage sein, Hunderte von Gigabytes pro Sekun- de zum Prozessorchip zu transportieren. Hier arbeitet z.B. Intel an der Entwicklung geeigneter Systeme. ¨ Tabelle 1.1 gibt einen Uberblick uber aktuelle Multicore- ¨ Prozessoren. Zu bemerken ist dabei, dass der Sun Ul- traSPARC T1-Prozessor im Gegensatz zu den drei ande- ren Prozessoren kaum Unterst¨ tzung f¨ r Floating-Point- u u Berechnungen bietet und somit uberwiegend f¨ r den Ein- u ¨ satz im Serverbereich, wie Web-Server oder Applikations- Server, geeignet ist. F¨ r eine detailliertere Behandlung der u Architektur von Multicore-Prozessoren und weiterer Bei- spiele verweisen wir auf [10, 28].
  21. 21. 1.4 Beispiele 13 ¨ Tabelle 1.1. Uberblick uber verschiedene Multicore-Prozessoren, ¨ vgl. auch [28]. Intel IBM AMD Sun Prozessor Core 2 Duo Power 5 Opteron T1 Prozessorkerne 2 2 2 8 Instruktionen 4 4 3 1 pro Zyklus SMT nein ja nein ja L1-Cache I/D 32/32 64/32 64/64 16/8 in KB per core L2-Cache 4 MB 1.9 MB 1 MB 3 MB shared shared per core shared Taktrate (GHz) 2.66 1.9 2.4 1.2 Transistoren 291 Mio 276 Mio 233 Mio 300 Mio Stromverbrauch 65 W 125 W 110 W 79 W 1.4 Beispiele Im Folgenden wird die Architektur von Multicore-Prozes- soren anhand zweier Beispiele verdeutlicht: der Intel Core 2 Duo-Architektur und dem IBM Cell-Prozessor. Intel Core 2 Prozessor Intel Core 2 bezeichnet eine Familie von Intel-Prozessoren mit ¨hnlicher Architektur. Die Intel Core-Architektur ba- a siert auf einer Weiterentwicklung der Pentium M Prozesso- ren, die viele Jahre im Notebookbereich eingesetzt wurden. Die neue Architektur l¨st die bei den Pentium 4 Prozesso- o ren noch eingesetzte NetBurst-Architektur ab. Signifikante Merkmale der neuen Architektur sind:
  22. 22. 14 1 Kurz¨berblick Multicore-Prozessoren u • eine drastische Verk¨ rzung der internen Pipelines (ma- u ximal 14 Stufen anstatt maximal 31 Stufen bei der NetBurst-Architektur), damit verbunden • eine Reduktion der Taktrate und damit verbunden auch • eine deutliche Reduktion des Stromverbrauchs: die Re- duktion des Stromverbrauches wird auch durch eine Power-Management-Einheit unterst¨ tzt, die das zeit- u weise Ausschalten ungenutzter Prozessorteile erm¨glicht o [48] und • die Unterst¨ tzung neuer Streaming-Erweiterungen (Stre- u aming SIMD Extensions, SSE). Intel Core 2 Prozessoren werden zur Zeit (August 2007) als Core 2 Duo bzw. Core 2 Quad Prozessoren mit 2 bzw. 4 unabh¨ngigen Prozessorkernen in 65nm-Technologie ge- a fertigt. Im Folgenden wird der Core 2 Duo Prozessor kurz beschrieben [24]. Die Core 2 Quad Prozessoren haben einen ahnlichen Aufbau, enthalten aber 4 statt 2 Prozessorkerne. ¨ Da die Core 2 Prozessoren auf der Technik des Pentium M Prozessors basieren, unterst¨ tzen sie kein Hyperthrea- u ding. Die allgemeine Struktur der Core 2 Duo Architektur ist in Abb. 1.4 wiedergegeben. Der Prozessorchip enth¨lt a zwei unabh¨ngige Prozessorkerne, von denen jeder separate a L1-Caches anspricht; diese sind f¨ r Instruktionen (32K) und u Daten (32K) getrennt realisiert. Der L2-Cache (4 MB) ist dagegen nicht exklusiv und wird von beiden Prozessorker- nen gemeinsam f¨ r Instruktionen und Daten genutzt. Alle u Zugriffe von den Prozessorkernen und vom externen Bus auf den L2-Cache werden von einem L2-Controller behandelt. F¨ r die Sicherstellung der Koh¨renz der auf den verschie- u a denen Stufen der Speicherhierarchie abgelegten Daten wird ein MESI-Protokoll (Modified, Exclusive, Shared, Invalid) verwendet, vgl. [17, 47, 59] f¨ r eine detaillierte Erkl¨rung. u a Alle Daten- und I/O-Anfragen zum oder vom externen Bus
  23. 23. 1.4 Beispiele 15 (Front Side Bus) werden uber einen Bus-Controller gesteu- ¨ ert. Core 2 Duo Prozessor Core 0 Core 1 Architektur−Ressourcen Architektur−Ressourcen Ausführungs−Ressourcen Ausführungs−Ressourcen L1−Caches (I/O) L1−Caches (I/O) Cache−Controller Cache−Controller Power−Management−Controller L2−Cache mit Controller (shared) Bus−Interface und −Controller FrontSideBus ¨ Abbildung 1.4. Uberblick Core 2 Duo Architektur. Ein wichtiges Element ist die Kontrolleinheit f¨ r den u Stromverbrauch des Prozessors (Power Management Con- troller) [48], die den Stromverbrauch des Prozessorchips durch Reduktion der Taktrate der Prozessorenkerne oder durch Abschalten (von Teilen) des L2-Caches reduzieren kann. Jeder Prozessorkern f¨ hrt einen separaten Strom von u Instruktionen aus, der sowohl Berechnungs- als auch Spei- cherzugriffsinstruktionen (load/store) enthalten kann. Da- bei kann jeder der Prozessorkerne bis zu vier Instruktionen gleichzeitig verarbeiten. Die Prozessorkerne enthalten sepa- rate Funktionseinheiten f¨ r das Laden bzw. Speichern von u
  24. 24. 16 1 Kurz¨berblick Multicore-Prozessoren u Daten, die Ausf¨ hrung von Integeroperationen (durch ei- u ne ALU, arithmetic logic unit), Floating-Point-Operationen sowie SSE-Operationen. Instruktionen k¨nnen aber nur o dann parallel zueinander ausgef¨ hrt werden, wenn keine u Abh¨ngigkeiten zwischen ihnen bestehen. F¨ r die Steue- a u rung der Ausf¨ hrung werden komplexe Schedulingverfah- u ren eingesetzt, die auch eine Umordnung von Instruktionen (out-of-order execution) erlauben, um eine m¨glichst gute o Ausnutzung der Funktionseinheiten zu verwirklichen [28]. Laden von Instruktionen Instruktionsschlange Mikrocode Dekodiereinheit L2− ROM Cache (shared) Register−Umbenennung und −Allokierung Umordnungspuffer Instruktions−Scheduler ALU ALU ALU Load Store Branch FPAdd FPMul MMX/SSE MMX/SSE MMX/SSE Speicherzugriffspuffer FPMove FPMove FPMove L1−Datencache Abbildung 1.5. Instruktionsverarbeitung und Speicherorganisa- tion eines Prozessorkerns des Intel Core 2 Prozessors. Abbildung 1.5 veranschaulicht die Organisation der Ab- arbeitung von Instruktionen durch einen der Prozessorker- ne [20]. Jeder der Prozessorkerne l¨dt x86-Instruktionen a in eine Instruktionsschlange, auf die die Dekodiereinheit zugreift und die Instruktionen in Mikroinstruktionen zer-
  25. 25. 1.4 Beispiele 17 legt. F¨ r komplexere x86-Instruktionen werden die zu- u geh¨rigen Mikroinstruktionen uber einen ROM-Speicher o ¨ geladen. Die Mikroinstruktionen werden vom Instruktions- Scheduler freien Funktionseinheiten zugeordnet, wobei die Instruktionen in einer gegen¨ ber dem urspr¨ nglichen Pro- u u grammcode ge¨nderten Reihenfolge abgesetzt werden k¨n- a o nen. Alle Speicherzugriffsoperationen werden uber den L1- ¨ Datencache abgesetzt, der Integer-und Floating-Point-Da- ten enth¨lt. a F¨ r Ende 2007 bzw. Anfang 2008 sollen Intel Core 2- u Prozessoren mit verbesserter Core-Architektur eingef¨ hrt u werden (Codename Penryn). Voraussichtlich f¨ r Ende 2008 u ist eine neue Generation von Intel-Prozessoren geplant, die auf einer neuen Architektur basiert (Codename Nehalem). Diese neuen Prozessoren sollen neben mehreren Prozessor- kernen (zu Beginn acht) auch einen Graphikkern und einen Speichercontroller auf einem Prozessorchip integrieren. Die neuen Prozessoren sollen auch wieder die SMT-Technik (si- multanes Multithreading) unterst¨ tzen, so dass auf jedem u Prozessorkern gleichzeitig zwei Threads ausgef¨ hrt werden u k¨nnen. Diese Technik wurde teilweise f¨ r Pentium 4 Pro- o u zessoren verwendet, nicht jedoch f¨ r die Core 2 Duo und u Quad Prozessoren. IBM Cell-Prozessor Der Cell-Prozessor wurde von IBM in Zusammenarbeit mit Sony und Toshiba entwickelt. Der Prozessor wird u.a. von Sony in der Spielekonsole PlayStation 3 eingesetzt, siehe [39, 34] f¨ r ausf¨ hrlichere Informationen. Der Cell- u u Prozessor enth¨lt ein Power Processing Element (PPE) und a 8 Single-Instruction Multiple-Datastream (SIMD) Prozesso- ren. Das PPE ist ein konventioneller 64-Bit-Mikroprozessor auf der Basis der Power-Architektur von IBM mit relativ
  26. 26. 18 1 Kurz¨berblick Multicore-Prozessoren u einfachem Design: der Prozessor kann pro Takt zwei In- struktionen absetzen und simultan zwei unabh¨ngige Thre- a ads ausf¨ hren. Die einfache Struktur hat den Vorteil, dass u trotz hoher Taktrate eine geringe Leistungsaufnahme re- sultiert. F¨ r den gesamten Prozessor ist bei einer Taktrate u von 3.2 GHz nur eine Leistungsaufnahme von 60-80 Watt erforderlich. Auf der Chipfl¨che des Cell-Prozessors sind neben dem a PPE acht SIMD-Prozessoren integriert, die als SPE (Syn- ergetic Processing Element) bezeichnet werden. Jedes SPE stellt einen unabh¨ngigen Vektorprozessor mit einem 256KB a großen lokalem SRAM-Speicher dar, der als Local Store (LS) bezeichnet wird. Das Laden von Daten in den LS und das Zur¨ ckspeichern von Resultaten aus dem LS in den u Hauptspeicher muss per Software erfolgen. Jedes SPE enth¨lt 128 128-Bit-Register, in denen die a Operanden von Instruktionen abgelegt werden k¨nnen. Da o auf die Daten in den Registern sehr schnell zugegriffen wer- den kann, reduziert die große Registeranzahl die Notwen- digkeit von Zugriffen auf den LS und f¨ hrt damit zu ei- u ner geringen mittleren Speicherzugriffszeit. Jedes SPE hat vier Floating-Point-Einheiten (32 Bit) und vier Integer- Einheiten. Z¨hlt man eine Multiply-Add-Instruktion als a zwei Operationen, kann jedes SPE bei 3.2 GHz Taktrate pro Sekunde uber 25 Milliarden Floating-Point-Operationen ¨ (25.6 GFlops) und uber 25 Milliarden Integer-Operationen ¨ (25.6 Gops) ausf¨ hren. Da ein Cell-Prozessor acht SPE u enth¨lt, f¨ hrt dies zu einer maximalen Performance von a u uber 200 GFlops, wobei die Leistung des PPE noch nicht ¨ ber¨ cksichtigt wurde. Eine solche Leistung kann allerdings u nur bei guter Ausnutzung der LS-Speicher und effizienter Zuordnung von Instruktionen an Funktionseinheiten der SPE erreicht werden. Zu beachten ist auch, dass sich diese Angabe auf 32-Bit Floating-Point-Zahlen bezieht. Der Cell-
  27. 27. 1.4 Beispiele 19 Prozessor kann durch Zusammenlegen von Funktionseinhei- ten auch 64-Bit Floating-Point-Zahlen verarbeiten, dies re- sultiert aber in einer wesentlich geringeren maximalen Per- formance. Zur Vereinfachung der Steuerung der SPEs und zur Vereinfachung des Schedulings verwenden die SPEs in- tern keine SMT-Technik. Die zentrale Verbindungseinheit des Cell-Prozessors ist ein Bussystem, der sogenannte Element Interconnect Bus (EIB). Dieser besteht aus vier unidirektionalen Ringver- bindungen, die eine Wortbreite von 16 Bytes haben und mit der halben Taktrate des Prozessors arbeiten. Zwei der Ringe werden in entgegengesetzter Richtung zu den ande- ren beiden Ringe betrieben, so dass die maximale Latenz im schlechtesten Fall durch einen halben Ringdurchlauf be- stimmt wird. F¨ r den Transport von Daten zwischen be- u nachbarten Ringelementen k¨nnen maximal drei Transfer- o operationen simultan durchgef¨ hrt werden, f¨ r den Zyklus u u des Prozessors ergibt dies 16 · 3/2 = 24 Bytes pro Zyklus. F¨ r die vier Ringverbindungen ergibt dies eine maxima- u le Transferrate von 96 Bytes pro Zyklus, woraus bei einer Taktrate von 3.2 GHz eine maximale Transferrate von uber ¨ 300 GBytes/Sekunde resultiert. Abbildung 1.6 zeigt einen schematischen Aufbau des Cell-Prozessors mit den bisher beschriebenen Elementen sowie dem Speichersystem (Me- mory Interface Controller, MIC) und dem I/O-System (Bus Interface Controller, BIC). Das Speichersystem unterst¨ tzt u die XDR-Schnittstelle von Rambus. Das I/O-System un- terst¨ tzt das Rambus RRAC (Redwood Rambus Access u Cell) Protokoll. Zum Erreichen einer guten Leistung ist es wichtig, die SPEs des Cell-Prozessors effizient zu nutzen. Dies kann f¨ r u spezialisierte Programme, wie z.B. Videospiele, durch di- rekte Verwendung von SPE-Assembleranweisungen erreicht werden. Da dies f¨ r die meisten Anwendungsprogramme u
  28. 28. 20 1 Kurz¨berblick Multicore-Prozessoren u Synergetic Processing Elements SPU SPU SPU SPU SPU SPU SPU SPU LS LS LS LS LS LS LS LS 16B/ Zyklus EIB (bis 96 B/Zyklus) L2 MIC BIC L1 PPU Dual RRAC I/O 64−Bit Power Architektur XDR Abbildung 1.6. Schematischer Aufbau des Cell-Prozessors. zu aufwendig ist, werden f¨ r das Erreichen einer guten u Gesamtleistung eine effektive Compilerunterst¨ tzung sowie u die Verwendung spezialisierter Programmbibliotheken z.B. zur Verwaltung von Taskschlangen wichtig sein.
  29. 29. 2 Konzepte paralleler Programmierung Die Leistungsverbesserung der Generation der Multicore- Prozessoren wird technologisch durch mehrere Prozessor- kerne auf einem Chip erreicht. Im Gegensatz zu bisherigen Leistungsverbesserungen bei Prozessoren hat diese Tech- nologie jedoch Auswirkungen auf die Softwareentwicklung: Konnten bisherige Verbesserungen der Prozessorhardware zu Leistungsgewinnen bei existierenden (sequentiellen) Pro- grammen f¨ hren, ohne dass die Programme ge¨ndert wer- u a den mussten, so ist zur vollen Ausnutzung der Leistung der Multicore-Prozessoren ein Umdenken hin zur paralle- len Programmierung notwendig [62]. Parallele Programmiertechniken sind seit vielen Jahren im Einsatz, etwa im wissenschaftlichen Rechnen auf Paral- lelrechnern oder im Multithreading, und stellen somit kei- nen wirklich neuen Programmierstil dar. Neu hingegen ist, dass durch die k¨ nftige Allgegenw¨rtigkeit der Multicore- u a Prozessoren ein Ausbreiten paralleler Programmiertechni- ken in alle Bereiche der Softwareentwicklung erwartet wird und diese damit zum R¨ stzeug eines jeden Softwareentwick- u lers geh¨ren werden. o
  30. 30. 22 2 Konzepte paralleler Programmierung Ein wesentlicher Schritt in der Programmierung von Multicore-Prozessoren ist das Bereitstellen mehrerer Be- rechnungsstr¨me, die auf den Kernen eines Multicore-Pro- o zessors simultan, also gleichzeitig, abgearbeitet werden. Zu- n¨chst ist die rein gedankliche Arbeit durchzuf¨ hren, einen a u einzelnen Anwendungsalgorithmus in solche Berechnungs- str¨me zu zerlegen, was eine durchaus langwierige, schwie- o rige und kreative Aufgabe sein kann, da es eben sehr viele M¨glichkeiten gibt, dies zu tun, und insbesondere korrekte o und effiziente Software resultieren soll. Zur Erstellung der parallelen Software sind einige Grund- begriffe und -kenntnisse hilfreich: • Wie wird beim Entwurf eines parallelen Programmes vorgegangen? • Welche Eigenschaften der parallelen Hardware sollen zu Grunde gelegt werden? • Welches parallele Programmiermodell soll genutzt wer- den? • Wie kann der Leistungsvorteil des parallelen Programms gegen¨ ber dem sequentiellen bestimmt werden? u • Welche parallele Programmierumgebung oder -sprache soll genutzt werden? 2.1 Entwurf paralleler Programme Die Grundidee der parallelen Programmierung besteht dar- in, mehrere Berechnungsstr¨me zu erzeugen, die gleichzei- o tig, also parallel, ausgef¨ hrt werden k¨nnen und durch ko- u o ordinierte Zusammenarbeit eine gew¨nschte Aufgabe er- u ledigen. Liegt bereits ein sequentielles Programm vor, so spricht man auch von der Parallelisierung eines Program- mes.
  31. 31. 2.1 Entwurf paralleler Programme 23 Zur Erzeugung der Berechnungsstr¨me wird die aus- o zuf¨ hrende Aufgabe in Teilaufgaben zerlegt, die auch Tasks u genannt werden. Tasks sind die kleinsten Einheiten der Par- allelit¨t. Beim Entwurf der Taskstruktur eines Program- a mes m¨ ssen Daten- und Kontrollabh¨ngigkeiten beachtet u a und eingeplant werden, um ein korrektes paralleles Pro- gramm zu erhalten. Die Gr¨ße der Tasks wird Granu- o larit¨t genannt. F¨ r die tats¨chliche parallele Abarbei- a u a tung werden die Teilaufgaben in Form von Threads oder Prozessen auf physikalische Rechenressourcen abgebildet. Die Rechenressourcen k¨nnen Prozessoren eines Paral- o lelrechners, aber auch die Prozessorkerne eines Multicore- Prozessors sein. Die Zuordnung von Tasks an Prozesse oder Threads wird auch als Scheduling bezeichnet. Dabei kann man zwischen statischem Scheduling, bei dem die Zuteilung beim Start des Programms festgelegt wird, und dynami- schem Scheduling, bei dem die Zuteilung w¨hrend der a Abarbeitung des Programms erfolgt, unterscheiden. Die Abbildung von Prozessen oder Threads auf Prozessorker- ne, auch Mapping genannt, kann explizit im Programm bzw. durch das Betriebssystem erfolgen. Abbildung 2.1 zeigt eine Veranschaulichung. Software mit mehreren parallel laufenden Tasks gibt es in vielen Bereichen schon seit Jahren. So bestehen Server- anwendungen h¨ufig aus mehreren Threads oder Prozes- a sen. Ein typisches Beispiel ist ein Webserver, der mit ei- nem Haupt-Thread HTTP-Anfragenachrichten von belie- bigen Clients (Browsern) entgegennimmt und f¨ r jede ein- u treffende Verbindungsanfrage eines Clients einen separa- ten Thread erzeugt. Dieser Thread behandelt alle von die- sem Client eintreffenden HTTP-Anfragen und schickt die zugeh¨rigen HTTP-Antwortnachrichten uber eine Client- o ¨ spezifische TCP-Verbindung. Wird diese TCP-Verbindung
  32. 32. 24 2 Konzepte paralleler Programmierung Prozessor− Tasks Threads Kerne T1 T2 Schedu− T1 ling Mapping P1 T2 T3 Thread− Task− T3 P2 Zerlegung Zuordnung Abbildung 2.1. Veranschaulichung der typischen Schritte zur Parallelisierung eines Anwendungsalgorithmus. Der Algorithmus wird in der Zerlegungsphase in Tasks mit gegenseitigen Abh¨ngig- a keiten aufgespalten. Diese Tasks werden durch das Scheduling Threads zugeordnet, die auf Prozessorkerne abgebildet werden. geschlossen, wird auch der zugeh¨rige Thread beendet. o Durch dieses Vorgehen kann ein Webserver gleichzeitig vie- le ankommende Anfragen nebenl¨ufig erledigen oder auf a verf¨ gbaren Rechenressourcen parallel bearbeiten. F¨ r Web- u u server mit vielen Anfragen (wie google oder ebay) werden entsprechende Plattformen mit vielen Rechenressourcen be- reitgehalten. Abarbeitung paralleler Programme F¨ r die parallele Abarbeitung der Tasks bzw. Threads oder u Prozesse gibt es verschiedene Ans¨tze, vgl. z.B. auch [3]: a • Multitasking: Multitasking-Betriebssysteme arbeiten mehrere Threads oder Prozesse in Zeitscheiben auf dem- selben Prozessor ab. Hierdurch k¨nnen etwa die Latenz- o zeiten von I/O-Operationen durch eine verschachtelte Abarbeitung der Tasks uberdeckt werden. Diese Form ¨
  33. 33. 2.1 Entwurf paralleler Programme 25 der Abarbeitung mehrerer Tasks wird als Nebenl¨ufig- a keit (Concurrency) bezeichnet; mehrere Tasks werden gleichzeitig bearbeitet, aber nur eine Task macht zu ei- nem bestimmten Zeitpunkt einen tats¨chlichen Rechen- a fortschritt. Eine simultane parallele Abarbeitung findet also nicht statt. • Multiprocessing: Die Verwendung mehrerer physi- kalischer Prozessoren macht eine tats¨chliche paralle- a le Abarbeitung mehrerer Tasks m¨glich. Bedingt durch o die hardwarem¨ßige Parallelit¨t mit mehreren physika- a a lischen Prozessoren kann jedoch ein nicht unerheblicher zeitlicher Zusatzaufwand (Overhead) entstehen. • Simultanes Multithreading (SMT): Werden meh- rere logische Prozessoren auf einem physikalischen Pro- zessor ausgef¨ hrt, so k¨nnen die Hardwareressourcen ei- u o nes Prozessors besser genutzt werden und es kann eine teilweise beschleunigte Abarbeitung von Tasks erfolgen, vgl. Kap. 1. Bei zwei logischen Prozessoren sind Leis- tungssteigerungen durch Nutzung von Wartezeiten ei- nes Threads f¨ r die Berechnungen des anderen Threads u um bis zu 30 % m¨glich. o • Chip-Multiprocessing: Der n¨chste Schritt ist nun, a die Idee der Threading-Technologie auf einem Chip mit dem Multiprocessing zu verbinden, was durch Multicore- Prozessoren m¨glich ist. Die Programmierung von Mul- o ticore-Prozessoren vereint das Multiprocessing mit dem simultanen Multithreading in den Sinne, dass Multi- threading-Programme nicht nebenl¨ufig sondern tat- a s¨chlich parallel auf einen Prozessor abgearbeitet wer- a den. Dadurch sind im Idealfall Leistungssteigerungen bis zu 100 % f¨ r einen Dualcore-Prozessor m¨glich. u o F¨ r die Programmierung von Multicore-Prozessoren wer- u den Multithreading-Programme eingesetzt. Obwohl viele
  34. 34. 26 2 Konzepte paralleler Programmierung moderne Programme bereits Multithreading verwenden, gibt es doch Unterschiede, die gegen¨ ber der Programmie- u rung von Prozessoren mit simultanem Multithreading zu beachten sind: • Einsatz zur Leistungsverbesserung: Die Leistungsver- besserungen von SMT-Prozessoren wird meistens zur Verringerung der Antwortzeiten f¨ r den Nutzer ein- u gesetzt, indem etwa ein Thread zur Beantwortung ei- ner oder mehrerer Benutzeranfragen abgespalten und nebenl¨ufig ausgef¨ hrt wird. In Multicore-Prozessoren a u hingegen wird die gesamte Arbeit eines Programmes durch Partitionierung auf die einzelnen Kerne verteilt und gleichzeitig abgearbeitet. • Auswirkungen des Caches: Falls jeder Kern eines Mul- ticore-Prozessors einen eigenen Cache besitzt, so kann es zu dem beim Multiprocessing bekannten False Sha- ring kommen. Bei False Sharing handelt es sich um das Problem, dass zwei Kerne gleichzeitig auf Daten arbei- ten, die zwar verschieden sind, jedoch in derselben Ca- chezeile liegen. Obwohl die Daten also unabh¨ngig sind, a wird die Cachezeile im jeweils anderen Kern als ung¨ ltig u markiert, wodurch es zu Leistungsabfall kommt. • Thread-Priorit¨ten: Bei der Ausf¨ hrung von Multithrea- a u ding-Programmen auf Prozessoren mit nur einem Kern wird immer der Thread mit der h¨chsten Priorit¨t zu- o a erst bearbeitet. Bei Prozessoren mit mehreren Kernen k¨nnen jedoch auch Threads mit unterschiedlichen Prio- o rit¨ten gleichzeitig abgearbeitet werden, was zu durch- a aus unterschiedlichen Resultaten f¨ hren kann. u Diese Beispiele zeigen, dass f¨ r den Entwurf von Multi- u threading-Programmen f¨ r Multicore-Prozessoren nicht nur u die Techniken der Threadprogrammierung gebraucht wer- den, sondern Programmiertechniken, Methoden und Design-
  35. 35. 2.2 Klassifizierung paralleler Architekturen 27 entscheidungen der parallelen Programmierung eine erheb- liche Rolle spielen. 2.2 Klassifizierung paralleler Architekturen Unter paralleler Hardware wird Hardware zusammenge- fasst, die mehrere Rechenressourcen bereitstellt, auf denen ein Programm in Form mehrerer Berechnungsstr¨me abge- o arbeitet wird. Die Formen paralleler Hardware reichen also von herk¨mmlichen Parallelrechnern bis hin zu parallelen o Rechenressourcen auf einem Chip, wie z.B. bei Multicore- Prozessoren. Eine erste Klassifizierung solcher paralleler Hardware hat bereits Flynn in der nach ihm benannten Flynnschen Klassifikation gegeben [23]. Diese Klassi- fikation unterteilt parallele Hardware in vier Klassen mit unterschiedlichen Daten- und Kontrollfl¨ ssen: u • Die SISD (Single Instruction, Single Data) Rechner be- sitzen eine Rechenressource, einen Datenspeicher und einen Programmspeicher, entsprechen also dem klassi- schen von-Neumann-Rechner der sequentiellen Pro- grammierung. • Die MISD (Multiple Instruction, Single Data) Rechner stellen mehrere Rechenressourcen, aber nur einen Pro- grammspeicher bereit. Wegen der geringen praktischen Relevanz spielt diese Klasse keine wesentliche Rolle. • Die SIMD (Single Instruction, Multiple Data) Rech- ner bestehen aus mehreren Rechenressourcen mit jeweils separatem Zugriff auf einen Datenspeicher, aber nur ei- nem Programmspeicher. Jede Ressource f¨ hrt dieselben u Instruktionen aus, die aus dem Programmspeicher gela- den werden, wendet diese aber auf unterschiedliche Da- ten an. F¨ r diese Klasse wurden in der Vergangenheit u Parallelrechner konstruiert und genutzt.
  36. 36. 28 2 Konzepte paralleler Programmierung • Die MIMD (Multiple Instruction, Multiple Data) Rech- ner sind die allgemeinste Klasse und zeichnen sich durch mehrere Rechenressourcen mit jeweils separatem Zugriff auf einen Datenspeicher und jeweils lokalen Programm- speichern aus. Jede Rechenressource kann also unter- schiedliche Instruktionen auf unterschiedlichen Daten verarbeiten. Zur Klasse der MIMD-Rechner geh¨ren viele der heu- o te aktuellen Parallelrechner, Cluster von PCs aber auch Multicore-Prozessoren, wobei die einzelnen Prozessoren, die PCs des Clusters oder die Kerne auf dem Chip ei- nes Multicore-Prozessors die jeweiligen Rechenressourcen bilden. Dies zeigt, dass die Flynnsche Klassifizierung f¨ r u die heutige Vielfalt an parallelen Rechenressourcen zu grob ist und weitere Unterteilungen f¨ r den Softwareentwickler u n¨ tzlich sind. Eine der weiteren Unterschiede der Hardware u von MIMD-Rechnern ist die Speicherorganisation, die sich auf den Zugriff der Rechenressourcen auf die Daten eines Programms auswirkt: Rechner mit verteiltem Speicher bestehen aus Re- chenressourcen, die jeweils einen ihnen zugeordneten lo- kalen bzw. privaten Speicher haben. Auf Daten im loka- len Speicher hat jeweils nur die zugeordnete Rechenres- source Zugriff. Werden Daten aus einem Speicher ben¨tigt, o der zu einer anderen Rechenressource lokal ist, so werden Programmiermechanismen, wie z. B. Kommunikation uber ¨ ein Verbindungsnetzwerk, eingesetzt. Clustersysteme, aber auch viele Parallelrechner geh¨ren in diese Klasse. o Rechner mit gemeinsamem Speicher bestehen aus mehreren Rechenressourcen und einem globalen oder ge- meinsamen Speicher, auf den alle Rechenressourcen uber ¨ ein Verbindungsnetzwerk auf Daten zugreifen k¨nnen. Da- o durch kann jede Rechenressource die gesamten Daten des
  37. 37. 2.3 Parallele Programmiermodelle 29 parallelen Programms zugreifen und verarbeiten. Server- Architekturen und insbesondere Multicore-Prozessoren ar- beiten mit einem physikalisch gemeinsamen Speicher. Die durch die Hardware gegebene Organisation des Speichers in verteilten und gemeinsamen Speicher kann f¨ r u den Programmierer in Form privater oder gemeinsamer Va- riable sichtbar und nutzbar sein. Es ist prinzipiell jedoch mit Hilfe entsprechender Softwareunterst¨ tzung m¨glich, u o das Programmieren mit gemeinsamen Variablen (shared va- riables) auch auf physikalisch verteiltem Speicher bereitzu- stellen. Ebenso kann die Programmierung mit verteiltem Adressraum und Kommunikation auf einem physikalisch gemeinsamen Speicher durch zus¨tzliche Software m¨glich a o sein. Dies ist nur ein Beispiel daf¨ r, dass die gegebene Hard- u ware nur ein Teil dessen ist, was dem Softwareentwickler als Sicht auf ein paralleles System dient. 2.3 Parallele Programmiermodelle Der Entwurf eines parallelen Programmes basiert immer auch auf einer abstrakten Sicht auf das parallele System, auf dem die parallele Software abgearbeitet werden soll. Diese abstrakte Sicht wird paralleles Programmiermo- dell genannt und setzt sich aus mehr als nur der gege- benen parallelen Hardware zusammen: Ein paralleles Pro- grammiermodell beschreibt ein paralleles Rechensystem aus der Sicht, die sich dem Softwareentwickler durch System- software wie Betriebssystem, parallele Programmiersprache oder -bibliothek, Compiler und Laufzeitbibliothek bietet. Entsprechend viele durchaus unterschiedliche parallele Pro- grammiermodelle bieten sich dem Softwareentwickler an. Folgende Kriterien erlauben jedoch eine systematische Her-
  38. 38. 30 2 Konzepte paralleler Programmierung angehensweise an diese Vielfalt der Programmiermodelle [59]: • Auf welcher Ebene eines Programmes sollen parallele Programmteile ausgef¨ hrt werden? (z.B. Instruktions- u ebene, Anweisungsebene oder Prozedurebene) • Sollen parallele Programmteile explizit angegeben wer- den? (explizit oder implizit parallele Programme) • In welcher Form werden parallele Programmteile ange- geben? (z.B. als beim Start des Programmes erzeugte Menge von Prozessen oder etwa Tasks, die dynamisch erzeugt und zugeordnet werden) • Wie erfolgt die Abarbeitung der parallelen Programm- teile im Verh¨ltnis zueinander? (SIMD oder SPMD (Sin- a gle Program, Multiple Data); synchrone oder asynchro- ne Berechnungen) • Wie findet der Informationsaustausch zwischen paral- lelen Programmteilen statt? (Kommunikation oder ge- meinsame Variable) • Welche Formen der Synchronisation k¨nnen genutzt o werden? (z.B. Barrier-Synchronisation oder Sperrme- chanismen) Ebenen der Parallelit¨t a Unabh¨ngige und damit parallel abarbeitbare Aufgaben a k¨nnen auf sehr unterschiedlichen Ebenen eines Programms o auftreten, wobei f¨ r die Parallelisierung eines Programmes u meist jeweils nur eine Ebene genutzt wird. • Parallelit¨t auf Instruktionsebene kann ausgenutzt a werden, falls zwischen zwei Instruktionen keine Daten- abh¨ngigkeit besteht. Diese Form der Parallelit¨t kann a a durch Compiler auf superskalaren Prozessoren einge- setzt werden.
  39. 39. 2.3 Parallele Programmiermodelle 31 • Bei der Parallelit¨t auf Anweisungsebene werden a mehrere Anweisungen auf denselben oder verschiede- nen Daten parallel ausgef¨ hrt. Eine Form ist die Da- u tenparallelit¨t, bei der Datenstrukturen wie Felder in a Teilbereiche unterteilt werden, auf denen parallel zuein- ander dieselben Operationen ausgef¨ hrt werden. Die- u se Arbeitsweise wird im SIMD Modell genutzt, in dem in jedem Schritt die gleiche Anweisung auf evtl. unter- schiedlichen Daten ausgef¨ hrt wird. u • Bei der Parallelit¨t auf Schleifenebene werden un- a terschiedliche Iterationen einer Schleifenanweisung par- allel zueinander ausgef¨ hrt. Besondere Auspr¨gungen u a sind die forall und dopar Schleife. Bei der forall- Schleife werden die Anweisungen im Schleifenrumpf par- allel in Form von Vektoranweisungen nacheinander ab- gearbeitet. Die dopar-Schleife f¨ hrt alle Anweisungen u einer Schleifeniteration unabh¨ngig vor den anderen a Schleifeniterationen aus. Je nach Datenabh¨ngigkeiten a zwischen den Schleifeniterationen kann es durch die Par- allelit¨t auf Schleifenebene zu unterschiedlichen Ergeb- a nissen kommen als bei der sequentiellen Abarbeitung der Schleifenr¨ mpfe. Als parallele Schleife wird eine u Schleife bezeichnet, deren Schleifenr¨mpfe keine Daten- u abh¨ngigkeit aufweisen und somit eine parallele Abar- a beitung zum gleichen Ergebnis f¨ hrt wie die sequentielle u Abarbeitung. Parallele Schleifen spielen bei Program- mierumgebungen wie OpenMP eine wesentliche Rolle. • Bei der Parallelit¨t auf Funktionsebene werden ge- a samte Funktionsaktivierungen eines Programms parallel zueinander auf verschiedenen Prozessoren oder Prozes- sorkernen ausgef¨ hrt. Bestehen zwischen parallel aus- u zuf¨ hrenden Funktionen Daten- oder Kontrollabh¨ngig- u a keiten, so ist eine Koordination zwischen den Funktio- nen erforderlich. Dies erfolgt in Form von Kommunika-
  40. 40. 32 2 Konzepte paralleler Programmierung tion und Barrier-Anweisungen bei Modellen mit verteil- tem Adressraum. Ein Beispiel ist die Programmierung mit MPI (Message Passing Interface) [59, 61]. Bei Mo- dellen mit gemeinsamem Adressraum ist Synchronisati- on erforderlich; dies ist also f¨ r die Programmierung von u Multicore-Prozessoren notwendig und wird in Kapitel 3 vorgestellt. Explizite oder implizite Parallelit¨t a Eine Voraussetzung f¨ r die parallele Abarbeitung auf ei- u nem Multicore-Prozessor ist das Vorhandensein mehrerer Berechnungsstr¨me. Diese k¨nnen auf recht unterschiedli- o o che Art erzeugt werden [60]. Bei impliziter Parallelit¨t braucht der Programmie- a rer keine Angaben zur Parallelit¨t zu machen. Zwei unter- a schiedliche Vertreter impliziter Parallelit¨t sind paralleli- a sierende Compiler oder funktionale Programmiersprachen. Parallelisierende Compiler erzeugen aus einem gegebenen sequentiellen Programm ein paralleles Programm und nut- zen dabei Abh¨ngigkeitsanalysen, um unabh¨ngige Berech- a a nungen zu ermitteln. Dies ist in den meisten F¨llen eine a komplexe Aufgabe und die Erfolge parallelisierender Com- piler sind entsprechend begrenzt [55, 66, 5, 2]. Programme in einer funktionalen Programmiersprache bestehen aus ei- ner Reihe von Funktionsdefinitionen und einem Ausdruck, dessen Auswertung das Programmergebnis liefert. Das Po- tential f¨ r Parallelit¨t liegt in der parallelen Auswertung u a der Argumente von Funktionen, da funktionale Program- me keine Seiteneffekte haben und sich die Argumente somit nicht beeinflussen k¨nnen [33, 64, 8]. Implizite Parallelit¨t o a wird teilweise auch von neuen Sprachen wie Fortress einge- setzt, vgl. Abschnitt 7.1.
  41. 41. 2.3 Parallele Programmiermodelle 33 Explizite Parallelit¨t mit impliziter Zerlegung liegt a vor, wenn der Programmierer zwar angibt, wo im Pro- gramm Potential f¨ r eine parallele Bearbeitung vorliegt, u etwa eine parallele Schleife, die explizite Kodierung in Thre- ads oder Prozesse aber nicht vornehmen muss. Viele paral- lele FORTRAN-Erweiterungen nutzen dieses Prinzip. Bei einer expliziten Zerlegung muss der Program- mierer zus¨tzlich angeben, welche Tasks es f¨ r die parallele a u Abarbeitung geben soll, ohne aber eine Zuordnung an Pro- zesse oder explizite Kommunikation formulieren zu m¨ ssen. u Ein Beispiel ist BSP [65]. Die explizite Zuordnung der Tasks an Prozesse wird in Koordinationssprachen wie Linda [12] zus¨tzlich angegeben. a Bei Programmiermodellen mit expliziter Kommuni- kation und Synchronisation muss der Programmierer alle Details der parallelen Abarbeitung angeben. Hierzu geh¨rt das Message-Passing-Programmiermodell mit MPI, o aber auch Programmierumgebungen zur Benutzung von Threads, wie Pthreads, das in Kap. 4 vorgestellt wird. Angabe paralleler Programmteile Sollen vom Programmierer die parallelen Programmteile ex- plizit angegeben werden, so kann dies in ganz unterschied- licher Form erfolgen. Bei der Angabe von Teilaufgaben in Form von Tasks werden diese implizit Prozessoren oder Kernen zugeordnet. Bei vollkommen explizit paralleler Pro- grammierung sind die Programmierung von Threads oder von Prozessen die weit verbreiteten Formen. Thread-Programmierung: Ein Thread ist eine Fol- ge von Anweisungen, die parallel zu anderen Anweisungsfol- gen, also Threads, abgearbeitet werden k¨nnen. Die Thre- o ads eines einzelnen Programmes besitzen f¨ r die Abarbei- u tung jeweils eigene Ressourcen, wie Programmz¨hler, Sta- a
  42. 42. 34 2 Konzepte paralleler Programmierung tusinformationen des Prozessors oder einen Stack f¨ r loka- u le Daten, nutzen jedoch einen gemeinsamen Datenspeicher. Damit ist das Thread-Modell f¨ r die Programmierung von u Multicore-Prozessoren geeignet. Message-Passing-Programmierung: Die Message- Passing-Programmierung nutzt Prozesse, die Programm- teile bezeichnen, die jeweils auf einem separaten physika- lischen oder logischen Prozessor abgearbeitet werden und somit jeweils einen privaten Adressraum besitzen. Abarbeitung paralleler Programmteile Die Abarbeitung paralleler Programmteile kann synchron erfolgen, indem die Anweisungen paralleler Threads oder Prozesse jeweils gleichzeitig abgearbeitet werden, wie et- wa im SIMD-Modell, oder asynchron, also unabh¨ngig von- a einander bis eine explizite Synchronisation erfolgt, wie et- wa im SPMD-Modell. Diese Festlegung der Abarbeitung wird meist vom Programmiermodell der benutzten Pro- grammierumgebung vorgegeben. Dar¨ ber hinaus gibt es ei- u ne Reihe von Programmiermustern, in denen parallele Pro- grammteile angeordnet werden, z.B. Pipelining, Master- Worker oder Produzenten-Konsumenten-Modell, und die vom Softwareentwickler explizit ausgew¨hlt werden. a Informationsaustausch Ein wesentliches Merkmal f¨ r den Informationsaustausch u ist die Organisation des Adressraums. Bei einem verteilten Adressraum werden Daten durch Kommunikation ausge- tauscht. Dies kann explizit im Programm angegeben sein, aber auch durch einen Compiler oder das Laufzeitsystem erzeugt werden. Bei einem gemeinsamen Adressraum kann
  43. 43. 2.4 Parallele Leistungsmaße 35 der Informationsaustausch einfach uber gemeinsame Varia- ¨ ble in diesem Adressraum geschehen, auf die lesend oder schreibend zugegriffen werden kann. Hierdurch kann es je- doch auch zu Konflikten oder unerw¨ nschten Ergebnis- u sen kommen, wenn dies unkoordiniert erfolgt. Die Koor- dination von parallelen Programmteilen spielt also eine wichtige Rolle bei der Programmierung eines gemeinsa- men Adressraums und ist daher ein wesentlicher Bestand- teil der Thread-Programmierung und der Programmierung von Multicore-Prozessoren. Formen der Synchronisation Synchronisation gibt es in Form von Barrier-Synchronisa- tion, die bewirkt, dass alle beteiligten Threads oder Pro- zesse aufeinander warten, und im Sinne der Koordination von Threads. Letzteres hat insbesondere mit der Vermei- dung von Konflikten beim Zugriff auf einen gemeinsamen Adressraum zu tun und setzt Sperrmechanismen und be- dingtes Warten ein. 2.4 Parallele Leistungsmaße Ein wesentliches Kriterium zur Bewertung eines parallelen Programms ist dessen Laufzeit. Die parallele Laufzeit Tp (n) eines Programmes ist die Zeit zwischen dem Start der Abarbeitung des parallelen Programmes und der Been- digung der Abarbeitung aller beteiligten Prozessoren. Die parallele Laufzeit wird meist in Abh¨ngigkeit von der An- a zahl p der zur Ausf¨ hrung benutzten Prozessoren und ei- u ner Problemgr¨ße n angegeben, die z.B. durch die Gr¨ße o o der Eingabe gegeben ist. F¨ r Multicore-Prozessoren mit ge- u meinsamem Adressraum setzt sich die Laufzeit eines paral- lelen Programmes zusammen aus:
  44. 44. 36 2 Konzepte paralleler Programmierung • der Zeit f¨ r die Durchf¨ hrung von Berechnungen durch u u die Prozessorkerne, • der Zeit f¨ r die Synchronisation beim Zugriff auf ge- u meinsame Daten, • den Wartezeiten, die z.B. wegen ungleicher Verteilung der Last oder an Synchronisationspunkten entstehen. Kosten: Die Kosten eines parallelen Programmes, h¨ufig a auch Arbeit oder Prozessor-Zeit-Produkt genannt, be- r¨ cksichtigen die Zeit, die alle an der Ausf¨ hrung beteilig- u u ten Prozessoren insgesamt zur Abarbeitung des Program- mes verwenden. Die Kosten Cp (n) eines parallelen Pro- gramms sind definiert als Cp (n) = Tp (n) · p und sind damit ein Maß f¨ r die von allen Prozessoren u durchgef¨ hrte Arbeit. Ein paralleles Programm heißt kos- u tenoptimal, wenn Cp (n) = T ∗ (n) gilt, d.h. wenn insge- samt genauso viele Operationen ausgef¨ hrt werden wie vom u schnellsten sequentiellen Verfahren, das Laufzeit T ∗ (n) hat. Speedup: Zur Laufzeitanalyse paralleler Programme ist insbesondere ein Vergleich mit einer sequentiellen Im- plementierung von Interesse, um den Nutzen des Einsatzes der Parallelverarbeitung absch¨tzen zu k¨nnen. F¨ r einen a o u solchen Vergleich wird oft der Speedup-Begriff als Maß f¨ r u den relativen Geschwindigkeitsgewinn herangezogen. Der Speedup Sp (n) eines parallelen Programmes mit Laufzeit Tp (n) ist definiert als T ∗ (n) Sp (n) = , Tp (n) wobei p die Anzahl der Prozessoren zur L¨sung des Pro- o blems der Gr¨ße n bezeichnet. Der Speedup einer paral- o lelen Implementierung gibt also den relativen Geschwin- digkeitsvorteil an, der gegen¨ ber der besten sequentiellen u
  45. 45. 2.4 Parallele Leistungsmaße 37 Implementierung durch den Einsatz von Parallelverarbei- tung auf p Prozessoren entsteht. Theoretisch gilt immer Sp (n) ≤ p. Durch Cacheeffekte kann in der Praxis auch der Fall Sp (n) > p (superlinearer Speedup) auftreten. Effizienz: Alternativ zum Speedup kann der Begriff der Effizienz eines parallelen Programmes benutzt werden, der ein Maß f¨ r den Anteil der Laufzeit ist, den ein Prozessor u f¨ r Berechnungen ben¨tigt, die auch im sequentiellen Pro- u o gramm vorhanden sind. Die Effizienz Ep (n) eines parallelen Programms ist definiert als T ∗ (n) T ∗ (n) Sp (n) Ep (n) = = = Cp (n) p p · Tp (n) wobei T ∗ (n) die Laufzeit des besten sequentiellen Algorith- mus und Tp (n) die parallele Laufzeit ist. Liegt kein super- linearer Speedup vor, gilt Ep (n) ≤ 1. Der ideale Speedup Sp (n) = p entspricht einer Effizienz Ep (n) = 1. Amdahlsches Gesetz: Die m¨gliche Verringerung von o Laufzeiten durch eine Parallelisierung sind oft begrenzt. So stellt etwa die Anzahl der Prozessoren die theoretisch obe- re Schranke des Speedups dar. Weitere Begrenzungen lie- gen im zu parallelisierenden Algorithmus selber begr¨ ndet, u der neben parallelisierbaren Anteilen auch durch Daten- abh¨ngigkeiten bedingte, inh¨rent sequentielle Anteile ent- a a halten kann. Der Effekt von Programmteilen, die sequentiell ausgef¨ hrt werden m¨ ssen, auf den erreichbaren Speedup u u wird durch das Amdahlsche Gesetz quantitativ erfasst [6]: Wenn bei einer parallelen Implementierung ein (kon- stanter) Bruchteil f (0 ≤ f ≤ 1) sequentiell ausgef¨ hrt u werden muss, setzt sich die Laufzeit der parallelen Imple- mentierung aus der Laufzeit f · T ∗ (n) des sequentiellen Teils und der Laufzeit des parallelen Teils, die mindestens (1 − f )/p · T ∗ (n) betr¨gt, zusammen. F¨ r den erreichbaren a u
  46. 46. 38 2 Konzepte paralleler Programmierung Speedup gilt damit T ∗ (n) 1 1 Sp (n) = ≤. = ∗ (n) + 1−f T ∗ (n) 1−f f f ·T f+ p p Bei dieser Berechnung wird der beste sequentielle Al- gorithmus verwendet und es wurde angenommen, dass sich der parallel ausf¨ hrbare Teil perfekt parallelisieren l¨sst. u a Durch ein einfaches Beispiel sieht man, dass nicht paral- lelisierbare Berechnungsteile einen großen Einfluss auf den erreichbaren Speedup haben: Wenn 20% eines Programmes sequentiell abgearbeitet werden m¨ ssen, betr¨gt nach Aus- u a sage des Amdahlschen Gesetzes der maximal erreichbare Speedup 5, egal wie viele Prozessoren eingesetzt werden. Nicht parallelisierbare Teile m¨ ssen insbesondere bei einer u großen Anzahl von Prozessoren besonders beachtet werden. Skalierbarkeit: Das Verhalten der Leistung eines par- allelen Programmes bei steigender Prozessoranzahl wird durch die Skalierbarkeit erfasst. Die Skalierbarkeit eines parallelen Programmes auf einem gegebenen Parallelrech- ner ist ein Maß f¨ r die Eigenschaft, einen Leistungsgewinn u proportional zur Anzahl p der verwendeten Prozessoren zu erreichen. Der Begriff der Skalierbarkeit wird in unter- schiedlicher Weise pr¨zisiert, z.B. durch Einbeziehung der a Problemgr¨ße n. Eine h¨ufig beobachtete Eigenschaft par- o a alleler Algorithmen ist es, dass f¨ r festes n und steigendes u p eine S¨ttigung des Speedups eintritt, dass aber f¨ r fes- a u tes p und steigende Problemgr¨ße n ein h¨herer Speedup o o erzielt wird. In diesem Sinne bedeutet Skalierbarkeit, dass die Effizienz eines parallelen Programmes bei gleichzeiti- gem Ansteigen von Prozessoranzahl p und Problemgr¨ße n o konstant bleibt.
  47. 47. 3 Thread-Programmierung Die Programmierung von Multicore-Prozessoren ist eng mit der parallelen Programmierung eines gemeinsamen Adress- raumes und der Thread-Programmierung verbunden. Meh- rere Berechnungsstr¨me desselben Programms k¨nnen par- o o allel zueinander bearbeitet werden und greifen dabei auf Variablen des gemeinsamen Speichers zu. Diese Berech- nungsstr¨me werden als Threads bezeichnet. Die Pro- o grammierung mit Threads ist ein seit vielen Jahren bekann- tes Programmierkonzept [9] und kann vom Softwareent- wickler durch verschiedene Programmierumgebungen oder -bibliotheken wie Pthreads, Java-Threads, OpenMP oder Win32 f¨ r Multithreading-Programme genutzt werden. u 3.1 Threads und Prozesse Die Abarbeitung von Threads h¨ngt eng mit der Abar- a beitung von Prozessen zusammen, so dass beide zun¨chst a nochmal genauer definiert und voneinander abgegrenzt wer- den.
  48. 48. 40 3 Thread-Programmierung Prozesse Ein Prozess ist ein sich in Ausf¨ hrung befindendes Pro- u gramm und umfasst neben dem ausf¨ hrbaren Programmco- u de alle Informationen, die zur Ausf¨ hrung des Programms u erforderlich sind. Dazu geh¨ren die Daten des Programms o auf dem Laufzeitstack oder Heap, die zum Ausf¨ hrungszeit- u punkt aktuellen Registerinhalte und der aktuelle Wert des Programmz¨hlers, der die n¨chste auszuf¨ hrende Instruk- a a u tion des Prozesses angibt. Jeder Prozess hat also seinen eigenen Adressraum. Alle diese Informationen ¨ndern sich a w¨hrend der Ausf¨ hrung des Prozesses dynamisch. Wird a u die Rechenressource einem anderen Prozess zugeordnet, so muss der Zustand des suspendierten Prozesses gespeichert werden, damit die Ausf¨ hrung dieses Prozesses zu einem u sp¨teren Zeitpunkt mit genau diesem Zustand fortgesetzt a werden kann. Dies wird als Kontextwechsel bezeichnet und ist je nach Hardwareunterst¨ tzung relativ aufwendig u [54]. Prozesse werden bei Multitasking im Zeitscheibenver- fahren von der Rechenressource abgearbeitet; es handelt sich also um Nebenl¨ufigkeit und keine Gleichzeitigkeit. Bei a Multiprozessor-Systemen ist eine tats¨chliche Parallelit¨t a a m¨glich. o Beim Erzeugen eines Prozesses muss dieser die zu sei- ner Ausf¨ hrung erforderlichen Daten erhalten. Im UNIX- u Betriebssystem kann ein Prozess P1 mit Hilfe einer fork- Anweisung einen neuen Prozess P2 erzeugen. Der neue Kindprozess P2 ist eine identische Kopie des Elternpro- zesses P1 zum Zeitpunkt des fork-Aufrufes. Dies bedeu- tet, dass der Kindprozess auf einer Kopie des Adressrau- mes des Elternprozesses arbeitet und das gleiche Programm wie der Elternprozess ausf¨ hrt, und zwar ab der der fork- u Anweisung folgenden Anweisung. Der Kindprozess hat je- doch eine eigene Prozessnummer und kann in Abh¨ngigkeit a
  49. 49. 3.1 Threads und Prozesse 41 von dieser Prozessnummer andere Anweisungen als der El- ternprozess ausf¨ hren, vgl. [46]. Da jeder Prozess einen ei- u genen Adressraum hat, ist die Erzeugung und Verwaltung von Prozessen je nach Gr¨ße des Adressraumes relativ zeit- o aufwendig. Weiter kann bei h¨ufiger Kommunikation der a Austausch von Daten (¨ ber Sockets) einen nicht unerheb- u lichen Anteil der Ausf¨ hrungszeit ausmachen. u Threads Das Threadmodell ist eine Erweiterung des Prozessmodells. Jeder Prozess besteht anstatt nur aus einem aus mehreren unabh¨ngigen Berechnungsstr¨men, die w¨hrend der Ab- a o a arbeitung des Prozesses durch ein Schedulingverfahren der Rechenressource zugeteilt werden. Die Berechnungsstr¨me o eines Prozesses werden als Threads bezeichnet. Das Wort Thread wurde gew¨hlt, um anzudeuten, dass eine zusam- a menh¨ngende, evtl. sehr lange Folge von Instruktionen ab- a gearbeitet wird. Ein wesentliches Merkmal von Threads besteht dar- in, dass die verschiedenen Threads eines Prozesses sich den Adressraum des Prozesses teilen, also einen gemein- samen Adressraum haben. Wenn ein Thread einen Wert im Adressraum ablegt, kann daher ein anderer Thread des glei- chen Prozesses diesen unmittelbar darauf lesen. Damit ist der Informationsaustausch zwischen Threads im Vergleich zur Kommunikation zwischen Prozessen uber Sockets sehr ¨ schnell. Da die Threads eines Prozesses sich einen Adress- raum teilen, braucht auch die Erzeugung von Threads we- sentlich weniger Zeit als die Erzeugung von Prozessen. Das Kopieren des Adressraumes, das z.B. in UNIX beim Er- zeugen von Prozessen mit einer fork-Anweisung notwendig ist, entf¨llt. Das Arbeiten mit mehreren Threads innerhalb a eines Prozesses ist somit wesentlich flexibler als das Arbei-
  50. 50. 42 3 Thread-Programmierung ten mit kooperierenden Prozessen, bietet aber die gleichen Vorteile. Insbesondere ist es m¨glich, die Threads eines Pro- o zesses auf verschiedenen Prozessoren oder Prozessorkernen parallel auszuf¨ hren. u Threads k¨nnen auf Benutzerebene als Benutzer-Thre- o ads oder auf Betriebssystemebene als Betriebssystem- Threads implementiert werden. Threads auf Benutzerebe- ne werden durch eine Thread-Bibliothek ohne Beteiligung des Betriebssystems verwaltet. Ein Wechsel des ausgef¨ hr- u ten Threads kann damit ohne Beteiligung des Betriebssys- tems erfolgen und ist daher in der Regel wesentlich schneller als der Wechsel bei Betriebssystem-Threads. Bibliotheks− BP Betriebssystem− T Scheduler Scheduler T BP T P BP T P BP Prozess 1 P BP Bibliotheks− T P BP Scheduler T Prozessoren BP T Prozess n Betriebssystem− Prozesse N:1-Abbildung – Thread-Verwaltung oh- Abbildung 3.1. ne Betriebssystem-Threads. Der Scheduler der Thread-Bibliothek w¨hlt den auszuf¨hrenden Thread T des Benutzerprozesses aus. a u Jedem Benutzerprozess ist ein Betriebssystemprozss BP zugeord- net. Der Betriebssystem-Scheduler w¨hlt die zu einem bestimmten a Zeitpunkt auszuf¨hrenden Betriebssystemprozesse aus und bildet u diese auf die Prozessoren P ab.
  51. 51. 3.1 Threads und Prozesse 43 Der Nachteil von Threads auf Benutzerebene liegt darin, dass das Betriebssystem keine Kenntnis von den Threads hat und nur gesamte Prozesse verwaltet. Wenn ein Thread eines Prozesses das Betriebssystem aufruft, um z.B. eine I/O-Operation durchzuf¨ hren, wird der CPU-Scheduler des u Betriebssystems den gesamten Prozess suspendieren und die Rechenressource einem anderen Prozess zuteilen, da das Betriebssystem nicht weiß, dass innerhalb des Prozesses zu einem anderen Thread umgeschaltet werden kann. Dies gilt f¨ r Betriebssystem-Threads nicht, da das Betriebssystem u die Threads direkt verwaltet. BT Betriebssystem− T Scheduler T BT T P BT T P BT Prozess 1 P BT P T BT T BT Prozessoren T Betriebssystem− Prozess n Threads Abbildung 3.2. 1:1-Abbildung – Thread-Verwaltung mit Betriebssystem-Threads. Jeder Benutzer-Thread T wird eindeutig einem Betriebssystem-Thread BT zugeordnet.
  52. 52. 44 3 Thread-Programmierung Bibliotheks− BT Betriebssystem− T Scheduler Scheduler T BT T P BT T P BT Prozess 1 P BT P T BT T Prozessoren BT T Bibliotheks− Scheduler Prozess n Betriebssystem− Threads Abbildung 3.3. N:M-Abbildung – Thread-Verwaltung mit Betriebssystem-Threads und zweistufigem Scheduling. Benutzer- Threads T verschiedener Prozesse werden einer Menge von Betriebssystem-Threads BT zugeordnet (N:M-Abbildung). Ausf¨hrungsmodelle f¨r Threads u u Wird eine Thread-Verwaltung durch das Betriebssystem nicht unterst¨ tzt, so ist die Thread-Bibliothek f¨ r das Sche- u u duling der Threads verantwortlich. Alle Benutzer-Threads eines Prozesses werden vom Bibliotheks-Scheduler auf einen Betriebssystem-Prozess abgebildet, was N:1-Abbildung genannt wird, siehe Abb. 3.1. Stellt das Betriebssystem eine Thread-Verwaltung zur Verf¨ gung, so gibt es f¨ r die Ab- u u bildung von Benutzer-Threads auf Betriebssystem-Threads zwei M¨glichkeiten: Die erste ist die 1:1-Abbildung, die o f¨ r jeden Benutzer-Thread einen Betriebssystem-Thread u erzeugt, siehe Abb. 3.2. Der Betriebssystem-Scheduler w¨hlta den jeweils auszuf¨ hrenden Betriebssystem-Thread aus und u verwaltet bei Mehr-Prozessor-Systemen die Ausf¨ hrung der u Betriebssystem-Threads auf den verschiedenen Prozesso-
  53. 53. 3.1 Threads und Prozesse 45 ren. Die zweite M¨glichkeit ist die N:M-Abbildung, die o ein zweistufiges Schedulingverfahren anwendet, siehe Abb. 3.3. Der Scheduler der Thread-Bibliothek ordnet die ver- schiedenen Threads der verschiedenen Prozesse einer vor- gegebenen Menge von Betriebssystem-Threads zu, wobei ein Benutzer-Thread zu verschiedenen Zeitpunkten auf ver- schiedene Betriebssystem-Threads abgebildet werden kann. Zust¨nde eines Threads a Ob ein Thread gerade von einem Prozessor oder Prozes- sorkern abgearbeitet wird, h¨ngt nicht nur vom Scheduler, a sondern auch von seinem Zustand ab. Threads k¨nnen sich o in verschiedenen Zust¨nden befinden: a • neu erzeugt beendet neu • lauff¨hig a  

×