SMiLE. DSM Softwarearchitekturen und Programmierumgebungen. Martin Schulz

Transkript

1 SMiLE DSM Softwarearchitekturen und Programmierumgebungen Martin Schulz Lehrstuhl für Rechnertechnik und Rechnerorganisation (LRR) Technische Universität München Vortrag im Rahmen der Vorlesung Cluster- und Gridcomputing Technische Universität Chemnitz, 26. Juni 2001

2 Parallele Programmierparadigmen Basisprinzipien der parallelen Programmierung Wie wird Parallelität spezifiziert? Wie werden Daten ausgetauscht? Die 2 wichtigsten Ansätze Nachrichtenaustausch (Message Passing) Gemeinsamer Speicher (Shared Memory) Beide Ansätze haben viele Anhänger Streit um den besseren Ansatz Fazit: Beides sollten unterstützt werden! 2

3 Paradigma vs. Architektur UMA/SMP NORMA/Cluster Bus CPU 1 CPU 2 Cache Speicher Cache... I/O Eigenschaften Globaler Speicherzugriff + Kommunikationsleistung Paradigmen Nativ: Shared Memory MP Implement. einfach CPU 1 Cache Speicher I/O CPU 2 Cache Speicher Eigenschaften Standard-Netzwerk + Skalierbarkeit Paradigmen Nativ: Message Passing Shmem??? I/O... Netzwerk 3

4 Distributed Shared Memory Shared Memory für NORMA Systeme Software Emulation eines globalen Speichers Implementierung auf Basis von Nachrichten Fragestellungen Transparenz der Speicherabstraktion Umsetzung in einzelne Nachrichten Speicherkonsistenz Effizienz des Gesamtsystems Unterstützte Shared Memory APIs Geeignete Anwendungen 4

5 Gliederung Distributed Shared Memory Klassische Implementierungstechniken Speicherkonsistenz Alternative Implementierungen Hardware Unterstützung Shared Memory für SCI/NUMA Cluster HAMSTER: Flexible Shared Memory Umgebung Anwendungen: Nuklearmed. Bildverarb. Zusammenfassung 5

6 SMiLE Klassische DSM Konzepte Seitenbasiertes DSM Prinzip und Protokolle

7 Distributed Shared Memory Globaler Virtueller Speicher Physikalisch verteilter Speicher Transparent für Anwendungen Unabhängig von zugrundeliegender Architektur Klassischer Ansatz: Software-DSM Segmentierung auf Seitenbasis Zugriffserkennung durch virtuellem Speicher Datentransport durch Nachrichten Erstes System: Kai Li s IVY (1986) Integrated shared Virtual memory at Yale 7

8 DSM Prinzip Knoten A Knoten B Prozeß auf A Prozeß auf B Virtueller AdreßraumGlobaler auf A Virtueller Adreßraum Virtueller Adreßraum auf B VMM Seiten Manager Phys. Speicher VMM 3 Seiten Manager Phys. Speicher 3 6 Netzwerk 8

9 DSM Protokolle Keine Migration Migration Keine Replikation Zentrales Schema Migrations Schema Replikation Volle Replikation Lese Replikation 9

10 DSM Protokolle Keine Migration Migration Keine Replikation Zentrales Schema Migrations Schema Replikation Volle Replikation Lese Replikation Zentrales Schema Alle Daten in einem zentralen Server Lese-Zugriff: Server schickt Daten Schreib-Zugriff: Server führt Schreiben aus + Ack. - Server kann Flaschenhals werden 10

11 DSM Protokolle Keine Migration Migration Keine Replikation Zentrales Schema Migrations Schema Replikation Volle Replikation Lese Replikation Migrations Schema Daten werden bei Zugriff verschoben Single Reader / Single Writer Jede Seite nur einmal im System - Gefahr: Seitenflattern 11

12 DSM Protokolle Keine Migration Migration Keine Replikation Zentrales Schema Migrations Schema Replikation Volle Replikation Lese Replikation Lese Replikation Erweiterung des Migrations Schemas durch Kopien Multiple Reader / Single Writer Invalidierung von Lesekopien bei Schreibzugriff Liste aller Kopien pro Seite nötig 12

13 DSM Protokolle Keine Migration Migration Keine Replikation Zentrales Schema Migrations Schema Replikation Volle Replikation Lese Replikation Volle Replikation Erweiterung des Lese Replikationsschemas Multiple Reader / Multiple Writer Kommunikation von Write-Updates Oft: Nutzung von Seiten- Diffs 13

