Diskussion:Cache

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 21. Februar 2007 um 12:15 Uhr durch Stefan64 (Diskussion | Beiträge) (Änderungen von 84.135.206.7 (Beiträge) rückgängig gemacht und letzte Version von Tönjes wiederhergestellt). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Letzter Kommentar: vor 18 Jahren von Jdiemer in Abschnitt Schattenspeicher

Erläuterungen im Sinne der Enzyklopädie beachten

Ich wurde hierher umgeleitet, weil ich L2-Cache nachschlagen wollte. Statt dessen werde ich mit Fachsimpelei zugemüllt, L2-Cache wird wird trotzdem nicht erläutert.

Ist Dir das Unterkapitel Cache-Hierarchie aufgefallen? Dort wird es doch erläutert. --PeterFrankfurt 20:34, 25. Sep 2006 (CEST)

Suchmaschinen-Cache

Mir fehlt bei dem Artikel noch ein Verweis auf die Cache-Funktion bei Suchmaschinen(z.B. bei Google), bei denen die zwischengespeicherten Seiten betrachtet werden können - nützlich, wenn eine Seite gerade nicht erreichbar ist oder Inhalte der Seite vor kurzem von der Seite genommen wurden. Eine Größenangabe für den Cache-Speicher bei Suchmaschinen fänd ich auch klasse! Weiß da jemand mehr? --Dalaja 13:04, 16. Aug 2006 (CEST)

Cache Flush

Was und wozu soll das gut sein ? Ich finde diesen Abschnitt ziemlich widersprüchlich.

