"Datenbit" Kapazität vs "Overhead-Bit" Größe?

9

Ich bin etwas festgefahren, weil ich nichts finden kann, was den "Daten" -Teil des Caches abdeckt, alles, was ich gegoogelt habe, behandelt 99,9% mit der Adressierung des Caches. Die Frage, die mir gestellt wurde, ist so formuliert.

%Vor%

Ich will die Antwort nicht, also werde ich nicht die tatsächlichen Setgrößen posten und was nicht, ich suche nur nach einer Richtung zu vielleicht einer Webseite oder einer Erklärung, wie man die zwei "kontrastiert". Jede mögliche Hilfe wird sehr geschätzt!

    
Serguei Fedorov 05.07.2012, 19:31
quelle

3 Antworten

2

Ich bin mir nicht sicher, ob Sie uns genügend Kontext für diese Frage gegeben haben, aber hier geht es.

Caches müssen nicht nur die tatsächlich zwischengespeicherten Daten speichern, sondern auch - für jedes Datenelement - den "Index", auf den es sich bezieht. Wenn Sie also den Datensatz N suchen, muss der Cache nicht nur den Wert von Datensatz N enthalten, sondern auch N -, damit Sie die Daten tatsächlich nachschlagen können. Und das ist eine ziemlich simple Betrachtungsweise. Caches können andere Metadaten haben, um die Gültigkeit und die letzte Zugriffszeit anzuzeigen, usw.

Beispiel # 1: Ein Cache von Bytes in einem 32-Bit-Adressraum

Jeder Cache-Eintrag muss den Datenwert (8 Bits) plus die Adresse (32 Bits) = 40 Bits speichern,

Beispiel # 2: Ein Cache mit 32-Bit-Wörtern in einem 32-Bit-Adressraum

Jeder Cache-Eintrag muss den Datenwert (32 Bit) plus die Adresse (32 Bit) = 64 Bit speichern,

Sie können sehen, dass Beispiel 1 einen erheblich höheren Aufwand hat.

Wie immer kann Wikipedia helfen. Ссылка )

    
Roddy 05.07.2012 19:41
quelle
2

Cachespeicher speichern Daten, normalerweise in SRAM-ähnlichen Datenfeldern, haben aber auch einen Overhead. Ich mag die Begriffe "Datenbitgröße" und "Overheadbitgröße" nicht besonders, weil (a) Overhead vorhanden ist, der keine Speicherbitzellen ist, und (b) nicht alle Bitzellen gleichermaßen kostspielig sind. Aber lassen Sie uns jetzt mit diesen Begriffen fortfahren.

Ich nehme an, dass "Overhead-Bitgröße" sich wahrscheinlich auf die Anzahl der Tag-Bits bezieht, die gespeichert werden müssen, um auf den Cache zuzugreifen. Oft sind diese in einem anderen Array gespeichert, einem Tag-Array, das vom Daten-Array getrennt ist. Vergleichen Sie mit der Anzahl der Datenbits.

Hier sind drei einfache Beispiele:

Betrachten Sie einen 32 KiB (Kilobyte) Cache mit 64 B (Byte) Cache-Zeilen. In der Regel würden wir die Bits 0-5 der Adresse als Cache-Zeilen-Offset verwenden.

32 KiB / (64 B / Linie) = & gt; 2 ^ (5 + 10) / 2 ^ 6 = & gt; 2 ^ 9 = & gt; 512 Cache-Zeilen.

--- ++ Beispiel 1: Direkt zugeordnet

Stellen wir uns vor, dass es sich um einen direkt zugeordneten Cache handelt. Dann könnten wir die nächsten 9 Bits, die Bits 6-14 der Adresse, als einen "Index" in das Array von Cache-Zeilen aufnehmen.

So weit, so gut. Um das Tag herauszufinden, müssen wir die volle Adressbreite kennen. Nehmen wir an, dass es 64 Bits sind (obwohl die meisten "64-Bit" -Maschinen nur 40 oder 48 Bits ab 2012 implementieren). Um eine Cache-Zeile von jeder anderen Cache-Zeile zu unterscheiden, die auf den gleichen Eintrag im Cache abbildet, müssen wir die verbleibenden Bits der Adresse, Bits 15-63, 49 Bit, als das Tag speichern.

Ein Zugriff auf einen solchen direkt zugeordneten Cache erfolgt dann durch Extrahieren des Indexes, Auslesen des Tags und der Daten mit diesem Index, Vergleichen des ausgelesenen Tags mit dem Tag der Adresse, die wir nachschlagen, Deklarieren eines Treffers, wenn sie übereinstimmen und ein Miss wenn nicht, und so weiter.

Overhead: 49 Bits des Tags für jede 64B (512 Bits) Daten.

Gesamt:   * Tag oder "Overhead": 512 * 49 Bit   * Datenbits: 512 * 512 = 32KiB = 256 Kib (kibi-Bits).

--- ++ Beispiel 2: 8-way Set Assoziativ

Nun stellen wir uns vor, dass der Cache 8-Wege-assoziativ ist. Dies bedeutet, dass die 512 Zeilen in 512/8 = 64 Sätze mit jeweils 8 Zeilen unterteilt werden.