14 Weitere Systemparameter Seitenlokalisierung Feste Zuordnungen (Home-based DSM) Broadcast Seitenmanager (zentral oder verteilt) Seitenersetzungsverfahren Ähnlich zu VMM Verfahren im BS Flags clean / dirty mitführen Löschen von Seiten, von denen Kopien existieren Granularität Bei diesem Ansatz mindestens Seitengröße 14

15 Beispiel: TreadMarks TM Eines der bekanntesten DSM Systeme Entwickelt an der Rice University, Texas, USA Kommerziell verfügbar TreadMarks Protokoll Volle Replikation / verteilter Seitenmanager Kommunikation via UDP/IP Einfach zu verwenden Kleine, einfache API Statische Prozeß-/Thread-Struktur 15

16 TreadMarks API Globale Variablen Tmk_proc_id Tmk_nprocs Initialisierung & Ende Tmk_startup Tmk_exit Shared Memory Verwaltung Tmk_alloc Tmk_free Synchronisation Tmk_barrier Tmk_lock_acquire Tmk_lock_release Verteilung lokaler Information Tmk_distribute Statistikfunktionalität Implizite Leistungsüberwachung 16

17 DSM Prinzipien und Probleme Bereitstellung eines Globalen Speichers Transparent für Anwendungen Anwendbar auch in NORMA Systemen Probleme Overhead durch Speicherverwaltung Granularität False Sharing Kommunikation von Updates (Latenz) Optimierungsmöglichkeiten? Verzögerung / Zusammenfassung von Updates? 17

18 SMiLE Abgeschwächte Speicherkonsistenz Ziel: Reduktion der Kommunikation Frage: Programmierbarkeit?

19 Speicherkonsistenz Verzögerung von Updates wünschenswert Weg von strikter Konsistenz Einfluß auf das Programmiermodell Konsistenzmodell: Vertrag System-Anwendung Charakterisierung des Speicherverhaltens Wann werden Updates garantiert sichtbar? Anpassung der Anwendung bzgl. dieser Garantie Beschrieben durch Regelmenge Weitere Informationen Hwang, Advanced Computer Architecture 19

20 Abgeschwächte Konsistenz Weak Consistency (WC) Aufteilung aller Zugriffe Reguläre Synchronisierend Sync. Zugriffe Globale Zugriffe Reguläre Zugriffe Synchronisationspunkte / Speicherbarrieren Danach Speicher garantiert konsistent Software und Hardware Implementierungen Multiprozessorsysteme (z.b. SPARC) Viele Threadlibraries (z.b. POSIX) 20

21 Release Konsistenz (RC) Unterteilung der Sync. Zugriffe RC Regeln Vor Regulärem Zugriff Alle Acquire abgeschlossen Vor Release Alle Reg. Zugriffe abgeschlossen Sync. Zugriffe strikt geordnet Sync. Zugriffe Acquire Globale Zugriffe Reguläre Zugriffe Release Explizite Signalisierung im Programm Daten fertig, sinnvoll für andere Release Datenupdate nötige Acquire 21

22 Programmierbarkeit Direkter Einfluß auf Anwendungen Explizites Konsistenzmanagement Kombination mit Synchronisationskonstrukte Acquire & Lock Release & Unlock Acq.+Rel. & Barriere Natürliche Erweiterung der Lock Semantik Lock/Acquire Unlock/Release Lock/Acquire Unlock/Release Barriere/Acquire & Release Minimaler Einfluß Die meisten guten Shared Memory Codes laufen 22

23 RC Implementierungsvarianten Eager RC (ERC) Kommunikation sofort bei Release Versand von Updates ohne Anforderung Lazy RC (LRC) Anforderung der Updates erst bei Acquire Verhinderung überflüssiger Kommunikation Erhöhter Verwaltungsaufwand (Update-Speicherung) Home-based LRC (HLRC) Feste Heimatknoten für jede Seite Geringerer Verwaltungsaufwand 23

24 Weitere Konsistenzmodelle Weitere Abschwächung über RC hinaus Acquire/Release haben globale Wirkung Einschränkung zur Optimierung Entry Cons. (EC) - Midway Angabe des Adressbereiches - Aufwendig für Programmierer Acquire(a1,a2) a1 a2 Virt. Adressraum LV3 LV1 LV2 Virt. Adressraum Scope Cons. (ScC) - Brazos Implizite Consistency Scopes Unterscheidung durch mehrere Lockvariablen 24

25 Konsistenz aus DSM Sicht Abgeschwächte Konsistenz nötig Nicht jedes Update sofort verschicken Optimierung der Kommunikation Programmierbarkeit Kombination mit Locks/Barrieren Die meisten Codes laufen unverändert Release Konsistenz am häufigsten LRC: TreadMarks, Shasta ERC: Quarks HLRC: HLRC aus Rutgers Mischsysteme: Midway, CVM 25