Versteh' ich nicht. Wo soll da ein Widerspruch sein? Ein Cache-Flush ist einen Anweisung an den Cache-Controller, alle bisherigen Cache-Inhalte zu verwerfen. Der Cache ist dann praktisch leer und kann mit neuen Inhalten gefüllt werden. Natürlich macht das bei LRU (scheinbar) keinen Sinn. Aber LRU ist nicht die einzige Ersetzungsstrategie, die es gibt: sie wird in der Praxis (bei CPUs) kaum eingesetzt, weil sie bei der Cache-Verwaltung nicht sonderlich effizient ist. Trotzdem ist sie ein hervorragendes Lehrbeispiel um das Prizip eines Caches zu veranschaulichen, deshalb hab ich sie beibehalten. Hier alle gängigen Strategien zu erklären, würde den Rahmen des Artikels sprengen und wäre eher ein Thema für das Wikibooks-Projekt. Ich habe den Cache-Flush auch nur beibehalten, weil er in der alten Fassung bereits erwähnt war. Er ist ein gutes Beispiel dafür, dass der Cache für den Programmierer doch manchmal in Erscheinung tritt. Übrigens ist bei der Überarbeitung des Artikels noch sehr viel zu tun. Nach dem Punkt, bis zu dem ich den Artikel überarbeitet habe, kommen viele Stichpunkte, die meist in keinen Zusammenhang gebracht werden und die sich ohne ein tieferes Einsteigen in die Materie nicht verstehen lassen. Da Wikipedia aber keine Stichwortsammelstelle ist, muss da noch viel dran gearbeitet werden. Wenn ich wieder mehr Zeit habe, mach ich mich dran... steht bereits auf meiner Liste. Wird aber noch etwas dauern. Die bisherige Überarbeitung war der leichte Teil --Ruscsi 12:13, 5. Mär 2005 (CET)
Da fehlt mir immernoch die Erklärung des praktischen Nutzens eines Cache-Flushes. Flush wäre dann auch falsch erklärt da ein flush das Ausschreiben des Caches bedeuteut - nicht das Leeren. D.h. ein flush bewirkt, dass alle Daten des Caches in den Hauptspeicher zurückgeschrieben werden um beide Speicher wieder konsistent zu machen. Ein pures Leeren entspräche nicht dem Wort "flush" wie es in der Informatik verwendet wird und ergibt meiner Meinung nach auch keinen Sinn. (Matrixx 14:21, 5. März 2005)
Stimmt. Das kommt noch dazu. Kommt auch auf das verwendete Konzept an (write through oder write back). Die Verwaltungsstrukturen werden aber dabei afair auch gelöscht. Warum zögerst Du? Ändere es doch! Dafür ist Wikipedia da :) --Ruscsi 15:03, 5. Mär 2005 (CET)
Hab den betreffenden Abschnitt geändert. Das mit den Verwaltungsstrukturen habe ich nicht übernommen, das mir unklar ist was das sein soll. (vieleicht sollte man das mehr spezifizieren). In welcher Situation ein Flush nun nötig ist wäre trotzdem noch schön zu wissen. Ziemlich häufig wird er ja nicht auftreten, da er ziemlich teuer ist. (Matrixx 17:23, 5. März 2005)
Das ist schon gut so. Jedenfalls drückt es das, was ein Cache-Flush ist erstmal besser aus. Zum Thema Verwaltungsstrukturen: Irgendwie muss der Cache ja auch verwaltet werden. Der Cache-Controller muss wissen, welche Daten er im Cache hat, also an welche Hauptspeicheradresse sie gehören und wo im Cache sie liegen und nicht zuletzt, ob sie überhaupt im Cache liegen und ob ein Block bereits in den Speicher zurückgeschriebn wurde usw... Kannst Du Dich vielleicht noch an die Tage erinnern, als man auf Mainboards bspw. auf dem ASUS T2P4 ein Tag-RAM nachrüsten konnte? In diesem Tag-RAM lagen z.B. ein Teil der Verwaltungsstrukturen des Cache. Erst damit konnte man die cacheable area vergrößern. Wichtig ist grundsätzlich, dass der Cache-Controller alle für ihn wichtigen Informationen bei der Entscheidung über das Ausliefern von Daten möglichst schnell bekommen kann. Die Verwaltungsstrategie muss also auf Geschwindigkeit und minimalen Verwaltungsbedarf ausgelegt sein. Aus diesem Grund ist die LRU-Strategie auch kaum auf CPU-Ebene umzusetzen. Wozu dient ein Flush: Wie gesagt, Du sagst dem Controller, dass die Daten nicht mehr gebraucht werden, der schreibt sie dann in den Speicher zurück bzw. stellt sicher, dass die Daten, die noch nicht wieder zurück in den Speicher gelangt sind wieder dort landen. Der Cache kann dann wieder schneller mit Daten gefüllt werden und der dahinterliegende Speicherbus kann auch entlastet werden, da der Cache-Controller jetzt keine Entscheidung mehr darüber treffen muss, welche Daten es "wert" sind, aus dem Cache geworfen zu werden (wobei natürlich auch manchmal falsche Entscheidungen fallen, die Du so verhindern kannst). Ein solcher Cache-Flush kann z.B. geschehen, wenn ein Programmierer weiss, dass er jetzt eine vollkommen neue Datenstruktur bearbeitet (flush des Daten-Caches) oder das Betriebssystem von einem Prozess zum anderen wechselt (code-cache-flush bei einem Kontext-switch). Das hängt auch gewaltig von der Architektur ab und ist im Detail natürlich viel komplizierter und auch nicht bei jeder CPU (Chipsatz) möglich. Die Details sind bei mir auch schon etwas länger her... ich muss da auch erst wieder alte Unterlagen rauskramen und mich einlesen. Daher alles ohne Garantie ;-) --Ruscsi 17:49, 5. Mär 2005 (CET)

missverständliche Formulierungen?

Warum der Umstand, dass Cache übersetzt "geheimes Lager" heisst, darauf hindeutet, dass der Cache "nicht direkt addressierbar" ist, verstehe ich nicht. Die nicht-direkte Adressierbarkeit ist zwar richtig, taugt aber nur bedingt als Erklärung. Vielmehr sollte man auf Lager als Äquivalent für Speicher und geheim als Äquivaltent für die Transparenz bzw. Verborgenheit des Caches abheben. Das tut die neue Formulierung keineswegs besser als die alte, imo eher schlechter.

