diff --git a/Assets/RA2_Simultaneous-Multithreading.png b/Assets/RA2_Simultaneous-Multithreading.png new file mode 100644 index 0000000..b3071fa Binary files /dev/null and b/Assets/RA2_Simultaneous-Multithreading.png differ diff --git a/Assets/RA2_Sprungvorhersage.png b/Assets/RA2_Sprungvorhersage.png new file mode 100644 index 0000000..bb9a4b6 Binary files /dev/null and b/Assets/RA2_Sprungvorhersage.png differ diff --git a/Assets/RA2_VLIW-dynamisch.png b/Assets/RA2_VLIW-dynamisch.png new file mode 100644 index 0000000..2c05099 Binary files /dev/null and b/Assets/RA2_VLIW-dynamisch.png differ diff --git a/Assets/RA2_VLIW-vergleich.png b/Assets/RA2_VLIW-vergleich.png new file mode 100644 index 0000000..d24604d Binary files /dev/null and b/Assets/RA2_VLIW-vergleich.png differ diff --git a/Assets/RA2_in-order-pipeline.png b/Assets/RA2_in-order-pipeline.png new file mode 100644 index 0000000..918f87e Binary files /dev/null and b/Assets/RA2_in-order-pipeline.png differ diff --git a/Assets/RA2_out-of-order-execution.png b/Assets/RA2_out-of-order-execution.png new file mode 100644 index 0000000..6a59639 Binary files /dev/null and b/Assets/RA2_out-of-order-execution.png differ diff --git a/Rechnerarchitekturen 2.md b/Rechnerarchitekturen 2.md index 7386a96..9004041 100644 --- a/Rechnerarchitekturen 2.md +++ b/Rechnerarchitekturen 2.md @@ -250,18 +250,22 @@ Gegenmaßnahmen ## Sprungvorhersage Je mehr die Parallelität ausgenützt werden soll, desto mehr sind Kontrollkonflikte der limitierender Faktor! +- wichtig für single-issue Prozessoren (pro Takt ein Befehl ausgegeben) +- aber essentiell für multiple-issue (n Befehle pro Takt ausgegeben) Dynamische Sprungvorhersage - Zur Laufzeit durch Prozessor-Hardware - Vorhersage, ob ein bedingter Sprung genommen wird oder nicht - Abhängig von der Vorhersage: Füllen der Prozessor-Pipeline mit Befehlen ab der vorhergesagten Programm-Stelle - Reduktion der branch penalty, falls vorhergesagtes Programm-Verhalten mit tatsächlichem übereinstimmt +- jedoch: Vorhersagen sind schwierig -### Einfache lokale Prädiktoren +Einfache lokale Prädiktoren - Liefern Vorhersage, ob bedingter Sprung genommen wird oder nicht - Prädiktion allein anhand der Historie des betrachteten, aktuellen Sprungs - Historie eines Sprungs wird mit 1, 2 oder n Bits gepuffert +### Einfache Sprungvorhersage (1 Bit) - Sprungvorhersage-Puffer - Branch prediction buffer oder branch history table - Kleiner Speicher, der mit (Teil der) Adresse des Sprungbefehls indiziert wird @@ -270,6 +274,7 @@ Dynamische Sprungvorhersage - Prädiktion: Sprung verhält sich wie beim letzten Mal - Nachfolgebefehle ab vorhergesagter Adresse holen - Falls Prädiktion fehlerhaft: Prädiktionsbit invertieren + - Alle Sprünge, deren Adressen im Indexteil übereinstimmen, werden derselben Zelle im branch prediction buffer zugeordnet. - Einfachste Art von Puffer (keine Tags, d.h. keine Überprüfung, ob Adresse tatsächlich im Puffer) - Entspricht sehr einfachem Cache - Hat eine bestimmte Kapazität @@ -278,35 +283,45 @@ Dynamische Sprungvorhersage - Prädiktion kann fehlerhaft sein - Prädiktion kann von anderem Sprungbefehl stammen (mit gleichen Bits im Indexteil der Adressen) +### Einführung von Tag Bits - Nachteile des einfachen 1-Bit Vorhersageschemas - Höhere Fehlerrate als überhaupt möglich, wenn Häufigkeit der Sprungentscheidungen betrachtet wird - D.h. auch wenn Sprung fast immer ausgeführt (taken) wird, entstehen 2 Fehler anstatt 1 +- Tag beseitigt eines der Probleme: gültiger Eintrag, falls Tag-Bits gleich sind +- Alle Sprünge, deren Adressen im Indexteil übereinstimmen, werden derselben Zelle im branch prediction buffer zugeordnet. Überprüfung mittels tags, ob es der richtige Eintrag ist. +- Allgemein: Fehlerrate von 1-Bit Prädiktor ist für Sprünge in Schleifenkonstrukten doppelt so hoch wie die Anzahl ausgeführter Sprünge -2-Bit Branch-Prediction Buffer -- Speicherung der Historie, Befehlsadressen als Zugriffsschlüssel: +### 2 Bit Vorhersagen +- Änderung der Vorhersage nur, wenn 2 falsche Vorhersagen in Folge +- 2-Bit Branch-Prediction Buffer: Speicherung der Historie, Befehlsadressen als Zugriffsschlüssel +![Sprungvorhersage](Assets/RA2_Sprungvorhersage.png) + +Vorhersagequalität für 2-Bit Prädiktor +- Studie von 1992 für SPEC89 auf IBM Power-Architektur +- Qualität nicht durch die Größe des Speichers beschränkt +- Fehlerwahrscheinlichkeit höher für Integer-Programme (gcc, eqntott) + +### n-Bit Prädikator Allgemein: n-Bit Prädiktor (Spezialfall: 2-Bit) - Verwendet n-Bit Zähler - Sättigungsarithmetik (kein wrap around bei Überlauf) - - Kann Werte zwischen 0 und 2 n - 1 annehmen - - Wenn Zähler größer als Hälfte des Maximums (2 n - 1): Vorhersagen, dass Sprung ausgeführt wird; ansonsten vorhersagen, dass Sprung nicht genommen wird + - Kann Werte zwischen 0 und $2^{n-1}$ annehmen + - Wenn Zähler größer als Hälfte des Maximums $(2^{n-1})$: Vorhersagen, dass Sprung ausgeführt wird; ansonsten vorhersagen, dass Sprung nicht genommen wird - Zähler wird bei ausgeführtem Sprung inkrementiert und bei nicht ausgeführtem dekrementiert - In der Praxis: 2-Bit Prädiktor ähnlich gut wie n-Bit Prädiktor - In den meisten Prozessoren heute: 2-Bit Prädiktor für (lokale) Vorhersage + +### Korrelierende Prädikatoren - Einschränkung des n-Bit (bzw. 2-Bit) Prädiktors: - Betrachtet nur (vergangenes) Verhalten eines Sprungs, um dessen (zukünftiges) Verhalten vorherzusagen. - Arbeitet rein lokal! - Idee: Verbesserung durch Betrachtung des Verhaltens anderer Sprünge - Man erhält so genannten korrelierenden Prädiktor (correlating predictor) oder zweistufigen Prädiktor - Prinzip: Aufgrund globaler Information (anderer Sprünge) wird einer von mehreren lokalen Prädiktoren ausgewählt - - -### Korrelierende Prädikatoren - Beziehen zur Vorhersage des Verhaltens eines Sprungs Kontext-Information mit ein, d.h. die Historie anderer Sprungbefehle - Prädiktor benutzt globale Kontext-Bits, um einen von mehreren lokalen Prädiktoren auszuwählen - - Betrachten wiederholte Ausführung des Codefragments (ignorieren dabei alle anderen Sprünge, inkl. dem für Wiederholung) -- Einschränkung: Statt aller möglicher Sequenzen: d wechselt zwischen 2 und 0 Zweistufiger Prädiktor - Verwendet 1 Bit Kontextinformation @@ -314,10 +329,10 @@ Zweistufiger Prädiktor - Kontext: Letzter (i.a. anderer) Sprung wurde ausgeführt/nicht ausgeführt (1 Bit) - Vorhersage des zweistufigen Prädiktors: Anhand des Kontexts wird lokaler Prädiktor für die Vorhersage des aktuell betrachteten Sprungs ausgewählt - Letzter Sprung ist i.a. nicht gleich aktuellem, vorherzusagendem Sprung (nur in einfachen Schleifen) -- Notation des Prädiktorstatus: / mit - - : Vorhersage, falls letzter Sprung not taken, d.h. Kontext = NT - - : Vorhersage, falls letzter Sprung taken, d.h. Kontext = T - - und Vorhersagen: jeweils entweder T oder NT +- Notation des Prädiktorstatus: `/` mit + - ``: Vorhersage, falls letzter Sprung not taken, d.h. Kontext = NT + - ``: Vorhersage, falls letzter Sprung taken, d.h. Kontext = T + - `` und `` Vorhersagen: jeweils entweder T oder NT (m,n)-Prädiktor - Betrachtet als Kontext das Verhalten der letzten m Sprünge, um aus $2^m$ vielen lokalen Prädiktoren einen n-Bit Prädiktor auszuwählen @@ -386,7 +401,168 @@ Allgemeines Ziel: Vorhersage indirekter Sprünge (d.h. bzgl. Basisadresse in Reg # Multiple-Issue-Architekturen +## Mehrere Ausführungseinheiten +- Techniken der vorangegangenen Abschnitte geeignet, um Daten- und Kontrollkonflikte zu lösen + - Idealer CPI ~1 +- Weitere Leistungssteigerung: + - CPI < 1 +- Mehrere Befehle pro Takt ausgeben (fertigstellen) +- Zwei Grundtypen von multiple-issue Prozessoren: + - Superskalar + - Geben variable Anzahl von Befehlen pro Takt aus + - Mit statischem (vom Compiler erzeugtem) oder dynamischem Scheduling in Hardware + - VLIW/EPIC + - Feste Anzahl von Befehlen ausgegeben, definiert durch Befehlscode (weitgehende Planung der Issue-Phase durch Compiler) +![In Order Pipeline](Assets/RA2_in-order-pipeline.png) + +## Superskalar +statisch: Details der Befehlsausgabe +- In IF werden 1-n Befehle von Instruction Fetch Unit geholt (ggfs. Max. von n nicht immer möglich, z.B. bei Sprüngen) +- Befehlsgruppe, die potentiell ausgegeben werden kann = issue packet +- Konflikte bzgl. Befehlen im issue packet werden in Issue-Stufe in Programmreihenfolge (d.h. in-order) geprüft + - Befehl ggfs. nicht ausgegeben (und alle weiteren) +- Aufwand für Prüfung in Issue-Stufe groß! + - Wegen Ausgewogenheit der Pipeline-Stufen ggfs. Issue weiter „pipelinen“, d.h. in mehrere Stufen unterteilen = nicht-trivial +- Parallele Ausgabe von Befehlen limitierender Faktor superskalarer Prozessoren! + +MIPS mit statischem Scheduling +- Annahme: 2 Befehle pro Takt können ausgegeben werden (1x ALU, Load/Store plus 1x FP) + - Einfacher als 2 beliebige Befehle (wegen „Entflechtung“) +- Befehlsstart umfasst + - 2 Befehlsworte holen (64-Bit Zugriff, d.h. komplexer als bei nur 1 Befehl - ggfs. Pre-fetch?) + - Prüfen, ob 0, 1 oder 2 Befehle ausgegeben werden können + - Befehl(e) ausgeben an korrespondierende funktionale Einheiten +- Prüfen auf Konflikte durch Entflechtung vereinfacht + - Integer und FP-Operationen nahezu unabhängig (verschiedene Registersätze) + - Abhängigkeiten nur bei Speichertransfers möglich (von Integer-ALU für FP ausgeführt) - Einschränkung des issue +- Leistungssteigerung nur bei „geeignetem“ Anteil von FP-Operationen im Programm sowie geeigneter „Verflechtung“ durch Compiler! + +## Dynamisches Befehlsscheduling – in-order execution +Bislang +- Reihenfolge der Befehlsabarbeitung = Reihenfolge der Befehle im Speicher, abgesehen von Sprüngen +- Behindert schnelle Ausführung + +Scoreboarding +- Jeder Befehl, der aus der Instruction fetch-Einheit kommt, durchläuft das Scoreboard. +- Wenn für einen Befehl alle Daten/Operanden bekannt sind und die Ausführungseinheit frei ist, wird der Befehl gestartet. +- Alle Ausführungseinheiten melden abgeschlossene Berechnungen dem Scoreboard. +- Dieses erteilt Befehlen die Berechtigung zum Abspeichern von Ergebnissen, sofern + - Speichereinheit frei ist und + - Antidaten- und Ausgabeabhängigkeiten berücksichtigt sind und prüft, ob dadurch neue Befehle ausführbereit werd +- Zentrale Datenstruktur hierfür: Scoreboard (deutsch etwa „Anzeigetafel“ [für Befehlsstatus]) + - Ursprünglich realisiert für CDC 6600 (1964): + - load/store-Architektur + - mehrere funktionale Einheiten (4xFP, 6xMem, 7xInteger ALU) + - Scoreboarding für MIPS nur sinnvoll + - für FP-Pipeline (Operationen mit mehreren Taktzyklen) + - und mehrere funktionale Einheiten (hier: 2 x Mult, Div, Add, Int) + +![Out Of Order Execution](Assets/RA2_out-of-order-execution.png) + + +### Verfahren von Tomasulo +- Erdacht für IBM 360 +- Verfahren von Tomasulo erlaubt auch bei Ausgabe- und Antidatenabhängigkeiten, die Reihenfolge zu vertauschen +- Umbenennung der Register; verschiedenen Benutzungen eines Registers werden verschiedene Speicherzellen zugeordnet +- Jeder funktionalen Einheit wird eine Reservation Station zugeordnet +- Reservation Stations enthalten die auszuführende Operation und, soweit bekannt, die Operanden bzw. eine Kennzeichnung in Form von tag bits des Operanden +- Sind alle Operanden bekannt und ist die funktionale Einheit frei, so kann die Bearbeitung beginnen +- Am Ende der Bearbeitung wird das Ergebnis von allen Einheiten übernommen, die das Ergebnis benötigen +- Verteilen der Daten erfolgt vor der Abspeicherung im Registerspeicher +- Aus den tag bits geht hervor, aus welcher Einheit der Operand kommen muss +- Registeradressen werden dynamisch auf größere Anzahl von Plätzen in den Reservation Stations abgebildet, d.h. Register effektiv umbenannt. Performance-Beschränkungen wegen weniger Register werden so umgangen + +### Register Renaming +- Prinzip: Verwendung temporärer Register für (logisch) neue möglicherweise interferierende Belegung +- Beispiel + - Annahme: es existieren zwei temporäre Register S und T + - Kollidierende Belegungen von F8 durch `sub.d` bzw. F6 durch `add.d` in (eindeutige) temporäre Register „umleiten“ + ```cpp + div.d $F0,$F2,$F4 + add.d $T,$F0,$F8 // Lesen von F8, Schreiben von T (F6) + s.d $T,0($R1) // Lesen von T (F6) + sub.d S,$F10,$F14 // Schreiben von S (F8) + mul.d $F6,$F10,S // Schreiben von F6 + ``` +- Alle Namenskonflikte durch Umbenennung auflösbar (Voraussetzung: genügend temporäre Register) +- Weitere Verwendung von F8/F6 durch S/T ersetzen! +- Wichtige Hardwarestruktur: Reservation Stations + - Zugeordnet zu funktionalen Einheiten (i.d.R. eine pro Einheit) +- Arbeitsweise von Reservation Stations + - Puffern Operanden für Befehle (sobald verfügbar/geladen) + - Müssen nicht aus Registern gelesen werden! + - Ausstehende Operanden verweisen auf Reservation Station, die Eingabe bereitstellen wird + - Bei aufeinander folgenden Schreibzugriffen auf Register: Nur letzter für Aktualisierung des Inhalts verwendet +- Wichtige Eigenschaften der Verwendung von Reservation Stations anstelle des zentralen Registersatzes + - Konfliktdetektion und Ausführungskontrolle verteilt + - Informationen in Reservation Stations bei den funktionalen Einheiten bestimmen, wann Ausführung eines Befehls möglich ist + - Ergebnisse werden direkt zu den funktionalen Einheiten (in jeweiliger Reservation Station) weitergereicht + - Erweiterte Form des Forwarding + - Realisiert implizit Register Renaming + - Möglich durch gemeinsamen Ergebnisbus (common data bus) + + +## Multiple-Issue mit dynamischem Scheduling +- Wesentlicher Nachteil von statischem Scheduling für superskalare Prozessoren: Latenzzeiten werden ca. mit Länge des issue packets skaliert +- „Längere“ Verzögerung (in Anzahl Befehlen) für Load/Stores bzw. Branches +- Lösung: Erweiterung des Tomasulo-Algorithmus auf Multiple-Issue durch + - Sequentielles Ausgeben mehrerer Befehle an Reservation Stations innerhalb eines Taktes, oder + - „Verbreiterung“ der Ausgabe-Logik (issue logic) zur Behandlung mehrerer Operationen parallel + - (alle Abhängigkeiten gleichzeitig überprüfen!) + +### VLIW - Very Long Instruction Word +VLIW (Very Long Instruction Word)-Prozessor +- verschiedene parallele Ausführungseinheiten +- Verteilung von Maschinencode direkt vom Befehlswort im Speicher vorgegeben +- Sieht für jede Ausführungseinheit dezidierte Anweisungen vor +- keine Abhängigkeiten daher geringere Komplexität in Hardware +- Meist für stark parallelisierbare Aufgaben verwendet (Signalverarbeitung, Vektorrechner, DSP) + +- Vorteile: + - Die parallele Architektur des Prozessors kann schon während der der Programmerstellung (Kompilieren) zur Optimierung genutzt werden. + - Keine aufwendige Prozessorhardware zur Befehlsverteilung/Abhängigkeitsanalyse erforderlich (einfacherer Prozessor) + - Ausführungszeiten sind im wesentlichen bekannt +- Nachteile: + - Aufwendigere Compiler + - Schlechte Prozessorauslastung bei ungünstigem Code + - Rekompilierung für den Prozessor erforderlich (kein Universalrechner) + - Größerer Speicherbedarf (Programm), wenn Code nicht parallelisiert werden kann. + +![VLIW Dynamisch](Assets/RA2_VLIW-dynamisch.png) + +EPIC = Explicitely Parallel Instruction Computing = IA64 +- Im wesentlichen Prinzip des VLIW-Prozessors +- Umsortieren der Befehle und Auflösung der Abhängigkeiten werden durch den Compiler durchgeführt + - Hauptnachteil; Neukompilierung erforderlich) +- Keine statische Aufteilung auf Funktionseinheiten +- Effizienteres Befehlswort - Keine Verwendung von zwangsweise NOPs + +Bei der IA64-Architektur werden verschiedene Ansätze verfolgt, um die Prozessorlogik zu vereinfachen. +1. Bedingte Befehlsverarbeitung + - Ein Befehl wird abhängig von einem Statusbit ausgeführt + - Dadurch kann die Sprungvorhersage bei einfachen if-then-else Zweigen entfallen + - Die then und else Befehle sind parallel, wobei jeweils nur einer ausgeführt wird +2. Statische Sprungvorhersage (Compiler) +3. Die Optimierung (Finden paralleler Befehle) wird im wesentlichen dem Compiler überlassen. +4. Spekulatives Laden von Operanden + - Möglichst geringe Wartezeit auf Operanden + - Schon im Compiler werden entsprechende Ladebefehle vorgezogen. + +![VLIW Vergleich](Assets/RA2_VLIW-vergleich.png) + +## Simultaneous Multithreading (SMT) +![SMT](Assets/RA2_Simultaneous-Multithreading.png) + +- Modellprozessor I (2-fach Superskalar) +- Modellprozessor II (2-fach Out-of-Order) + +Ansätze zur Effizienzsteigerung durch Mikroparallelität +| Bezeichnung | Konflikterkennung | Issue-Struktur | Scheduling | Hauptmerkmal | Beispiele | +| -- | -- | -- | -- | -- | -- | +| Superskalar (statisch) | Hardware | Dynamisch | Statisch | In-order Execution | Sun UltraSPARC II/ III | +| Out of Order | Hardware | Dynamisch | Dynamisch mit Spekulation | Out of Order mit Spekulation | Pentium III, Pentium 4, MIPS 10000 | +| VLIW | Software | Statisch | Statisch | Keine Konflikte | Trimedia, diverse DSPs | # Microcontroller und Digitale Signalprozessoren