Komplettes Neu-Design einer Allzweck-CPU als "belt machine"
-
Ihr kennt sicherlich Modelle wie "Stapelmaschine" (stack machine) oder "Registermachine" (register machine). Aber habt ihr auch schon von einer "Förderbandmaschine" (belt machine) gehört? Das ist eine der neuen Ideen der Firma OOTB Computing, die sie in ihre Architektur für Allzweck-CPUs namens "Mill" steckt. Zur Zeit gibt es nicht so viele Infos dazu, weil sie ihre Patente noch nicht alle durch haben. Es gibt nur zwei Vorträge, einen zum Thema "Belt Machine" und einen zum Thema "Instruction Encoding". Das Teil soll bis zu 33 Befehle gleichzeitig in einem Taktzyklus dekodieren und zur Verarbeitung anstoßen können (eine moderne Intel-CPU schafft nur 4) und eine sehr hohe Performace pro Watt-Dollar Quote haben. Es wird erklärt, wofür bei "normalen" superskalaren CPUs wie so ein moderner Intel-Chip so viele Transistoren und so viel Strom drauf geht und dass sie (OOTB Computing) mit ihrem von-Grund-auf-neu-Design viel weniger Overhead und viel mehr FUs (functional units) in ihre CPUs stecken haben. Ich fand das alles relativ interessant. Wird aber wohl noch ein paar Jahre dauern, bis man so kleine Chips mit Beinchen unten dran sehen kann. Noch ist es Vaporware, wie der liebe Herr Godard bei 05m:00s im Belt-Video zugibt.
-
Der Typ hat lange weiße Haare, den kann man doch nicht ernst nehmen. Ich guck mir die Vorträge jetzt erstmal nicht an.
In so einen normalen Intel Chip könnte man ja auch mehr Funktionseinheiten einbauen, nur kann man praktisch nur etwa vier ausnutzen. Soll das bei der Architektur anders sein, wenn ja warum?
-
Gruum schrieb:
In so einen normalen Intel Chip könnte man ja auch mehr Funktionseinheiten einbauen
Der Unterschied liegt im Aufwand. Wenn Intel O(n^2) Aufwand für n Rechenleistung braucht irgendwo Schluss. Wenn seine Architektur nur O(n) Aufwand benötigt, steckt darin viel mehr Potential, von den Geschwindigkeit her als auch vom Stromverbrauch. Ein grundlegend neues Architekturmodell halte ich prinzipiell für eine gute Idee.
Allerdings sehe ich nicht ganz den Vorteil von einem Förderband zu einer Registermaschine. Wenn die Architektur genau 100 frei adressierbare Register hat, kann der Compiler eine Förderbandmaschine mit 100 Elementen simulieren. Er kann aber viel mehr machen, er hat ja völlige Kontrolle darüber, welches Element wie lange lebt. Der einzige Unterschied ist der, dass eine Instruktion nicht Länge 4, sondern nur Länge 3 hat. Aber den 25% Speedup vom Decoder bezahlt man damit, dass die Register nicht optimal ausgenutzt werden.
Nach meinem Verständnis ist das wirklich der einzige Vorteil vom Belt gegenüber einer allgemeinen Registermaschine.
Die angepriesenen Vorteile wie kein Register Renaming nötig sehe ich eher skeptisch.
Die Zahlen sind auch eher mager. Das 2x besser als Intel wird zu einem gleich gut wie Intel bis das Ding fertig ist.
-
gandalff schrieb:
[...]
Die angepriesenen Vorteile wie kein Register Renaming nötig sehe ich eher skeptisch.Erklärt er doch. Rename-Register brauchst du bei dem Belt-Dingen nicht, weil "belt" "SA" ist (single assignment, da wird nix überschrieben sondern fällt höchstens hinten rüber). SA macht deswegen ILP (instruction level parallelization) einfacher. Ohne Register-Renaming spart er an "Quellen und Senken". Und das spart Transistoren und Strom.
Das Dekodieren der 33 Instruktionen pro Zyklus (Spitze) ist durch das clevere Encoding möglich.
Also mich überzeugt das. Man braucht die ganze register renaming und out-of-order Logik nicht mehr bei so einem Design und spart damit an Schaltungen und Strom.
-
ich habe leider bislang nicht die Zeit aufbringen können, den talk komplett anzuschauen.
Aber wie ist das: wenn krümelkackers post stimmt, dann fällt jedes berechnete Ergebnis nach k Zeitschritten aus dem Speicher. Bedeutet das nicht mehr Aufwand für den Compiler der nun damit arbeiten muss, das seine Register nicht persistent sind? Könnte das evenuell extrem hart zu optimieren sein?
-
krümelkacker schrieb:
Erklärt er doch. Rename-Register brauchst du bei dem Belt-Dingen nicht, weil "belt" "SA" ist (single assignment, da wird nix überschrieben sondern fällt höchstens hinten rüber).
Oder mit klassischen Worten: Da wird immer der älteste Wert überschrieben. Das einzige magische ist, dass man das Ziel nicht von Hand angeben muss. Und dass die Register den Namen wechseln (gut, das ist magisch).
SA macht deswegen ILP (instruction level parallelization) einfacher. Ohne Register-Renaming spart er an "Quellen und Senken". Und das spart Transistoren und Strom.
Ja, es entspricht einer normalen CPU ohne Register Renaming mit sehr wenigen Registern.
Das Dekodieren der 33 Instruktionen pro Zyklus (Spitze) ist durch das clevere Encoding möglich.
Wie gesagt, 25% weniger Instruktioncode gegenüber einer CPU ohne Register Renaming. Dafür aber auch weniger Register als mit Register Renaming. Und folglich weniger Parallelisierung. Ups. Wären es gleich viele Register wären die Adressen länger und damit der Instructioncode, was das Decoding ausbremst und 33 Instruktionen unmöglich macht. Ups.
Also mich überzeugt das. Man braucht die ganze register renaming und out-of-order Logik nicht mehr bei so einem Design und spart damit an Schaltungen und Strom.
Ja, eine ganz normale CPU ohne Optimierungen wie Register Renaming (komprimiert den Code) und Out-Of-Order-Logik (bei ihm halt Leerlauf). Spart Strom, aber kostet Schnelligkeit.
-
erinnert mich an den replay buffer vom pentium 4.
-
gandalff schrieb:
Ja, es entspricht einer normalen CPU ohne Register Renaming mit sehr wenigen Registern.
Stimmt nicht ganz; denn erst wenn eine FU (functional unit) mit etwas fertig ist, landet das Ergebnis auf der/dem Belt ("retire").
gandalff schrieb:
Wie gesagt, 25% weniger Instruktioncode gegenüber einer CPU ohne Register Renaming. Dafür aber auch weniger Register als mit Register Renaming. Und folglich weniger Parallelisierung. Ups. Wären es gleich viele Register wären die Adressen länger und damit der Instructioncode, was das Decoding ausbremst und 33 Instruktionen unmöglich macht. Ups.
wie gesagt, ich denke, du hast da diesen Aspekt übersehen, dass erst, wenn die Ergebnisse auch da sind, sie auf der/dem Belt landen. Das dürfte schon noch was bringen bzgl Parallelisierung.
[...] eine ganz normale CPU ohne Optimierungen wie Register Renaming (komprimiert den Code) und Out-Of-Order-Logik (bei ihm halt Leerlauf).
Nix Leerlauf. Das Scheduling wird nur von der CPU in den Compiler verlagert, was angeblich keine besonders schwierige Aufgabe für einen Compiler sein soll.
Spart Strom, aber kostet Schnelligkeit.
Es sieht so aus, als könntest du mit der Mill-Architektur beides haben.
Mal gucken, was von denen noch so kommt. Interessant dürfte sein, wann bei einem Speicher-Lesezugriff die Daten auf dem/der Belt landen, inwefern da Cache Misses reinspielen u.s.w.
-
krümelkacker schrieb:
gandalff schrieb:
Ja, es entspricht einer normalen CPU ohne Register Renaming mit sehr wenigen Registern.
Stimmt nicht ganz; denn erst wenn eine FU (functional unit) mit etwas fertig ist, landet das Ergebnis auf der/dem Belt ("retire").
Ja, ich scheine das noch nicht ganz verstanden zu haben.
Mal ne Frage:
Das ganze Indexgeschiebe mit den relativen Indices kostet ja nur Strom und Zeit (er wollte das mit einem Indexregister + CAM lösen).
Könnte man den Registern nicht einen fixen Index geben und das Umbenennen dem Compiler überlassen? Die nötigen Informationen hätte er ja dafür.
-
krümelkacker schrieb:
Das Scheduling wird nur von der CPU in den Compiler verlagert, was angeblich keine besonders schwierige Aufgabe für einen Compiler sein soll.
Beim Itanium wurde das auch behauptet.
-
camper schrieb:
krümelkacker schrieb:
Das Scheduling wird nur von der CPU in den Compiler verlagert, was angeblich keine besonders schwierige Aufgabe für einen Compiler sein soll.
Beim Itanium wurde das auch behauptet.
ja, der knackpunkt der nie ohne viel progammieraufwand funzte. der compiler weiss nicht, wie lange ein memory fetch dauern wird, auch weiss der compiler nicht wie wahrscheinlich ein branch genommen wird usw. bei normalen vanilla code ist wohl jede 4. instruktion ein branch und im schnitt braucht man wohl nach 8 operationen das ergebnis einer operation zum weiterverarbeiten.
das ist auch der grund weshalb der P4 so langsam war. bei 128bit-SSE code, den die cpu in mehrere 64bit operationen zerlegt hatte, war der P4 wirklich schnell, aber der normale code hat dem P4 das genick gebrochen. wenn en branch miss da war ->30cycles, wenn daten nicht im L1D waren ->30cycles (weil der 'belt' weiterlief und die instruktionen erst nach 30cycles wieder drankamen).
genau wie VLIW, eine sehr nette idee in der theorie.
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
-
krümelkacker schrieb:
[...] eine ganz normale CPU ohne Optimierungen wie Register Renaming (komprimiert den Code) und Out-Of-Order-Logik (bei ihm halt Leerlauf).
Nix Leerlauf. Das Scheduling wird nur von der CPU in den Compiler verlagert, was angeblich keine besonders schwierige Aufgabe für einen Compiler sein soll.
Dazu dass das nicht unbedingt so einfach ist wie manchmal gerne behauptet wird haben camper und rapso ja schon was geschrieben.
Und...
Wieso "nix Leerlauf"?
Klar Leerlauf.Angenommen du hast zwei verschiedene Maschinen.
1 = Klassische Registermaschine mit z.B. 100 Registern, Register-Renaming, unendlich grosser Renaming-Registerbank und perfektem OOE Scheduler.
2 = Belt-Machine mit unendlich grossem Band und perfekt angepasstem CompilerBeide haben unendlich viele Execution-Units.
Dann werden sich die in der Performance genau nix nehmen. Die Belt-Machine wird genau so oft im Leerlauf sein wie die Registermaschine.
Die Latency der einzelnen Befehle wird ja dadurch nicht besser, und die parallelisierbarkeit bzw. "reorderbarkeit" des Codes bleibt ja auch gleich -- die ist ja nicht abhängig vom Maschinentyp sondern vom Code.Klar kann man durch Verlagerung bestimmter Dinge in den Compiler viele Transistoren einsparen. Und natürlich kann man durch ein einfacheres Instruction-Set auch nochmal viel einsparen, und evtl. den Decoder massiv beschleunigen.
Aber weniger Leerlauf, also bessere Ausnutzung der vorhandenen EUs bekommst du damit nicht.
Weniger Leerlauf bekommst du eher mit Dingen wie Hyper-Threading.
Und - doch nochmal zurück zum Thema "alles nicht so einfach" - man sollte eins nicht vergessen: es ist ein riesen Vorteil wenn man Programme nicht neu übersetzen muss, wenn ne neue CPU Generation rauskommt (die möglicherweise ganz anders arbeitet, so dass man ganz anders optimieren muss).
Und dazu gibt's eigentlich nur eine sinnvolle Möglichkeiten: "Bytecode" der vor der Ausführung gejitted wird.
Das kann man dann entweder direkt in der CPU machen (=aktuelle Intel CPUs) oder irgendwo in Software.Ein Beispiel wo die "in Software" Variante versucht wurde das mir jetzt einfällt ist Android. Dort hat das nicht so wirklich hingehaut. Hat nicht sehr lange gedauert bis alle Spiele bzw. sonstige Apps die viel Rechenleistung brauchen native programmiert wurden. Bei Windows Phone sieht es ähnlich aus. Windows 7 Phone = nur .NET Zeugs, Windows 8 Phone = native Code wieder erlaubt.
Gibt natürlich auch Beispiele wo es gut funktioniert hat. Es gibt da eine Server-Serie, wo mir jetzt natürlich der Name & Hersteller nicht mehr einfällt, wo Anwendungen gezwungenermassen nur Bytecode verwenden können. Was enorm zur Langlebigkeit der Plattform beigetragen hat. Ist halt toll wenn man heute noch 20 Jahre alte Programme ausführen kann, obwohl die CPU des Servers so-gut-wie nichts mehr mit der ursprünglichen CPU des ersten Servers zu tun hat.
-
gandalff schrieb:
Das ganze Indexgeschiebe mit den relativen Indices kostet ja nur Strom und Zeit (er wollte das mit einem Indexregister + CAM lösen).
Könnte man den Registern nicht einen fixen Index geben und das Umbenennen dem Compiler überlassen? Die nötigen Informationen hätte er ja dafür.
Keine Ahnung, wieviel Strom und Zeit "das Indexgeschiebe" kostet. Godard betonte ja immer wieder, dass es kein riesiges, teures Schieberegister ist. Er beschrieb eine Implemtierung mit per Frame-ID und Belt-Nr "ge-tag-ten" Registern, denen dann gesagt wird, dass sie ihre Belt-Nr erhöhen sollen. Eine Art Crossbar verbindet dann Quellen mit Senken. eine Senke sagt "ich will b2" und das Register, was mit der entsprechenden Belt-Nr ge-tag-t ist, schreit "hier! hab ich!". Kann ich aber nicht beurteilen, ob das so die intelligenteste Lösung ist. Chip-Design ist einfach nicht mein Spezialgebiet.
Ich kann mir das aber auch als zyklischen Puffer
R[32]vorstellen, wobei es dann noch einen Counteroffsetgibt, so dass bi = R[(offset+i)&31] ist und nur dieser Counter verändert wird, wenn neue Werte auf'm "Band" landen.Dein Vorschlag könnte einen Haken haben. Das funktioniert nicht mehr so gut in Loops wenn nicht gerade zufällig nach einem Schleifendurchlauf die Verschiebung auf dem Belt ein Vielfaches der Beltlänge ist. Und das könnte ein sehr wichtiger Unterschied sein. Godard sagte ja, dass sie mit der Mill-Architektur Loops schön pipelinen wollen. Ich denke, dafür bietet sich die temporale Adressierung eher an.
hustbaer schrieb:
krümelkacker schrieb:
[...] eine ganz normale CPU ohne Optimierungen wie Register Renaming (komprimiert den Code) und Out-Of-Order-Logik (bei ihm halt Leerlauf).
Nix Leerlauf. Das Scheduling wird nur von der CPU in den Compiler verlagert, was angeblich keine besonders schwierige Aufgabe für einen Compiler sein soll.
Dazu dass das nicht unbedingt so einfach ist wie manchmal gerne behauptet wird haben camper und rapso ja schon was geschrieben.
Und...
Wieso "nix Leerlauf"?
Klar Leerlauf.Was ich meinte: Nicht mehr Leerlauf als nötig; denn gandalff hatte suggeriert, es würde zu mehr Leerlauf führen. Zumindest kam das bei mir so an.
hustbaer schrieb:
Angenommen du hast zwei verschiedene Maschinen.
1 = Klassische Registermaschine mit z.B. 100 Registern, Register-Renaming, unendlich grosser Renaming-Registerbank und perfektem OOE Scheduler.
2 = Belt-Machine mit unendlich grossem Band und perfekt angepasstem CompilerBeide haben unendlich viele Execution-Units.
Dann werden sich die in der Performance genau nix nehmen. Die Belt-Machine wird genau so oft im Leerlauf sein wie die Registermaschine.
Sicherlich. Die Frage ist nur, wie bekommst du mehr Ops pro Joule? Wie bekommst du mehr Ops/s pro Dollar? Man wird's ja vielleicht irgendwann sehen können, ob das mit der Mill-Architektur eine gute Idee ist. Ist IMHO jedenfalls eine interessante Idee.
hustbaer schrieb:
[...] es ist ein riesen Vorteil wenn man Programme nicht neu übersetzen muss, wenn ne neue CPU Generation rauskommt (die möglicherweise ganz anders arbeitet, so dass man ganz anders optimieren muss).
Wenn ich das richtig verstanden habe, stellen sie sich das so vor, dass das zur Ladezeit passiert, was man ja auch irgendwie cachen könnte. LLVM wird auch mal am Rande erwähnt.
-
otze schrieb:
Aber wie ist das: wenn krümelkackers post stimmt, dann fällt jedes berechnete Ergebnis nach k Zeitschritten aus dem Speicher. Bedeutet das nicht mehr Aufwand für den Compiler der nun damit arbeiten muss, das seine Register nicht persistent sind? Könnte das evenuell extrem hart zu optimieren sein?
Keine Ahnung. Ich nehme mal an, dass das Belt nur für den "schnellen Datenfluss" da ist, für die Werte, die nach der Berechung eh nur einmal wieder gebraucht werden, was angeblich in vielen Programmen 80% all der Zwischenergebnisse ausmacht. Dann gibt es noch das Scratchpad, wo man Dinge parken kann, die man öfters braucht, was angeblich in 14% der Fällen so ist.
rapso schrieb:
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
Ich glaube, da hast du nicht ganz aufgepasst. Die Jungs wollen Loops beschleunigen. Und dafür wäre es extrem praktisch, viele Instruktionen gleichzeitig dekodieren zu können. Vor 30 Jahren haben CPUs wahrscheinlich nicht 33 Befehle parallel dekodieren wollen sondern immer nur einen. Und selbst heute schafft Intel angeblich nur 4 pro Taktzyklus. Der Aufwand wächst angeblich polynomiell mit der Zahl der zu dekodierenden Befehle und durch eine geschickte Kodierung lässt sich etwas drücken. Das mit den pre-decoded ops klingt interessant. Da hatte ich noch nicht von gehört bisher.
rapso schrieb:
[...] VLIW, eine sehr nette idee in der theorie.
...und wohl auch in der Praxis, siehe digitale Signalprozessoren.
-
krümelkacker schrieb:
rapso schrieb:
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
Ich glaube, da hast du nicht ganz aufgepasst.
das stimmt, doch scho ein langer talk.
Die Jungs wollen Loops beschleunigen. Und dafür wäre es extrem praktisch, viele Instruktionen gleichzeitig dekodieren zu können. Vor 30 Jahren haben CPUs wahrscheinlich nicht 33 Befehle parallel dekodieren wollen sondern immer nur einen. Und selbst heute schafft Intel angeblich nur 4 pro Taktzyklus.
das liegt nicht am koennen, sondern wollen. wenn du nur 4 pro takt verarbeiten kannst, weil du 4 einheiten hast, bringt es nichts 5 zu dekodieren. es beschleunigt die sache auch marginal. intel hat in einem der letzten updates die einheiten bzw ports von 3 auf 4 erweitert (also 33%mehr) und in der parxis bringt das <10% mehr leistung. (laut intel). dabei haben die nicht nur die die extra einheit verbaut, sondern die anderen auch umorganisiert damit die einheiten besser ausgelastet werden (die einheiten koennen unterschiedliche dinge).
Der Aufwand wächst angeblich polynomiell mit der Zahl der zu dekodierenden Befehle und durch eine geschickte Kodierung lässt sich etwas drücken.
das ist nur bedingt so. wenn du schnell decoden willst, kannst du ein RISC encoding verwenden z.b. arm, wo jeder befehl exakt 32bit hat und du somit mit linearem aufwand mehr decoden kannst. aber auch arm decoded nicht mehr als sie einheiten haben.
Das mit den pre-decoded ops klingt interessant. Da hatte ich noch nicht von gehört bisher.
und wie gesagt, das ist um die latenz zu mindern, nicht um die parallelitaet zu vergroessern, denn die ist durch den code limitiert, nicht wirklich durch hardware.
rapso schrieb:
[...] VLIW, eine sehr nette idee in der theorie.
...und wohl auch in der Praxis, siehe digitale Signalprozessoren.
die wirklich leistungsstarken signal/stream processoren wie GPUs sind wieder von VLIW abgerueckt. je maechtiger das jeweilige VLIW ist, desto weniger effizient ist es. du kannst dir die details sammt der von AMD gemessenen effiziens z.b. da durchlesen.
-
rapso schrieb:
krümelkacker schrieb:
rapso schrieb:
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
Ich glaube, da hast du nicht ganz aufgepasst.
das stimmt, doch scho ein langer talk.
Die Jungs wollen Loops beschleunigen. Und dafür wäre es extrem praktisch, viele Instruktionen gleichzeitig dekodieren zu können. Vor 30 Jahren haben CPUs wahrscheinlich nicht 33 Befehle parallel dekodieren wollen sondern immer nur einen. Und selbst heute schafft Intel angeblich nur 4 pro Taktzyklus.
das liegt nicht am koennen, sondern wollen.
Behauptest du mal so.
rapso schrieb:
wenn du nur 4 pro takt verarbeiten kannst, weil du 4 einheiten hast, bringt es nichts 5 zu dekodieren.
Das ist klar. Nur kannst du bei dem Design wahrscheinlich schlecht mehr Einheiten einbauen, ohne das Instruction Encoding für eine leichteres, paralleles Decoding zu verändern.
Die Motivation, mehrere Befehle dekodieren (und natürlich verarbeiten) zu können, wenn ich das vom Vortrag richtig in Erinnerung habe, kommt daher, dass das bei Loops richtig was bringen soll.
rapso schrieb:
das ist nur bedingt so. wenn du schnell decoden willst, kannst du ein RISC encoding verwenden z.b. arm, wo jeder befehl exakt 32bit hat und du somit mit linearem aufwand mehr decoden kannst. aber auch arm decoded nicht mehr als sie einheiten haben.
Ist halt ein Trade-Off. ARM Thumb2 ist beispielsweise wieder ein Mix aus 32- und 16-Bit-Befehlen, weil man sich so Performance und kompakten Code verspricht. Das ist aber nicht für ILP ausgelegt.
Ich kaufe OOTBC es ab, dass
- ihr Instruction Encoding sowohl zu kompaktem als auch flott dekodierbarem Code führt
- temporale statt räumliche Adressierung geschickter für Loops sind
- das Belt, auf dem die neuen Ergebnisse erst landen, wenn sie "fertig" sind,
eine effektivere Nutzung der Speicherkapazitäten ist.
Aber die Vorteile der letzten beiden Punkte kommen mir jetzt nicht mehr so groß vor, ehrlich gesagt.
Übrigens: Die Vortrags-Folien gibts auch ohne die Videos.
-
hustbaer schrieb:
Es gibt da eine Server-Serie, wo mir jetzt natürlich der Name & Hersteller nicht mehr einfällt, wo Anwendungen gezwungenermassen nur Bytecode verwenden können. Was enorm zur Langlebigkeit der Plattform beigetragen hat. Ist halt toll wenn man heute noch 20 Jahre alte Programme ausführen kann, obwohl die CPU des Servers so-gut-wie nichts mehr mit der ursprünglichen CPU des ersten Servers zu tun hat.
IBM iSeries (bzw. heissen sie jetzt System i) mit OS/400.
Super dinger, aber performant sind sie nicht - dafür halt rock solid und überleben jede Hardware migration.
-
@krümelkacker
Wenn man nen µOP Cache hat (was die Intel Kekse ja tun), dann sollte doch gerade für Loops egal sein wie viel Instructions der Decoder pro Zyklus schafft.@Shade Of Mine
Genau, ich denke das waren die.
Danke
Richtig schnell mögen die nicht sein, aber die heutigen sind doch so richtiv viel schneller als die ersten Kisten.
-
krümelkacker schrieb:
rapso schrieb:
krümelkacker schrieb:
rapso schrieb:
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
Ich glaube, da hast du nicht ganz aufgepasst.
das stimmt, doch scho ein langer talk.
Die Jungs wollen Loops beschleunigen. Und dafür wäre es extrem praktisch, viele Instruktionen gleichzeitig dekodieren zu können. Vor 30 Jahren haben CPUs wahrscheinlich nicht 33 Befehle parallel dekodieren wollen sondern immer nur einen. Und selbst heute schafft Intel angeblich nur 4 pro Taktzyklus.
das liegt nicht am koennen, sondern wollen.
Behauptest du mal so.
und hatte erklaert weshalb. ich sehe da jetzt kein gegenargument.
rapso schrieb:
wenn du nur 4 pro takt verarbeiten kannst, weil du 4 einheiten hast, bringt es nichts 5 zu dekodieren.
Das ist klar. Nur kannst du bei dem Design wahrscheinlich schlecht mehr Einheiten einbauen, ohne das Instruction Encoding für eine leichteres, paralleles Decoding zu verändern.
aber arm koennte es und dennoch hat arm, trotz linearer decoding complexitaet in relation zur menge der decodierten instructions/cycle es nicht gemacht. stattdessen investieren sie in jeder generation transistoren um die effizienz zu steigern in richtung der einheitenauslastung.
Die Motivation, mehrere Befehle dekodieren (und natürlich verarbeiten) zu können, wenn ich das vom Vortrag richtig in Erinnerung habe, kommt daher, dass das bei Loops richtig was bringen soll.
nur bei vorhersagbaren loops ohne branches. itanium, der sogar spekulativ mehrere branches gleichzeitig abarbeitet, kann dennoch die effiziens von x86/x64 nicht halten, weshalb keiner mehr drauf setzt. dabei war das das 1st class prestige projekt von intel. da kann man nicht behaupten man haette irgendwas halbherzig gemacht.
rapso schrieb:
das ist nur bedingt so. wenn du schnell decoden willst, kannst du ein RISC encoding verwenden z.b. arm, wo jeder befehl exakt 32bit hat und du somit mit linearem aufwand mehr decoden kannst. aber auch arm decoded nicht mehr als sie einheiten haben.
Ist halt ein Trade-Off. ARM Thumb2 ist beispielsweise wieder ein Mix aus 32- und 16-Bit-Befehlen, weil man sich so Performance und kompakten Code verspricht. Das ist aber nicht für ILP ausgelegt.
Das Thumb effizienter ist, ist etwas komplexer zu erklaeren.
wenn du ARM auf unterseter eben (ohne OS) programmierst, dann legst du Thumb code im ram ab und ARM code im scratch memory. ram ist dann meist mit 16bit angebunden, waehrend das scratch pad (z.b. 32kb "IWRam") mit 32bit. bevor du dann etwas ausfuehrst mit ARM, kopierst du dir den code ins scratch pad, machst du das nicht, braucht jede instruktion aus dem main memory im ARM mode 2 cycles.
ARM ist also eigentlich maechtiger und schneller, da viele instruktionen mehr als nur eine sache machen (z.b. zusaetzlich shift, conditional checks, increment/decrement). aber compiler das nicht so gut ausnutzen. hand geschriebener assembler kann hingegen sehr sehr gut sein, nicht erreichbar mit Thumb.(sogar hand getunter c code, aber da bluten dir die augen).
das ist bei aktuellen handy cpus auch so, zwar ist da ram mit 32bit angebunden, aber die cpus koennen meist 2 instructions dekodieren pro cycle. hast also 2 thumb oder 1 ARM. wenn du hand optimierten code hast und dieser in L1i passt, bist du mit ARM schneller. compiler generierter code aus vanilla source, ist mit thumb schneller (laut ein paar presentationen von ARM selbst).ARM ist besser hand optimiert oder wenn die bandbreite genau soviel op codes zulaesst wie beim Thumb.
Thumb is besser als ARM wenn compiler generiert.Thumb widerlegt also quasi deine behauptung. einzelne stupide ops enden beim compilierten code effizienter als wenn der compiler 'smart' sein muss und selbst die triviale ARM ISA ausnutzen soll.
Ich kaufe OOTBC es ab, dass
[list]
[*] ihr Instruction Encoding sowohl zu kompaktem als auch flott dekodierbarem Code führtbestreite ich nicht, da dasselbe fuer MIPS, ARM, PowerPC auch zutrifft. linearer aufwand fuers dekodieren.
aber man sieht anhand von in-order vs OoO cores, dass OoO mehr leisten. in-order sind effizienter wenn sie trivial arbeiten z.b. ARM mit 3 cycle latenz/instruction und 1instruction/cycle throughput. aber es wird ineffizient wenn du viele instruction/cycle haben willst. mehr als 2 instruction/cycle in-order macht deswegen AFAIK niemand.(lustig finde ich, dass viele ARM als beispiel fuer effizientes RISC angeben und arm dann Thumb entwickelt was wie Cisc auf op ebene arbeitet und eigentlich total ineffizient sein sollte fuers decodieren :D)
