Cache zwischen die CPU Ausführungseinheiten???

[Dj dicke Brust]

Es geht mir bei diesem Posting einfach nur darum ob es bei den heutigen Prozessoren nicht Sinn machen würde zwischen die einzelnen Stufen in der CPU-Pipeline eine Art Cache einzubauen. Ich meine damit einen Cache nicht mit viel größe sondern sehr klein vielleicht für einen oder zwei Befehle die dort zwischengelagert werden können und so nicht mehr die Pipeline verstopfen würden. Ich denke mir einfach das es Sinn macht in anbetracht einer 20+ stufigen Cpu wie dem P4. Weiterhin denke ich mir das dies nicht so schwierig sein dürfte da die aktuellen CPU´s ja sowieso out-of-order arbeiten.
Hab in dem zusammenhang auch schon gehört das ja eine ganze Pipeline gelöscht wird wenn ein Ergebnis eines Befehls abhängig von einem unbearbeiteten anderen Befehl ist. Ich denke mit so einem Zwischenspeicher könnte die Pipeline weiterlaufen indem der abhängige Befehl in den Cache geschoben wird. Liegt dann das Ergebnis vor vom dem der Befehl abhängig ist wird er aus dem Cache geholt und schwupp die wupp ist er ohne Pipeline löschen und ähnliches wieder im rennen und schnell bearbeitet.

Nur als denkanstoss weil ich mich auch nicht so sehr mit der ganzen CPU bisher auseinandergesetzt habe und noch in der Lernphase bin. Wäre schön wenn sich dazu ein paar Stimmen sammeln könnten.

Gruss Dj dicke Brust

[BlackBirdSR]

Original geschrieben von Dj dicke Brust
Es geht mir bei diesem Posting einfach nur darum ob es bei den heutigen Prozessoren nicht Sinn machen würde zwischen die einzelnen Stufen in der CPU-Pipeline eine Art Cache einzubauen. Ich meine damit einen Cache nicht mit viel größe sondern sehr klein vielleicht für einen oder zwei Befehle die dort zwischengelagert werden können und so nicht mehr die Pipeline verstopfen würden. Ich denke mir einfach das es Sinn macht in anbetracht einer 20+ stufigen Cpu wie dem P4. Weiterhin denke ich mir das dies nicht so schwierig sein dürfte da die aktuellen CPU´s ja sowieso out-of-order arbeiten.
Hab in dem zusammenhang auch schon gehört das ja eine ganze Pipeline gelöscht wird wenn ein Ergebnis eines Befehls abhängig von einem unbearbeiteten anderen Befehl ist. Ich denke mit so einem Zwischenspeicher könnte die Pipeline weiterlaufen indem der abhängige Befehl in den Cache geschoben wird. Liegt dann das Ergebnis vor vom dem der Befehl abhängig ist wird er aus dem Cache geholt und schwupp die wupp ist er ohne Pipeline löschen und ähnliches wieder im rennen und schnell bearbeitet.

Nur als denkanstoss weil ich mich auch nicht so sehr mit der ganzen CPU bisher auseinandergesetzt habe und noch in der Lernphase bin. Wäre schön wenn sich dazu ein paar Stimmen sammeln könnten.

Gruss Dj dicke Brust

hmm..
es gibt diese Pufferspeicher. Schließlich müssen die Befehle ja durch die CPU geführt werden und auch verteilt werden, bzw sich sammeln und warten bis sie an der Reihe sind ;)

Allerdings helfen diese nicht wirklich hinsichtlich den Pipeline flushes (löschen). Das Sprungvorhersage findet weit vor der Ausführung statt, und wenn sich eine Vorhersage als inkorrekt herrausstellt, muss eben von vorne begonnen werden. DAs beinhaltet auch, den bisherigen Werdegang eines befehles zu löschen.
Allerdings gibt es da schon so einige Tricks um da etwas nachzubessern.
IA-64 rechnet gleich mal für alle Sprünge die Pfade durch.
der P4 hat mehrere Sprungvorhersagen des selben Befehles mitunter gleichzeitig im Tracecache gespeichert.
Der K7/8 hat extra bits für Befehle im Befehlscache die mit Informationen hinsichtlich der Sprünge versehen werden und damit solche flushed verhindern können.

[Dj dicke Brust]

Aber bedeutet dieses vorherige Überprüfen nicht zusätzlichen Rechenaufwand? Oder wäre es möglich dieses Konzept als sozusagen worst-case Scenario aushilfe zu nutzen in verbindung mit den vorhergehenden überprüfungen. Weil soweit ich gelesen hab sollen diese flushes (schon was gelernt ;D) ja doch noch vorkommen und ein großes Problem sein.

[Muh-sagt-die-Kuh]

