Die glorreichen 10 – Computerarchitekturen (1)

Heute wieder ein kurzweiliger, trotzdem informativer Blog in meiner locken Reihe „Die Glorreichen 10„, angelehnt an das gleichnamige Fernsehformat von ZDFneo. Es geht um Elemente von Computerarchitekturen also Dingen die den Rechner schneller oder besser machten.

Ich will mich von dem Ranking lösen, also keine Platzierung wie „1-ter Platz“ vergeben und das aus einem guten Grund – es hängt von dem jeweiligen Computer ab. Ein kleines Beispiel: In der x86 Entwicklung brachte die Einführung der Pipeline den größten Performancesprung nämlich 250 Prozent beim Übergang vom 8086 zum 80286. Der nächste Sprung – die Einführung des Caches beim 80386 brachte nur 160 Prozent Geschwindigkeit (so zu verstehen = alte Architektur = 100 %). Langfristig ist der Cache aber der Teil der den Prozessor am stärksten beschleunigt. Der Grund liegt daran, dass langfristig die Geschwindigkeit von Arbeitsspeicher kaum gesteigert wurde. Heute kann DRAM Daten mit einer Verzögerung von 7 bis 10 ns liefern. Das ist zwar 15-mal schneller als 1986, als der 80386 eingeführt wurde, der Takt steig in derselben Zeit aber um den Faktor 300 bis 400. Ein zweiter Grund ist, dass es auch von der Anwendung abhängt. Heute haben alle PC Vektoreinheiten. Wären sie nicht da, der normale PC Nutzer würde nichts bemerken. Supercomputer die dieselben Prozessoren einsetzen, würden aber auf einen Bruchteil ihrer Leistung zurückfallen.

Also legen wir los. Ich weiß, dass es Blogleser gibt, die sich in der Materie noch besser als ich auskennen, ich versuche aber aus didaktischen Gründen und Platzgründen mich auf das Wichtigste zu beschränken. Also habt Verständnis, wenn alles sehr einfach erklärt ist und ihr noch viel dazu beitragen könntet. (Wie wäre es mit einem Gastartikel?) Wer mehr wissen will – es gibt eine ganze Sektion zu dem Thema auf der Website. Und ja ich kann bei 10 Punkten nicht alles hereinnehmen, es gäbe noch einiges mehr zu erwähnen, wie VLIW / Branch Prediction.

Obwohl ich mich für meine Verhältnisse kurz fasse, ist der Artikel doch zu lang für einen Blog geworden, daher heute die ersten fünf Stichwörter und morgen die nächsten fünf.

Von Neumann – Harvard Architektur

Sehr früh in der Geschichte des Computers musste man festlegen, wie der Speicher genutzt wird. Jeder Computer verarbeitet Programme, also Code und die Programme verarbeiten wiederum Daten. Es gibt nun zwei Ansätze wie man den Speicher zwischen Code und Daten aufteilt: Die von Neumann Architektur hat einen gemeinsamen Speicher für Daten und Code. Beide Ansätze sind sehr alt und entstanden schon bei den ersten Computern: Die Harvard Architektur 1944 beim Mark I und die von Neumann Architektur wurde gleich mehrfach entdeckt und sowohl von Zuses Z3, wie auch dem ersten US-Computer ENIAC eingesetzt. John von Neumann fungiert, obwohl er die Theorie erst 1945 aufstellte, trotzdem als Namensgeber, weil vorher man sie einfach umsetzte aber nicht benannte

