Duran schrieb:
Das glaub ich ehrlich gesagt nicht. Zumindest nicht bei den aktuellen Größen.
Du hast gefragt, warum man nicht konstant die Caches erhöht und ich habe dir die dazugehörige Antwort geliefert und es ist an dieser Stelle vollkommen egal, ob du es glaubst oder nicht. Und das haben dir sogar noch ein paar mehr Leute versucht zu erklären.
Da andere bereits versucht haben dir zu erklären, warum das so ist und du scheinbar noch nicht mal verstehst, warum es verschiedene Cache Stufen gibt (die sind ja angeblich egal …). Selbst wenn ich dir also nun erklären würde, warum deine Beiträge zu weiten Teilen falsch sind, würdest du am Ende immer noch denken, dass du recht hast, weil dir vermutlich jegliche Kompetenz in diesem Bereich fehlt. Ich verschwende daher auf dich nicht mehr Lebenszeit, als diese zwei Absätze gekostet haben.
bensen schrieb:
Es bringt eben nichts wenn die untere Cache-Stufe nicht wesentlich schneller ist als die darüber liegende. Es ist ein trade-off zwischen Größe, Durchsatz und Latenz. Selbst wenn man Kosten außen vorlässt, hat die Vergrößerung des Caches Grenzen.
Bei einer CPU gibt es neben den Cache-Stufen auch noch das Register-File und heute immer bessere Daten-Prefetcher, die hier mit wirken.
Der große L2-Cache bei RaptorLake zieht einen großen Teil seiner Stärke aus einem deutlich intelligenteren Prefetching, das relativ gut die Daten aus dem L3 und vom RAM in den L2 und von dort auch in den L2-Cache schaffen kann.
bensen schrieb:
Ja und? Niemand will Caches niedrig takten, da die Latenz wichtig ist. Hat schon seinen Grund warum die heutzutage mit vollem Coretakt laufen.
Ja und Nein, an der Stelle hast Du theoretisch recht, aber er hat hier einen "validen" Punkt, auch wenn er an dieser Stelle am Ende dennoch weitgehend falsch liegt. Für den Cache ist nicht die absolute Latenz (also die Zeit) entscheiden, sondern die relative Zeit in Ticks. Nur ist der Takt der CPU nur ein Faktor, der die Ticks bestimmt, die der Cache benötigt, sondern auch die Größe ist entscheidend.
Bei den heutigen Cache-Designs bestimmt in der Regel eher die Menge des Caches die Ticks als primär der Takt und genau hier kommen wir zu dem Punkt, denn du ja angesprochen hast und warum es verschiedene Cache-Stufen gibt. Von den Register-Files (quasi keine Latenz, dafür aber komplex angebunden) über den L1 und L2 zu heute dem L3 - und bei Broadwell der "L4". Wenn man heute pro "Kern" einen L1 von 128 MiB anbinden würde, wäre das sehr langsam im Vergleich zu den L1 von 32 KiB (oder sind es 48 KiB, keine Ahnung, keine Lust nachzusehen.).
bensen schrieb:
Nein, ist sie nicht. Cachen bringt eben nichts, wenn die Latenz riesig ist.
Für den Cache ist die Latenz ebenso wichtig wie die Anbindung. Je näher du am eigentlichen Kern bist, umso schneller ist die Anbindung und umso kürzer ist die Latenz, damit man möglichst schnell im Register-File ist.
Auch hier: Er hat zwar nicht unrecht, dass die Cache-Stufen auch etwas mit der "Geschwindigkeit" der Caches zu tun hat, aber er blendet die Latenz vollständig aus, was falsch ist. Je näher man am Kern ist, um so schneller und umso mehr Daten fließen hin und her. Register werden in den L1 verschoben und aus dem L1 in die Register gelesen. Hier hat man relativ wenig "Zeit" um nicht benötigte Register in den L1 zu schieben und im nächsten Schritt von dort die Daten zu holen.
bensen schrieb:
Der L2 ist private. Da greift niemand anders drauf zu.
Selbst wenn der L2 geteilt werden würde - die e-Cores teilen sich den L2 - haben die anderen Kerne nicht einfach Zugriff auf diese Daten. Die Daten - egal ob sie im L1, L2, L3 oder im RAM liegen - sind so lange für andere Kerne tabu, solange ein Kern mit diesen arbeitet und diese ggf. sich ändern. Hier sind Entwickler - Mehrläufigkeit - als auch die Compiler gefragt und in solchen Fällen wird gerne - aus Komplexitätsgründen - eher mit "Kopien" gearbeitet. Das ist einfacher und besser zu händeln.
bensen schrieb:
eder Kern hat heute ebenfalls 2 MB, wo sind die also klein? Dazu kommt pro Kern 3 MB L3 Cache.
Nur das er keine Ahnugn hat, warum Prescott damals so viele Cache hatte.
@Piktogramm führt es schön aus. Precott hatte damals eine Pipeline von fast 50 Stufen - also 50 Cycle. Wenn da in den RAM musste für Befehle und Daten, wäre das quasi der Tod für die CPU gewesen. Dazu kam, dass der L1d-Cache vergleichsweise gering ist - 16 KiB - zu den heute teilweise 32 - 48 KiB. Dazu kommt noch etwas wichtiges, das er vergisst: Prescott griff noch über den FSB auf den RAM-Controller in der Northbridge zu: zusätzliche Latenzen.
bensen schrieb:
Was verstehst du unter voll angebunden?
Er versteht darunter nicht viel. Der L1-Cache wird an den Kern mit der Anzahl der Load/Store-Einheiten angebunden. In diesem Fall - bei GoldenCove/RaptorCove - 3 * 32 Byte. Der L2-Cache ist an den L1 mit 1 * 64 Byte angebunden und mit 1 * 32 Byte an den L3. Nur hat das nichts mit "voll angebunden" zu tun, sondern erneut etwas mit der Cache-Ebene. Die meiste direkte Kommunikation zwischen Kern und Cache findet im L1 statt, der L1 bekommt seine Daten, wenn er sie benötigt vom L2 und der aus dem L3 oder dem RAM. Prefetching ist hier das Stichwort.
Und all das lässt sich am Ende darauf herunterbrechen, was ich geschrieben hatte: Ab einer gewissen Größe steigt die Latenz so an, dass sich der positive Effekt egalisiert. Deswegen macht man den L1-Cache bei den CPUs auch nicht immer größer, weil man die Latenzen beachten muss und das gilt auch für den L2 und L3 Cache. Je weiter man weg ist vom Kern, umso höher darf die Latenz sein.