Original geschrieben von Dj dicke Brust
Aber bedeutet dieses vorherige Überprüfen nicht zusätzlichen Rechenaufwand? Oder wäre es möglich dieses Konzept als sozusagen worst-case Scenario aushilfe zu nutzen in verbindung mit den vorhergehenden überprüfungen. Weil soweit ich gelesen hab sollen diese flushes (schon was gelernt ;D) ja doch noch vorkommen und ein großes Problem sein. Man kann Flushes nur dann eliminieren, wenn man OHNE Branch-Prediction arbeitet...was allerdings bedeutet, dass man die Pipe bei JEDEM Branch für ein paar Takte stallen muss. Conditional Branches machen schonmal 20% der gesamten Instruktionen aus, du kannst dir vorstellen was für Auswirkungen auf die Performance solch ein Vorgehen hätte...ein paar Mispredictions und Flushes sind die deutlich bessere Lösung.

P.S.:

Lies dir lieber etwas grundlegendes Wissen über Pipelining an bevor du solche abenteuerlichen Theorien aufstellst...

[Exxtreme]

Also solche Puffer hätten wieder einige Nachteile. Erstens steigt der Transistor-Count und zwotens würde es sich ungünstig im Bezug auf die internen Latenzen auswirken.

Da sind Sprungvorhersagen doch besser.

[GloomY]

@DJ dB: Ich verstehe nicht, wo der Vorteil dieser Maßnahme sein soll. Das Problem ist, dass bei konditionalen Sprüngen - also Sprüngen, die abhängig von einem zu berechnenden Ergebnis sind - erst nach der Ausführungsphase feststeht, ob der Sprung genommen wird oder nicht. Die Ausführungsphase ist allerdings sehr weit hinten in der Pipeline, daher steht das Ergebnis erst zu einem recht späten Zeitpunkt fest. In den Stufen davor sind schon die nachfolgenden Befehle (sprich: die Befehle, die nach dem konditionalen Sprung kommen würden, wenn dieser nicht genommen wird) drin. Wenn der Sprung nicht genommen wird, ist alles in Ordnung. Dann ist der Programmverlauf ja genau der, wie die Befehle bereits in der Pipeline liegen. Wenn der Sprung aber genommen wird, ist der nächste Befehl aber ein völlig anderer als der, der sich als nächstes in der Pipeline befindet. Daher muss man die bisherigen Einträge in der Pipeline verwerfen, da diese ja gar nicht mehr bearbeitet werden. Der nächste Befehl ist nämlich der, der bei der Sprungadresse steht und nicht der, der nach dem Sprung kommt (das Programm springt hier ja an eine andere Stelle)

Out-of-Order Execution kann hierbei nur insofern helfen, dass man die Berechnungen mit den konditionalen Sprüngen möglichst früh macht. OOO-Exec ist aber auch nur dann möglich, wenn die zu bearbeitenden Befehle unabhängig von anderen Berechnungsergebnissen sind. Das ist längst nicht immer gegeben, daher schätze ich den Profit von OOO-Exec hierbei ziemlich gering ein. Eine gute Sprungvorhersage kann im Gegensatz dazu förmlich Wunder bewirken.

Ich sehe nicht, wie man dieses Problem mit zusätzlichen Puffern zwischen den einzelnen Stufen lösen oder zumindest teilweise verbessern kann. Ob der Sprung genommen wird oder nicht, entscheided ja, wie der Programmverlauf weitergeht, also wo der nächste zu bearbeitende Befehl steht. Entweder geht er in die vorhergesagte Richtung, dann sind alle Befehle richtig, die vor dem Sprungbefehl in der Pipeline liegen, oder es sind alle falsch. Wenn alle falsch sind hilft es nichts, wenn man pro Stufe zwei oder drei falsche Befehle zur Verfügung hat. ;)
Original geschrieben von BlackBirdSR
Der K7/8 hat extra bits für Befehle im Befehlscache die mit Informationen hinsichtlich der Sprünge versehen werden und damit solche flushed verhindern können. Diese Eigenschaft stammt übrigends aus der Alpha 21264 von Digital. Der Athlon hat hier sehr viel Know-How aus der ehemaligen "besten Prozessorschiede der Welt" ;) in sich verbaut.

[zeckensack]

Auch wenn ich glaube, daß das hier garnicht gemeint war, will ich mich mal zum Thema "Cache" äußern ;)

Ein Cache speichert Daten "nah" am Verbraucher. Das ist dann sinnvoll, wenn der normale Weg, diese Daten zu beschaffen "teuer" ist (in Form von Wartezyklen und/oder Rechenzeit).

Im Gegenzug macht es keinen Sinn, Caches für Dinge anzulegen, die man sowieso sehr schnell beschaffen kann. Denn der Cache muß verwaltet werden und belegt Platz. Im Extremfall ist unbedacht eingeführter Cache deswegen sogar langsamer als kein Cache. Klassisches Beispiel: Software-Lookups für Sinus/Cosinus auf modernen Prozessoren.

