Hallo, ich bin neu hier und fange bald eine Ausbildung zum Programmierer an. Ich möchte aber trotzdem auch ein wenig Ahnung vom Innenleben eines PC's haben. Daher zwei Fragen: 1. Frage In einem Buch über Rechnerarchitektur steht, dass die CPU bzw. der Cache-Controller , wenn Daten angefordert werden sollen, immer zuerst in den L1 bis L3-Caches nachguckt, ober die Daten bereits dort drin stehen, bevor er auf den langsamen RAM zugreift. Jetzt nun meine Frage: Ist es wirklich schneller, wenn der Prozessor alle 3 Caches durchsucht als direkt auf den RAM zuzugreifen? Also wenn nur der L1-Cache durchsucht werden würde und bei einem Cashe-Miss des L1-Cashes direkt zum RAM gesprungen werden würde, dann könnte ich mir vorstellen, dass es schneller wäre. Aber wenn doch alle Cashes durchsucht werden, dann müsste das doch also mehr Takte brauchen, als direkt auf den RAM zuzugreifen? 2. Frage Warum liest der Cache-Controller bei einem Cashe-Miss im RAM immer direkt eine ganze Cache-Line? Vielen Dank :)
Lars L. schrieb: > Jetzt nun meine Frage: Ist es wirklich schneller, wenn der Prozessor > alle 3 Caches durchsucht als direkt auf den RAM zuzugreifen? Ja und zwar mehrere Größenordnungen! RAM hat lange Latenz beim Zugriff. Schau Dir mal die entsprechenden Latenz Zeiten an. > Also wenn > nur der L1-Cache durchsucht werden würde und bei einem Cashe-Miss des > L1-Cashes direkt zum RAM gesprungen werden würde, dann könnte ich mir > vorstellen, dass es schneller wäre. Der L1 ist aber extrem mickrig, so 16KB-64KB. L3 ist mehrere MByte bei modernen CPUs. Da ist die Wahrscheinlichkeit für Cache Hits viel größer. Lars L. schrieb: > Warum liest der Cache-Controller bei einem Cashe-Miss im RAM immer > direkt eine ganze Cache-Line? Was soll er sonst lesen? Die Cache Line ist die kleinste Einheit in der Verwaltung des Caches. Außerdem ist moderner RAM extrem schnell bei sequenziellem Zugriff.
1) "Durchsuchen" ist vielleicht das falsche Wort. Da gibt es extra Tabellen, die sehr schnell und vor allem parallel ausgelesen werden können um herauszufinden was gerade im Cache liegt und auch noch aktuell ist. 2) Weil es praktisch keine zusätzliche Zeit kostet. Nimm ein "normales" DDR3-1600-Modul, das braucht mindestens 10 - 15 ns bis es überhaupt Daten liefern kann, schaufelt dann aber alle 0.6ns 8 Byte zur CPU. Kleinere Zugriffe als einige Dutzend bis Hundert Byte machen also zeitlich gesehen keinen Sinn. Zumal es in vielen Programmen sehr wahrscheinlich ist, dass diese Daten auch gebraucht werden.
RAM Zugriffszeit dürfte bei 100-200 Takten liegen. L1 bei 3-4, Ĺ2 bei 11-15. L3 und RAM wird von vielen Cores gemeinsam genutzt, L1 und L2 sind lokal. Summe Durchsatz aller L1 und L2 zusammen viel höher als RAM. Caches sind oft nonblocking, d.h. der Core wartet zwar mit dem Befehl, macht aber ansonsten mit anderen Befehlen weiter, auch im gleichen Cache.
:
Bearbeitet durch User
Zu 2: Die Wahrscheinlichkeit ist hoch, dass diese Daten auch benötigt werden und die verbratene Zeit ist klein gegenüber der Zugriffszeit. Bei Cache mit ECC kann es zudem zwingend sein.
:
Bearbeitet durch User
Apropos Rechnerarchitektur und Algorithmen: Während man früher in der Theorie RAM als uniformen wahlfreien Speicher ansah fährt man heute besser, wenn man es bei Performance-Betrachtungen und größeren Datenmengen als eher sequential arbeitenden Speicher betrachtet.
Jim M. schrieb: > Lars L. schrieb: >> Warum liest der Cache-Controller bei einem Cashe-Miss im RAM immer >> direkt eine ganze Cache-Line? > > Was soll er sonst lesen? Die Cache Line ist die kleinste Einheit in der > Verwaltung des Caches. Außerdem ist moderner RAM extrem schnell bei > sequenziellem Zugriff. Abgesehen davon ist das ja auch der Trick. Der Prozessor greift sehr häufig sequentiell auf den Speicher zu oder zumindest auf nahe beieinander liegende Speicherstellen, und in dem Fall sind dann für die nächsten Zugriffe die Daten gleich schon im Cache.
Cat C. schrieb: > In einem Buch über Rechnerarchitektur steht, dass die CPU bzw. der > Cache-Controller , wenn Daten angefordert werden sollen, immer zuerst in > den L1 bis L3-Caches nachguckt, ober die Daten bereits dort drin stehen, > bevor er auf den langsamen RAM zugreift. > Jetzt nun meine Frage: Ist es wirklich schneller, wenn der Prozessor > alle 3 Caches durchsucht Der Cache wird nicht in dem Sinne "durchsucht", sondern es wird einfach ein Zugriff gemacht, der entweder die Daten direkt liefert oder fehlschlägt (und im zweiten Fall auf den Cache der nächsthöheren Ebene oder eben das RAM durchgreift). Und ja, das ist schneller. Sonst würde es nicht gemacht. Bzw. eigentlich eher anders herum: schon beim Design der CPU wird darauf geachtet, daß die Caches wirklich schneller sind als der Datenspeicher den sie cachen. Wenn man das nicht hinkriegt, dann baut man auch keinen Cache ein. > Warum liest der Cache-Controller bei einem Cashe-Miss im RAM immer > direkt eine ganze Cache-Line? Entweder weil der RAM nur in genau dieser Breite angesprochen werden kann. Ein RAM-Zugriff mit weniger Datenbreite wäre dann nicht schneller. Wenn die Chacheline tatsächlich länger als die physikalische Wortbreite ist, dann nutzt der RAM-Controller einen anderen Effekt: das Lesen mehrerer aufeinanderfolgender Worte ist viel schneller als das Lesen von mehreren einzelnen Worten. Das liegt daran, daß im letzteren Fall immer erst die Adresse an das RAM übertragen werden muß. Beim sequenziellen Lesen nur die Adresse für das erste Wort.
Axel S. schrieb: >> Jetzt nun meine Frage: Ist es wirklich schneller, wenn der Prozessor >> alle 3 Caches durchsucht > > Der Cache wird nicht in dem Sinne "durchsucht", sondern es wird einfach > ein Zugriff gemacht, der entweder die Daten direkt liefert oder > fehlschlägt (und im zweiten Fall auf den Cache der nächsthöheren Ebene > oder eben das RAM durchgreift). Doch, klar muss der durchsucht werden. Wie sollte denn "einfach ein Zugriff" funktionieren? Wenn ich die Daten von einer bestimmten Speicher-Adresse haben will, muss ich erstmal wissen, ob diese Daten im Cache sind, und wenn ja, wo sie stehen. Das ist ja auch der Grund, warum man überhaupt mehr als eine Cache-Ebene hat. Eine Ebene ist größer als die vorherige und kann damit mehr Daten zwischenspeichern, braucht aber länger zum durchsuchen.
>Das ist ja auch der Grund, warum man überhaupt mehr als eine Cache-Ebene >hat. Eine Ebene ist größer als die vorherige und kann damit mehr Daten >zwischenspeichern, braucht aber länger zum durchsuchen. Nein der CPU-Cache wird nicht durchsucht! Ein kleines RAM hat kürzere Zugriffszeiten als ein größeres, deshalb ist der L1 klein und schnell, der L3 groß und langsamer https://de.wikipedia.org/wiki/Cache http://www.elektronik-kompendium.de/sites/com/0309291.htm
Rolf M. schrieb: > Wie sollte denn "einfach ein > Zugriff" funktionieren? "Content Adressable Memory" nennt man so etwas. Axel S. schrieb: > Der Cache wird nicht in dem Sinne "durchsucht", sondern es wird einfach > ein Zugriff gemacht, der entweder die Daten direkt liefert oder > fehlschlägt (und im zweiten Fall auf den Cache der nächsthöheren Ebene Ist das so? Oder werden alle drei Caches (falls es die physikalisch überhaupt gibt und nicht ein Decodertrick dahinter steckt) gleichzeitig adressiert und dann geht es weiter, sobald der schnellste die Daten liefert?
bko schrieb: > Nein der CPU-Cache wird nicht durchsucht! Nur ein direct mapped Cache wird tatsächlich nicht durchsucht. Sobald Assoziativität dabei ist wird parallel durchsucht. So werden bei einen 4fach assoziativen Cache 4 Einträge durchsucht. Oft parallel, nicht selten aber auch in 2 Stufen, wenn way prediction verwendet wird. Und vollassoziative Caches werde vollständig durchsucht.
Hp M. schrieb: > Oder werden alle drei Caches (falls es die physikalisch überhaupt gibt > und nicht ein Decodertrick dahinter steckt) gleichzeitig adressiert und > dann geht es weiter, sobald der schnellste die Daten liefert? Nein, das erfolgt nacheinander. Ein L1 Cache ist oft so organisiert, dass mehrere Zugriffe parallel erfolgen können. Beispielsweise 2 Lese- und/oder 1 Schreibzugriff, wenn kein Konflikt in ein paar unteren Adressbits vorliegt. Anders wäre in Highend-Prozessoren die hohe Dichte entsprechender Operationen nicht handhabbar. L2 Caches sind hingegen anders organisiert und haben auch nicht unbedingt den gleichen Durchsatz wie L1 Caches. Spätestens die L3 Caches werden, soweit vorhanden, von mehreren Cores geteilt.
Rolf M. schrieb: > Eine Ebene ist größer als die vorherige und kann damit mehr Daten > zwischenspeichern, braucht aber länger zum durchsuchen. Wobei für die schlechtere Zugriffszeit eines L2/L3 Caches nicht allein die Grösse selbst verantwortlich ist. Da spielen noch andere Faktoren mit hinein, wie etwa eine platz- und stromsparendere dafür aber langsamere Technik. Gelegentlich findet man in L3 oder L4 Caches auch embedded DRAM Speichertechnik. Nicht schnell, aber dichter gepackt.
Axel S. schrieb: > Der Cache wird nicht in dem Sinne "durchsucht", sondern es wird einfach > ein Zugriff gemacht, der entweder die Daten direkt liefert oder > fehlschlägt (und im zweiten Fall auf den Cache der nächsthöheren Ebene > oder eben das RAM durchgreift). Das trifft so nur auf direct mapped Caches zu. Die haben den Vorteil, dass man mit dem Inhalt direkt spekulativ weiterarbeiten kann, um erst danach festzustellen, ob das überhaupt Sinn ergibt. Das ist extrem schnell. Die findet man mittlerweile allerdings recht selten. Zu häufige Konflikte. Meist gibt es pro Adresse mehrere mögliche Speicherstellen im Cache. Und zwischen denen wird dann zum Zugriffszeitpunkt entschieden, welche den Inhalt enthält, sofern überhaupt. Das ist tatsächlich eine Suche, parallel. Das ist langsamer als direct mapped, weil zwischen dem Zugriff auf das Cache-Array und der Weiterverarbeitung der Daten eine Entscheidung erfolgt (besagte Suche), also zusätzliche Laufzeit entsteht. Was besonders in L1 Caches mitunter zur Kompromisslösung "way prediction" führt. Hier versucht der Cache vorherzusagen, welcher der N (typ 2-16) möglichen Einträge ein Treffer wird und arbeitet dann spekulativ damit weiter. Im Folgetakt wird diese Entscheidung entweder bestätigt, oder die laufende Operation anulliert und mit korrigierten Daten erneut durchgeschoben.
:
Bearbeitet durch User
A. K. schrieb: > Axel S. schrieb: >> Der Cache wird nicht in dem Sinne "durchsucht", sondern es wird einfach >> ein Zugriff gemacht, der entweder die Daten direkt liefert oder >> fehlschlägt (und im zweiten Fall auf den Cache der nächsthöheren Ebene >> oder eben das RAM durchgreift). > > Das trifft so nur auf direct mapped Caches zu. > Die findet man mittlerweile allerdings recht selten. > Meist gibt es pro Adresse mehrere mögliche Speicherstellen im > Cache. Und zwischen denen wird dann zum Zugriffszeitpunkt entschieden, > welche den Inhalt enthält, sofern überhaupt. Das ist tatsächlich eine > Suche, parallel. Das ist alles richtig, aber das war nicht mein Punkt. Für Otto Normaluser (und offensichtlich auch den TE) bedeutet "durchsuchen" eine langwierige Operation a'la "wir schauen uns jeden Eintrag im Cache an und im Extremfall müssen wir einmal alles anschauen bevor wir wissen daß es keinen Treffer gibt". Und genau so funktionieren Caches nicht. Wie sie genau funktionieren ist ein Detail, das von Architektur zu Architektur und gern auch mal von Implementierung zu Implementierung unterschiedlich ist. Was aber immer stimmt: die Zeit um zu ermitteln ob ein Cache einen gesuchten Datensatz enthält oder nicht, ist kürzer als der direkte Zugriff um den Cache herum. Wäre das nicht so, wäre der ganze Cache eine Fehlkonstruktion. Und die findet man (zumindest unter den Architekturen, die sich am Markt behauptet haben) gerade nicht. Das war der Kern der Frage und folglich der Kern meiner Antwort. Detailwissen ist sicherlich hilfreich, aber erst nachdem diese grundlegenden Dinge geklärt sind.
Axel S. schrieb: > Für Otto Normaluser (und offensichtlich auch den TE) bedeutet > "durchsuchen" eine langwierige Operation a'la "wir schauen uns > jeden Eintrag im Cache an Möglicherweise. Aber da sich seine Frage aus der Lektüre eines Buches über Rechnerarchitektur ergab, halte ich genauere Betrachtungen der Arbeitsweise nicht für verkehrt. Der Schwerpunkt der Antwort liegt deshalb darin, was man unter dem Begriff "Suche" versteht. Im Fall von Caches erfolgt auch eine Suche, aber nicht nacheinander alle Plätze einzeln, sondern alle in Frage kommenden Plätze gleichzeitig. > eine langwierige Operation a'la "wir schauen uns > jeden Eintrag im Cache an Vollassoziative Caches tun genau das. Nur eben nicht nacheinander, sondern gleichzeitig, washalb es nicht langwierig ist.
:
Bearbeitet durch User
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.