Was ist eigentlich genau SSE?

[Mantikor]

Tach,

Ich als relativ unerfahrener Schüler in Sachen Computerinterna stößt hier desweilen beim Durchlesen der ganzen Treads öfters auf den Begriff SSE (1,2..), welchen ich zwar mittlerweile etwas "einordnen" konnte, aber immer noch nicht verstehe was genau es eigentlich ist.
Wäre nett, wenn der ein oder andere ein paar interessante Informationen zum Thema SSE hat oder gute Links kennt. Falls es in der Materie doch etwas zu schwierig ist, fände ich es toll, wenn einer der "Gurus" mir eine kurze Oberflächlichkeitserklärung geben könnte.

Danke im Voraus

Mfg Der Mantikor

[mrdigital]

SSE (1,2,3) ist eine Befehlssatzerweiterung für x86 Prozessoren. Es ist eine Weiterentwicklung von MMX (das steht für Multi Media eXtension). Es handelt sich hierbei um Befehle, die sich bei der Bearbeitung von Audio und Videodaten besonders gut eignen. Bei dieser Art von Daten ist es häufig so, das man den selben Befehl (z.B. multiplizieren) auf viele Daten anwenden muss. Hier liegen die Särken von SSE, einen Befehl gleichzeitig auf mehrere Daten anwenden (SIMD - Single Instruction Multiple Data). Man kann seit SSE2 auch "klassische" FPU (Floating Point Unit) Aufgaben mit diesen Befehlen bearbeiten. Das war mal eine Grobzusammenfassung ;)

[incurable]

Und nicht vergessen:

iSSE macht das Internet schneller! :up: :naughty:

[Peppo]

@mrdigital

MMX heißt in wirklichkeit Matrix Math eXtension.
Multi Media Extension wurde aus marketingtechnischen Gründen genommen. ;)

[Benedikt]

SSE (1,2,3) ist eine Befehlssatzerweiterung für x86 Prozessoren. Es ist eine Weiterentwicklung von MMX (das steht für Multi Media eXtension). Es handelt sich hierbei um Befehle, die sich bei der Bearbeitung von Audio und Videodaten besonders gut eignen. Bei dieser Art von Daten ist es häufig so, das man den selben Befehl (z.B. multiplizieren) auf viele Daten anwenden muss. Hier liegen die Särken von SSE, einen Befehl gleichzeitig auf mehrere Daten anwenden (SIMD - Single Instruction Multiple Data). Man kann seit SSE2 auch "klassische" FPU (Floating Point Unit) Aufgaben mit diesen Befehlen bearbeiten. Das war mal eine Grobzusammenfassung ;)
Und deswegen heißt es "streaming", weil die Daten quasi im Strom (nacheinander) "daher kommen", und bearbeitet werden?
Ist das dann mit der quasi-Eignung der P4-Architektur für Multimedia/Streaming gemeint?

MFG,
B. W.

[mrdigital]

Ja genau, man will Daten mit immer der selben Operation bearbeiten. MPEG oder MP3 (De)Kodierung sind hier Paradebeispiele. Der P4 ist nun so konsturiert, dass er eben einen hohen Datendurchsatz hat, wenn man immer die selbe Instuktionenfolge wiederholt auf den Daten anwendet. Hier kann die lange Pipeline ihre Stärken voll ausspielen. Der "Performance-Katastrophen-Fall" ist es, wenn man die Daten und Befehle, die in der Pipe stecken wegwerfen muss, weil man festgestellt hat, das man nun eine andere Befehlsfolge abarbeiten muss (das passiert immer dann, wenn die Sprungvorhersage sich geirrt hat): D.h. Code mit vielen Sprüngen (und einen Sprung gibts an der Stelle, wo man eine Entscheidung treffen muss, a > b oder c = 0 oder so was) ist für CPUs mit langen Pipelines ungünstig, denn wenn jedes mal die lange Pipe weggeworfen wird, muss man sie wieder füllen ;) Kurze Pipes werden hier nicht so stark getroffen (das Wiederbefüllen geht halt schneller).