26 SMiLE Alternative/Optimierte DSM Systeme Neue Methoden für DSM Systeme Nutzung von Spezialnetzwerken

27 Alternativen zur Seitenbasierung Nachteile von seitenbasierten Systemen Große Granularität Granularität nicht an Anwendung angepaßt Änderungen Abfangen von Zugriffen Speicherstatusmanagement Optionen Codeinstrumentierung Feinere Granularität OO-basierte Systeme Angepaßte Granularität 27

28 Ansatz 1: Instrumentierung Direkte Erkennung jedes globalen Zugriffes Einfügen von Abfragen vor globalen Zugriffen Cache ähnliche Steuerung Bei Cache Miss laden entfernter Daten Wichtig: Beibehaltung der Transparenz Automatisches Einfügen der Instrumentierung Code Transformation Beispiele Shasta (reine Instrumentierung) Midway (Kombination mit Pagefaults) 28

29 Beispiel int i,j; float a,b; Prüfe glob[i,j] If Cache Miss Hole Daten a = glob[i,j]; Lokaler Speicher a = a * b; Lokale Operation glob2[j] = a; Vermerke globalen Speicherzugriff DSM System Cache Protokoll Komm. Schicht Cache Protokoll Basis: Speicherblöcke Beliebige Granularität CC-Verzeichnisse Kombination mit LRC Verzögerung von Updates Optimierungen Compiler Nachrichtenaggregation Overhead bei Shasta < 20% (SPLASH) 29

30 Ansatz 2: Objekt-basierte Systeme Objekte als Granularität Implizite Anpassung an die Anwendung Minimierung von False-Sharing Umsetzung Zugriff über Objektreferenzen Keine Mechanismen zur Zugriffskontrolle nötig Konsistenz auf Objektbasis Implementierung Eigene Compiler / Präprozessor Beispiele: ORCA, ICC++, CC++ 30

31 Chancen und Probleme Flexiblere Systeme Migration von Objekten möglich Alle Zugriffe nur via Referenzen Task-Migration einfacher möglich Methodenausführung am Objektort Größere Codeänderungen nötig Kein reiner Shared Memory Code Objekte müssen explizit benannt werden Fließender Übergang zu DOC Systemen Forschung in Richtung Grids 31

32 Ansatz 3: Netzwerk als Flaschenhals Netzwerk oft der begrenzende Faktor Hauptproblem: Latenz Verzögert Update Zustellungen Kurze und Häufige Nachrichten Protokolle wie TCP/UDP-IP ungeeignet Weiterentwicklung der Netztechnik System Area Networks (SANs) Kommunikation auf Benutzerebene Z.T. weitere Hardware für Shared Memory Wie kann man dies für DSM Systeme nutzen? 32

33 System Area Networks (SANs) Neue Verbindungstechnologien Hohe Bandbreite Geringe Latenz Im PC Bereich Meist als PCI Adapter Beispiele SCI / Scalable Coherent Interface Myrinet Nicht im Laden um die Ecke Relativ teuer 33

34 Kommunikation auf Benutzerebene Nur Setup via Kernel Kommunikation direkt Vorteile Kein BS Overhead Keine Protokolle Direkte HW Ausnutzung Typische Leistung (PCs) Latenzen < 10 µs Bandbreite > 80 MB/s (bis an die PCI Grenze) z.b. Sockets TCP/IP UDP/IP Stack Ethernet Treiber Anwendungen Setup Routinen 1x Setup NIC Treiber Hardware / NIC Betriebssystem Gerätetreiber Benutzerbibliothek Komm. 34

35 Einsatz für DSM Systeme Zwei Optionen Schnelle Kommunikation Direkter Einsatz von Hardwarefähigkeiten Schnelle Kommunikation Ersatz der Kommunikationsroutinen Keine prinzipiellen Änderungen Beispiele SCI: SVMlib, NOA, Madeleine, HPPC-SEA DVSM clan/hw-vi: HLRC Myrinet: Shrimp-2, Madeleine 35

36 Einsatz spezieller Hardware Direkter Einsatz spezieller HW Unterstützung Kleine Erweiterungen im Netzwerkadapter Beibehaltung der Skalierungseigenschaften SHRIMP: Automatic Update Idee: Weiterleitung lokaler Schreibzugriffe Basis: Home-based LRC Updates zum Heimatknoten propagieren CASHMERE: Nutzung von Memory Channel MC ermöglicht entfernte Schreibzugriffe Effiziente Synchronisation & Broadcasts 36

37 Alternativen & Optimierungen Feinere / Angepaßte Granularität Instrumentierung Objekt-basierte Systeme Direkter Einsatz von SANs Keine prinzipiellen Protokolländerungen Einsatz von speziellen HW Techniken Automatic Update in Shrimp Entferntes Schreiben in Cashmere Neue Protokollvarienten nötig 37

