Dann starten wir eine ganze Sache. Ich habe noch einen Nachtrag... ja bitte... also nee, ich dachte, das stellt eine Frage.

Ich habe noch einen Nachtrag zu letzter Woche. Da hat mich die Kommiliton noch aufmerksam gemacht, da war ein Kopierfehler drauf.

Ich glaube, da stand 2x1, F, F, 1 und 3xF. Das war natürlich falsch. Also das war ein Kopierfehler.

Und das bezieht sich auf die letzten beiden Einträge hier.

Und einmal muss das die Menge Nummer 1, F, F, E sein und einmal das andere Mal 1 und 3xF.

Okay, ich habe es berichtigt und ich glaube, ich muss sowieso noch mal einen neuen Satz hochladen,

weil ich heute noch mal eine andere Folie eingebaut habe.

Dann lade ich dann komplett und mache noch mal PDF aus dem ganzen Kapitel und laute es nochmal hoch.

So, ja, dann... wie weit sind wir jetzt gekommen?

Also wir sind jetzt hoffentlich in Bilde darüber, wie die Visokashes von der Organisation her aufgebaut sind.

Und was mir auch fiel, ich habe die Übungsleiter dann gesagt, dass es wahrscheinlich nicht schlecht ist, wenn sie in Übungen nochmal das durchprobieren.

Ich hatte irgendwie so ein Gefühl, es war vielleicht noch nicht ganz so völlig klar,

wie man die Adressen, die man tatsächlich dann abbildet, auf die richtigen Initias.

Das muss man einfach 4, 5, 6, 7, 8 mal machen und dann sitzt es und das sollen sie dann in Übungen auch nochmal tun.

Gut, ja, dann hat man das hier, Cash-Organisation, alles gemacht. Stimmt, eins genau.

Und heute geht es los mit 142. Wir haben eigentlich ein bisschen ein Programm für heute.

Also heute wollen wir uns dann anschauen, wie werden jetzt dann die Dinge, die man graben, wo wir nicht wirklich die Zeit dafür hatten,

Aktualisierungsstrategie, welche Einträge werden aktualisiert bzw. wann erfolgt die Aktualisierung im Hauptspeicher z.B. oder in übergeordneten Caches.

Denn es ist ja so, dass ich dann immer eine Inkonsistenz bekomme, zumindest wenn ich schreibe.

Beim Lesen, wenn ich natürlich nur Lesen darauf zugreife, dann kriege ich nie eine Inkonsistenz.

Dann profitiere ich halt davon, dass es schneller geht, wenn ich die Daten aus dem Cash hole.

Aber irgendwann werde ich es ja doch mal wahrscheinlich auch schreiben, wollen, müssen.

Und dann gibt es eine Inkonsistenz mit dem Eintrag im Hauptspeicher. Und dann ist die Frage, wie geht man damit um?

Und dann wird es irgendwann mal auch so sein, dass man nicht mehr genügend Platz im Cash hat und dann muss irgendwas raus.

Und dann stellt sich die Frage nach der Ersetzung. Welcher Block wird denn ersetzt?

Also das geht dann um die Ersetzungsstrategie. Und da werden wir uns dann im Laufe der heutigen Vorlesung ein paar quantitative Analysen anschauen

und Aussagen dazu treffen. Und dann will ich zur Cash-Modellierung kommen. Und dann will ich noch dazu kommen, wie kann man das Ganze von der Software aus auch nutzen?

Also wie kann man von entsprechenden Cash-Effekten positiv profitieren?

Und wenn es dann auch klappt, ja, ich stehe hier unten 20.11., das heißt, das war letzte Woche, das war ein bisschen optimistisch.

Und wenn es dann auch klappt, dann habe ich noch das Problem der Cash-Koherenz, was sich dann eben stellt, wenn man verschiedene Kerne hat

und die gemeinsame Daten haben und jeder hat seinen separaten Cash. Und es gibt also von diesen gemeinsamen Daten Kopien in den jeweiligen privaten Caches.

Und wie wird da eine Konsistenz hergestellt? Wenn der eine was überschreibt, wie kriegt der andere das mit? Oder muss er vielleicht gar nicht mitkriegen?

Das wollen wir uns anschauen. Aber Stück für Stück, wir kommen jetzt erstmal zur Aktualisierungsstrategie, also das Zurückschreiben der Cash-Werte.

Und wir haben das Problem, wir kriegen irgendwann mal eine Inkonsistenz zwischen Hauptspeicher und Cash, insbesondere dann, wenn wir halt schreiben.

Wann und wie wird der Hauptspeicher aktualisiert? Und da gibt es zwei grundsätzliche Strategien, die man verfährt, je nachdem, was man aktualisieren will, also wo man in der Cash-Wertarchie genau ist.

Und das eine ist das Durchschreiben des Write-Through. Das heißt, jede Änderung wird sofort im übergeordneten Speicher aktualisiert.

Wenn ich dann etwas verändere in meinem Cash, wenn ich den schreibe, bringe ich das in die nächst übergeordnete Komponente rüber.

Und dann ist immer eine Konsistenz gegeben, aber ich habe natürlich eine hohe Belastung des Prozessorspeicherbus.

Die L1, L2 Caches, die arbeiten häufig nach diesem Prinzip.

Das macht Sinn, weil da habe ich einen schnellen Zugriff vom L1 auf dem L2-Cache. Die sind nahe beieinander angeordnet, in der Regel auf dem gleichen Chip.

Und dann kriege ich eine Konsistenz.

Die andere Strategie ist das Write-Back. Das heißt, ich mache eine Aktualisierung erst bei einer Verdrängung.

Wenn also der Block aus dem Cash rausfliegt, erst dann, dann ist er weg und ich habe ihn verändert.

Also spätestens dann muss ich die Konsistenz wiederherstellen, dann muss ich zurückschreiben.

Und das kann passieren eben bei einer Verdrängung oder beispielsweise auch bei einer Ausgabeoperation.

Wenn ich also etwas ausgeben will, dann will ich es auch erst einmal im Speicher aktualisieren, damit es dann, wenn es später auf die Platte rausgeschrieben wird,

dass dann auch der richtige Wert auf der Platte gesichert wird.

Oder es erfolgt der Zugriff auch eines anderen Prozessors.

Man muss vielleicht auch zurückschreiben.

Der will auf das Datum im Speicher zugreifen, im Hauptspeicher.