[BlackBirdSR]

Original geschrieben von GloomY
Diese Eigenschaft stammt übrigends aus der Alpha 21264 von Digital. Der Athlon hat hier sehr viel Know-How aus der ehemaligen "besten Prozessorschiede der Welt" ;) in sich verbaut.



:bier:

ich benutze jetzt auch mal das böse Wort mit "z":
Alpha rulez :)

[GloomY]

Original geschrieben von BlackBirdSR
:bier:

ich benutze jetzt auch mal das böse Wort mit "z":
Alpha rulez :) :up: :bier: :D
Original geschrieben von zeckensack
Im Gegenzug macht es keinen Sinn, Caches für Dinge anzulegen, die man sowieso sehr schnell beschaffen kann. Denn der Cache muß verwaltet werden und belegt Platz. Im Extremfall ist unbedacht eingeführter Cache deswegen sogar langsamer als kein Cache. Klassisches Beispiel: Software-Lookups für Sinus/Cosinus auf modernen Prozessoren. Öhm, nur mal nebenbei als Information: Wie funktioniert das mit Sin/Cos? Und was ist Software-Lookup? Ist das ein numerisches Programm, was im Prozessor abläuft?

[Demirug]

Original geschrieben von GloomY
Öhm, nur mal nebenbei als Information: Wie funktioniert das mit Sin/Cos? Und was ist Software-Lookup? Ist das ein numerisches Programm, was im Prozessor abläuft?

Nein. Das ganze kommt noch aus der guten alten Zeit als Fliesspunkt berechnungen noch richtig teuer waren (Keine FPU oder nur eine ganz langsame). Damals hat man sich dann oft im Speicher eine Tabelle angelegt mit vorberechneten Werten. Eine Cos/Sinustabelle könnte dann zum Beispiel 90 Werte für die Winkel von 0-89 Grad enthalten. Damit konnte man dann recht einfach und schnell den Sinus oder Cosinus Werte auf ein Grad genau bestimmen in dem man den Wert aus dem Speicher geholt hat welcher am besten passt (Point-Samping). Manchmal hat man auch zwischen den beide Werte die am genausten gepasst haben linear Interpoliert.

Das ganze könnte übrigens in Verbindung mit Pixelshader wieder interesant werden. Dort könnte man auch in einer Texture entsprechende vorberechnete Werte speichern.

[zeckensack]

Gaynau ;)

Laut AMD dauert "sin" bis zu 200 Takte. "sincos" bis zu 320 Takte (oder so ähnlich). Also mit die teuersten Instruktionen überhaupt. Ich habe also mal ausprobiert, ob ich nicht mittels Lookups (also vorberechneten Stufen der Sinus-Kurve) und Interpolation schneller an Sinus und Kosinus komme. Das ganze auch noch in handgebautem 3DNow-Assembler (ich traue mir ernsthaft zu, das absolut optimal umgesetzt zu haben).

Das Ergebnis war dann, daß - trotzdem - bereits ein Athlon 600 den Sinus ca 50% schneller ausrechnen kann, als ich ihn aus einer LUT (=Lookup table) hole.

Und eine LUT ist eben immer eine Form von Cache, weil dort "teure" Berechnungen bereits fertig vorliegen.

[Demirug]

Zeckensack das bestätigt ja nur die These das Anweisungen im verhältniss zu Speicheroperationen immer billiger werden. Meistens bringt es heute mehr die Datenstrukturen zu überarbeiten als mit dem Inline-Assembler zu versuchen etwas schneller zu bekommen.

[zeckensack]

Es gibt sinnvolle Anwendungen für Assembler, Demi, bitte glaub mir ;)
(allerdings verabscheue ich mittlerweile jede Form von Inline-ASM)

Was ich damit aber eigentlich sagen wollte, wenn eine Information aus
a)sowieso vorhandenen Daten
und
b)Durchlauf weniger Gatter gewonnen werden kann,
und
c)dieser Prozess sich parallel (kleinere Laufzeit) in die gleiche Pipeline-Stufe einfügen lässt,
dann ist ein 'Cache' pure Platzverschwendung.

[Demirug]

Original geschrieben von zeckensack
Es gibt sinnvolle Anwendungen für Assembler, Demi, bitte glaub mir ;)
(allerdings verabscheue ich mittlerweile jede Form von Inline-ASM)

Was ich damit aber eigentlich sagen wollte, wenn eine Information aus
a)sowieso vorhandenen Daten
und
b)Durchlauf weniger Gatter gewonnen werden kann,
und
c)dieser Prozess sich parallel (kleinere Laufzeit) in die gleiche Pipeline-Stufe einfügen lässt,
dann ist ein 'Cache' pure Platzverschwendung.

Das streite ich ja gar nicht ab. Die Fälle werden nur immer seltener.