38 SMiLE Einen Schritt weiter: NUMA Non-Uniform Memory Architecture Entfernte Lese-/Schreibzugriffe

39 Nächster Schritt: HW-Lesezugriffe Bisher diskutierte Ansätze: Nur entfernte Schreibe/Update Zugriffe Laden von Daten weiterhin explizit DSM weiterhin durch komplexe Updateprotokolle Erweiterte Hardwareunterstützung Entfernte Lesezugriffe in Hardware Ergebnis: NUMA Systeme Ohne Cache Kohärenz im Gegensatz zu CC-NUMA Damit auch für preiswerte Cluster geeignet 39

40 NUMA Architekturen CPU Caches CC Inkons. Caches CPU Caches Systembus CC CPU Caches CPU Caches Systembus I/O Bridge Speicher I/O Bridge Speicher I/OPCI Netzwerk Bridge Adapter Speicher I/O Bridge Netzwerk Glob. Adr.: ID ID // Lokale Adr. NUMA Netzwerk Globaler Physikalischer Adreßraum = HW-DSM 40

41 Nutzung von NUMA Systemen Kommunikation auf Benutzerebene Standard Lese-/Schreibbefehle Sehr geringe Latenz & Hohe Bandbreite Gute Voraussetzung für HPC Vom Prinzip her einfach zu implementieren Kein aufwendiges CC-Protokoll Umsetzung auf Clusters Gutes Preis/Leistungsverhältnis Nutzung der Skalierbarkeit von Clustern Beispiel: Scalable Coherent Interface (SCI) 41

42 SCI = Scalable Coherent Interface IEEE Standard 1596 (seit 1992) Hervorgegangen aus der FutureBus+ Spezifikation Überwindung der Einschränkungen in Bussystemen Aber: Beibehaltung von Busdiensten Hierarchische Ringlets mit bis zu Knoten Packet basiert, split transaction Protokoll Zugriffe auf entfernten Speicher möglich Optionale HW Cache Kohärenz Synchronisations Operationen Anbindung an Hostsystem nicht standardisiert 42

43 SCI-basierte Systeme Verbindungsnetzwerk für CC-NUMA Nutzung des optionalen CC Protokolls Typischerweise eng gekoppelt NUMA-Liine (Data General), NUMA-Q (IBM) I/O Erweiterungen PCI-PCI Brücken Cluster Verbindsnetzwerk (lose Kopplung) PCI-SCI Brücken (von Dolphin ICS) Vergleichbar mit anderen SAN Technologien Aber: mit NUMA Fähigkeiten durch HW-DSM 43

44 Clustering mit SCI PCs mit PCI-SCI Adapter Globaler Adreßraum SCI Verbindungsnetzwerk Hardware DSM mit NUMA Charakteristik Unterstützung von entfernten Speicherzugriffen Globaler Adreßraum, umfaßt alle physikalische Speicher Keine Cache-Kohärenz Reine NUMA Architektur 44

45 Technische Realisierung SCI Ringlet Export Abb. Phys. SCI Adreßraum Export des Phys. Speichers Physikalischer SCI Adreßraum Abbildung in den virt. Speicher Von SCI in den PCI Adreßraum Von PCI in den Virt. Adreßraum Komm. auf Benutzerebene Lesen/Schreiben auf Abbildungen Hohe Komm.leistung Keine Protokolle Kein BS Einfluß Latency: < 2 µs Bandbreite: MB/s 45

46 Überblick: NUMA Systeme Globaler physikalischer Adreßraum Zugriff auf alle Speicher (HW-DSM) Verschiedene Latenzen je nach Zugriff Ohne (komplexe) Cache Köherenz Implementierung auf Clustern möglich Letzter Schritt vor CC-NUMA Systemen Beispiel: Scalable Coherent Interface Fehlend: Software Infrastruktur Nutzung von NUMA in Anwendungen Fokus des SMiLE Projektes am LRR 46

47 SMiLE Das SMiLE Projekt am LRR Aufbau und Nutzung von NUMA Clustern Direkte Nutzung für DSM Systeme

48 SMiLE Shared Memory in a LAN-like Environment SCI als Basistechnologie Ausnutzung der speziellen Eigenschaften von SCI Hardware Entwicklungen PCI-SCI Adapter Hardware Monitor zur Überwachung von Zugriffen Erweiterbarkeit durch FPGA Einsatz Software Entwicklungen Umfassende Multi-Paradigma Infrastruktur 48

