Cell Broadband Engine & CellSs: ein Programmiermodel für den Cell Prozessor

Größe: px

Ab Seite anzeigen:

Download "Cell Broadband Engine & CellSs: ein Programmiermodel für den Cell Prozessor"

Brigitte Amsel
vor 6 Jahren
Abrufe

1 Cell Broadband Engine & CellSs: ein Programmiermodel für den Cell Prozessor Hardware-Software-Co-Design Universität Erlangen-Nürnberg 1

2 Cell Broadband Engine Übersicht Motivation Architektur Merkmale Power Processor Element Synergistic Processor Element Element Interconnect Bus 2

Cell Broadband Engine Motivation: Architekturen skalieren nicht sehr effektiv mit der Frequenz Trend zu immer mehr Kernen und Threads pro Prozessor - Intel Gulftown 6

3 Cell Broadband Engine Motivation: Architekturen skalieren nicht sehr effektiv mit der Frequenz Trend zu immer mehr Kernen und Threads pro Prozessor - Intel Gulftown 6 Kerne mit je 2 Threads AMD Magny Cours mit bis zu 12 Kernen IBM Power7: bis zu 4 Kerne mit je 4 Threads Entwicklung von GPGPUs Heterogener Ansatz: CELL Broadband Engine : 3

4 Cell Architektur 4

5 Merkmale der Cell Architektur 2 Unterschiedliche Processor Elemente: Power Processor Element (PPE) mit L2 Cache Synergistic Processor Element (SPE) mit Local Store Über DMA kann jedes Element auf den gesamten Adressraum (Local Store der SPEs und Hauptspeicher) zugreifen SPEs werden vom PPE gesteuert Alle Elemente verbunden durch einen Ringbus 5

6 Power Processor Element (PPE) 64-bit RISC PowerPC Prozessor Kern (ähnlich Power5+ nach PowerPC ISA) 2-Fach Multithreaded L1 Cache 2x32KB L2 Cache 512KB VMX 3,2 Ghz + 6

7 Synergistic Processor Element (SPE) SPU 32-bit SIMD Local Store (256Kb SRAM) Synergistic Memory Flow Controller (SMF) DMA Engine (Direct Memory Access) Berechnung und Kommunikation gleichzeitig 7

8 Element Interconnect Bus (EIB) Ringbus der mit halber Prozessortaktrate läuft 4 Ringe die 16bit pro Takt Übertragen können Jeder Busteilnehmer verfügt über je 25,6GB/s für lesen und schreiben Der Gesamte Bus hat eine theoretische Bandbreite von 204,8GB/s 8

9 Referencen

10 Inhalt CellsS Einleitung Standard Cell Programmierung Struktur & Architektur Source-to-Source Compiler Laufzeit-Bibliothek Middleware Nutzung der lokalen Speicher Tracing Beispiele und Ergebnisse Ausblick & Zusammenfassung 10

11 Einleitung Hardware soll effizient genutzt werden Höheres Modell nötig, um parallele Abläufe besser nutzen zu können Modell nötig, um sequenziellen Programmcode zu parallelisieren Cell superscaler (CellSs): Einfach und Flexibel Anwender schreibt sequenziellen Code Framework nutzt Nebenläufigkeit im Programmablauf 11

12 Einleitung (Forts.) Verwendung: Über Annotations im Code werden Funktionen als parallel ausführbar deklariert Komponenten: Source-to-Source Compiler Laufzeit Bibliothek Locality aware task scheduling PPE & SPE Compiler Funktionsweise: Laufzeit Bibliothek erzeugt Graph aller Funktionen (Tasks) - Abhängigkeiten zwischen Tasks werden als Kanten repräsentiert Voneinander unabhängige Tasks werden parallel in den SPE's ausgeführt 12

13 Standard Cell Programmierung Grundlage: 'Linux-on-Cell' OS wird auf dem PPE ausgeführt SPU's werden nicht genutzt SPE's ohne OS Kein automatisches Speichermanagement Speichertransfers per DMA Quellcode für PPU und SPU getrennt Übersetzung mit verschiedenen Compilern nötig Threads müssen angelegt, parametrisiert und ausgeführt werden Umfangreiche API zur Kontrolle der SPU's 13

14 Standard Cell Programmierung (Forts.) Kommunikation via Mailbox System Alternative: IBM Octopiler Parallisierung zur Compilezeit Automatic SIMDization - Single Instruction Multiple Data z.b. Vektoraddition c = a + b 14

