Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 3 » CISC/RISC   (Übersicht)

Prüfung: Rechnerarchitektur (7.5 ECTS)
Prüfer: Prof. Dr.-Ing. Dietmar Fey, Beisitzer Sebastian Rachuj
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 ;-))

Die Prüfungsatmospäre ist recht locker, Papier und Stift wurden gestellt. 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 fast immer geklappt hat.

Ich habe mich bemüht hier die Prüfung so gut wie möglich zu rekonstruieren, aber es kann natürlich sein, dass ich 1) die Reihenfolge zum Teil falsch habe, 2) Fragen/Antworten falsch in Erinnerung habe, oder 3) Fragen einfach hier vergessen habe.

CISC/RISC

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 vom Compiler verwendet werden. Daher also RISC (Reduced Instruction Set Computer).

P: Wodurch zeichnet sich also RISC aus?

RISC (Reduced Instruction Set Computer) hat gleich lange Befehle und man muss explizit die Werte mittels Load/Store laden. Außerdem besitzen diese ein fest verdrahtetes Leitwerk.

P: Sie hatten eben das fest verdrahtete Leitwerk angesprochen. Ist das etwa bei CISC nicht der Fall?

Erklärt, dass CISC Mikroprogrammierung verwendet, welches einen Makrobefehl in eine Folge von Mikroinstruktionen umwandelt. Das ist flexibler und ermöglicht Fehlerbehebung, Befehlskompatibilität und Befehlsemulation. Da aber selten verwendet etwas vergeudet.

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 'RISC-Kern' und 'CISC-Schale'. Die RISC Befehle lassen sich in der Folge besser pipelinen.

Pipelining

P: Was hat es denn mit dem Pipelining auf sich?

Pipeline hingezeichnet, erklärt was BH, BD, OP, BA und RS machen. Erläutert, dass bei CISC alle Stufen fertig bevor nächste Instruktion ausgeführt, bei RISC allerdings sofort nächster Befehl sobald Stufe frei. Daher höherer Durchsatz. Aber Register zwischen den Stufen, also Overhead. Erwähnt das moderne Intel-Chips 20 Stufen. [siehe Folie 18, Kap 1]

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).

P: Aber das ist nicht der Durchsatz. Wie berechnet man den generell den Durchsatz?

Anazhl an Instruktionen pro Zeit.

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 tau = max(tau) + d, Durchsatz also 1/tau. Daher sollten die Stufen alle in etwa gleich lang sein. Auf Nachfrage dann erwähnt, dass das bei CISC eben nicht der Fall.

P: Wieso erhöhen wir eigentlich nicht einfach auf 1000 Stufen?

Ich hatte hier argumentiert, dass man ja den Overhead der Register hat und damit jede Instruktion insgesamt länger brauchen würde. Er wollte hier aber vor allem den energetischen Aspekt der Register hören.

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, man also alle unabhängig voneinander nutzen will. Nach Zwischenfrage zu in-order/out-of-order erwähnt, dass eben in-order installiert wird aber dann out-of-order ausgeführt und zurückgeschrieben. Dann wollte er noch den Begriff Installation geschärft haben, womit hier die Einbringung zur Ausführung auf der Funktionseinheit (FU) gemeint ist.

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?

add r1, r2, r3
add r4, r1, r6
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, dass das Ergebnis der ALU wieder zu den Eingängen zurückgeführt wird damit der nachfolgende Befehl dieses als Operand verwenden kann.

P: Wie kann in diesem Zusammenhang das Multi-Threading beitragen?

Erst erklärt, dass mehrere logische Prozessoren, aber nur ein physikalischer. Die Threads haben eigene Register etc., aber teilen sich Rechenwerk. Unter der Annahme, dass die Threads datenunabhängig laufen (das wollte er auf Nachfrage nochmal explizit hören) kann z.B. zwischendurch ein anderer Thread laufen, womit beim aktuellen mehr Zeit für das Rückschreiben bleibt. Daher also geringere Wahrscheinlichkeit für RAW.