Die Harvard Architektur hat dagegen getrennte Speicher für Daten und Code. Beide Ansätze sind weit verbreitet. Pcs oder Smartphones haben Prozessoren mit der von Neumann Architektur, da wo die Prozessoren versteckt sind, also in Geräten wie Waschmaschine oder MP3-Player, dominiert die Harvard Architektur. Die von Neumann Architektur hat den Vorteil, dass die beiden Teile Daten und Code variabel sind. Beispiel auf dem PC: Eine Textverarbeitung hat viel Code, die meisten verfassen damit aber eher kurze Texte, also wenige Daten. Eine Videobearbeitung verarbeitet dagegen Videos, also sehr große Datenmengen. Daneben braucht man bei der von Neumann-Architektur nur einen Datenbus, was die Pins die ein Prozessor hat deutlich verringert. Die Harvard Architektur trennt die beiden Busse. Sie können auch unterschiedlich groß sein und unterschiedliche Architekturen haben. Mikrocontroller mit der Harvard Architektur haben meist einen sehr kleinen Codespeicher aus DRAM und einen größeren Datenspeicher in Form von Flash-ROMs. Ein Vorteil ist auch das so der Codespeicher geschützt ist. Code kann sich so nicht selbst modifizieren.

Risc – CISC

Ein zweiter Ansatz eine Architektur aufzustellen liegt in den Befehlen. Sie können sehr elementar sind (RISC – Reduced Instruction Set) oder sehr komfortabel (CISC – Complex Instruction Set). Ein Beispiel: in Zählschleifen hat man oft die Befehlsfolge Dekrementiere Register und Springe wenn Register=0. Dies können zwei Befehle sein (RISC) oder einer (CISC). RISC benötigt weniger Transistoren für eine Architektur, auch weil die Anzahl der Befehle und ihre Leistung großen Einfluss auf die Größe und Komplexität der internen Einheiten eines Prozessors hat. CISC ist, wenn dies keine Rolle spielt meist schneller. Da zumeist mit jeder Generation neue Befehle aufgenommen werden, neigen auch RISC-Architekturen dazu zu CISC zu werden. So waren die weit verbreiteten ARM Prozessoren mal RISC-Prozessoren, doch 30 Jahre nach der Einführung sind sie das nicht mehr.

Heute dominiert RISC noch in dem Segment wo der Preis sehr wichtig ist, bei Microcontrollern. In den späten Achtzigern sah man in RISC die Option einen 32-Bit-Prozessor zu designen und die Aufwendungen dafür zu begrenzen, indem er nicht komplexer als ein 16 Bit CISC-Prozessor ist. Das ermöglichte es Firmen die nicht die Marktmacht von Intel oder Motorola hatten, einen Prozessor einzuführen.

Microcode

Wenn ein Befehl im Prozessor ankommt, gelangt er in den Dekoder und das Steuerwerk in denen das Bitmuster Aktionen auslöst. Diese Teile sind bei einfachen Prozessoren wie z.B. den 8-Bit-Prozessoren meist hardware-verdrahtet. Heute setzen alle größeren Prozessoren Microcode ein. Microcode ist ein ROM im Prozessor. Der Decoder liefert eine Adresse im ROM und dann wird das Bitmuster für einen Befehl – nicht eines, sondern meist mehrere nacheinander aus dem ROM geholt und an das Steuerwerk gesendet. Dabei können auch Schleifen und Verzweigungen realisiert werden. Ein Befehl für das Kopieren eines Blocks kann z.B. in einen Einzelkopierbefehl und eine Schleife zerlegt werden.

Der Vorteil ist, dass man so sehr komplexe Befehle realisieren kann, ohne ein komplexes Steuerwerk und einen komplexen Dekorder zu haben. Bessere Architekturen erlauben auch das Austauschen des Inhalts eines Microcode-ROM, man kann so Fehler beseitigen oder den Microcode verbessern, das geht heute sogar über das Internet, war aber schon (allerdings nur mit physischen Zugriff auf den Baustein) in den Siebzigern möglich, was die Herstellung eines Prozessors oder ein Update deutlich vereinfachte.

Der Nachteil ist, dass Microcode langsamer als die direkte Verdrahtung ist weil er einen Zwischenschritt einschiebt. Bei dem IBM System /360 war es z.B. so, dass die meisten Systeme bis auf die schnellsten Microcode einsetzten, nur die schnellsten waren hardwarekodiert. Bei dieser Linie zeigte sich auch ein anderer Vorteil von Microcode: die gesamte Serie verarbeitete denselben Programmcode, die interne Architektur variierte aber und so auch der Mikrocode, der im ROM war. Das Einstiegssegment hatte eine 16-Bit-Architektur mit wenigen Kilobyte RAM, das Endsegment 32-Bit-Architektur und bis 1 MByte RAM.