49 SMiLE Softwareschichten NT Prot. Stack NDIS Treiber SISAL auf MuSE Zielanwendungen / Benchmarksuites SISCI PVM AM 2.0 SS-lib CML SCI-Nachrichtendienste SCI Treiber & SISCI API SPMD artiges Modell TreadMarks kompatible API HAMSTER Dienste / Module SCI-VM SCI-Hardware: SMiLE & Dolphin Adapter, HW-Monitor Obere SMiLE Schichten Untere SMiLE Schichten Benutzer/Kernel Grenze 49

50 SMiLE Softwareschichten Unterstützung mehrere Parallelen Paradigmen Message Passing Effiziente NUMA Implementierung Mehrere APIs: Sockets, AM, CML, PVM Shared Memory Hybrid DSM Umgebung / Multi-API fähig Experimente: Exoten Datenfluß und Multithreading Visuelle Programmierung 50

51 Shared Memory in SMiLE HAMSTER Hybrid DSM SISALbased Adaptive and auf Modular NT MuSE Prot. Shared Stack Memory architecture Zielanwendungen / Benchmarksuites SISCI PVM AM 2.0 SS-lib CML SCI-Nachrichtendienste SPMD TreadMarks artiges kompatible Modell API HAMSTER Dienste / Module NDIS Treiber SCI Treiber & SISCI API SCI-VM Hybrid-DSM SCI-Hardware: SMiLE & Dolphin Adapter, HW-Monitor Obere SMiLE Schichten Untere SMiLE Schichten Benutzer/Kernel Grenze 51

52 Motivation für HAMSTER Nutzung der NUMA Eigenschaft für DSM Management Unterstützung (DSM aus Lund) Direkter Einsatz von NUMA (HAMSTER) Hybrid DSM System Setup & Management in Software Kommunikation in Hardware Kein Protokoll Overhead Optimale Systemausnutzung Vielfalt an Programmiermodellen HAMSTER als einheitliche Basis 52

53 Shared Memory Vielfalt Große Anzahl von Modellen, z.b. Thread Libraries (e.g. Win32, POSIX, Java,...) APIs von DSM Systemen Parallele Hochsprachen (z.b. HPF) Alle Modelle mit gleicher Basisfunktionalität Gemeinsamer Virtueller Adreßraum Explizite Synchronization Unterschiede zwischen Modellen Task Struktur (statisch / dynamisch) Konkrete Konstrukte (Locks, Barriers, Signals) Kleine Semantische API Unterschiede 53

54 Shared Memory Standardisierung Probleme durch diese Vielfalt Portierungsaufwand zwischen Platformen Keine einheitliche Anwendungsbasis Verringert die Akzeptanz Versuch einer Standard API hoffnungslos Existierende Anwendungen & Akzeptanz Es gibt Ansätze aber nur für UMA/SMPs HAMSTER bietet einheitliche Plattform Shared Memory Dienste in orthogonalen Modulen Basis für beliebige Programmiermodelle 54

55 HAMSTER Übersicht Clusterverw. Shared Memory Anwendung Shared Memory Programmiermodell Aktivitäts Dienste Einzelplatz BS Linux & WinNT Sync. Dienste Cluster aufgebaut aus Standard PC Komponenten Kons. Dienste SCI Treiber Speicher Dienste SCI-VM: Hybrid DSM für SCI Cluster VI-ähnl. Komm. durch dirketen direkten HW Zugriff Große Bandbreite von Programmiermodellen und Anwendungen NUMA Clusterarchitektur SCI / NUMA Netzwerk Basisdienste für Shared Memory Unterstützung 55

56 SCI/NUMA-basierte Cluster Einzelplatz BS Linux & WinNT Cluster aufgebaut aus Standard PC Komponenten SCI Treiber SCI / NUMA Netzwerk 56

57 SMiLE Hardwareplattform Cluster aus Standard SMP Knoten Prozessoren: Intel Xeon TM (450 MHz) Konkrete Konfiguration: 6 Dual SMP Knoten (12 Prozessoren) Je 512 MB Hauptspeicher (3 Gbyte insgesamt) Linux (kernel 2.2.x) oder Windows NT/2000 TM Scalable Coherent Interface (D320 Adapter) Spezielle Treibererweiterungen notwendig Konzept nicht nur an SCI gebunden Im Prinzip auf jede NUMA Architektur anwendbar 57

58 Das SMiLE Labor 58

59 Globale Speicherabstraktion Einzelplatz BS Linux & WinNT Cluster aufgebaut aus Standard PC Komponenten SCI-VM: Hybrid DSM für SCI Cluster SCI Treiber SCI / NUMA Netzwerk 59

