Archiv verlassen und diese Seite im Standarddesign anzeigen : Vorteile von VLIW-Architekturen?
CrazyIvan
2004-01-30, 09:52:58
Komme gerade aus meiner ReOrg Vorlesung ohne befriedigende Antwort auf diese Frage...
Also worin bestehen nun die Vorteile einer VLIW-Architektur, wie sie ja z. B. Transmeta benutzt, gegenüber einer Vektor- oder einer superskalaren Architektur?
Vor allem hinsichtlich Effizienz und Parallelisierung.
Wäre Euch für Antworten sehr dankbar... :)
Matti
2004-01-30, 11:42:47
VLIW braucht afaik weniger Transistoren, als superskalar.
Eine Vektor-Architektur ist nur sinnvoll, wenn man oft den gleichen Befehl auf verschiedene Daten anwendet, in allen anderen Fällen sind VLIW und superskalar besser.
mrdigital
2004-01-30, 12:14:16
Mit Verlaub, Matti, dein Vergleich klingt für mich wie: "Dieselmotoren brauchen weniger Zylinder als Benzinmotoren". Nicht dass ich dir nun VLIW im Detail erklären könnte, aber per se braucht weder das eine noch das andrere mehr oder weniger Transitoren, es ist immer eine Frage dessen, was ich damit machen will und wieviel (Transistoren)Aufwand man betreiben will
Schroeder
2004-01-30, 12:33:38
lasst mich mal bitte nicht dumm sterben, was ist denn eine VLIW-Architektur?
Matti
2004-01-30, 12:49:30
bei VLIW muß ein Compiler die Optimierung für die Parrallel-Arbeit machen, bei superskalar macht das die Hardware in Echtzeit. Deshalb braucht superskalar mehr Transistoren. Bin mir aber nicht 100%ig sicher, dieses Thema liegt schon 2 Jahre zurück ;)
Der Crusoe ist auf den ersten Blick superskalar, aber in Wirklichkeit wird die Optimierung von einer im CPU-Kern integrierten Software gemacht. Der optimierte Code wird in einem speziellen Teil des RAMs gelagert, und wenn er nochmal ausgeführt werden muß, steht sofort der optimierte Code zur Verfügung. Also der Crusoe ist VLIW. Profitieren kann er aber davon nur in Schleifen, denn Code der nur 1x abgearbeitet wird, kann der Crusoe nicht optimieren.
Schroeder
2004-01-30, 12:53:03
aha, danke das hilft etwas @ matti
und äh was heißt VLIW?
das ist doch mit sicherheit eine abkürzung für irgendwas, oder?
Matti
2004-01-30, 12:58:03
Very Long Instruction Word
->mehrere Befehle werden zu einem sehr langen Befehl zusammengefaßt, und deshalb können mehrere Befehle in 1 Takt ausgeführt werden.
Schroeder
2004-01-30, 13:04:41
Original geschrieben von Matti
Very Long Instruction Word
->mehrere Befehle werden zu einem sehr langen Befehl zusammengefaßt, und deshalb können mehrere Befehle in 1 Takt ausgeführt werden.
aha, langsam geht mir ein lichtlein auf :idea:
edit. dankeschön.
CrazyIvan
2004-01-30, 13:55:39
Nagut,
alles bisherige wusste ich auch. Und soweit ich das mitbekommen habe, ist der Vorteil von VLIW-Rechnern gegenüber Vektorrechnern, dass Operationen auf verschiedene Datentypen parallelisiert werden können (also z. B. integer und float).
Aber wie soll das ganze funktionieren. Kann mir das net so recht vorstellen, während ich bei superskalaren und Vektorrechnern noch halbwegs mitkomme.
BTW
Kennt jemand von Euch noch andere VLIW-CPUs als den Crusoe. Der ist ja aufgrund der (quasi) fest verdrahteten Code - Morphing Software ein eher atypisches Exemplar.
Zecki, Demi, wo seit Ihr??? ;D
Bokill
2004-01-30, 14:39:57
VLIW
kommt ja auch bei vielen kleinen unscheinbaren schwarzen Käfern vor.
Ob nun Video oder Audio, diese sind hochspezialisiert. Zum einen sind die verdrahteten Funktionen sehr schnell aber auch die Organisation/Anordnung der Daten hilft da sehr.
Wenn diese speziellen Einheiten diese Datenportionen nun nicht Bitweise sondern gleich in vielfach Bitbreite bekommen, dann ist der Durchsatz viel besser.
Der Transmeta ist ja nicht nur ein VLIW- Prozessor, sondern hat das Codemorphing CMS. Durch Codemorphing werden Transistoren durch Software gleichsam eingespart.
Die erste Inkarnation de Transmeta konnte Datenhappen von 128 Breite intern verarbeiten, bekam aber Leistungsprobleme, wenn intern nicht immer schnell diese 128 Bit aufgefüllt werden konnten.
Die aktuellen Efficeon können Datenportionen von 256 Bit Breite verarbeiten und sollen nicht mehr so allergisch reagieren, wenn mal doch nicht die gesamte Dantenhappenbreite möglich ist.
x86 ist ja derzeit auf 32Bit breite Datenhappen ausgelegt, auch wenn die "Busse" dahinter (L1 zu L2 Cache, Speicherinterface) durchaus breiter sein können.
AMD64 und die Hardware (Soll ja bald nicht nur die Hammerfamilie sein ;-) ) ist dafür ist ja auf eine Datenhappenbreite von 64Bit ausgelegt.
MFG Bokill
Demirug
2004-01-30, 14:59:40
Bei CPUs ist VILW nicht sonderlich verbreitet.
Bei DSP und Medienprozessoren findet man es dagegen öfter. Auch Grafikchips sind durchaus als eine besondere Form von VLIW-Chips anzusehen.
Ist der Itanium nicht ein VLIW Prozessor?
Stone2001
2004-01-30, 16:05:40
Original geschrieben von RoKo
Ist der Itanium nicht ein VLIW Prozessor?
Nicht ganz, er ist ein EPIC-Prozessor!
EPIC = Explicit Parallel Instruction Computing ist als eine Mischform von Superskalaren und VLIW Prozessoren anzusehen! (obwohl es nicht ganz stimmt).
VLIW bezieht sich doch nur auf die Instructions und somit ist EPIC eine VLIW Architektur.
EPIC ist eine andere Ausdrucksweiße für VLIW, beide beschreiben das gleiche Prinzip.
GloomY
2004-01-30, 23:24:16
Original geschrieben von Coda
VLIW bezieht sich doch nur auf die Instructions und somit ist EPIC eine VLIW Architektur.
EPIC ist eine andere Ausdrucksweiße für VLIW, beide beschreiben das gleiche Prinzip. Ack, wobei EPIC eben eine spezielle VLIW Architektur ist.
Vorteile von VLIW sind, dass die Befehle lang sind ;) Ja genau, denn wenn man richtig viel Platz zum Codieren hat, kann man unglaublich viele Informationen reinstecken. Nicht einfach nur Opcode, Quell- und Zielregister, damit der Prozessor weiss, was er zu tun hat sondern z.B. auch Informationen über Parallelität, bedingte Sprünge, spekulative Loads, Prioritäten bei der Befehlsausführung uvm.
Außerdem kann man die Anzahl der Register im Prozessor vergrößern, weil man eben auch so viel Platz hat, diese in den Befehlen zu Codieren (je mehr Register, desto mehr Platz wird beim Codieren verbraucht). Mehr Register bedeuten im Normalfall bessere Performance :)
Demirug
2004-01-30, 23:48:37
GloomY, bist du dir sicher das du das VLIW Konzept verstanden hast?
Solche Zusatzinformationen wie du sie aufführst haben nur am Rande etwas damit zu tun.
Gehen wir von einem Prozessor aus der 3 ALUs hat. Bei x86 Ansatz habe ich nun Befehle die jeweils nur eine ALU ansprechen können. Die CPU muss selbst entscheiden wie sie nun solche Befehle auf die 3 ALUs verteilt. Bei einer VLIW Architektur enthält der Befehls (das VLIW) Steueranweisungen für alle 3 ALUs. Aus diesem Grund ist der Befehl auch viel grösser als bei einer "normalen" CPU Architektur.
Der Vorteil ist das die gesamte Logik für das Verteilen der Anweisungen auf die Funktiosneinhiten entfällt. Der Nachteil ist allerdings das VLIW Code meist nur von einem spezifischen Prozessor ausgeführt werden kann. Es ist durchaus wahrscheinlich das sich beim Nachfolgemodel der Code geändert hat und man alles neu compilieren muss.
GloomY
2004-01-31, 16:41:00
Original geschrieben von Demirug
GloomY, bist du dir sicher das du das VLIW Konzept verstanden hast?Nicht so sicher wie bei anderen Sachen...
Original geschrieben von Demirug
Solche Zusatzinformationen wie du sie aufführst haben nur am Rande etwas damit zu tun.
Gehen wir von einem Prozessor aus der 3 ALUs hat. Bei x86 Ansatz habe ich nun Befehle die jeweils nur eine ALU ansprechen können. Die CPU muss selbst entscheiden wie sie nun solche Befehle auf die 3 ALUs verteilt. Bei einer VLIW Architektur enthält der Befehls (das VLIW) Steueranweisungen für alle 3 ALUs. Aus diesem Grund ist der Befehl auch viel grösser als bei einer "normalen" CPU Architektur.
Der Vorteil ist das die gesamte Logik für das Verteilen der Anweisungen auf die Funktiosneinhiten entfällt. Der Nachteil ist allerdings das VLIW Code meist nur von einem spezifischen Prozessor ausgeführt werden kann. Es ist durchaus wahrscheinlich das sich beim Nachfolgemodel der Code geändert hat und man alles neu compilieren muss. Gut, aber gerade weil im Code festhalten wird, wie ein Befehl alle Ausführungseinheiten ansteuert, sind die oben angesprochenen Optimierungen möglich. So ganz zusammenhangslos ist das nun auch nicht.
Übrigends ziehe ich meine Aussage zurück, dass EPIC eine spezielle Form von VLIW sei.
Stone2001
2004-01-31, 19:34:54
Eine eigenständige Architektur?
Die EPIC-Achitektur bietet zuviel Möglichkeiten, um sie als spezielle Form von VLIW zu bezeichnen.
GloomY
2004-02-01, 01:58:14
Original geschrieben von Coda
Sondern? Eine Mischung aus traditionellem Superskalar und VLIW.
Die Verteilung, welcher Befehl in welche Ausführungseinheit hineinkommt, ist bei EPIC nicht fest, bei VLIW schon.
Ich hab' da gestern (als ich eigentlich etwas anderes bei Google gesucht habe) eine sehr nette Grafik dazu gesehen, leider kann ich sie heute nicht mehr finden :|
Naja das ist ja schon richtig, aber ich finde das hat trotzdem nichts damit zu tun.
Ein "Very Long Instruction Word" hat EPIC trotzdem, in der Bezeichung ist keine Beschreibung enthalten was die CPU dann damit macht ;)
vielleicht mal global aufraeumend:
vliw bezeichnet zwar das instruktionswort, aber nicht nur das. es definiert so gesehen auch das scheduling der befehle auf die alus. bei reinem vliw wird also z.b. der erste befehl eines befehlswortes auf die integer, das zweite auf die mem und das dritte auf ne float-alu gelegt. GANZ STARR!! Von der Position des Befehls weiss der Prozessor also, welcher befehl auf welche Einheit kommt. Alle befehle eines instruktionswortes sind voneinander unabhaengig und koennen ohne zu warten direkt verarbeitet werden. Dafuer hat der Compiler gesorgt, der fuer die jeweilige vliw-architektur speziell compilieren muss. das heisst auch, dass ein neuer Prozessor auch einen neuen compiler benoetigt, damit man von mehr alus auch mehr leistung hat.
der compiler hat also die gesamte arbeit des schedulings am hals, auch was zeit-abhaengigkeiten angeht, wenn befehle laenger dauern als andere etc.
zusammengefalls: vliw : kein scheduling, viele befehle in einem wort, starre zuordnung.
durch dieses wegfallen des scheduling hat man dann auch den spareffekt bei transistoren.
Allerdings spar man dadurch nicht an code-laenge, da bei geringer code-parallelitaet viele nops gesetzt werden muessen, um codewoerter noetigenfalls zu fuellen.
bei epic hat man auf einmal wieder ein scheduling. Die Befehle sitzen zwar immernoch zu mehreren (drei) in einem Wort (von 128bit), aber sie werden nicht starr zugeordnet, wie es bei reinem vliw der fall waere. Die Alu die frei ist bekommt den befehl. Dadurch profitiert man von mehr alus bei gleichem Code. Obendrein muss die parallelitaet, also dir unabhaengigkeit der Befehle nicht schon bei nur einem Codewort aufhoeren. Es gibt "stop-felder" zwischen unabhaengigen Bloecken von Befehlen. Die Bloecke selbst werden dann vom scheduler zu jeweils zwei worten verarbeitet (im Moment. dies zu erhoehen bleibt der zukunft ueberlassen, ebenfalls im Gegensatz zu vliw, wo das so ohne weiteres nicht moeglich ist) und dynamisch auf die alus verteils bis es nicht mehr geht. Wenn es also auf einmal (bei der naechsten Generation des prozessors) mehr alus gibt, so profitiert _jeder_ code davon und muss nicht erst neu compiliert werden.
(ich hoffe es ist klar geworden, ist ein bisschen wirr...)
(hab mal nen vortrag darueber gehalten... http://www.whurst.net/ihensler/ps/epic.ps.gz )
dass bei ia64 dennoch so riesige prozessoren rauskommen ist hauptsaechlich durch die ia32 einheit begruendet, weil man zur kompatiblitaet gewissermassen nen pentium nochmal mit rein packen musste... ausserdem die riesigen caches, die die "voraussage-befehle" abfangen muessen.
dass es auch kleiner und billiger geht beweisen die hp-drucker, in denen ebenfalls epic-prozessoren werkeln. ob windows64 drauf laufen wuerde weiss ich nicht, linux sicherlich.
der Vorteil von VLIW verbleibt also das wenige silizium, das man fuer so etwas verbraten muss. Allerdings duerfte das wieder durch erhoehte codelaengen und dadurch mehr noetigen Speicher wieder aufgefressen werden.
CrazyIvan
2004-02-01, 16:16:52
@ immi
Danke für die Ausführungen. Jetzt hab ich, was ich wollte.. :)
Bokill
2004-02-07, 07:35:08
@immi
Super Beitrag!
Habs auf P3D mit Link und ausdrücklich deinem Namem nochmals zitiert.
Sehr kompakt und effektiv ausformuliert, is eine Auszeichnung wert ;) :)
MFG Bokill
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.