Auch gegen die uneingschränkte Transparenz des Caches wehre ich mich. Ich hatte die Formulierung "weitgehend transparent" gewählt, weil ein Programmierer die Existenz eines Caches keineswegs grundsätzlich ignorieren kann. Grade bei der Verarbeitung großer Datenmengen ist der richtige Umgang mit der Cachgröße bei der Wahl der Verarbeitungsalgorithmen keineswegs vernachlässigbar. Werden die zu verarbeitenden Datenstrukturen zu groß gewählt, kann das erhebliche Performanceprobleme nach sich ziehen, weshalb ein Algorithmus unter Umständen durchaus die Existenz und die Größe eines Caches berücksichtigen muss. Daher auch der Hinweis auf die Relevanz bei der Performance-Optimierung.

Auch die Vernachlässigbarkeit des Caches für den Compiler ist nur richtig, solange der Compiler keinen Wert auf Optimierung legt. So kann ein Compiler durch geschickte Platzierung von Datenstrukturen durchaus dafür sorgen, dass Zugriffe auf konkurrierende Speicherbereiche sich nicht gegenseitig aus dem Cache werfen. Kaum ein Compiler kann es sich heute noch leisten, die Existenz und das Wissen um die Funktionsweise von Caches zu ignorieren, weshalb ich diese Aussage in der heutigen Zeit sogar als grundlegend falsch bezeichnen würde: vergleiche auch [1].

Ob die nicht weiter erklärte Erwähnung des "Quotes-of-the-day" wirklich sein muss, darüber kann man ja streiten und auch die Erweiterung mit dem "Schattenspeicher" ist eigentlich gut, aber eine Sinnentstellung der Aussagen eines ganzen Absatzes sollte bitte nicht vorgenommen werden.

Ich bitte um eine weniger radikale Veränderung der Aussagen dieses Absatzes und um einen syntaktisch korrekten Satzbau ohne vergessene Worte. Gut, kann ja mal passieren, aber es läßt vermuten, dass die Änderungen mal schnell so-la-la gemacht wurden. --Ruscsi 15:33, 19. Mär 2005 (CET)

„On-Die“

Warum heißt es im Text „on-Die“? Ich kenne „On-Chip“, was ich für wesentlich sinnvoller halte, da ich „Die“ nur als Bezeichnung für den Chip kenne, wenn es darum geht, auszusagen, dass ein ungehäuster Chip gemeint ist. (Ein Die wird auf eine Platine geklebt, dort gebondet und vergossen. Ich habe noch nie gehört, dass von Die gesprochen wird, wenn es um einen Chip im herkömmlichen Chip-Gehäuse geht. (Außer wenn es um den Akt der Montage des Chips in das Gehäuse geht.)) Für die Funktion des Caches ist es interessant, ob er auf demselben Chip sitzt; die Gehäusetechnik ist nicht von Belang.

Deutsch (na ja) dafür wäre „monolithisch“.

Architektur

Auf Grund der konkreten Angaben vermute ich, dass der Beschreibung eine konkrete Prozessor-Architektur zu Grunde liegt. Vielleicht sollte man im Text darauf hinweisen. (So was wie „die folgenden Angaben beziehen sich auf die Terzium-7-Technologie des Herstellers Entil, die zu Grunde liegenden Prinzipien sind jedoch von allgemeiner Natur“.)

-- Peter, 217.95.172.146 01:46, 28. Mär 2005 (CEST)

Die beschriebenen Technologien sind Basistechnologien, die sogut wie jede heutige Architektur umsetzt. Wie sie im Detail implementiert sind, unterscheidet sich natürlich, aber darauf wird hier auch nicht eingegangen. --Matrixx 09:53, 9. Dez 2005 (CET)

Adressierungstechnik - satzassoziativ

Hallo,

wie ich meine ist die gegebende Beschreibung nicht korrekt. Ein neuer Block kann in jedem set doch nur an genau eine Position geschrieben werden - nicht, wie behauptet, beliebig gewaehlt werden. Die Wahl eines Sets ist voll-assoziativ und innerhalb eines Sets sind die Bloecke direkt abgebildet. So steht es auch hier: [2]

Bis dann, Klaus

