Cache‐Grundlagen
Speicherunterstützung für Caches
Motivation
Erinnerung: CPU und Speicher kommunizieren über einen Bus.
Was beeinflusst die Miss‐Penalty?
• Geschwindigkeit des Busses.
• Speicherorganisation (siehe gleich).
Ein angenommenes Beispiel von Speicherzugriffswerten:
• 1 Speicherbuszyklus die gewünschten Adressen zu senden
• 15 Speicherbuszyklen für jeden initiierten DRAM‐Zugriff
• 1 Speicherbuszyklus ein Datenwort zu senden
Was ist die Miss‐Penalty bei einem Cache mit vier Word Breite und sequentiellem Zugriff auf ein DRAM mit einem Word Breite?
Kann man das verbessern?
Bessere Unterstützung durch das DRAM
Was ist die Miss‐Penalty für zweimal breiteren Bus und Speicher?
Bezeichnet man auch als Interleaving.
Bessere Unterstützung durch das DRAM
Was ist die Miss‐Penalty für Speicherorganisation mit 4 parallelen Bänken aber unverändertem Bus?
Bezeichnet man auch als Interleaving.
Entwicklungen der letzten Jahre
Organisation des Speichers in Zeilen und Spalten.
Vorhalten einer ganzen Zeile in einem schnelleren RAM‐internen SRAM.
SDRAM (Synchronous DRAM) – Eleminiere Zeit zur CPU‐RAM‐Synchronisation durch eigene Clock.
DDR (Double‐Data‐Rate) – Verdopplung des Datentransfers durch Verwendung sowohl
Verbessern der Cache‐Performance
Verbesserte Cache Strategien
Im Folgenden betrachten wir eine Verbesserung von Direct‐
Mapped‐Caching.
Zur Darstellung der Verbesserung verwenden wir folgende vereinfachte Cache‐Darstellung:
Tag Data 0
1 2 3 4 5 6 7
Speicher‐Blöcke 0 : ...
1 : ...
2 : ...
. .
8 : ...
9 : ...
10 : ...
.
Fully‐Associative‐Cache
Beobachtung: bei Direct‐Mapped‐
Cache kann ein Speicherblock nur an einer Stelle gespeichert werden.
Konsequenz: wechselhafter Zugriff auf zwei Speicherblöcke die auf die selbe Stelle gemappt werden, führt
permanent zu Cache‐Misses.
Praktisch wäre doch folgender Cache:
Ein Eintrag kann überall stehen.
Nachteil: Durchsuchen des Cache dauert länger und mehr Hardware‐Aufwand! Wie wäre es mit einem Kompromiss: ...
Tag Data 0
1 2 3 4 5 6 7
Speicher‐Blöcke 0 : ...
1 : ...
2 : ...
. .
8 : ...
9 : ...
10 : ...
.
Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data
(N‐Wege)‐Set‐Associative‐Cache
Tag Data 0
1 2 3 4 5 6 7
Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data Tag Data
Direct‐Mapped
Set Tag Data Tag Data
0 1 2 3
Set Tag Data Tag Data Tag Data Tag Data
0 1
Two‐Way‐Set‐Associative
Four‐Way‐Set‐Associative Speicher‐Blöcke
0 : ...
1 : ...
2 : ...
. .
8 : ...
9 : ...
10 : ...
.
Zwischenbilanz
Finden der Cache‐Zeile c des Speicher‐Blocks n in einem Direct‐
Mapped‐Cache der Größe k?
(Vergleiche anschließend n mit dem in Zeile c gespeicherten Tag)
Finden der Set s des Speicher‐Blocks n in einem N‐Way‐Set‐
Associative‐Cache mit k Sets?
(Durchlaufe dann die Set s und suche nach einem Tag der n entspricht)
Eine Frage ist noch zu klären
Annahme die Set eines N‐Way‐Set‐Associative‐Cache ist voll (bzw.
der Fully‐Associative‐Cache ist voll). Wo kann ein neuer Speicherblock abgelegt werden?
Häufig verwendete Strategie: Least‐Recently‐Used (LRU)
Ersetze den Block, auf den schon am längsten nicht zugegriffen wurde.
Tag Data Tag Data Tag Data Tag Data
24 ... 66 ... 20 ... 16 ...
Tag Data 44 ...
???
Mehr Wege resultieren in weniger Misses
Beispiel: betrachte Cache‐Varianten mit vier Speicherblöcken
Wie viele Cache‐Misses erzeugt die folgende Sequenz von Speicherblockzugriffen?
0 , 8 , 0 , 6 , 8
Tag Data Tag Data Tag Data Tag Data Tag Data
0 1 2 3
Set Tag Data Tag Data 0
1
Direct‐Mapped Set‐Associative Fully‐Associative
Mehr Wege resultieren in weniger Misses
Beispiel: Direct‐Mapped
Speicherblockzugriffe: 0 , 8 , 0 , 6 , 8 (Speicherblockinhalt = M[i])
Tag Data 0
1 2 3
Zugriff Hit oder Miss
Inhalt der Cache‐Blöcke nach der Referenz
0 1 2 3
0 8 0 6 8
Block‐Adresse Cache‐Block 0
6 8
Vorüberlegung: Auf welchen Cache‐Block werden die Block‐Adressen gemapped?
Mehr Wege resultieren in weniger Misses
Beispiel: Set‐Associative
Speicherblockzugriffe: 0 , 8 , 0 , 6 , 8 (Speicherblockinhalt = M[i])
Zugriff Hit oder Miss
Inhalt der Cache‐Blöcke nach der Referenz Set 0 Set 0 Set 1 Set 1 0
8 0 6 8
Block‐Adresse Cache‐Set 0
6 8
Vorüberlegung: In welche Set werden die Block‐Adressen gemapped?
Set Tag Data Tag Data 0
1
Mehr Wege resultieren in weniger Misses
Beispiel: Fully‐Associative
Speicherblockzugriffe: 0 , 8 , 0 , 6 , 8 (Speicherblockinhalt = M[i])
Zugriff Hit oder Miss
Inhalt der Cache‐Blöcke nach der Referenz Block 0 Block 1 Block 2 Block 3 0
8 0 6 8
Tag Data Tag Data Tag Data Tag Data
Wie Aufwendig sind mehr Wege?
Offset 2 Bits
Wie viele Wege sind sinnvoll?
Feste Zahl kann hier nicht genannt werden. Tradeoff:
Zeit/Hardware‐Aufwand versus Miss‐Raten.
Beobachtung:
(64KB Cache, 16‐Word‐Blöcke)
Miss‐Raten lassen sich in dem Beispiel mit mehr Assoziativität nicht besonders weiter reduzieren. Zeit/Hardware‐Aufwand durch mehr Assoziativität würde sich hier nicht weiter lohnen.
CPU
Multi‐Level‐Caches
First‐Level‐Cache
Second‐Level‐Cache
Speicher
Optimiert auf geringe Hit‐Time (und damit
recht klein)
Optimiert auf geringe Miss‐Ratio (also mehr und größere Blöcke und
damit höhere Hit‐Time)
Programm‐Performance
Beispiel: Quicksort und Radix‐Sort
Quicksort
• Vergleichsbasiertes Verfahren
• Generelle untere Schranke der asymptotischen Laufzeitkomplexität: O(n log n)
• Worst‐Case: O(n2)
• Best‐Case und Average‐Case: O(n log n)
• [n = Anzahl zu sortierender Elemente]
Radix‐Sort
• Bucket‐Sort‐basiert
• Laufzeitkomplexität: O(n * l)
• [n = Anzahl zu sortierender Zahlen, l = maximale Anzahl Ziffern pro Zahl]
• somit asymptotische lineare Laufzeit, wenn die zu sortierenden Zahlen eine feste Länge haben
Ist Radix‐Sort immer Quicksort vorzuziehen?
Asymptotischer Vergleich bzgl. Anzahl
Instruktionen pro zu sortierendem Element
Vergleich der Taktzyklen bei wachsender
Problemgröße
Vergleich der Cache‐Probleme bei wachsender Problemgröße
Radix‐Sort hat einen wesentlich größeren Speicherbedarf
mij 0x10000000
0x10000010 0x10000020 0x10000030 0x10000040 0x10000050 0x10000060 0x10000070 0x10000080 0x10000090 0x100000a0 0x100000b0 0x100000c0 0x100000d0 0x100000e0 0x100000f0
Beispiel: Matrix‐Multiplikation
Hier am Beispiel: 16 × 16 Matrix mit Byte‐Einträgen (256 Bytes)
Zugriff auf Eintrag mij der n × n Matrix M:
= *
C A B
i
j j j
Beispiel: Matrix‐Multiplikation
Betrachte C = A*B von n × n Matrizen A und B. Ergebnis Matrix (cij) :
= *
C A B
i
j j j
Matrix Multiplikation als Algorithmus
for i=0 to n-1 do
for j=0 to n-1 do result = 0
for k=0 to n-1 do
result += A[i,k] * B[k,j]
C[i,j] = result
= *
C A B
i
j j j
Cache‐Performance bei vergleichsweise sehr kleinem Cache
Zur Illustration: Annahme voll assoziativer Cache der Größe 256 Bytes und LRU Anzahl an Cache‐Misses, wenn mit leerem Cache gestartet wurde:
• Berechnung einer Zeile in C Zugriff auf C :
• Berechnung einer Zeile in C Zugriff auf A :
• Berechnung einer Zeile in C Zugriff auf B :
• Also insgesamt bei 16 Zeilen :
Verbesserung mittels Blocking
= *
C A B
i
j j j
Berechnung eines Eintrags (i,j) in einem m × m Block (x,y):
Umrechnung zwischen 𝑑 und Eintrag der Originalmatrix D klar:
Block (x,y)
Generelle Idee: Teile die große Schleife in viele hintereinander ablaufende Schleifen, die kleineren Speicherbereich adressieren und damit die Lokalität fördern.
Betrachte C = A*B von n × n Matrizen A und B (hier n=16)
• Zerlege Berechnung in Blöcke der Größe m × m (hier m=4)
• 𝑑 = Eintrag (i,j) in Block (x,y)
• Setze initial das Ergebnis 𝑐 = 0
Blocking als Algorithmus
n = 16 # n x n Matrix
m = 4 # m x m Blöcke; vereinfachende Annahme: n ist durch m teilbar
# Einträge in C[i,j] seien initial auf 0 gesetzt ---
for x=0 to n/m-1 do # durchlaufe alle Blockzeilen for y=0 to n/m-1 do # durchlaufe alle Blockspalten
for z=0 to n/m-1 do # für jede Zeilen/Spalten-Kombination do_block(x,y,z)
---
do_block(x,y,z):
for i=x*m to (x+1)*m-1 do
for j=y*m to (y+1)*m-1 do cij = 0
for k=z*m to (z+1)*m-1 do cij += A[i,k] * B[k,j]
C[i,j] += cij
Abschätzung der Cache‐Misses
= *
C A B
i
j j j
Einfache Abschätzung der maximalen Anzahl Cache‐Misses zur Berechnung eines Blockes in C
• für Zugriffe auf A :
• für Zugriffe auf B :
• für Zugriff auf C :
• also insgesamt :
Hier 4*4 = 16 viele Blöcke in C also
• maximale Anzahl Cache‐Misses insgesamt :
Vergleiche dies zu vorhin mit genau 4608 auf jeden Fall doppelt so vielen Cache‐Misses.
Zur Illustration Annahmen wie vorhin
• 256 Byte Cache
• voll Assoziativ
Virtueller Speicher
Die Idee
Speicherblock 0
Virtuelle Adressen
Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock 5 Speicherblock 6 Speicherblock 7
...
Speicherblock n Prozess 1
Speicherblock 0
Virtuelle Adressen
Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock 5 Speicherblock 6 Speicherblock 7
...
Speicherblock n Prozess 2
Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock 5
...
Speicherblock m
Virtueller Speicher Sekundärer Speicher Virtueller Speicher (Festplatte oder SSD)
Physikalischer Speicher Address‐
Translation
Address‐
Translation
Abbilden von virtuellen auf physikalische Adressen
Virtuelle Seitennummer Seiten‐Offset
Translation
Physikalische Seitennummer Seiten‐Offset
31 30 29 28 27 ... 15 14 13 12 11 10 9 8 ... 3 2 1 0 Virtuelle Adresse
29 28 27 ... 15 14 13 12 11 10 9 8 ... 3 2 1 0 Physikalische Adresse
Quiz: Größe x des virtuellen Adressraumes, Größe y des physikalischen Adressraumes und Größe z der Speicherblöcke?
Weitere Details zur Address‐Translation
Page‐Faults
Page‐Fault: die Page muss in eine freie Page im Speicher geladen werden. Was, wenn keine Page mehr frei ist?
Andere Page im Speicher muss ausgelagert werden. Mögliche Ersetzungsstrategie: LRU (siehe voriges Thema Caching).
Woher weiß man eigentlich, welche Page schon lange nicht mehr adressiert wurde?
Manche Prozessoren können die Page‐Table mit einem
Reference/Use‐Bit taggen. Den Rest muss das Betriebssystem übernehmen (mehr dazu in der Vorlesung Betriebssysteme)
Wie groß ist die Page‐Table?
Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum
indizieren der Page‐Table. Typischerweise spendiert man 32 Bits pro Tabellen‐Zeile (im Vorigen Beispiel brauchten wir mindestens 18
Bits). Damit benötigen wir insgesamt:
Anzahl Page‐Table‐Einträge:
Größe der Page‐Table:
Wir benötigen so eine Page‐Table pro Prozess!
Noch gravierender ist es natürlich für 64‐Bit‐Adressen!
Größe der Page‐Table:
Techniken zur Reduktion der Page‐Table‐Größe
Page‐Table‐Größe ist limitiert durch ein spezielles Limit‐Register:
Adressen erst mal nur bis maximal dem Inhalt des Limit‐Registers erlaubt. Limit‐Register wird nur bei Bedarf (also überschreiten) erhöht. Sinnvoll, wenn Speicher nur in eine Richtung wächst.
Page‐Table ist in zwei Segmenten organisiert:
Beide Segmente wachsen wie vorhin beschrieben mittels eines Limit‐
Registers nur bei Bedarf. Ein Segment wird für den Stack verwendet und wächst von oben nach unten. Das andere Segment wird für den Heap verwendet und wächst von unten nach oben. Höchstes Adress‐
Bit bestimmt welches der beiden Segmente verwendet wird. (Also:
Speicher in zwei gleich große Teile unterteilt)
Techniken zur Reduktion der Page‐Table‐Größe
Invertierte Page‐Tables:
Es wird eine Hash‐Funktion auf die virtuelle Adresse angewendet.
Die Größe der Page‐Table entspricht der Anzahl Seiten im
physikalischen Speicher. Jeder Eintrag speichert die aktuellen High‐
Order‐Bits der Adressen zu den die aktuelle Page gehört.
Mehrere Level von Page‐Tables:
Oberster Level zeigt zunächst auf sehr große Blöcke (auch als
Segmente bezeichnet). Innerhalb eines Segments wird wiederum mittels Page‐Table feiner (dann als Pages bezeichnet) unterteilt.
Referenzieren einer Page: High‐Order‐Bits bestimmen das Segment (wenn vorhanden); die nächsten Bits dann die richtige Page in
diesem Segment. Nachteil dieses Verfahrens: Adress‐Translation ist aufwendiger.
Techniken zur Reduktion der Page‐Table‐Größe
Paged‐Page‐Tables:
Page‐Table befindet sich selber im virtuellen Speicher. Mögliche rekursive Page‐Faults müssen durch geeignete Betriebssystem‐
Mechanismen verhindert werden. (Keine weiteren Details hier)
Schreiben von Pages
Schreiben einer Page in den Swap‐Space ist sehr teuer (kostet millionen von CPU‐Zyklen).
Write‐Through‐Strategie (siehe Abschnitt über Caching) ist hier
somit nicht sinnvoll. Eine sinnvolle Strategie ist Write‐Back, d.h. nur, wenn die Seite von einer anderen in den Swap‐Space verdrängt
wird, wird diese auch in den Swap‐Space geschrieben.
Auch das ist immer noch gleich so teuer, kommt aber seltener vor.
Muss man eine verdrängte Seite eigentlich immer zurückschreiben?
Nur, wenn diese verändert wurde.
CPU muss bei jedem schreibenden Zugriff auf eine Page in der Page‐
Table ein Dirty‐Bit setzen.