Pipelines

Die Ausführung eines Befehls durchläuft im Prozessor mehrere Phasen die unterschiedlich lang sein können und bei komplexen Befehlen sich auch wiederholen können:

• Fetch – Befehl aus dem Speicher holen
• Dekode – Feststellen was man machen muss
• Execute – Befehl ausführen.

Bei jeder dieser Aktion(en) sind andere Teile des Prozessors aktiv. So kam man darauf, diese parallel arbeiten zu lassen. Also der Teil, der mit dem Speicher kommuniziert startet nach einem Fetch einfach schon den nächsten bei der Adresse+1. Das nennt man Pipeline. In der Theorie kann man so bei einer Pipeline von n-Stufen n Befehle parallel abarbeiten und so die Geschwindigkeit um den Faktor n erhöhen – in der Theorie, denn zum einen können Befehle voneinander abhängen, man muss also warten bis ein Befehl ausgeführt ist bevor man den nächsten ausführen kann und zum anderen können die Einheiten auch belegt sein, die Speichereinheit wird nicht nur beim Fetch aktiv, sondern auch, wenn Daten vom Speicher gelesen oder geschrieben werden. Eine Pipeline ist aber ein recht einfacher Weg die Geschwindigkeit eines Prozessors deutlich zu erhöhen. Heute können bei der x86 Linie Pipelines 30 oder 40 Stufen haben, also extrem feingliedrig sein. Das liegt aber auch an den komplexen CISC-Befehlen dieser Architektur, ein RISC-Prozessor kommt dagegen mit 6-7 Stufen aus, auch ein Grund warum diese Architekturen weniger Transistorfunktionen benötigen.

Caches

Seit es Speicher gibt, gab es ein Problem: er war immer langsamer als der Prozessor. Man kann Speicher zwar so schnell machen, dass ein Prozessor nahezu verzögerungsfrei auf ihn zugreifen kann, aber solcher Speicher ist viel teurer als der normale. Caches ist eine Lösung des Problems. Sie basieren darauf, dass Code, aber auch Daten eine große Lokalität aufweisen. Sprich: Es ist sehr wahrscheinlich, dass wenn man Daten aus einer bestimmten Speicherstelle braucht, man bei den nächsten Zugriffen Daten aus benachbarten Speicherstellen braucht. Ein Cache ist ein kleiner sehr schneller Speicher der diese Daten zwischenspeichert, aufteilt in kleine Segmente, die Cachelines. Bei der x86 Architektur ist eine Cacheline immer 32 Bytes lang. Er besteht aus Flip-Flops, einer Schaltung aus 4 bis 6 Transistoren die ein Bit speichert und die genauso schnell wie die Logik ist. Verglichen mit den Speicherzellen eines DRAM-Bausteins brauchen Flip-Flops aber viel mehr Platz und sind aufwendiger zu fertigen und damit ist Cache-Speicher sehr teuer.

Heute sind Caches so wichtig für die Geschwindigkeit das sie sowohl von der Fläche wie auch der Anzahl der Transistoren das vorherrschende Element von Prozessoren sind. Spezielle Serverprozessoren haben meist noch größere Caches als Prozessoren für den Desktop, denn auf ihnen laufen viele Prozesse von unterschiedlichen Nutzern, heute auch mehrere Betriebssysteme parallel.

Anfangs kam man mit einem Cache aus – später L1 (Level 1) Cache genannt, heute ist normal, dass der Prozessor einen sehr schnellen, aber kleinen Level 1 Cache haben, dann einen größeren aber etwas langsameren L2-Cache und dann teilen sich mehrere Kerne noch einen noch größeren aber noch langsameren L3-Cache.