DSM-(Distributed-shared-memory)-Multiprozessoren
DSM-(Distributed-shared-memory)-Multiprozessoren besitzen einen, allen Prozessoren gemeinsamen Adressraum, einzelne Speichermodule sind jedoch auf die einzelnen Prozessoren verteilt
Voraussetzung: Der Zugriff eines Prozessors auf ein Datenwort in seinem lokalen Speicher geschieht schneller als der Zugriff auf ein Datenwort, das in einem der lokalen Speicher eines anderen Prozessors steht
→ Einordnung als NUMA
In der Regel werden zusätzliche Cache-Speicher (prozessorinterne Primär-Cache-Speicher und optionale Sekundär-Cache-Speicher) verwendet
Diese können die Cache-Kohärenz über sämtliche Cache-Speicher des gesamten Systems sichern (CC-NUMA und COMA), oder sie puffern Cache-Blöcke nur im Falle eines prozessorlokalen Speicherzugriffs (NCC-NUMA)
Drei Arten von DSMs
1) Der Zugriff geschieht in einer für das Maschinenprogramm transparenten Weise
2) durch explizite Befehle, die nur dem entfernten Speicherzugriff dienen
Die erste Variante ist bei CC-NUMAs üblich, die zweite Variante bei NCC-NUMA-Systemen
Im ersten Fall (CC-NUMA) muss Spezial-Hardware anhand der Adresse zwischen einem prozessorlokalen und einem entfernten Speicherzugriff unterscheiden
Im zweiten Fall (NCC-NUMA) wird der Maschinenbefehlssatz des Prozessors erweitert
3) Eine weitere Option sind Software DSM
Software DSM-Systeme
Illusion eines gemeinsamen Speichers auf Rechen-Clustern oder Multiprozessoren mit verteilten Speichern wird softwaremäßig hergestellt
Jeder Prozessor kann auf gemeinsame Daten mittels Schreib-/Leseoperationen so zugreifen, als ob ein gemeinsamer globaler Speicher zur Verfügung stünde
Synchronisation über Schloß-, Semaphor- oder Bedingungsvariablen
Notwendige Netzwerkkommunikation wird durch das DSM-System veranlasst (Implementierung häufig „on top of“ „message passing“)
Vorteile:
Entlastung des Programmierers
Leichte Portierbarkeit zu und von eng gekoppelten Multiprozessoren
Wichtig: Lokalität und Konsistenz der Daten
Größtes Problem: false sharing
Typischerweise: seitenbasierte Software DSM-System
Datenverwaltung in Software DSM-Systemen
Seitenbasierte Ansätze
Illusion des gemeinsamen Adressraums durch Nutzung der virtuellen Speicherverwaltung des Betriebssystems
Explizite Platzierung der Daten im DSM
Der gemeinsame virtuelle Speicher wird in Seiten mit unterschiedlicher Granularität (z.B. von 16 Byte bis zu 8 KByte) aufgeteilt
Völlig transparente Abwicklung der Netzwerktransfers
Objektbasierte Ansätze
Realisierung des DSM mit Hilfe von speziell ausgewiesenen Speicherbereichen
Explizite Bekanntgabe dieser Datenstrukturen
Weitere Aufteilung großer Blöcke in kleinere, linear aufeinander folgende Bereiche
Speicherkonsistenz auf Basis dieser Speichereinheiten
Typische Merkmale von (Software) DSM-Systemen
Granularität
Größe der Speichereinheiten des DSM bzgl. der Datenverwaltung, etwa Speicherseiten oder Daten-Objekte
Einfügen der DSM-Zugriffe
Virtuelles Speichermanagement des Betriebssystems
Modifizierte Compiler
Explizit im Quellcode
Konsistenz-Modell
Vertrag zwischen Anwendung und Speicher darüber, wann evtl. vorhandene Repliken von DSM-Daten konsistent sind
False sharing und Flattern
False sharing
verschiedene Datenwörter, die innerhalb einer Seite liegen, werden von verschiedenen Prozessoren z.B. für Schreibzugriffe benötigt
Da die Kohärenzmechanismen immer nur die gesamte Seite betreffen, muss die Seite vor jedem Schreibzugriff dem anderen Prozessor entzogen und anschließend erneut übertragen werden
Bei mehrfachen Schreibzugriffen kommt es nicht nur zu häufigen Blockierungen der Prozessoren, sondern auch zum sogenannten Flattern (thrashing), da die Seite immer wieder übers Netz übertragen werden muss
Möglichkeit der Minderung des Effektes
Verkleinern der Seitengröße, da dadurch die Wahrscheinlichkeit, dass mehrere unabhängige Datenwörter auf einer gemeinsamen Seite liegen, verringert wird
Andererseits verringert eine größere Seite den Aufwand für die Seitenverwaltung
Zurück zu (Hardware) DSM-Multiprozessor-Systemen
Experimentelle DSM-Systeme:
Dash der Universität Stanford und Alewife vom MIT als Vorläufer Kommerzielle DSM-Systeme:
Mit CC-NUMA-Konzept:
Meiko CS-2 (1993; Netzwerk-Technologie heute integriert in QsNet der Fa. Quadrics)
HP/Convex Exemplar (1994; Modell ausgelaufen)
IBM NUMA-Q (ehemals Sequent, Modell ausgelaufen)
SGI Altix und Origin (Modell ca. 2010 ausgelaufen)
Mit COMA-Konzept (Cache-Only Memory Access, Spezialfall von CC- NUMA)
KSR2 (1994 Konkurs der Fa. KSR)
Mit NCC-NUMA-Konzept
Cray T3E (Modell ausgelaufen, Nachfolger Cray X1E (X1) Vereinigung von Cray T90, SV1 und T3E)
Beispielsystem: Cray T3E
2. Generation der von Cray Research hergestellten MPP; Auslieferung ab 1996
Beibehaltung der T3D Makro-Architektur u.a. DSM-Konzept: physikalisch verteilte Speichermodule, globaler Adressraum; 3D-Torus Verbindungsnetzwerk
Erster Supercomputer, der 1 TeraFlop/s „sustained performance“ mit einer wissenschaftlichen Anwendung (Simulation von Magnetismus) erzielte (1998)
Adressierung
Eine globale Adresse in einem Cray-MPP-System mit physisch verteiltem Speicher besteht prinzipiell aus der Verarbeitungselement- Nummer (PE-Nummer) sowie dem Offset in den lokalen Speicher
Die Partitionierung des Systems muss berücksichtigt werden → 3 Ebenen der Verarbeitungselement-Adressierung:
Die virtuelle Verarbeitungselement-Nummer: Sicht der Anwendung unabhängig von der Lage der vom Betriebssystem gewählten Partition
Die logische Verarbeitungselement-Nummer: Sicht des Betriebssystems, d.h. alle benutzten Verarbeitungselemente
Die physische Verarbeitungselement-Nummer: Hardware-Sicht, d.h. alle tatsächlich vorhandenen Verarbeitungselemente einschließlich der redundanten Verarbeitungselemente
Die Umsetzung von virtueller zu logischer und schließlich zu
physischer Adresse erfolgt in Hardware
Verbindungsnetzwerk
Netzwerktopologie ist ein dreidimensionaler Torus, d.h. ein dreidimensionales ringförmig geschlossenes Gitter
Mechanismen zur Synchronisation
Barrier-Synchronisation
Neben der logischen UND-Verknüpfung (Barrier-Modus) ist auch die ODER-Verknüpfung (Eureka-Modus) möglich
Atomic-Swap-Operation
Tausch des Inhaltes spezieller lokaler Register mit dem Inhalt einer Speicherzelle, die auch in einem entfernten Speicher liegen kann, in einer unteilbaren Operation
Fetch-and-Increment-Operation
Lesen und Inkremetieren des Wertes eines Registers oder einer Speicherzelle in einer unteilbaren (atomaren) Operation
-> Unabhängig arbeitende Hardware-Unterstützung für den Nachrichtenaustausch
Betriebssystem
UNICOS-Betriebssystem für T3E wurde im Hinblick auf eine Microkernel Technologie umstrukturiert und mit UNICOS/mk bezeichnet Einheitliche Sicht des Gesamtsystem (Single System Image)
Kompakter Microkernel läuft auf jedem Verarbeitungselement (PE)
Implementiert nur die wichtigsten Basisfunktionen wie Speicherverwaltung und Interprozesskommunikation und die hardwareabhängigen Funktionen
Erhaltung der UNICOS-Benutzerschnittstelle (z.B. Login, Prozessverhalten)
Einheitliche Schnittstelle aus Sicht einer Anwendung (System Call Ebene)
Einheitliche Sicht für den Systemadministrator (z.B. Ressourcen-Vergabe, Accounting)
Charakterisierung Kommunikation früher und heute
Jeder Knoten agiert als eigenständiges System mit eigenem Betriebssystem (üblich Linux, vereinzelt auch Windows HPC)
Früher:
Interprozesskommunikation über Netzwerk und Nachrichtenaustausch
Heute:
insbesondere mit Aufkommen der Multi-Core Prozessoren, sind Cluster heutzutage hybride Systeme
Gemeinsamer Speicher in einem Knoten (Programmierung mit OpenMP)
Verteilter Speicher zwischen den Knoten (Programmierung mit MPI)
➔ Somit zwei Ebenen der Parallelität
ForHLR II – HPC-System am KIT
Energie-effiziente Warmwasserkühlung direkt in den Knoten für CPU
~ 40° C Vorlauf, > 45°C Rücklauf
Freie Kühlung selbst bei tropischen Sommertemperaturen
Wärme-Nachnutzung zur Gebäudeheizung 84% der Abwärme in Warmwasser
Gesamtsystem ForHLR II
24.048 cores, 95 TB Arbeitsspeicher
1,1 PetaFlop/s peak Rechenleistung
HoreKa – HPC-System
CPU-Partition „ Blue“ -> 602 Knoten, 270 Watt, 256 oder 512 GB RAM, 960 GB NVMe SSD, InfiniBand HDR200 (non-blocking)
GPU-Partition „Green“-> 167 Knoten, Gleiche CPUs, 512 GB RAM, Zusätzlich 4x NVIDIA A100-40 GPUs
-> Total: 58.444 Cores, 668 GPUs, 247 TB RAM
-> Spitzenleistung: 17 PetaFLOP/s
-> Budget: 15 Mio. Euro
Future Technologies Partition -> An HoreKa angegliedertes Testbett für neue Technologien
Beschleuniger Entstehung
„Irgendwann“ stagnierte die Leistungszunahme bei den CPUs, aber der Leistungshunger nahm weiter zu – was tun? → Beschleuniger
Co-Prozessoren gab es bereits sehr früh, „können bspw. mathematische sowie Gleitkomma-Operationen, Grafikoperationen, Signalverarbeitung, I/O-Verarbeitung oder Kryptographie ausführen“ eine Gleitkommaeinheit hatten (aufwendige Softwareroutinen wurden anstelle verwendet)
Ko-Prozessoren mussten als Zubehör separat erworben werden – bis zum i486
1. (großes) HPC System in der top500 Liste mit Beschleunigern -> IBM Roadrunner mit 6.480 AMD Opteron CPUs und 12.960 PowerXCell 8i Beschleunigern (Juni 2008) → 1 PF/s
Neben Spezialprozessoren (z.B. PowerXCell) gab/gibt es auch vereinzelt Systeme mit FPGAs (Field Programmable Gate Arrays) als Beschleuniger
Gegenwart und Zukunft
Aber: GPUs setz(t)en sich rasch durch…
ATI Radeon HD 4870 in der Tianhe-1 (November 2009-Juni 2010)
Nvidia Tesla C2050 in der Tianhe-1A (seit November 2010 bis heute)
Ein Blick in die Zukunft:
Frontier: erster Exascale-Supercomputer mit AMD Epyc CPUs und AMD Radeon Instinct GPUs seit Mitte 2022
Programmierung
Parallelrechner mit verteiltem Speicher in vielen Rechenknoten
Nachrichtenübertragung: MPI Bibliothek (OpenMPI oder Hersteller-spezifische MPI-Versionen, z.B. von Intel)
Rechenknoten mit Multi-Core-Prozessoren und gemeinsamen Adressraum und Speicher (SMP)
Synchronisation & Kommunikation über gemeinsame Variablen: OpenMP oder Pthreads Programmierung
SMP Rechenknoten zusätzlich mit Beschleunigern (GPUs, FPGAs, SIMD-Instruktionen, Intel MIC, …)
Auslagern spezieller Programmteile auf die Beschleuniger: CUDA, OpenCL, OpenACC
OpenCL
Ursprünglich entwickelt von Apple für heterogene Plattformen mit CPUs, GPUs und anderen Prozessoren
Inzwischen standardisiert über Khronos Group Daten- und Task-paralleles Computing-Modell
Für C, C++ (jedoch ohne Zeiger, Rekursion, etc.)
Kann direkt auf OpenGL und DirectX Objekte zugreifen
Spezielle Datentypen und Operationen
Es existieren kommerzielle (AMD, IBM, Intel, NVIDIA) und OpenSource Implementierungen (z.B. ROCm)
Zahlreiche Anwendungsprogramme setzen auf OpenCL auf, z.B. Grafikprogramme (z.B. GIMP), 3D-Renderer, Video, Simulationscodes (z.B. GROMACS, Monte-Carlo, Particle-in-Cell), Programmierbibliotheken (z.B. Netlib BLAS)
OpenACC, CUDA
OpenACC
Von Cray, Nvidia und PGI entwickelter Programmierstandard, um einfach CPU/GPU-Systeme zu programmieren
Annotierung von C, C++, Fortran Code mit Compiler-Direktiven, ähnlich wie OpenMP für SMP-Programmierung – damit keine direkte Veränderung des SourceCode
Unterstützung für Nvidia, Intel, AMD Beschleuniger
CUDA
Von Nvidia entwickelte APIs (low-level, high-level) für GPUs
Für C, C++, Fortran
Gibt spezielle CUDA-beschleunigte Bibliotheken, z.B. CUBLAS, CUFFT, CUSPARSE, CUMATRIX
Nur für Nvidia GPUs (Tesla, Fermi, Kepler, Pascal, Volta, …)
Definition Vektorrechner
Definition: Ein Vektorrechner ist ein Rechner mit pipelineartig aufgebautem/n Rechenwerk/en zur Verarbeitung von Vektoren von Gleitpunktzahlen
Vektor = Array (Feld) von Gleitpunktzahlen
Jeder Vektorrechner besitzt in seinem Rechenwerk einen Satz von Vektorpipelines; diese wird als Vektoreinheit bezeichnet Im Gegensatz zur Vektorverarbeitung wird die Verknüpfung einzelner Operanden als Skalarverarbeitung bezeichnet
Ein Vektorrechner enthält neben der Vektoreinheit auch noch eine oder mehrere Skalareinheiten Dort werden die skalaren Befehle ausgeführt, d.h. Befehle, die nicht auf ganze Vektoren angewendet werden sollen
Die Vektoreinheit und die Skalareinheit(en) können parallel zueinander arbeiten, d.h. Vektorbefehle und Skalarbefehle können parallel ausgeführt werden
Beispiel: Vektor-Addition
Pipelining-Prinzip
Besonderheiten eines Vektorrechners
Pipeline-Verarbeitung wird mit einem Vektorbefehl für zwei Felder von Gleitpunktzahlen durchgeführt
Die bei den Gleitpunkteinheiten skalarer Prozessoren nötigen Adressrechnungen entfallen
Bei ununterbrochener Arbeit in der Pipeline kann man nach einer gewissen Einschwingzeit bzw. Füllzeit, die man braucht, um die Pipeline zu füllen, mit jedem Pipeline-Takt ein Ergebnis erwarten
Dabei ist die Taktdauer durch die Dauer der längsten Teilverarbeitungszeit zuzüglich der Stufentransferzeit gegeben
Verkettung (Chaining)
Möglichkeiten der Parallelarbeit
Vektor-Pipeline-Parallelität:
durch die Stufenzahl der betrachteten Vektor-Pipeline gegeben Mehrere Vektor-Pipelines in einer Vektoreinheit: Vorhandensein mehrerer, meist funktional verschiedener Vektor- Pipelines in einer Vektoreinheit, durch Verkettung hintereinander geschaltet
Vervielfachung der Pipelines:
Vektor-Pipeline vervielfachen, so dass bei Ausführung eines Vektorbefehls pro Takt nicht nur ein Paar von Operanden in eine Pipeline, sondern jeweils ein Operandenpaar in zwei oder mehr parallel arbeitende gleichartige Pipelines eingespeist werden
Mehrere Vektoreinheiten:
Arbeiten parallel zueinander nach Art eines speichergekoppelten Multiprozessors (SMP)
Vektorrechner heute
Vektorrechner haben in den letzten Jahren durch große Rechencluster, die aus vielen Tausend Standardprozessoren aus den Consumer-Markt, starke Konkurrenz bekommen
Enorme Kostenersparnis durch Verwendung von Standardprozessoren und –komponenten (z.B. Mainboards)
Standardprozessoren sind enorm leistungsfähig geworden (→ Multi-Core)
Auch Standardprozessoren wurde dahingehend erweitert, Operationen auf mehreren Daten gleichzeitig auszuführen (SIMD) und damit zu beschleunigen
➔ Traditionelle Vektorrechner sind kaum noch vorhanden ->In der aktuellen top500 Liste existiert kein Vektorrechner mehr
Beispielsystem: NEC SX-9 am SCC@KIT
Zuletzt geändertvor 2 Jahren