[Negative Creep]

Nur kurze Zwischenfrage... Seit welcher Prozessorgeneration werden CPUs mit RISC Architektur gebaut und hat der Celeron CISC oder RISC

[mrdigital]

Seit dem AMD K6 und dem Pentium Pro. Alle Auskopplungen der jeweilig aktuellen Prozessorgeneration (P2 / P3 / P4 und die zugehörigen Celerons oder bei den Athlons eben die Duron CPUs) basieren immer auf dem selben Kern wie das zugehörige Spitzenmodell.
Demnach sind alle Celerons im Kern RISC Maschinen.

[BlackBirdSR]

Seit dem AMD K6 und dem Pentium Pro. Alle Auskopplungen der jeweilig aktuellen Prozessorgeneration (P2 / P3 / P4 und die zugehörigen Celerons oder bei den Athlons eben die Duron CPUs) basieren immer auf dem selben Kern wie das zugehörige Spitzenmodell.
Demnach sind alle Celerons im Kern RISC Maschinen.

K5 auch schon.
Der Erste war trotzdem der PPro.

[StefanV]

Hm, war nicht der NX5x86 auch ein RISC?? :|

[Coda]

Der Pentium hatte aber auch schon nen Decode, der konnt nur noch keine Out-Of-Order Execution.

[BlackBirdSR]

Der Pentium hatte aber auch schon nen Decode, der konnt nur noch keine Out-Of-Order Execution.

War trotzdem ein CISC Chip.
Wenn auch Superskalar, also mehr als einen Befehl/Takt

@Payne:
Stimmt den hatte ich vergessen.
´94 oder so müsste der das Licht der Welt erblickt haben

[Coda]

Naja wie trennst du dann CISC und RISC? Die internen Befehle vom Pentium waren sicher auch nicht mehr CISC.

[BlackBirdSR]

Naja wie trennst du dann CISC und RISC? Die internen Befehle vom Pentium waren sicher auch nicht mehr CISC.


Nach Allem was ich weis, waren sie genau das.
Befehle wurden nicht direkt in µOps zerlegt, [sondern direkt als Operationen ausgeführt.]
durch den Microcode geschickt und dann bearbeitet.

edit: Das in den Klammern gefällt mir nicht.
Ansonst ist das Ganze eh eine Sache für die Geschichstbücher.

Es gibt keine echten RISCs und keine echten CISCs mehr.
Hängt nur noch vom Befehlsformat ab.

[Negative Creep]

Nur für die nicht wissen über was wir reden:

CISC: Ein Befehl wird im ganzen vom CPU innerhalb von mehreren Taktzyklen bearbeitet. Braucht keine große Chache

RISC: Ein längerer Befehl wird zerlegt, so dass die einzelnen "Datenfragmente" in jeweils einem Takt bearbeitet werden. Bracht größere Chache

/Edit... Ganz einfach ausgedrückt. :P

[Muh-sagt-die-Kuh]

Nur für die nicht wissen über was wir reden:

CISC: Ein Befehl wird im ganzen vom CPU innerhalb von mehreren Taktzyklen bearbeitet. Braucht keine große Chache

RISC: Ein längerer Befehl wird zerlegt, so dass die einzelnen "Datenfragmente" in jeweils einem Takt bearbeitet werden. Bracht größere Chache

/Edit... Ganz einfach ausgedrückt. :PZu einfach und auch nicht ganz richtig ausgedrückt ;)

RISC und CISC beziehen sich eigentlich nur auf den Befehlssatz (Instruction Set Architecture), wie das ganze intern umgesetzt wird tut nichts zur Sache. Ein RISC Befehlssatz stellt nur die nötigsten Befehle (Load, Store, ALU-Operationen, Branches) zur Verfügung, aus denen sich dann komplexere Operationen zusammensetzen lassen....die 32 bit MIPS ISA ist ein gutes Beispiel für einen solchen Befehlssatz. CISC Befehlssätze bieten zusätzlich zu diesen elementaren Befehlen noch einige komplexe an, ein Beispiel hierfür sind die String-Operationen der x86 ISA.