P: Ich wäre noch an WAR interessiert. Wollen Sie dazu mal ein Beispiel nennen?

div r1, …
add r0, r1, r2
sub r2, r3, r4
Erklärt, dass div relativ lange braucht und sowohl add als auch sub installiert werden, der add-Befehl aber warten muss bis r1 von div ausgerechnet wird, dabei aber das sub schon das von add benötigte r2 überschreibt. (Hier hatte ich erst versehentlich statt r2 nochmal r1 verwendet, auf Nachfrage aber ausgebessert.)

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 'freigegeben' werden. Erklärt, dass bei Write Result gewartet wird bis alle Instruktionen das Zielregister gelesen haben (WAR). Insbesondere wollte er hier die Verbindung zwischen Ri,j=No bei den Operanden und der Abfrage bei Write Result hören. Das Zielregister darf dadurch sofort schreiben sobald gelesen wurde und muss nicht auf die eigentliche Beendigung warten.

Cache

P: Gut, machen wir mal weiter mit dem Cache. Wir hatten da doch ein theoretisches Modell für den Zugriff kennengelernt.

Hingeschrieben, dass T = T_h + m * T_m, erklärt was die einzelnen Bestandteile bedeuten.

P: Wie kann man dann die Zugriffszeit T veringern?

  • T_h: Kleineren Cache mit geringerer Schaltungkomplexität bzw. Pfaden; geht auf Kosten von m.
  • m: Wechsel von direkt abbildend auf n-fach assoziativ; Vergrößerung des Caches; geht auf Kosten von T_h.
  • T_m: Einführung eine L2-Cache, dann wird T_m wieder rekurziv zu der eben beschriebenen Formel.

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? Können Sie die mal nennen?

Angefangen mit Struct of Arrays vs Arrays of Structs als Bsp. auf Papier, erklärt das man hier ausnützt das im Array of Structs die beiden Werte direkt nebeneinander im Cache stehen. Auf Nachfrage bemerkt, dass räuml. Lokalität ausgenutzt. Danach Schleifenvertauschen hingeschrieben, angesprochen, dass, wenn ungeschickt, man mit großem Stride durch Array wandert. Wieder auf Nachfrage bemerkt, dass räuml. Lokalität ausgenutzt. (Hier hatte ich mich erst verhaspelt und zeitl. Lokalität genannt.)

P: Gut, wir haben jetzt nur noch zwei Minuten. Können Sie mal nur noch ganz grob die anderen beiden Cache-Effekte erklären?

Kurz die Schleifenzusammenführung angesprochen, dass hier evt. Werte die noch aus der vorherigen Schleife im Cache liegen und wiederverwendet werden. Auf Nachfrage bemerkt, das hier tatsächlich zeitl. Lokalität ausgenutzt. Dann noch kurz Blocking, dass hier z.B. bei der Matrix-Matrix-Multiplikation versucht wird möglichst alle Blöcke im Cache zu behalten.

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, max. Bandbreite * op. Intensität). Den Graphen hingezeichnet und erklärt, dass links memory-bound und rechts compute-bound.

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, indem einfach die Anzahl der Operationen und die Codegröße betrachtet wird, also quasi 'kostenfreier' Zugriff durch Cache. (Hier hatte ich die beiden in der Prüfung leider verwechselt.)

Eingebettete Prozessoren

P: Trotzdem noch kurz zu Kapitel 3. Wollen Sie mir kurz die Unterschiede von ASIC, FPGA und GPP skizzieren?

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?

Erklärt, dass bei GPP Prozessor von Neumannsche Ausführung, d.h. wir haben Register, eine ALU mit unterschiedlichen Ops und einen Befehlssatz. Letzten Endes dann am Beispiel if (a+b)<c hingezeichnet wie GPP und ASIC aussehen würden. [siehe Folie 27, Kap 3]