60 Hybrid-DSM für NUMA Systeme Einsatz von HW-DSM nicht direkt möglich Basiert auf physikalischem Speicher Benötigt: Globaler virtueller Speicher Getrennte Betriebssysteminstanzen Keine clusterweite Resourcenverwaltung Software Komponente notwendig Aufbau einer globalen virt. Speicherabstraktion Abbildung auf globalen phys. Speicher Globale Prozeß- und Resourcenverwaltung Ergebnis: Hybrid-DSM System 60

61 SCI Virtual Memory (SCI-VM) SCI Virtual Memory Flexible globale virtuelle Speicherabstraktion Einziger prozeßweiter virtueller Speicher Volle Transparenz für den Benutzer Direkter Einsatz von HW-DSM Hybrid DSM System HW-DSM für implizite Kommunikation SW-DSM Komponente für Management Keine Protokoll gestützte Ausführung Im Gegensatz zu SW-DSM Systemen 61

62 SCI-VM Design Globale Prozeßabstraktion Team auf jedem Knoten als Threadumgebung Jedes Team muß den gleichen Virt. Speicher sehen Transparenter Zugriff auf den gesamten Speicher Lokale Zugriffe mittels MMU Abbildung Entfernte Zugriffe zusätzlich durch SCI Aufbau der Abbildungen durch SW Komponente Erweiterung des Virt. Speicher Managements Feingranulare Abbildungen (Seitenweise) Zugang zu internen Routinen 62

63 SCI-VM Abbildungsschema Team auf A Thread Thread Thread Globale Prozeßabstraktion mit SCI Virtual Memory Team auf B Thread Thread Thread Virtueller Adreßraum auf A Virtueller Adreßraum auf B PCI Adr. auf A 1 Phys. Speicher auf A 4 6 PCI Adr. auf B 46 Phys. Speicher auf B 1 Knoten A Physikalischer SCI Adreßraum Knoten B 63

64 Speicherkonsistenz Standardlösung für SCI Cluster Caches abschalten Nicht tragbar für Shared Memory Alternative: Hybrides Cache Management Caches anschalten (+ weitere Puffer) Explizites, anwendungsgetriebenes Cachemngt. Abgeschwächte Speicherkonsistenz In Kombination mit Synchronization Anpaßbar an Programmiermodell 64

65 Shared Memory Dienste Einzelplatz BS Linux & WinNT Sync. Dienste Cluster aufgebaut aus Standard PC Komponenten Kons. Dienste SCI Treiber Speicher Dienste SCI-VM: Hybrid DSM für SCI Cluster VI-ähnl. Komm. durch direkten HW Zugriff SCI / NUMA Netzwerk 65

66 Shared Memory Dienste Speicher Dienste Allokation von globalem Speicher Angabe von Datenverteilungen Konsistenz Dienste Kontrolle über Speicherkonsistenz Routinen um Puffer zu löschen & propagieren Synchronisations Dienste Standardmechanismen Locks & Barrieren Unterstützung für weitere Mechanismen Effiziente, hardware-nahe Implementierung 66

67 Aktivitäts und Cluster-Kontrolle Clusterverw. Aktivitäts Dienste Einzelplatz BS Linux & WinNT Sync. Dienste Cluster aufgebaut aus Standard PC Komponenten Kons. Dienste SCI Treiber Speicher Dienste SCI-VM: Hybrid DSM für SCI Cluster VI-ähnl. Komm. durch direkten HW Zugriff SCI / NUMA Netzwerk 67

68 Aktivitäts und Cluster-Kontrolle Aktivitäts Dienste An- und Abmeldung von lokalen Threads Aktivitätszähler Keine API zur Threadkontrolle Größtmögliche Flexibilität Clusterverwaltung Koordination der verteilten Teams Globale Resourcen-/Prozeßverwaltung Einfache ARPC-ähnliche Nachrichtenschnittstelle Saubere Prozeßterminierung 68

69 HAMSTER Programmiermodelle Clusterverw. Shared Memory Programmermodell Aktivitäts Dienste Einzelplatz BS Linux & WinNT Sync. Dienste Cluster aufgebaut aus Standard PC Komponenten Kons. Dienste SCI Treiber Speicher Dienste SCI-VM: Hybrid DSM für SCI Cluster VI-ähnl. Komm. durch direkten HW Zugriff SCI / NUMA Netzwerk 69

70 Implementierung von Modellen Basis: HAMSTER Interface Sammlung aller Dienste Konkrete Fragestellungen bei Implementierung Speicherkonsistenz Aktivitätsstruktur Initialisierung Geringe Implementierungskomplixität Spezialisierung von HAMSTER Diensten Nur wenige Routine von Grund auf zu schreiben 70