Wer eine ganz ausführliche Betrachtung zu dem Thema RISC und CISC haben möchte....die gibts hier (http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html).

[GloomY]

Ich möchte doch ebenso wie mein Vorposter anmerken, dass sich eine echte RISC Architektur bzw. der Unterschied CISV <-> RISC nicht nur dadurch auszeichnet, ob Befehle intern in ein anderes Format zerlegt werden.

RISC sieht als einzigste Speicheroperation das Laden bzw. Speichern eines Registers mit/von einer Adresse vor. Daher wird auch manchmal Load/Store- Architektur als synonym für RISC benutzt. (Es gibt keine absolute oder indirekte Adressierung, wie man sie z.B. von x86 kennt).

Eine weiterer wichtige Eigenschaft ist die konstante Länge der codierten Befehle, welche den Dekodierungsvorgang erleichtern. (Ja, auch RISCs dekodieren noch intern, insofern ist das obige Argument mehrfach Blödsinn).

Historische Ansätze von RISC waren eine hohe Anzahl an Prozessorregistern (sowohl GPR als auch spezielle Register). Das ist aber heutzutage kein Unterscheidungsmerkmal mehr, da es durchaus andere Architekturen mit vielen Registern gibt (Itanium), welche man aus anderen Gründen nicht als "RISC" einordnung würde.
Eine weitere historische Sache war die konsequente Ausnutzung von Instruction-Level-Paralism (ILP), zuerst mit Pipelining, dann mit superskalaren Prozessoren (und wenn die EV8 gekommen wäre auch mit extensivem Multithreading). Ausnutzung von ILP ist aber heutzutage ebenso wie eine hohe Registeranzahl kein Alleinstellungsmerkmal für eine RISC-Architektur.


Zusätzlich dazu ist RISC ein Philosophie, wie man einen Chip baut. Dabei geht es vor allem darum, für Dinge nicht zu viele Transistoren zu verschwenden, die kaum etwas bringen. Amdahl's Law lässt grüßen ;)
Das zeigt sich u.a. eben auch in den Befehlen der ISA (Instruction Set Architecture). IMHO besitzt keine einzige RISC CPU Befehle für z.B. Sinus, Cosinus oder Exponentialfunktion wie man sie z.B. bei x86 findet. Diese Befehle kommen viel zu selten in durchschnittlichen Programmen vor, als dass es sich von einem (Transistor-)Aufwandt/Nutzen Standpunkt lohnen würde, diese zu implementieren. RISC Architekturen verzichten mit Absicht auf solche Dinge, um dann an anderen Stellen, bei denen es sich (eher) lohnt, diese gewonnenen Transistoren wieder 'reinzubuttern ;)

Zusätzlich dazu ist das Layout des Chips weniger komplex und man kann die kritischen Stellen für die Taktfrequenz besser optimieren. Es kam nicht von Ungefähr, dass die erste Alpha 21064 bei ihrer Einführung zwei- bzw. dreimal so hohe Taktraten hatte wie die schnellste x86 CPU zu der Zeit (200 MHz gegenüber 100 MHz 486 bzw. 66 MHz Pentium1). Der Layoutnachteil ist wohl heutezutage nicht mehr wirklich groß vorhanden. Dazu sind die Transistorzahlen wohl zu groß geworden, als dass man nur noch von mehr oder weniger komplex reden kann. Außerdem haben sich die meisten Prozessoren vom traditionellen RISC- bzw. CISC hin zu Hybrid-Lösungen gewandt. Man kann also nur noch von graduell RISC bzw. CISC reden. Die Sparcs sind (nach Compaqs und HPs glorreichem Absägen der Alphas am grünen Tisch) wohl noch die lebende ISA, die man am ehesten als rein RISC bezeichnen kann.