Also was haben wir letzte Woche gemacht? Letzte Woche, letztes Bildchen. Caches. Wir haben uns

angeguckt. Caches machen generell mal Sinn. Aber man muss sich immer darum bemühen beim

Caching die Cache Blockgröße richtig zu wählen. Wir haben gesehen, ist die Cache Blockgröße zu klein.

Dann hatten wir das Problem. Wir holen zwar das Datum, was wir brauchen und können es auch

wieder verwenden, aber das Datum links und rechts davon, was wir wahrscheinlich auch gleich brauchen,

das haben wir noch nicht. Deshalb dauert es relativ lang. Du siehst nichts.

Und so ähnlich auf der anderen Seite. Wenn wir die Cache Blockgröße zu groß wählen, dann kommen wir

wieder in Bereiche, wo wir viele Misses haben, schlicht und ergreifend deshalb, weil dann zu wenig

Cache Zeilen im Cache sind. Und da kommt noch was dazu. Also das war jetzt sozusagen diese Grafik

hier. Kleine Blockgröße, hohe Missrate, große Blockgröße, irgendwann steigt es wieder. Es kommt

aber noch was dazu, was man natürlich nicht unbedingt vernachlässigen darf. Wenn man große

Blöcke hat, dann dauert es entsprechend natürlich auch länger, die Blöcke aus dem Speicher zu holen.

Und das ist jetzt hier noch die sogenannte Miss-Penalty. Erstmal dauert es einen Augenblick,

bis ich dem Speicher gesagt habe, ich hätte gerne ab Adresse sowieso meine Daten. Je nachdem,

wie viel Daten ich gerne hätte, kommt natürlich noch ein bisschen Zeit dazu, die einzelnen Bites

dann ranzuschaufeln. Es gibt erstmal diesen Offset. So lang dauert es mindestens. Ganz einfach,

ich muss dem Speicher meine Adresse sagen. Ab dann kommen die Daten zurück. Die zwei Graphen,

die überlagern sich sozusagen noch. Also hier haben wir gesehen, die Missrate steigt,

aber es steigt zusätzlich auch noch die Dauer, bis wir die Daten überhaupt dran haben. Wenn wir

die zwei überlagern, dann können wir uns die mittlere Zugriffszeit ausrechnen auf den Cache

und dann hat man auch so eine Badewannenkurve. Was wir brauchen ist jetzt letztendlich natürlich

immer eine Blockgröße möglichst genau da unten. Das hängt ein bisschen von der Applikation ab.

Ihr könnt euch vorstellen, wenn ihr große RAs von vorne bis hinten durchwühlt, dann habt ihr die

perfekte Lokalität. Wenn ihr das nullte byte braucht, dann ist die Wahrscheinlichkeit, dass

ihr das erste, zweite, dritte, vierte und alle nacheinander auch braucht sehr groß. Da kann man

sagen, ok, schöne große Blöcke, perfekt. Wenn ihr eine Datenbank habt, wo ihr mal hier, mal da,

mal da, mal da hin langt, dann habt ihr von großen Blöcken nichts. Das dauert bloß ewig lang,

wenn ihr die mal drin habt, um dann einen byte davon zu verwenden und dann sie nie wieder zu

gebrauchen. Also das kommt darauf an auf die Applikation. In der Praxis macht man es meistens so,

wer weiß was die heutigen Prozessoren so an Cash Block Größen besitzen. 64 byte ist,

ich sag mal, das Standardmaß im Moment. Es gibt auch andere, 32, 128, aber es ist ziemlich genau

immer 64. Da kann man natürlich sagen, eigentlich wären doch vielleicht 95 besser. Aber das werden

wir noch sehen, Blockgrößen anders als zweier Potenz, funktioniert nicht wirklich. Jo, ok. Wie

sollte das bei unserer kleinen CPU aussehen? Gut, kann man sagen. Da kann man natürlich sagen,

Standard ist irgendwie 64, haben sich ja wahrscheinlich Intel und Co. was bei gedacht,

dann sollten wir ja vielleicht auch 64 nehmen. Wir werden noch sehen, mit Blockgrößen,

es ist gar nicht so einfach, das zu implementieren. Wenn man es implementiert, ist natürlich sehr

viel einfacher, einfach die Größe zu cashen, die man sowieso gerade haben will. Also wenn die CPU

sagt, ich hätte gern vier byte, dann holt man sich die vier byte, packt sie in den Speicher und gut

ist. Wir werden uns nachher noch angucken, wie man unseren Cash bauen kann. Sehr viel einfacher.

Sehr, sehr viel einfacher. Nichtsdestotrotz würde ich dieses sehr einfache mal euch sehr

empfehlen und es tut natürlich das, wofür euer Cash da ist. Also im Prinzip könnt ihr eure kleine

Demo-CPU natürlich auch ohne Cash bauen. Ich meine, Performance bringt die eh nicht hier,

weil sie moniert in VHDL. Performance könnt ihr vergessen. Aber ihr braucht den Cash. Warum

braucht ihr den Cash? Genau. Ihr habt eure Pipeline und habt da euren Daten, euren Instruction-Cash und

die gehen dann irgendwie über einen Arbeiter auf den Bus. Es kommt bei unserem Pipeline bisher

nur darauf an, die Harbert-Architektur zu haben. Hier ist ein Weg zum Speicher, da ist ein Weg zum

Speicher und die funktionieren im Prinzip auch beide gleichzeitig. Das ist das, was wir erstmal

brauchen. Dass das auch noch Performance bringt, ist noch eine andere Geschichte. Aber wir brauchen

diese zwei Wege. Insofern muss man sagen, ihr braucht den Cash, sonst funktioniert eure CPU nicht.