Hi. Ich hab ein Buch, in welchen behauptet wird dass dynamische Sprungvorhersage bei VLIW unmöglich und bei EPIC Architekturen schwer möglich ist. Ich sehe irgendwie keinen Grund dafür, kann das jemand erläutern? Nach allem was ich jetzt gelesen habe, schien es mir so zu sein, dass es einfach eine Designentscheidung ist, man will soviel wie möglich den Compiler übernehmen lassen.
Wüsste auch gerne warum das bei VLIW unmöglich sein sollte. Und EPIC
versucht zwar, die Anzahl von Sprüngen durch predication zu reduzieren,
aber ganz ohne geht's da auch nicht.
Sicher gibt's ein paar neue Hürden. So können VLIWs möglicherweise
mehrere Sprünge pro Befehl enthalten. Aber das ist nicht wirklich ein
Hindernis, denn das fügt der Vorhersage lediglich eine Ebene hinzu
("welcher isses denn?").
Wen es noch interessiert: Da ich mit VLIW und EPIC nun rein garnichts anfangen konnte, hab' ich mal gegoogelt u.a.: http://www.tecchannel.de/server/hardware/402288/index5.html seite 5 von 17, geht also noch weiter.
Ich könnte mir vorstellen, dass eine dynamische Sprungvorhersage extrem kompliziert ist - eben genau wegen dem VLIW. Schon bei aktuellen x86er ist die Sprungvorhersage eine der kompliziertesten Geschichten in der CPU.
VLIW hat mehrere Spruenge per Zeile ? Eher nicht. Wie soll denn das gehen ?
3349 wrote: > VLIW hat mehrere Spruenge per Zeile ? Eher nicht. Wie soll denn das > gehen ? Warum sollte das bei bedingten Sprüngen nicht gehen? Es kann nur nicht mehr als einer davon tatsächlich ausgeführt werden. Stell dir mal die Realisierung eines switch-Statements vor, wenn eine Tabelle keinen Sinn ergibt.
I_ H. wrote: > Ich könnte mir vorstellen, dass eine dynamische Sprungvorhersage extrem > kompliziert ist - eben genau wegen dem VLIW. Sehe ich nicht. AMDs Architekturen erinnern seit K7/Athlon bereits etwas an VLIW. Die branch prediction arbeitet in 16 (K7-K8) bis 32 (K10) Byte breiten fetch blocks, wobei mit Einschränkungen mehrere darin enthaltene branches parallel gehandhabt werden (wenn maximal einer davon dynamisch ist). Danach werden (interne) Befehle in Zeilen aus 3 Stück bis zum retirement parallel durchgeschoben. Das ist natürlich noch nicht das Ende, eben die dynamische Vorhersage von mehreren gleichzeitig fehlt noch. Und AMDs predictor ist dafür nicht unbedingt ideal, aufgrund der Abhängigkeit verschiedener branches untereinander. Aber local predictors (vgl. P3) geht das problemlos. Branch prediction wird auch deshalb immer komplexer, weil Fehler darin meist keine dramatischen Auswirkungen haben und die Designer sich folglich fast ad infinitum austoben können. Immerhin arbeiten die Verfahren meist fail-safe, weil weiter hintern ja ohnehin alles nochmal kontrolliert wird. Einzig eine target instruction prediction ist kritisch - prompt war AMD beim branch target line cache des ersten K6 da auch reingetappt.
Intel hat die lange Pipeline mit der Netburst Architektur beim P4 als Irrweg eingestuft. Es geht wieder mit PIII bzw Pentium M Technologie weiter.
Naja, so'n VLIW und auch EPIC Design ist aber was ganz anderes als eine aktuelle x86 CPU. K10 und P3 sind auf massives out-of-order ausgelegt, weil sonst nix bei rauskommt. Da wird "wild" mit irgendwelchen Sprungvorhersagealgorithmen rumspekuliert, der Befehlssatz vollständig umcodiert, das Zeugs auf Shadowregister verteilt usw. Dementsprechend steckt in x86 CPUs extrem viel Entwicklungsaufwand. Die Dinger sind bei "üblichen" Sachen zwar effizienter als die ganzen anderen Desings (Power, Itanium usw.), aber auch 10mal so kompliziert. Heute stampft niemand mal eben einen guten x86er aus dem Boden, allein die Tatsache das alle heutigen Designs ziemlich alte Vorfahren haben zeigt denke ich, wie schwer sowas ist (K10 -> nicht unähnlich K6, und K6 lief früher mal als NexGen 686; Core Duo -> P3 -> PPro; Via wieauchimmer -> IDT Winchip). Der einzige Herteller der sich mit VLIW bei x86 probiert hat war Transmeta. Die CPU war - wie für VLIW typisch - ziemlich einfach aufgebaut und hatte trotzdem brachiale Rechenleistung. Der Großteil ging allerdings für's Codemorphing drauf. Also man könnte sicher eine VLIW Architektur mit dynamischer Sprungvorhersage bauen, aber einmal wird die dann noch komplizierter, und zum anderen entspricht das auch garnicht der VLIW-Philosophie. Die Dinger sind nicht für Spiele oder Desktop gedacht, sondern für numerische Berechnungen. Die "Dynamik" bei der Befehlsausführung wie x86er (irgend'n Code in dem alle 3 Behfehle ein bedinger Sprung drinnen ist, und die CPU führt's so aus als wär kein einziger Sprung drinnen) erreicht VLIW schon prinzipbedingt nicht. EPIC auch nicht. Man muss sich mal vor Augen halten, das ein aktueller Opteron mit ca. 100Mio Transistoren in ähnlichen Bereichen wie ein Itanium mit x-mal so vielen Ausführungseinheiten und 2Mrd Transistoren liegt. Außer man lässt den Itanium das machen was er wirklich kann. Muss aber dazusagen, dass ich bei dem Thema inzwischen etwas raus bin. Daher sowenig handfeste Details.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.