Der Offset innerhalb einer Cachezeile ist immer noch die Bits 0-5.

Allerdings brauchen wir jetzt nur 6 Bits als Index, um die gesetzte Zahl zu bestimmen. Bits 6-11.

Das Tag muss alle verbleibenden Bits, Bits 12-63, insgesamt 52 Bits enthalten.

Somit ist der Tag-Overhead für einen assoziativen 8-Wege-Cache 52 Bit des Tags für 512 Datenbits.

Gesamt:    * Tag: 512 * 52 Bits    * Daten: 512 Kib

Vergleiche mit den 49 Bits des Tags für die direkte Zuordnung. 8-Wege-Satz assoziativ bewegt im Wesentlichen log2 (8) mehr Bits in das Etikett; Im Allgemeinen bewegt N-Way-assoziativ assoziativ ceil (log2 (N)) - Bits in das Tag.

--- ++ Beispiel 3: Vollständig assoziativ

Dies ist das ferne Ende des Spektrums von direkt kartiert. Wir haben immer noch 512 Datenbits pro Cache-Zeile, aber jetzt ist die gesamte 64-Bit-Adresse, außer dem 6-Bit-Offset, ein Tag. 58 Bits des Tags für vollständig assoziative, gegenüber 52 Bits für 8-Wege, gegenüber 49 Bits für direkte Zuordnung.

Aber denken Sie daran, dass ich sagte, dass ich den Begriff "Overhead-Bits" nicht mag? Die Markierungsbits in einem vollständig assoziativen Cache müssen typischerweise nicht nur gewöhnliche Speicherbits sein, sondern müssen auch Komparatoren aufweisen - im wesentlichen XOR-Gatter. Solche "CAM (Content Addressable Memory)" Bits sind normalerweise teurer als gewöhnliche Bits.

--- + Fazit

Also, ich denke, das ist, was dein Lehrer will: ein einfacher Vergleich von Datenbits und Tagbits. Dies ist eine untere Grenze für den Overhead.

Das Spektrum von direkt zugeordnetem N-Wege-Set-assoziativ bis vollständig-assoziativ liefert ein Beispiel. Aber es gibt andere Aspekte des Cache-Designs, die den Overhead beeinflussen. Zum Beispiel:

  • Wenn Sie unterschiedliche Adressgrößen verwenden, ändert sich der prozentuale Overhead. Z.B. 32-Bit-Adressen würden nur 17 Bits des Tags im Diredt-gemappten Beispiel haben, im Gegensatz zu 49 Bits für eine 64-Bit-Adresse.

  • Wenn Sie die Cache-Indexierungsfunktion ändern, müssen Sie möglicherweise die Tag-Größe ändern. Zum Beispiel gibt es einen gewissen Vorteil, eine Primzahl von Cache-Zeilen oder -Sätzen in einem Cache zu haben, z. 511 Zeilen anstelle von 512 für einen sdirect-gemappten Cache. Primzahlen wie diese haben Resonanzprobleme reduziert. Aber einfach gemacht, müssen sie die Tag-Breite auf volle Breite von 58 Bits erhöhen.

  • Schemas wie sektorierte Caches ermöglichen die gemeinsame Nutzung bestimmter Teile der Tag-Bits.

Und so weiter.

Wie für eine Tutorial-Website:

  • Entschuldigung, ich kenne keinen solchen Anfänger-Kram. Aber ich würde nach Klassennotizen von vielen Universitäten googlen.

  • Meine Website Ссылка behandelt fortgeschrittene Themen in der Computerarchitektur. Aber diese Art von Dingen ist zu einfach, zu elementar, um comp.arch aufzustellen. Obwohl ich vermutlich einige einfache Erklärungen zu den Grundlagen schreiben sollte, bevor ich zu den fortgeschrittenen Themen übergehe.Gelegentlich schreibe ich solche Tutorials wie hier, aber ich habe sie nicht gesammelt.

  • kann die USEnet-Newsgroup comp.arch nützlich sein.

--- + Warum ist dies für Programmierer auf Stackoverflow wichtig?

Dies ist hauptsächlich ein Hardware-Thema.

Aber Programmierer, die den Code optimieren, müssen solche Dinge verstehen, um die beste Leistung zu erzielen.

    
Krazy Glew 20.09.2012 04:02
quelle
1

Da Sie Computerarchitektur und C markiert haben, nehme ich an, dass dies eine Aufgabe ist, bei der Sie aufgefordert werden, einen Cachesimulator in C oder etwas Ähnliches zu erstellen. Und die "zwei Caches" in der Frage beziehen sich auf zwei verschiedene Arten von Caching (vollständig assoziativ, n-way, direkt gemappt ..). In diesem Bereich werden Sie gebeten, den Unterschied zwischen den beiden Cachetypen und hauptsächlich das Verhältnis zwischen der Größe des 'Overhead-Bits' zu diskutieren. Hier sind die Informationen enthalten, die der Cache für Cache-Einträge (gültiges Bit, Offset, Tag) benötigt. Datenbit ", welches die tatsächlichen Daten sind, die in der Cache-Zeile gespeichert sind. Ich hoffe, das hilft.

    
acez 05.07.2012 19:42
quelle