71 Konsistenz am Beispiel von RC Implementierung von Acquire und Release Release Operation Schreibpuffer propagieren Speicherbarriere Unlock ausführen Alle Schreibzugriffe vor Unlock abgeschlossen Acquire Operation Lock ausführen Lesepuffer invalidieren Alle Updates seit letztem Release sichtbar 71

72 Software vs. Hybrid DSM Aus Benutzersicht gleiches Verhalten Zugriffe zwischen Acquire und Release korrekt Systemverhalten bei SW Implementierung Kommunikation nur bei Acquire / Release Ansonsten nur lokale Operationen Systemverhalten bei Hybrid-DSM Kommunikation im laufenden Programm Zugriffe auf globalen Speicher via HW-DSM Acquire / Release sind nur Synchronisationspunkte Im Prinzip lokale Operationen 72

73 Bereits bestehende Prog. Modelle Programmiermodell SPMD SMP/SPMD ANL Makros TreadMarks TM API HLRC API * JiaJia API (Teilm.) * Vert. POSIX Threads Win32 Threads (Teilm.) Cray Shmem API # Zeilen # API Aufrufe * Based on SMP/SPMD Zeilen/ Aufruf Plattform NT & Lin. NT & Lin. NT & Lin. NT & Lin. NT & Lin. NT & Lin. Linux NT Linux 73

74 Last but not least : Anwendungen Clusterverw. Shared Memory Programmiermodell Aktivitäts Dienste Einzelplatz BS Linux & WinNT Cluster aufgebaut aus Standard PC Komponenten Shared Memory Anwendung Sync. Dienste Kons. Dienste SCI Treiber Speicher Dienste SCI-VM: Hybrid DSM für SCI Cluster VI-ähnl. Komm. durch direkten HW Zugriff SCI / NUMA Netzwerk 74

75 Ausführungsumgebung Verwendung von HAMSTER Voraussetzung: Erweiterte SCI und VMM Treiber Erstellung des Programmiermodelles Linken der Anwendung mit Modell und HAMSTER Start auf jedem Knoten mit gleichen Parametern Konfigurationsdatei Beschreibt Cluster SMP Beschreibung (für manche Modelle) ~/.hamster # Name ID ID CPUs smile1 4 2 smile

76 Kleinere Benchmarks Kernel (SPMD/Linux) Arraysumme: SU 2.8 on 4 CPUs MatMult: SU 2.7 on 4 CPUs SOR: SU 3.8 on 4 CPUs Gauss. Elimination: SU 3.5 on 4 CPUs SPLASH-2 Suite SOR (Win32 threads): LU (Win32 threads): WATER (HLRC): SU 6.6 on 8 CPUs SU 7.3 on 8 CPUs SU 7.4 on 12 CPUs 76

77 Rückblick: HAMSTER Shared Memory für NUMA Vervollständigt die SMiLE Infrastruktur Direkte Nutzung der NUMA Eigenschaften Einsatz eines Hybrid-DSM Systemes Umgang mit Vielfalt an Modellen Einheitliche Multi-API Plattform Hauptkomponenten SCI-VM: Hybrid DSM für SCI Module mit Shared Memory Diensten Programmiermodelle 77

78 SMiLE Anwendungen Medizinische Bildverarbeitung Positronen Emissions Tomography

79 DSM Anwendungen Bisher nur wenige große DSM Anwendungen Größtes Problem bei DSM Akzeptanz Oft nur kleinere Benchmarks / SPLASH Gründe: Forschung auf HPC ausgerichtet Dort meist MPI Codes Shared Memory Codes oft nicht HPC Industrielle Akzeptanz für Forschungsysteme gering Rühmliche Ausnahme TreadMarks / ILINK Software 79

80 HAMSTER & Anwendungserfahrung Medizinische Bildverarbeitung von PET Daten PET = Positron Emission Tomography Radioaktiv markierter Tracer (Positron-Emitter) Externe Erkennung der Strahlung aus dem Körper Funktionale Informationen Stoffwechsel, Rezeptordichte im Gehirn Anwendbar auf Gehirn, Brust, Leber, Tumore, Z.B. für: Demenz, Herzgefäße, Überwachung von Krebs, Therapieüberwachung Rechenintensive Verarbeitungsschritte 80

81 Das PET-Prinzip 81

82 PET Bild Rekonstruktion Umwandlung von PET Daten in 3D Volumen Hauptmethode: Gefilterte Rückprojektion + Kurze Rechenzeiten - Bildartefakte Moderne Methoden basierend auf Iteration Vergleich einer Schätzung mittels Vorwärtsprojektion Korrektur des Bildes & Iteration + Hervorragende Bildqualität - Hohe Rechenanforderungen Implementiert mittels SPMD Prog.modell 82

