Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 3 » CISC/RISC (Übersicht)
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Nächste Überarbeitung | Vorherige Überarbeitung | ||
pruefungen:hauptstudium:ls3:ra-2020-02-07 [07.02.2020 11:01] – angelegt Thomas R | pruefungen:hauptstudium:ls3:ra-2020-02-07 [07.02.2020 16:04] (aktuell) – Thomas R | ||
---|---|---|---|
Zeile 3: | Zeile 3: | ||
**Note:** 1.0 (schwankte zwischen 1.0 und 1.3 - letzten Endes aber doch 1.0 wegen des konsequenten Besuchs der Tafel- und Rechnerübung. Lohnt sich also ;-)) | **Note:** 1.0 (schwankte zwischen 1.0 und 1.3 - letzten Endes aber doch 1.0 wegen des konsequenten Besuchs der Tafel- und Rechnerübung. Lohnt sich also ;-)) | ||
- | Generell ist Prof. Fey relativ kulant, wenn man nicht auf dem ersten Anhieb versteht worauf er hinaus will. Er formuliert die Frage dann meistens detaillierter um, womit es bei mir beim zweiten Anlauf eigentlich immer geklappt hat. | + | Die Prüfungsatmospäre ist recht locker, Papier und Stift wurden gestellt. |
+ | |||
+ | Ich habe mich bemüht hier die Prüfung so gut wie möglich zu rekonstruieren, | ||
==== CISC/RISC ==== | ==== CISC/RISC ==== | ||
**P:** Aus welchen Gründen ist man von CISC nach RISC gewechselt? | **P:** Aus welchen Gründen ist man von CISC nach RISC gewechselt? | ||
- | Erklärt, das CISC (Complex Instruction Set Computer) kompliziertere Addressierungsmodi enthält, die vielleicht anfangs von Vorteil waren als man Assembler händisch geschrieben hatte, aber später eigentlich nur noch Compiler, der Maschinencode erzeugt. Patterson-Studie erwähnt, nach der im schlimmsten Fall nur 30% der Befehle verwendet werden. Daher also RISC (Reduced Instruction Set Computer). | + | Erklärt, das CISC (Complex Instruction Set Computer) kompliziertere Addressierungsmodi enthält, die vielleicht anfangs von Vorteil waren als man Assembler händisch geschrieben hatte, aber später eigentlich nur noch Compiler, der Maschinencode erzeugt. Patterson-Studie erwähnt, nach der im schlimmsten Fall nur 30% der Befehle |
- | ==== Pipelining ==== | + | **P: |
- | **P: | + | |
- | Pipeline hingezeichnet, | + | RISC (Reduced Instruction Set Computer) hat gleich lange Befehle |
- | **P: | + | **P: |
+ | Erklärt, dass CISC Mikroprogrammierung verwendet, welches einen Makrobefehl in eine Folge von Mikroinstruktionen umwandelt. Das ist flexibler und ermöglicht Fehlerbehebung, | ||
+ | **P:** Ist CISC also ausgestorben? | ||
+ | |||
+ | Nein, moderne Intel x86 Prozessoren sind weiterhin CISC, die komplexen Befehle werden aber zumeist in eine Abfolge von RISC Befehlen umgesetzt. Nach seinen Worten also ' | ||
+ | |||
+ | ==== Pipelining ==== | ||
+ | **P:** Was hat es denn mit dem Pipelining auf sich? | ||
+ | |||
+ | Pipeline hingezeichnet, | ||
**P:** Wie berechnet sich der Durchsatz? | **P:** Wie berechnet sich der Durchsatz? | ||
- | Hier erst erklärt, dass man mit Pipelining insgesamt k + (n-1) Schritte braucht (bei n Instruktionen mit k Stufen). | + | Hier erst erklärt, dass man mit Pipelining insgesamt k + (n-1) Schritte braucht (bei n Instruktionen mit k Stufen). |
**P:** Aber das ist nicht der Durchsatz. Wie berechnet man den generell den Durchsatz? | **P:** Aber das ist nicht der Durchsatz. Wie berechnet man den generell den Durchsatz? | ||
Zeile 29: | Zeile 39: | ||
**P:** Okay, und wie schaut es mit der Ausführungszeit pro Stufe bei der Pipeline aus? | **P:** Okay, und wie schaut es mit der Ausführungszeit pro Stufe bei der Pipeline aus? | ||
- | Ah, die orientiert sich natürlich an der langsamsten Stufe, also '' | + | Ah, die orientiert sich natürlich an der langsamsten Stufe, also '' |
- | P: Ist doch schön. Aber wieso klappt das mit dem Pipelining doch nicht ganz so? | + | **P:** Wieso erhöhen wir eigentlich |
- | Ewähnt, dass drei Arten von Hazards. Strukturhazards entstehen bei gemeinsamer Nutzung von Resourcen. Bsp: Gemeinsamer Daten- und Instruktionscache bei Single-Port Speicher wenn BH und OP-Phase; oder bei Funktionseinheiten in superskalaren Architekturen. | + | Ich hatte hier argumentiert, |
+ | |||
+ | **P:** Sie hatten ja vorhin schon mit dem Speedup angefangen. Was ist da denn der Optimale? | ||
+ | |||
+ | Bei k Pipelinestufen ist der asymptotische Speedup k. | ||
+ | |||
+ | **P:** Was hat es denn prinzipiell mit der Superskalarität auf sich? | ||
+ | |||
+ | Mehr schlecht als recht Funktionseinheiten skizziert. Erklärt, dass man daran interessiert ist möglichst alle Recheneinheiten auszulasten, | ||
+ | |||
+ | **P:** Ist doch schön. Aber wieso klappt das mit dem Pipelining doch nicht ganz so? | ||
+ | |||
+ | Ewähnt, dass drei Arten von Hazards. Strukturhazards entstehen bei gemeinsamer Nutzung von Resourcen. Bsp: Gemeinsamer Daten- und Instruktionscache bei Single-Port Speicher wenn BH und OP-Phase; oder bei Funktionseinheiten in superskalaren Architekturen. Datenhazard genannt, wenn Instruktionen voneinander abhängen. Bsp: RAW, WAR, WAW. | ||
+ | |||
+ | **P:** Dann bleiben wir doch mal bei den Datenhazards. Wollen Sie mal ein Beispiel für RAW hinschreiben? | ||
+ | |||
+ | '' | ||
+ | '' | ||
+ | Kurz erklärt, dass der zweite Befehl dann r1 liest bevor der erste das Ergebnis dort hin schreiben konnte. Auf Nachfrage dann angemerkt, dass in OP Phase geholt und in RS Phase geschrieben. | ||
+ | |||
+ | **P:** Was kann man denn gegen RAW machen? | ||
+ | |||
+ | Forwarding angesprochen, | ||
+ | |||
+ | **P:** Wie kann in diesem Zusammenhang das Multi-Threading beitragen? | ||
+ | |||
+ | Erst erklärt, dass mehrere logische Prozessoren, | ||
+ | |||
+ | **P:** Ich wäre noch an WAR interessiert. Wollen Sie dazu mal ein Beispiel nennen? | ||
+ | |||
+ | '' | ||
+ | '' | ||
+ | '' | ||
+ | Erklärt, dass '' | ||
+ | |||
+ | **P:** Also, nun zum Scoreboarding. Können Sie grob den Ablauf skizzieren? | ||
+ | |||
+ | Einfach die vier Phasen DE1, DE2, BA und RS hingeschrieben. Erklärt, dass DE1 WAW Hazards und Strukturhazards löst; DE2 die RAW Hazards löst; und RS die WAR Hazards löst. [siehe Folie 59, Kap 1] | ||
+ | |||
+ | **P:** [Folie 64, Kap 1 vorgelegt] Würden Sie bitte die einzelnen Schritte des Scoreboard Algorithmus näher erklären. | ||
+ | |||
+ | Erklärt, dass warten bis freie FU und keine Instruktion mit gleichem Zielregister bei Issue (WAW). Erklärt, dass warten bis beide Quellregister erzeugt wurden (RAW), falls nötig. Dort ist er dann auf die rechte Spalte eingegangen und wollte wissen, dass die Register nach dem Lesen ' | ||
==== Cache ==== | ==== Cache ==== | ||
Zeile 40: | Zeile 91: | ||
Hingeschrieben, | Hingeschrieben, | ||
- | **P:** Wie kann man dann die Zugriffszeit T veringern? | + | **P:** Wie kann man dann die Zugriffszeit |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | * '' | + | * '' |
- | Hier ging es ein paar mal hin und her. Besser kommt es vermutlich an, wenn man gleich gut vorbereitet ist und das parat hat. | + | Hier ging es bei mir ein paar mal hin und her. Besser kommt es vermutlich an, wenn man gleich gut vorbereitet ist und das parat hat! |
**P:** Wir hatten doch diese Cache-Effekte? | **P:** Wir hatten doch diese Cache-Effekte? | ||
Zeile 55: | Zeile 106: | ||
Kurz die Schleifenzusammenführung angesprochen, | Kurz die Schleifenzusammenführung angesprochen, | ||
+ | |||
+ | ==== Multicore ==== | ||
+ | **P:** Die Zeit ist nahezu um. Können Sie noch das Roofline Modell beschreiben? | ||
+ | |||
+ | Erklärt das operationelle Intensität (Anzahl Instruktionen pro Byte), maximale Rechenleisung und maximale Bandbreite von Relevanz. Für die Roofline gilt dann min(max. Rechenleistung, | ||
+ | |||
+ | **P:** Wir hatten in der Vorlesung zwischen operationeller und arithmetischer Intensität unterschieden. Was war denn der Unterschied? | ||
+ | |||
+ | Operationelle Intensität ist die eigentliche Anzahl der Operationen pro Byte, die auch den Transfer DRAM-Cache berücksichtigt. Arithmetische Intensität ist hingegen eher theoretisch, | ||
==== Eingebettete Prozessoren ==== | ==== Eingebettete Prozessoren ==== | ||
- | **P: | + | **P: |
+ | Die Hierarchie wie sie in der Vorlesung drankam hingeschrieben. Erwähnt, dass GPP teurer und mit mehr Leistungsverbrauch verbunden durch die hohe Flexibilität. FPGA rekonfigurierbar mit LUT und Routing, größere Stückzahlen und billiger als GPP. ASIC für sehr Energie- oder Performance-sensitive Anwendungen am besten geeignet, (in großen Stückzahlen auch?) sehr günstig. [siehe Folie 2 und 26, Kap 3] | ||
**P:** Was genau ist denn hier der Overhead des GPP im Vergleich zu ASIC? | **P:** Was genau ist denn hier der Overhead des GPP im Vergleich zu ASIC? | ||
+ | Erklärt, dass bei GPP Prozessor von Neumannsche Ausführung, |