15 Struktur & Architektur Source to Source Compiler erzeugt zwei C-Files: Haupt-Programm: Wird im PPE ausgeführt Mit PPE-Compiler übersetzt Task-Programm Eigenständiges Programm, wird in jedem SPE ausgeführt Mit SPE-Compiler übersetzt SPE-Programm muss ins Binary für das PPE integriert werden Beim Programmstart werden die Speicher der SPE's mit dem ausführbaren SPE-Binary geladen 15

16 Struktur & Architektur 16

17 Source-to-Source Compiler Funktionen & Verwendung: Funktionen werden als Task spezifiziert, die in den SPE's ausgeführt werden: - 2. Richtung der Parameter muss festgelegt werden - #pragma css task input; output; input/output 3. Übergabe von Arrays und ihrer Länge möglich Beispiel: #pragma css task input(a{}, b{}, index_i, index_j) output(c{}) void array_op(float a[n], float b[n], float c[n], float c[n], int index_i, int index_j); main(){ array_op(a, B, C, i, j); } 17

18 Source-to-Source Compiler (Forts.) Modifikation des Code: Aufrufe zur Initialisierung der Laufzeit Bibliothek Aufrufe zur Registrierung der Tasks und zur Erzeugung des Task-Graphen Task-Aufrufe werden durch Aufrufe zur entsprechenden Execute( ) Funktion ersetzt Für jeden Task wird ein Adapter erzeugt, der vom SPEHauptprogramm aufgerufen wird void css_array_op_adapter(int *params, char *data_buffer) { array_op_adapter(data_buffer[params[0]], data_buffer[params[2]], data_buffer[params[4]],...); } 18

19 Übersicht Teil 3 Runtime Library Cell SS runtime library Was passiert während der Programmausführung? Der Task-Graph Locality-Aware Scheduling Policy Beispiel Datenübertragung an SPEs Performance 19

20 Cell Superscalar Runtime Library Zwei Binärdateien: Hauptprogramm für PPEs Task-Programm für SPEs (wartet auf Anfragen des Hauptprogramms) Aufruf einer annotierten Funktion im Hauptprogramm (execute-aufruf): Task als Knoten in Ablaufgraph einfügen Datenabhängigkeitsanalyse Parameter Renaming (entfernt Write-Abhängigkeiten) Keine Abhängigkeiten: Ausführungsfreigabe (ready list) 20

21 Der Task-Graph Gerichteter, azyklischer Graph (DAG) Knoten entsprechen Tasks, Kanten sind Datenabh. Wird nach jedem Execute und jeder Task-Fertigstellung aktualisiert Knoten ohne unberechnete Vorgängerknoten bilden die ready list Verwendung des DAG: Nummerierung nach Zeitpunkt des Eintreffens Pro Scheduling-Schritt Subgraph mit max. Tiefe 2 Partitionierung Für jede SPE wird ein Task ausgewählt (ready list, Pfadlänge, Alphabetische Reihenfolge) Nach Ende des Tasks: - Knoten aus Graph entfernen Zeuweisung eines neuen Tasks 21

22 Locality-Aware Scheduling Policy Datenabhängigkeiten bei der Partitionierung: Abhängige Tasks möglichst in der selben SPE ausführen Dadurch weniger Speicherzugriffe und Datenaustausch zwischen SPEs Partitionen werden an SPEs geschickt Partitionierung kann sich zur Laufzeit dynamisch ändern, workload (un)balance 22

23 Beispiel (1) 23

24 Beispiel (2) 24

25 Datenübertragung in SPEs Tasks werden als ganze Partition an SPE übermittelt Benachrichtigung zum Start eines Tasks: Mailbox-System, ein Eintrag für jede SPE Enthält Anfrage und Adresse des task control buffer (TCB) Untätige SPEs pollen ihre Mailbox, bis Nachricht vorliegt Datentransfer TCB enthält Speicheradressen der benötigten Parameter Laden per DMA Nach Task-Ende: Daten entweder im lokalen Speicher halten oder zurückschreiben (laut TCB) 25

26 Performance Vergleich des Speedup bei verschiedenen Anwendungen Blockweise Matrix-Multiplikation (matmul) Travelling Salesman Problem (TSP) Blockweise Cholesky-Faktorisierung (cholesky) 26

Ähnliche Dokumente

Cell Broadband Engine

Cell Broadband Engine 21.March 2006 Benjamin Keck Outline Why Cell?!? Application Areas Architectural Overview SPU Programming Model Programming on the PPE C/C++ Intrinsics The Cell Supercomputer on a