83 Ergebnisbild/-volumen 3D Volumen, Basis für: Volumenrenderingmethoden z.b. Raycasting Visualisierung durch Volumenschnitte Mittels Gefilterter Rückprojektion Mittels Ordered Subset Expectation Maximization (OSEM) 83

84 Datensatz für Experimente Rekonstruktion eines Vollkörpers 282 Schnitte, 130 MB Rohdaten Zielzeit < 5 Minuten 84

85 PET Rekonstruktion / Ergebnisse Speedup Proc/Node 2 Proc/Node 1 Proc/Node (no I/O) 2 Proc/Node (no I/O) Ideal Execution time (sec) I/O Barrier Weights Recon Number of CPUs Number of CPUs

86 Spectral Analyse von PET Daten Analyse von Bildserien Zeitliche Verteilung des Tracers im Körper Unter Verwendung des Tracer-Spektrums E.g.: Quantifizierung der Rezeptordichte im Gehirn Unabhängige Untersuchung für jede Voxelserie Ermöglicht eine feingranulare Verteilung Ergebnis sind ebenfalls Volumen 86

87 Implementierung & Datensatz Implementierung basierend auf TreadMarks TM Master/Slave Ansatz Portierung durch TreadMarks TM API Emulation Erneutes Linken der Anwendung mit HAMSTER Keine weiteren Optimierungen Datensatz für die Experimente: Menschliches Gehirn Sequenz von 25 Scans über 60 Minuten Je Scan: 47 Schnitte zu je 128x128 Pixels 87

88 Spektral Analyse / Ergebnisse Speedup Proc/Node 2 Proc/Node 1 Proc/Node (no I/O) 2 Proc/Node (no I/O) Ideal Execution time (sec) Barrier I/O Overhead Work Number of CPUs Number of CPUs

89 Rückblick: Anwendungen Hauptdefizit bei DSM Systemen Nur wenige größere Anwendungen Experimente mit Med. Bildverarbeitung PET Bildrekonstruktion PET Spektralanalyse Ergebnisse Gute Leistung / Speedup HAMSTER hat sich bewährt bei: Neuen Anwendungen ohne festes Modell Portierung alter Anwendungen 89

90 SMiLE Zusammenfassung & Ausblick DSM Softwarearchitekturen und Programmierumgebungen

91 Zusammenfassung (1) Vielfalt der parallelen Programmierparadigmen Wichtigsten: Message Passing & Shared Memory Unterstützung beider wünschenswert/nötig Möglichst breite Anwendungspalette (SW) DSM System schließen eine Lücke Shared Memory für NORMA Architekturen DSM = Distributed Shared Memory Globale, transparente Speicherabstraktion Basis für Shared Memory Programmierung Architekturunabhängig 91

92 Zusammenfassung (2) Reine Softwarevarianten Seitenbasiertes DSM DSM durch Codeinstrumentierung OO-basiertes DSM Hardware Unterstützung Entfernte Updates/Schreibzugriffe Vollwertiges NUMA / HW-DSM bzw. Hybrid-DSM Komplettes Architekturspektrum abgedeckt Von NORMA über NUMA bis zu SMPs Shared Memory auf allen Plattformen möglich 92

93 DSM Ein Erfolg? Viele Projekte / Systeme Leistungsdaten auf Benchmarks ansprechend Kommerziell kaum erfolgreich Kein Standardpaket auf Parallelrechner Kaum größere Anwendungen Grund: Falsche Anwendungsgebiet? Ziel oft technisch/wissenschaftliche Anwendungen Tests meist nur mit kleinen Benchmarks MPI dominant (erfahrene parallele Programmierer) SEHR leistungsorientiert 93

94 Ausblick Ausbau der bestehenden Systeme Single System Image Ausbau und Nachweis der Skalierbarkeit Neue Zielrichtungen Neue Anwendungsgebiete (CSCW, OLTP, Spiele,...) Werkzeuge für DSM/NUMA Systeme Transfer von DSM Konzepten in andere Gebiete DOC / Grid Computing Enger gekoppelte NUMA Systeme Globale Betriebssysteme für Cluster 94

95 SMiLE Zum Schluß... Danksagungen Weitere Informationen

96 Die SMiLE Gruppe Wolfgang Karl SMiLE Gruppenleitung Martin Schulz Shared Memory & Anwendungen Jürgen Jeitner & Robert Lindhof & SMiLE Hardware Monitor Georg Acher SMiLE SCI Adapter Michael Eberl & Carsten Trinitis Message Passing & Anwendungen Jie Tao Shared Memory Werkzeuge Kooperationen mit Klinik für Nuklearmedizin & ABB Heidelberg & AEA Technologies 96

97 Weiterführendes... Die DSM Seiten: DSM Tutorial: SMiLE & HAMSTER: