This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
MIN-FakultätFachbereich Informatik
64-040 Modul InfB-RS: Rechnerstrukturenhttps://tams.informatik.uni-hamburg.de/
lectures/2018ws/vorlesung/rs
– Kapitel 15 –
Andreas Mäder
Universität HamburgFakultät für Mathematik, Informatik und NaturwissenschaftenFachbereich InformatikTechnische Aspekte Multimodaler Systeme
I ursprüngliche Idee: Parallelrechner mit n-Prozessoren
Speedup Sgesamt =1
(1− f ) + k(n) + f =n
n #Prozessoren als Verbesserungsfaktorf Anteil parallelisierbarer Berechnung1− f Anteil nicht parallelisierbarer Berechnungk() Kommunikationsoverhead zwischen den Prozessoren
I Aufgaben verteilenI Arbeit koordinierenI Ergebnisse zusammensammeln
I lange Pipelines mit vielen Phasen: Fetch (Prefetch, Predecode),Decode / Register-Renaming, Issue, Dispatch, Execute, Retire(Commit, Complete / Reorder), Write-Back
I je nach Implementation unterschiedlich aufgeteiltI entscheidend für superskalare Architektur sind die Schritte
vor den ALUs: Issue, Dispatch ⇒ out-of-order Ausführungnach -"- : Retire ⇒ in-order Ergebnisse
I Reservation Station für jede FunktionseinheitI speichert: initiierte Instruktionen die auf Recheneinheit wartenI –"– zugehörige OperandenI –"– ggf. ZusatzinformationI Instruktion bleibt blockiert, bis alle Parameter bekannt sind und
wird dann an die zugehörige ALU weitergeleitet
I ggf. „Retire“-StufeI Reorder-Buffer: erzeugt wieder in-order ReihenfolgeI commit: „richtig ausgeführte“ Instruktionen gültig machen
abort: Instruktionen verwerfen, z.B. Sprungvorhersage falsch
I Dynamisches Scheduling: zuerst ’67 in IBM360 (R. Tomasulo)I ForwardingI Registerumbenennung und Reservation Stations
Spezielle Probleme superskalarer Pipelines− weitere Hazard-Möglichkeiten
I die verschiedenen ALUs haben unterschiedliche LatenzzeitenI Befehle „warten“ in den Reservation Stations⇒ Datenabhängigkeiten können sich mit jedem Takt ändern
− Kontrollflussabhängigkeiten:Anzahl der Instruktionen zwischen bedingten Sprüngenlimitiert Anzahl parallelisierbarer Instruktionen
Interrupts, System-Calls und ExceptionsI Pipeline kann normalen Ablauf nicht fortsetzenI Ausnahmebehandlung ist wegen der Vielzahl paralleler Aktionen
und den Abhängigkeiten innerhalb der Pipelines extrem aufwändigI einige Anweisungen können verworfen werden− andere Pipelineaktionen müssen vollendet werden
benötigt zusätzliche Zeit bis zur Ausnahmebehandlung− wegen Register-Renaming muss viel mehr Information gerettet
Prinzip der InterruptbehandlungI keine neuen Instruktionen mehr initiierenI warten bis Instruktionen des Reorder-Buffers abgeschlossen sindI Verfahren ist von der „Art“ des Interrupt abhängig
I Precise-Interrupt: Pipelineaktivitäten komplett BeendenI Imprecise-Interrupt: wird als verzögerter Sprung
(Delayed-Branching) in Pipeline eingebrachtZusätzliche Register speichern Information über Instruktionendie in der Pipeline nicht abgearbeitet werden können(z.B. weil sie den Interrupt ausgelöst haben)
I Definition: Precise-InterruptI Programmzähler (PC) zur auslösenden Instruktion ist bekanntI alle Instruktionen bis zur PC-Instr. wurden vollständig ausgeführtI keine Instruktion nach der PC-Instr. wurde ausgeführtI Ausführungszustand der PC-Instruktion ist bekannt
I superskalare Architektur (mehrere ALUs)I CISC-Befehle werden dynamisch in „—OPs“ (1 . . . 3) umgesetztI Ausführung der —OPs mit „Out of Order“ Maschine, wenn
I Operanden verfügbar sindI funktionelle Einheit (ALU) frei ist
I Ausführung wird durch „Reservation Stations“ kontrolliertI beobachtet die Datenabhängigkeiten zwischen —OPsI teilt Ressourcen zu
I „Trace“ CacheI ersetzt traditionellen AnweisungscacheI speichert Anweisungen in decodierter Form: Folgen von —OPsI reduziert benötigte Rate für den Anweisungsdecoder
I „Double pumped“ ALUs (2 Operationen pro Taktzyklus)
I ein zentraler SteuerprozessorI 64 Prozessoren/ALUs und Speicher, 8× 8 MatrixI Befehl wird parallel auf allen Rechenwerken ausgeführtI aufwändige und teure ProgrammierungI oft schlechte Auslastung (Parallelität Algorithmus vs. #CPUs)
I mehrere Prozessoren, über Bus/Netzwerk verbundenI gemeinsamer („shared“) oder lokaler SpeicherI unabhängige oder parallele Programme / MultithreadingI sehr flexibel, zunehmender Markterfolg
I mehrere CPUs, aber gemeinsamer SpeicherI jede CPU bearbeitet nur eine TeilaufgabeI CPUs kommunizieren über den gemeinsamen SpeicherI Zuordnung von Teilaufgaben/Speicherbereichen zu CPUs
I jede CPU kann auf jeden Speicher zugreifenI hoher Hardwareaufwand: O(n2) Schalter und VerbindungenI Konflikte bei gleichzeitigem Zugriff auf einen Speicher
Wie viele CPUs kann man an ein System anschliessen?I Bus: alle CPUs teilen sich die verfügbare Bandbreite⇒ daher normalerweise nur 2 . . . 8 CPUs sinnvoll
I Gitter: verfügbare Bandbreite wächst mit Anzahl der CPUs
I Maß für die Effizienz einer Architektur / eines Algorithmus’I wegen Amdahl’s Gesetz maximal linearer ZuwachsI je nach Problem oft wesentlich schlechter
I Programmierung: ein ungelöstes ProblemI Aufteilung eines Programms auf die CPUs/Rechenknoten?I insbesondere bei komplexen Kommunikationsnetzwerken
I Programme sind nur teilweise parallelisierbarI Parallelität einzelner Programme: kleiner 8
gilt für Desktop-, Server-, Datenbankanwendungen etc.⇒ hochgradig parallele Rechner sind dann Verschwendung
I Wohin mit den Transistoren aus „Moore’s Law“?⇒ SMP-/Mehrkern-CPUs (4 . . . 32 Proz.) sind technisch attraktiv
I Vektor-/Feld-Rechner für Numerik, Simulation . . .I Grafikprozessoren (GPUs) sind Feld-RechnerI neben 3D-Grafik zunehmender Computing-Einsatz (OpenCL)I hohe Fließkomma-Rechenleistung (single precision)
I mehrere Prozessoren nutzen gemeinsamen HauptspeicherI Zugriff über Verbindungsnetzwerk oder BusI geringer Kommunikationsoverhead+ Bus-basierte Systeme sind sehr kostengünstig− aber schlecht skalierbar (Bus als Flaschenhals, s.o.)− Konsistenz der Daten
I lokale Caches für gute Performanz notwendigI Hauptspeicher und Cache(s): Cache-Kohärenz
MESI-Protokoll und „Snooping“ 18-Kern Xeon E7 v3 [Intel]
[TA14] A.S. Tanenbaum, T. Austin: Rechnerarchitektur –Von der digitalen Logik zum Parallelrechner.6. Auflage, Pearson Deutschland GmbH, 2014.ISBN 978–3–8689–4238–5