Wenn du Recht hättest, wäre ja auch die Erklärung zu vollassoziativ verkehrt. --matrixx 14:56, 26. Jan 2006 (CET)
Ich versehe nicht, was du damit meinst. Ich behaupte, dass innerhalb eines sets bei n-fachen Speichern direct mapping angewandt wird. Die Erklärungen zu direkt mapping und vollassoziativität sind richtig.
Unter dem englischsprachigem Wikipedia Eintrag steht dies auch so. Die Realisierung der Notwendigen Comparatoren bei vollassoziativen Sets wäre relativ aufwendig. Laut Wikipedia (eng.) ist der Level 1 Cache des AMD Athlon ein 2-fach assoziativer Speicher. Gehen wir nun von 512kb Cachegroesse aus. Eine Cacheblock hält 8 Byte. => Es existieren 32768 Blöcke innerhalb jedes Sets. Wie würdest du alle einzelnen Cache Einträge innerhalb eines Sets überprüfen, um den richtigen zu finden?
Klaus
Ich habe mich seit langem nicht mehr mit diesem Thema auseinandergesetzt. Habe den Abschnitt im Rahmen einer Prüfungsvorbereitung verfasst. Wenn du dir also sicher bist, dass was nicht stimmt - ändere es. --matrixx 12:02, 31. Jan 2006 (CET)

Aussprache

Unser Dozent meint, da Cache aus dem Französischen komme, würde es wie "kasch" ausgesprochen und nicht wie "käsch".

Cache als solches gibts im franz. gar nicht. Nur caché bzw. cacher. Wenn wir also von cache sprechen, kann nur das engl. Wort gemeint sein. [3] --matrixx 23:05, 9. Feb 2006 (CET)

Dein Dozent hat natürlich völlig recht. Auch im Englischen wird Cache wie Kasch ausgesprochen (zumindest von den mir bekannten Engländern). Allerdings finde ich Pufferspeicher doch schöner... Geggo 16:06, 17. Nov. 2006 (CET)Beantworten

Pufferspeicher würde ich auch bevorzugen. Im Zeichen der Veramerikanisierung muß man doch einfach mal ein "Statement" :-) setzen...[Unbekannter Nutzer]

Coherency Miss

"Wenn durch das Schreiben eines Prozessors in einen Cache-Block der gleiche Block im Cache eines zweiten Prozessors hinausgeworfen werden muss, so führt der Zugriff des zweiten Prozessors auf eine Adresse, die durch diesen entfernten Cache-Block abgedeckt war, zu einem Miss, den man als Kohärenz-Miss bezeichnet."

Der Satz oben ist mir nicht ganz klar. Hat hier jede CPU ihren eigenen Cache, so dass wir von 2 Caches sprechen? Wieso muss dann ein Block aus Cache2 raus, weil CPU1 einen Block in Cache1 geschrieben hat? Er kann doch eigentlich drin bleiben, oder? (Vorstehender nicht signierter Beitrag stammt von 134.100.6.209 (DiskussionBeiträge) 2006-10-19T10:54:38)

Schattenspeicher

Hier der gleiche Kram wie unter Paging.. Wer bitteschön sagt denn "Schattenspeicher"? Ich mein, Pufferspeicher, klar, das kennt und liest man auch, aber Schattenspeicher? --84.56.140.80 01:15, 5. Jan. 2007 (CET)Beantworten

Lt. Google gibt es gut 700 Referenzen auf Schattenspeicher (bei Kachelverwaltung nur gut 100)... Die Ausdrücke werden also genutzt, wenn auch recht wenig. Zum Vergleich: "Rechenwerk" (ebenfalls ein deutsches Wort aus dem Umfeld) wird knapp 100.000 mal referenziert, "Fließkommaeinheit" (von meinem Sprachempfinden deutlich gebräuchlicher als Schattenspeicher) aber ebenfalls nur gut 700 mal... Vielleicht sollte man solche Eindeutschungen entsprechend kennzeichnen, z.B. "zu deutsch, aber unüblich" oder so. --Jdiemer 09:39, 5. Jan. 2007 (CET)Beantworten
Hab die Resultate mal überflogen.. Ein guter Teil dieser 700 Treffer hat mit Caches gerade mal garnix zu tun.. [[4]] [[5]]. Also wech..