Diskussion:Cache

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Cache“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

mehrere Schnitzer

"Zurückkopieren (write-back): Beim Schreiben wird der zu Schreibende Block nicht sofort in der nächsthöheren Speicherebene abgelegt, sondern zunächst im Cache. Dabei entsteht eine Inkonsistenz zwischen Cache und zu cachendem Speicher. Letzterer enthält somit veraltete Information. Erst wenn das Wort aus dem Cache verdrängt wird, wird es auch in die nächsthöhere Speicherebene geschrieben. Dazu bekommt jeder Cacheblock ein dirty bit, welches anzeigt ob der Block beim Ersetzen zurückkopiert werden muss.Dies führt bei Speicherzugriff durch andere Prozessoren oder DMA-Geräte zu Problemen, weil diese veraltete Informationen lesen würden.

Durchgängiges Schreiben (write-through): ..."

Abgesehen vom fehlenden Leerzeichen stecken hier zwei Probleme drin:

Erstens ist die Aussage falsch, weil besagte Probleme nicht vom dirty bit verursacht werden - sie sind auch ohne das schon da. (Der Fehler kommt daher, dass das Wort "dies" an dieser Stelle einen falschen grammatikalischen Bezug hat. Ohne den Satz über das "dirty bit" ist dieser Fehler nicht da; dieser Satz wurde also wohl nachträglich eingefügt, ohne Rücksicht auf das Nachfolgende zu nehmen.)

So weit ist deine Anmerkung korrekt: Das "Dies" muss sich auf die Inkonsistenz beziehen, nicht auf das dirty-bit, welches das Problem ja (mit) behebt.

--arilou (Diskussion) 12:11, 26. Nov. 2013 (CET)

Zweitens ist hier die Formulierung "ZURÜCKschreiben" verwirrend. Verdeutlichend formuliere ich mal um: " Beim Schreiben wird ... nicht sofort in der Zielstation geschrieben, sondern zunächst einer Zwischenstation. (...) Erst wenn das Wort aus der Zwischenstaton verdrängt wird, wird es auch in die Zielstation geschrieben. Dazu bekommt jede Zelle der Zwischenstation ein dirty bit, welches anzeigt, ob sie beim Ersetzen zurückkopiert werden muss." Die Generalrichtung ist also anscheinend sonnenklar: vom Startpunkt in die Zielstation. Diese Vorstellung wird von den beiden ersten Sätzen suggeriert. Der Ausdruck "zurückkopiert" bedeutet hier sprachlich ganz klar die GEGENrichtung; also von der Zielstation zur Zwischenstation (= Cache). Das würde hier aber doch Datenverlust bedeuten - kann also nicht richtig sein! (Oder habe ich das Ganze nicht verstanden? (Was wieder die Frage aufwerfen würde, ob das nicht an einer unzulänglichen Erklärung liegt! ;-) ))

Halb richtig. Es wird davon ausgegangen, dass im Allgemeinen "vom Hintergrundmedium gelesen" und später "ins Hintergrundmedium (die Daten verändert) zurück geschrieben" werden.

In deinem Beispiel ist das etwas verwirrend, ja. Hm, vmtl. eine dieser "schlampigen Sprechweisen" von uns Computerleuten, die wir "schon wissen, was damit gemeint ist"...

--arilou (Diskussion) 12:11, 26. Nov. 2013 (CET)

"non-write-allocate: Es wird am Cache vorbei in die nächsthöhere Speicherebene geschrieben, ohne dass der dazugehörige Block in den Cache geladen wird." Das bedeutet doch eine Inhalte-Diskrepanz! Kommt jetzt ein Lesezugriff auf den Block im Cache, werden veraltete DAten ausgelesen!! Hier muss offenbar umformuliert werden.

Nein, denn der Inhalt ändert sich, wie gewünscht, direkt auf dem Hintergrundmedium. Im Cache ist der entsprechende Bereich gar nicht vorhanden, und kann somit auch nicht "diskrepant" zum Hintergrundmedium sein.

--arilou (Diskussion) 12:18, 26. Nov. 2013 (CET)

Und ganz allgemein: Die Darstellungsweise "je höher, desto langsamer" für die Speicherebene ist widersinnig: Schaltet man das Gerät aus, sind die Daten im Dauerspeicher noch da, und sonst überall weg. Grundlage des Datenbestandes, auf die aufgebaut wird, ist der Dauerspeicher, der langsamste Speicher von allen. Darauf bauen die anderen Datenspeicher auf: von Etage zu Etage immer schneller, immer kurzlebiger. Der Artikel stellt diese natürliche Betrachtungsweise also unnötig auf den Kopf. Gruß, Yog-S, 213.102.96.140 12:56, 16. Jun. 2007 (CEST)

Ansichtssache. Manch einer baut sich sein Gedankenmodell "von unten nach oben" auf, andere gerade andersherum. Da muss ich auch ab und zu zweimal denken. Für beide Modelle gibt's übrigend die absolut logische Tatsache(!), dass man es genau so betrachten muss. Mein Rat: Gewöhn' dich dran, dass die "schnellste Cache-Ebene" mal ganz oben, mal ganz unten angenommen wird...

--arilou (Diskussion) 12:18, 26. Nov. 2013 (CET)

Angenommen die CPU arbeitet im WriteBack und Spiecherstelle 4711 ist gechached und wird geändert. Es erfolgt kein sofortiges Zurückschreiben - das stimmt. Es stimmt aber nicht, dass es zu einer Inkonstitnz käme - das verhindert die Northbridge. Wird durch eine andere Einhait (z.B. durch deine Graka) auf den Speicher zugegriffen, so löst die Northbridge in der CPU einen Flush Cache und somit einen Abgleich des Caches mit dem Speicher. (nicht signierter Beitrag von 84.170.62.207 (Diskussion | Beiträge) 18:05, 15. Mär. 2009 (CET))

Äh, doch. Im Cache stehen (neue) Daten, die im Ram noch veraltet stehen - dat is eine Inkonsistenz. Kann jedoch hingenommen werden, solange sonst niemand diese Ram-Stelle zugreift. Erst wenn ein anderes Gerät (2. Prozessor, DMA-Controller, ...) auf dieselbe Adresse zugreifen will, muss diese Inkonsistenz aufgelöst werden. Bis dahin ist sie jedoch durchaus vorhanden ;-) --arilou 14:55, 11. Jul. 2011 (CEST)

Irrtum. Nachhilfe Informatik, auch für Nicht-Techniker: Die Northbridge oder was sonst auch immer erfüllt eine verpflichtende Aufgabe bei der 'Funktion Cache' (dt. kachieren), wenn ein Schreibzugriff erfolgte muß ein nicht unterbindbarer Vorgang geplant werden, der das Schreiben der neuen Daten auf den Hauptspeicher (ggf. auch Festplatte) also das eigentliche Speichermedium auslößt; entweder bevor ein anderer direkter Lesezugriff erfolgt oder ein konkurrierender Lesezugriff wird ggf. verzögert bis der Schreibzugriff auf dem Hauptspeicher erfolgt ist.

Vielen ist der Sinn nicht bewußt genug: Langsames Medium wird durch Cache kaschiert, damit meist schneller auf Daten zugegriffen werden kann. Gilt für alle Formen von Cache außer Geocaches. Einfach, aber gut und NUR sinnvoll wenn die Mehrzahl der Zugriffe so schneller erfolgt, sonst nicht!

Kaschieren bedeutet die Wirklichkeit/Wahrheit zu verbergen und etwas schöneres/besseres (für uns eben schnelleres) vorzutäuschen, begriffen? --Harter Kritiker (Diskussion) 12:54, 24. Nov. 2013 (CET)

Der Irrtum ist auf deiner Seite. Was du beschreibst nennt man "Write-Through", steht auch im Artikel. Bei "Write-Back" wird eben gerade nicht sofort ins langsame Hintergrundmedium geschrieben, sondern erst mal nur in den Cache. Erst wenn's dem Cache irgendwann gefällt wird dann tatsächlich auf das Hintergrundmedium geschrieben - ggf. niemals.

--arilou (Diskussion) 12:11, 26. Nov. 2013 (CET)

Hast du überhaupt meine Bemerkung gelesen und nicht irgendwas anderes? Ein Cache kann ein Schreib- und Lesecache sein oder nur Lesecache, ist das nicht festgelegt, so wird durch die Einstellung Write-Through das Verhalten eines Lesecaches gewählt, bei Write-Back arbeitet er auch als Schreibcache. Ich schrieb über kaschierte Schreibzugriffe, also Write-Back notwendigerweise. Und von sofortigem Zurückschreiben war nicht die Rede, eher von 'rechtzeitigem'; das Timing ist ja wieder eine ganz eigene Geschichte. und in einem Punkt irrst du dich garantiert, 'niemals' ist per definition beim Zurückschreiben unzulässig. Das wäre gewisssermaßen eine Fehlimplentierung! --Harter Kritiker (Diskussion) 21:36, 27. Nov. 2013 (CET)

1. Es gibt auch reine Schreib-Caches.
2. Ein Write-Through-Cache ist zwar ein Lesecache, verhält sich aber anders, je nachdem ob man non-write-alloc oder write-alloc mit ihm kombiniert.
3. Der Begriff "Timing" ist unüblich, er unterstellt, dass es Race Conditions geben könnte. Ein anständiger Cache arbeitet stets deterministisch.
4. Dass "niemals" keine "saubere" Implementierung sein mag ~ ok. Aber es wird durchaus gemacht, z.B. wenn eine Festplatte von einer SSD gecachet wird. Es ist durchaus üblich, dass ein durchgeführter Schreibvorgang (auf die SSD) lange Zeit nicht (oder niemals) auf der Festplatte nachgeholt wird. Zumindest kann der PC zwischenzeitlich heruntergefahren und ausgeschaltet werden. 2.) Bei exclusive-Prozessorcaches kann die Cache-Hierarchie durchaus durchbrochen werden, und statt einem Schreiben in die nächst-niedrigere Cache-Ebene wird direkt ins Ram geschrieben - das spart Umsortiererei im exclusive-Cache (~ in die nächst-tiefere Hierarchiebene wird diese Änderung also niemals übernommen...)

--arilou (Diskussion) 14:09, 28. Nov. 2013 (CET)

Cache-Strategien

im text steht "Normalerweise wird entweder die Kombination write-back mit write-allocate oder write-through mit non-write-allocate verwendet." gibt es dazu eine begründung? ist mir irgendwie nicht offensichtlich klar, warum das so ist. oder ist das einfach historisch so gewachsen? --85.178.79.38 17:12, 16. Jan. 2009 (CET)

Die erste Kombination beruht auf der Annahmen, dass aufeinander folgende Schreibzugriffe auf denselben Block komplett im Cache abgewickelt werden (bis auf den ersten Miss). Dies ergibt im 2. Fall keinen Vorteil, da eh jeder Schreibzugriff zum Hauptspeicher muss, weshalb die Kombination write-through mit write-allocate eher unüblich ist. PS: Ich schreib das auch so in den Artikel. --Jdiemer 17:47, 16. Jan. 2009 (CET)

Zuerste einmal: Für jede Speicherebene sind darüber oder darunter liegende Speicherebenen transparent. WriteBack bedeutet kein sofortiges Durchreichen and die Ebene darunter, WriteThrough heisst update des eigenen Caches UND durchreichen nach unten. write-allocate bedeutet Datum im eigenen Cahce merken, non-write-alloc bedeutet diesen nicht merken.

"write-allocate" und "non-write-alloc" hast du nicht ganz richtig beschrieben (vmtl. meinst du's richtig). --arilou (Diskussion) 12:33, 26. Nov. 2013 (CET)

Keinen Sinn ergibt die Kombination WriteBack und non-write-alloc - auf Deutsch: Datum nur in den Cache aber Datum im Cache nicht merken. Wird non-write-alloc geschaltet, bedeutet dies automaitsch write-Through. (nicht signierter Beitrag von 84.170.62.207 (Diskussion | Beiträge) 18:13, 15. Mär. 2009 (CET))

Da muss ich widersprechen, anscheinend hast du "non-write-alloc" nicht richtig verstanden. Es kann sehrwohl sinnvoll sein, Write-back mit non-write-alloc zu kombinieren; und non-write-alloc einzuschalten, bedeutet nicht zwangsweise, Write-Through verwenden zu müssen. --arilou (Diskussion) 12:33, 26. Nov. 2013 (CET)

Getrennte Befehls- und Datencaches

Frage: "Selbstmodifizierender Code" klar, macht Probleme. Wie ist es aber mit Code, der sich zwar nicht selbst modifiziert, aber bei dem die Variablen/Konstanten ihre Speicherorte zwischen den Anweisungen liegen haben:

Sprungmarke1:
 Befehle
 Sprunganweisung
 Variable(n)
Sprungmarke2:
 ...

? Außerdem gibt's doch bei vielen Befehlen "immediate" Parameter (Zahlenwerte), die stehen doch auch direkt "zwischen" den Befehlen? --arilou 15:57, 10. Mai 2011 (CEST)

He, das sieht ja verdächtig wie die alte PRINT-Routine bei Commodores 8-Bittern aus :-), und das "immediate" kenne ich auch vor allem vom 6502. Also: "Immediate"-Werte sind unzweifelhaft Bestandteile von Befehlen und werden (außer bei selbstmodifizierendem Code) auch nicht zur Laufzeit verändert. Variablen zwischen Programmteile zu platzieren, ist einfach nicht mehr üblich, auch nicht mehr nötig, weil man mehr Platz hat, da nimmt man heutzutage Stack oder Heap. Wenn es doch noch vorkommt, wirkt es halt wie selbstmodifizierender Code. --PeterFrankfurt 02:48, 11. Mai 2011 (CEST)

Zum C64 (und sonstigen 8-Bittern) kann ich (fast) nix sagen X-)

"immediate" bzw. Operanden gibt's bei sehr vielen Assemblerbefehlen, hab' mich schon immer gefragt, wie denn der Prozessor vor dem Dekodieren des Befehls das aufspalten soll in Befehl und Daten (hab' schon vermutet, dass, wie Du sagst, es einfach gar nicht gemacht wird).

Zur Unterscheidung, ob eine Cache-Line in Befehls- oder Datenbereich kommt, dient vmtl. der Umstand, ob's eine Anforderung via IP oder via Datenzugriff ist? Wenn sich eine Daten-Line dann doch als Befehl entpuppt, ist es dann üblich, beide Cachebereiche umzugeladen (raus aus "Daten", rein in "Befehl"), oder kann der Datenbereich dann i.A. "direkt als Befehl liefern"?

--arilou 12:09, 11. Mai 2011 (CEST)

Die Vermutung ist korrekt: Befehlszugriffe über den IP landen im CC, Zugriffe über die Operatoren im DC. Es findet jedoch kein Austausch zwischen den beiden Caches statt - sollte sich ein Datum als Befehl entpuppen, wird die entsprechende Cacheline im CC aus dem Speicher neu befüllt. 2003:CB:A70A:2C01:1DB7:9099:1105:9BB3 09:33, 1. Jul. 2019 (CEST)

Quellenangabe #5 nicht korrekt

Der Betreiber der Seite www.google-cache.de ist nicht Google, sondern "ein Projekt von WeltDerTutorials.de". Keine Ahnung ob die Angabe "Google-Cache wird in der Regel alle 7 Tage aktualisiert" korrekt ist und daher ist es fragwürdig ob die Quelle überhaupt herangezogen werden sollte. (nicht signierter Beitrag von 193.174.73.57 (Diskussion) 23:44, 24. Jun. 2013 (CEST))

Die wichtige Frage «warum & wozu» fehlt, die vieles verständlicher machen könnte

Wozu wird Cache (diese Technik) überhaupt eingesetzt und warum erscheint dies notwendig?

Auf diese Frage gibt es eine gute und recht allgemeinverständliche Antwort, die weiterhilft, als tiefer gehende Erläuterungen des «wie», die eher in eine universitäre Informatikvorlesung gehören. Solche Vorlesungen habe ich genug gehört und biete deshalb einen hoffentlich für alle gangbaren Ausweg an.

Soweit ich das sehe, ist das "warum & wozu" gut bis sehr gut

1. direkt im 1. Satz der Einleitung (sowie teilweise in der weiteren Einleitung)
2. sowie ausführlich im Abschnitt "Nutzen", direkt nach der Einleitung,

beschrieben.

--arilou (Diskussion) 14:42, 26. Nov. 2013 (CET)

—Übrigens gilt auch in solchen Vorlesungen die Frage der Aussprache als zumindest umstritten, nicht für mich, da ich die Entstehungsgeschichte als Student miterlebt habe. [Richtig nach meiner Erinnerung und Notizen: Cache (frz. [kaʃ]^[1], verbreitet auch [kæʃ]) bezeichnet in der EDV den Einsatz eines schnellen Puffer-Speicher … Cache ist ein Lehnwort. Seinen Ursprung hat es im französischen …] Sofern kein qualifizierter Widerspruch erfolgt, würde ich die Korrektur kurz nach dem Nikolaustag einpflegen.

Dazu bitte oben weiter diskutieren - ich dachte, du wärst derjenige, der "niemals" zulassen wollte, dass jemand ein "richtig" oder "falsch" festlege.

Und was den "qualifizierten Widerspruch" (sic!) betrifft: Wer Änderungen durchführen will, muss qualifiziert (also belegt) agieren; von vorhandenen Artikel-Inhalten wird angenommen, dass sie belegt sind. Also: Für Änderungen deinerseits fordere ich Belege.

So herum wird da ein Schuh draus. --arilou (Diskussion) 14:42, 26. Nov. 2013 (CET)

Zurück zu Antwort auf die Sinnfrage:
Das Kaschieren einer (potentiell) langsamen Quelle durch ein vornehmlich schneller Resultate lieferndes 'Cache' erscheint notwendig wegen sogenannter (technischer) 'Flaschenhälse' oder ineffizient arbeitender Technik (sowohl Hardware als auch Software, sowie Übertragungstechnik) bei (oft unnötig) großen Datenmengen. Wenn also z.B. etwas das Betriebssystem genannt wird, nur langsam auf beispielsweise Informationen eines Datenträgers zugreift, ist ein Cache erst einmal das probate Mittel, dieses Geschwindigkeitsproblem so zu umgehen, das es nicht auffällt. {Genau dies tut ein Cache doch und nichts anderes — so macht es Sinn!}

Ziemlich umgangssprachlich, und damit auch teilweise falsch. Zum Beispiel:

• Das Hintergrundmedium muss keine "Quelle" sein, es kann auch Datensenke (Ziel) sein.
• Das Hintergrundmedium wird nicht "kaschiert", sonder "gecachet". "Kaschieren" bedeutet "verstecken", was nicht zwingend notwendig ist. Der Verwender (das Anwendungsprogramm) kann durchaus (zusätzlich) einen echt-direkten Zugriff auf das Hintergrundmedium erhalten.
• "Cache" ist laut Duden maskulin, nicht neutrum.
• Gecachete Technik mit langsamem Zugriff ist trotzdem nicht zwingend "ineffizient".
• usw. usw.

"Genau dies tut ein Cache doch und nichts anderes — so macht es Sinn!" - nur teilweise richtig. Es gibt weitere sinnvolle Einsatzmöglichkeiten für einen Cache, als nur "um die Zugriffsgeschwindigkeit zu erhöhen". "nichts anderes" - falsch.

--arilou (Diskussion) 14:42, 26. Nov. 2013 (CET)

Konkret braucht Microsoft diese Technik für seine Systeme, es gibt andere Systeme die so effizient arbeiten, das sie nicht nur darauf verzichten können, sondern auch ausdrücklich dazu raten alle (nicht in Hardware gegossene) Caches zu deaktivieren, dies kann das System bremsen. Dieser Ausfall dient nur der Erläuterung, daß der Einsatz von Cache nicht immer sinnvoll ist, sondern einen Grund (nämlich Langsamkeit) erfordert.
Sowohl bei Hardware wie bei Software kann effizientere Technik häufig den Einsatz von Caches erübrigen.
Bei Übertragungen (also Netzwerken) liegt das Problem neben geringer Bandbreite oft in unnötig großen Dateien, meist unkomprimierten Dateiformaten oder ineffizient (schlecht) arbeitenden Digitalisierungen von Signalen oder anderen Informationen. Würde das Internet z.B. die Formate BMP oder WAV und äquivalente nicht übertragen, weil sie als nicht standardkonform eingestuft würden, wäre ohne höhere Bandbreite durch eingesparte überflüssige Datenmengen vieles schneller, man bedenke außerdem, daß sogar eine eventuelle Komprimierung auch unnötige Zeit kostet. Höhere Qualität oder schnellere Übertragung würden ermöglicht, wenn bei der Digitalisierung reale Signale (Bild, Ton, Video etc.) weniger digitale Daten entstehen (weniger Nullen und Einsen), dies ist beispielsweise durch nichtlineare Wandlung besser möglich. So arbeiten menschliche Sinne und unser Gehirn weitgehend. Aber noch gibt es hier kaum 'Bionische Lösungen'. Auch hier wären dann oft Caches unsinnig und überflüssig.

Auf den ganzen Text geh' ich jetzt nicht ein, aber es sind sehr viele unbelegte, und auch haltlose Behauptungen darin ~ z.B.:

• als ob durch's iNet heutzutage noch nennenswerte Anteile an .bmp's oder .wav's gehen würden;
• das Microsoft-Beispiel ist so dermaßen unspezifisch, dass es einfach nur wie Bashing erscheint;
• "Sowohl bei Hardware wie bei Software kann effizientere Technik häufig den Einsatz von Caches erübrigen." ~ trivialer Allgemeinplatz;
• [dem menschlichen Wahrnehmungsvermögen angepasste Komprimierung] "Aber noch gibt es hier kaum 'Bionische Lösungen'." - der Herr beschäftige sich mal eine Weile im Bild/Videobereich mit JFIF (JPEG) bzw. MPEG, sowie im Audiobereich mit .mp3 . Dort wird nähmlich gerade das menschliche Wahrnehmungsvermögen für die (hohe) Kompression ausgenutzt...

--arilou (Diskussion) 14:42, 26. Nov. 2013 (CET)

Ergänzend möchte ich anmerken, daß ich mich immer noch wundere, daß kaum Komprimierung bei der Realisierung von Caches Verwendung findet.
--Harter Kritiker (Diskussion) 09:50, 24. Nov. 2013 (CET)

Sorry, aber an dieser Theorie ist doch ein wenig Mumpitz dabei - hier scheint wohl die Aufgabenstellung eines Caches nicht ganzg verstanden worden zu sein. Die Technik des Cachens verwendet man nicht nur in der IT, sondern auch jeder von uns in seinem alltäglichen Leben. Wer in seiner Hobbywerkstatt etwas bastelt, der wird nach kurzer Zeit die wichtigsten Werkzeuge um sich herum liegen haben und diese nicht nach jedem einzelnen gebrauch sorgfältig wieder ins Regel legen um sie kurze Zeit später wieder von dort zu holen. Die Werkbank wird zu Zwischenablage, zum Cache. Ohne den Einsatz von Caches wären viele IT-Architekturen schlicht und ergreifend nicht möglich, Kein Bussystem der Welt könnte die Datenmenge, die schon bei einem i7 mit vier Kernen bei voller Last durchgesetzt werden müssen, in der notwendigen Geschwindigkeit bereitstellen. Ein Zugriff auf den Cache erspart einen Speicherzugriff - dieser steht dann andren Komponenten zur Verfügung. Caches wurden und werden verbraut eben auch weil die Anbindung des Hauptspeichers mit voller Geschwindigkeit aufgrund von Lokalitäten gar nichts bringen würde. Caching ist nicht das "Kaschieren" einer vermeindlich suboptimalen Systemarchitektur, sondern ein Verfahren bestehende Limitationen zu vermindern und Bandbreiten einzusparen.

Was die sogenannten 'Bionische Lösungen' betrifft - hier hat Benutzer:Arilou berteits korrekt eingehakt. Ein FullHD-Bild bei 32Bit Farbtiefe kommt unkomprimiert auf rund 8MB Speicherbedarf - bei 24 Bildern je Sekunde sind das 192MB - je Sekunde wohlgemerkt. Das wären dann 11,5GB je Minute und für einen 90 Minutenfilm rund 1TB an Daten. Ohne 'Bionische Lösungen' in Form von mp4 wären wir heute von FullHD noch sehr weit entfernt. 2003:CB:A70A:2C01:1DB7:9099:1105:9BB3 10:01, 1. Jul. 2019 (CEST)

Anderer Ansatz: Cache ist ein Verfahren, eine Funktion, eine Technik

Beim funktionalen Betrachten des Begriffs unter Berücksichtigung des Sinnes kommt man weiter. Ein Cache soll uns Wartezeiten ersparen indem viele Zugriffe auf langsame oder ineffiziente (Speicher-)Medien durch deutlich schnellere Zugriffe auf schnelleres Cache-Memory (Schattenspeicher/Cache-Speicher) bei bereits bekannten Daten ersetzt wird. Damit wird die Langsamkeit kaschiert, verdeckt oder versteckt. Angenehmer Nebeneffekt, der sich positiv nutzen läßt, ist das für den Transport/Übertragung/Zugriff weniger Bandbreite benötigt wird. Das ist allen Techniken die als Cache bezeichnet werden gemein.

Wie gesagt, das ist nunmal _so_ nicht ganz richtig. Außerdem ist es

• inhaltlich sowieso recht nah' an der bisherigen Einleitung (nur ist die bisherige exakter)
• sprachlich ein Rückschritt zur bisherigen Einleitung.

Einer Verschlimmbesserung der Einleitung muss ich leider widersprechen. --arilou (Diskussion) 13:46, 28. Nov. 2013 (CET)

Wann ist Cache sinnvoll einsetzbar? Es muß einen Engpass geben.

kann, muss aber nicht.

Dies kann ein deutlich zu langsamer Zugriff sein, ein bekannter Flaschenhals oder beschränkte Bandbreite.

Und es gibt noch weitere Gründe.

Zweitens muß es redundante Zugriffe auf die dort liegenden Informationen geben.

Nicht zwingend ~ nunja - bei Nicht-Redundanz reduziert sich der "Cache" in Richtung "Schreib-Buffer"/"Lese-Buffer". Wobei beim Lesebuffer ein spekulatives Read-ahead immernoch eher eine Cache-Eigenschaft darstellt.

Drittens sollten die dabei wiederholt übertragenen Daten zwischen einer Mindestmenge und einer Höchstmenge ihres Umfangs liegen.

? Und du bist sicher, so ein Satz sei eine Verbesserung des Artikels?

Das setzt aber keine ineffiziente Darstellung der Daten, z.B. interne Redundanz voraus. Auch für beliebig stark komprimierte Daten sollte das Verfahren verwendbar sein, unkomprimierte Daten können schneller zugreifbar werden, wenn die Datenmenge größer ist und vor Erreichen des Cache-Speichers komprimiert wird. — Brachliegender Cache-Speicher kann teilweise für andere Nutzung bereitgestellt werden. Für viel Cache genutzter freier Speicher, der sonst brachliegen würde ist keine Verschwendung oder Speicherhunger, sondern effizientere Nutzung vorhandener Ressourcen. Nur die Vermeidung der Notwendigkeit des Einsatzes von Cache ist (weil überlegen) vorzuziehen, wenn große Datenmengen häufig mehrfach zum gleichen Speichermedium übertragen werden.

Sprachlich teilweise *autsch*, und inhaltlich ziemlich holterdipolter - so mancher Punkt sollte erst genauer erläutert/erklärt werden, bevor du zum nächsten weitergehst. --arilou (Diskussion) 13:46, 28. Nov. 2013 (CET)

Eine kurze Liste wann Cache-Einsatz meist oder immer unsinnig ist, wären nach meiner Kenntnis

• Vektorrechner
• und der Betriebssystemaufsatz PC/GEOS (sowie das Betriebssystem GEOS) im Zusammenhang mit Festplatten-Caches und zahlreicher internen Caches.

Diese zeichnen sich durch bisher nicht wieder erreichte Software-Effizienz, Redundanz-Armut und kompromisslose objektorientierte Programmierung aus, die oft zu höherer Effizienz als alles andere führte.

1. Bitte belegen; so ist das erst mal eine Behauptung von dir.
2. Konkrete Software-Produkte zu nennen, ist eher unerwünscht in einem Grundlagen-/Allgemein-Artikel zu einem Thema. Interessanter wäre, durch welche prinzipiellen Techniken genau dieses GEOS weitgehend auf Caches verzichten kann.

--arilou (Diskussion) 13:46, 28. Nov. 2013 (CET)

Für die Behandlung des Sonderfalls Browser-Cache wünsche ich mir eine kurze, prägnante Erklärung des Problems gleichzeitiger Nutzung von RAM und Festplatte, der zu vermeiden ist, und warum. --Harter Kritiker (Diskussion) 15:25, 24. Nov. 2013 (CET)

Das bitte im Artikel Browser-Cache klären. --arilou (Diskussion) 13:46, 28. Nov. 2013 (CET)

Stilfrage

Dies soll doch keine Rezitierung von Vorlesungsstoff sein. Bitte verschiebt entsprechende Passagen in Unterbegriffe in anderen Artikeln oder löscht etwas. Die Verständlichkeit ist so schon unter aller Sau. Eigene kurze Artikel zu verschieden Cache-Techniken und Anwendungsfällen mit denen eine Auflistung hier verknüpft wird erscheint sinnvoller. Zu allgemeinen Auslassungen, für die dieser Hauptartikel da sein sollte, habe ich hier genug Beispiele verfasst. Jeder Mitwirkende hat meine Erlaubnis sich daran ungeniert zu bedienen. Ich erkläre sie für bedingungslos lizenziert innerhalb Wikipedia. ansonsten CC-BY-NC. --Harter Kritiker (Diskussion) 15:54, 24. Nov. 2013 (CET)

Wie bei allen Grundlagenartikeln geht es auch hier vom einfachen, verständlichen, zum komplexen, detaillierten.

Dass nicht der gesamte Artikel einfach und leicht verständlich sein kann, hast du in allen Artikeln der WP - egal ob Mathematik, Informatik, Biologie, ...

Über die Möglichkeit, einzelne Abschnitte in eigene Artikel auszulagern ~ warum nicht, wenn's für einen eigenen Artikel reicht, ok. Bitte Hilfe:Artikelinhalte auslagern beachten.

--arilou (Diskussion) 13:50, 28. Nov. 2013 (CET)

Google-Cache, gibt's auch nen Yahoo-Cache?

Oder sollte man das vielleicht nicht in Suchmaschinen-Cache umbennen und den Begriff Google-Cache dann lediglich im Text als Beispiel erwähnen? Hier kriegt meiner Meinung nach Google sehr viel Aufmerksamkeit. --91.89.138.41 09:06, 8. Mai 2014 (CEST)

Danke für das Ansprechen dieser Betriebs-Blindheit (meinerseits).

Hab' den Abschnitt jetzt weitgehend ent-Google-t.

--arilou (Diskussion) 11:59, 8. Mai 2014 (CEST)

Beispiele: Valid/Dirty

In den Beispielen steht:

• 1024 x 64 bit Valid-Tags
• 1024 x 64 bit Dirty-Tags

aber jede Cache-Zeile braucht nur ein Valid-Bit und ein DirtyBit und damit:

• 1024 x 1-Bit Valid-Tags
• 1024 x 1-Bit Dirty-Tags

--84.142.132.164 17:43, 26. Aug. 2015 (CEST)

Hm, kommt darauf an, ob man nur die gesamte Cache-Line (aus 64 Bytes) als (insgesamt) 'valid' oder 'dirty' markieren will (was wohl üblich ist),

oder ob man innerhalb der 64-Bytes-Cache-Line wiederum jedes Byte einzeln als 'valid' oder 'dirty' markieren können will.

--arilou (Diskussion) 11:47, 9. Sep. 2015 (CEST)

Und mal wieder Datengrößen

In dem Artikel herrscht wieder Durcheinander, mal sind's KByte, mal KB, mal KiB. Hat jemand einen Vorschlag, wie man's vereinheitlichen sollte? --Pohli (Diskussion) 06:43, 30. Aug. 2018 (CEST)

In der deWP soll man sich an amtliche & anerkannte Bezeichnungen halten - also SI-/IEC-Präfixe.

In diesem Hardware-nahen Themenfeld ist wohl praktisch immer die 1024er-Basis gemeint.

Das Einheitenzeichen für Byte ist 'B', IEC-konform verwendet man Binärpräfixe.

Fazit: 'KiB', 'MiB', 'GiB'

--arilou (Diskussion) 09:17, 30. Aug. 2018 (CEST)

Ich würde auch lieber die IEC-Präfixe hier sehen, da sie eindeutig sind, wobei es in diesem Artikel nicht so schlimm wäre, eine andere Schreibweise zu verwenden, da es keine gemischten Größen gibt wie zum Beispiel im Artikel Festplattenlaufwerk (Stichwort Cache). Nun gibt es ja immer noch das zehn Jahre alte und umstrittene Meinungsbild, in dem festgelegt wurde, die IEC-Präfixe nicht zu verwenden. Aber ich habe bis jetzt auch keine Richtlinie in Wikipedia gefunden, die diese Schreibweise empfiehlt oder vorschreibt und im Portal Informatik ist dazu auch nichts ausgeführt, oder? Es wird wohl leider noch Jahrzehnte dauern, bis man in dieser Thematik eine wesentliche Konstanz im Artikelnamensraum vorfinden wird. --Pohli (Diskussion) 21:25, 30. Aug. 2018 (CEST)

Korrekt wären IEC-Präfixe - Caches haben prinzipbedingt immer "binäre" Größen. IEC-Angaben sind zwar nicht weit, aber durchaus verbreitet und bestehen seit 20 Jahren. Eine durchgängig korrekte Bezeichnung wäre wünschenswert. --Raumfahrtingenieur (Diskussion) 21:34, 30. Aug. 2018 (CEST)

Da die deWP noch keine 20 Jahre existiert, würde ich "Jahrzehnte" eher nicht vermuten. Eher andersherum - dein Beitrag zeigt, dass der Prozess in Gange ist; ich würde mal annehmen, dass in 2-3 Jahren der Großteil der "bi"-Umstellung gelaufen ist, und man nur noch selten in "Randthemen-Artikeln" über Problemstellen stolpert.

Ein 10 Jahre altes Meinungsbild stammt aus einer Zeit, als die 'bi'-Schreibweise noch kaum verbreitet war - Schnee von gestern.

--arilou (Diskussion) 13:05, 31. Aug. 2018 (CEST)

Wir können uns ja in der Mitte treffen, 10 Jahre? :-D Läuft die Umstellung wirklich schon? Naja, ich habe jetzt mal die Einheiten hier angepasst und werde das auch in anderen Artikeln versuchen, wenn's mir auffällt. Ich bin mal gespannt, wann ich das erste Mal auf Widerstand treffe. --Pohli (Diskussion) 06:32, 1. Sep. 2018 (CEST)

Ich wäre ein wenig vorsichtig mit solchen Aussagen. Außerthalb der Wikipedia läuft einem die bi Schreibweise doch eher selten über den Weg. Du weißt auch, das die Einheit für die Motorleistung eines KFZ seit 1978 nicht mehr PS ist? Frag mal Leute wie viel kW ihr Auto hat - die PS-Zahl können dir alle sagen. Soviel zur Beständigkeit alter Bezeichnungen. Weitere Beispiele gefällig? Gerne doch: wer verwendet im Alltag Hektopascal anstatt von Millibar beim Luftdruck? Der Schraubenzieher ist noch immer nicht zum Schraubendreher geworden, tausende in den Werkstätten arbeiten noch mit Schieblehren und Drehbänken anstatt Messschiebern Drehmaschinen. Man bekommt eingebürgerte Bezeichnungen nicht einfach dadurch aus den Köpfen heraus, wenn man sie durch eine neue, oftmals ungelenke Bezeichnung, ersetzt. Ich habe so das Gefühl, dass viele hier einer Religion fröhnen und aus wesentlicher Eitelkeit unbedingt auf den neuen Bezeichnungen bestehen. Eine neue Bezeichnung hat nur dann eine Chance, wenn sie aufgrund eines Verständnisvorteils von selbst einbürgert - nicht wenn sie von Teilzeitpedanten und Sprach- und Definitionsfreaks einfach übergestülpt wird. Ich für meinen Teil würde die bi Geschichte komplett sausen lassen und dem C64 einen Hauptspeicher von 65,536 kB anstatt 64 KibiByte verpassen. 2003:CB:A731:4A01:516:EE8D:FFE3:DFD3 11:14, 13. Dez. 2019 (CET)

Jedem Tierchen sein Pläsierchen. Das Teil hieß und heißt 'C64', nicht 'C65,536'. Viel Spaß dabei, das zu verfechten. --arilou (Diskussion) 12:11, 13. Dez. 2019 (CET)

PS: Es ging um "eine wesentliche Konstanz im Artikelnamensraum [der deWP]", nicht um die 'bi'-Verwendung außerhalb der WP. Und innerhalb der WP denke ich durchaus, dass wir schon weitgehend die 'bi'-Einheitenvorsätze haben und behalten werden. --arilou (Diskussion) 12:14, 13. Dez. 2019 (CET)

Transparenz?

3. Abschnitt: „Wegen der Unsichtbarkeit dieser zwischengeschalteten Einheit spricht man auch von Transparenz.“ „Transparenz“ heißt auf Deutsch „Sichtbarkeit“. Ich habe zu wenig Ahnung von der Materie, aber das hier scheint mir leicht unlogisch ((-; Dä Chronist (Diskussion) 18:17, 9. Jan. 2021 (CET)

Das nennt man tatsächlich so. Bedeutet einfach, das man als "Benutzer" nicht merkt das noch ein cache zwischen einem selber und dem Speicher ist. Da man den Cache nicht "sieht" nennt man ihn Transparent. --BlauerBaum (Diskussion) 15:19, 13. Jan. 2021 (CET)

Danke für die Auskunft; ich habe auch jetzt erst gemerkt, dass ich mich vertan hatte. Transparenz heißt ja in Wirklichkeit „Durchsichtigkeit“. Dä Chronist (Diskussion) 18:50, 13. Jan. 2021 (CET)

Aussprache

also ich bevorzuge "Kasché", wie beim "kaschieren", --Fachwart (Diskussion) 00:22, 15. Jan. 2022 (CET)

Und wie würdest du dann "knife" ausspreichen? "Neifé"? Oder "avalanche", "mustache", "niche"...

Die einzigen englischen Worte, die mich "-ché" am Ende ausgesprochen werden, kommen aus dem Spanischen.

Das heißt natürlich nicht, dass man Cache im Deutschen nicht doch anders aussprechen würde... Aber wenn's nicht im Duden steht, dann braucht man schon eine verdammt gute Quelle, die das belegt – zumindest besser als ein Forum...

Wenn dieser Beitrag von Chip gilt, könnte man es jedoch als seltenere Version einer Aussprache hinzufügen, aber so viele verschiedene Varianten kann man doch eigentlich gar nicht abbilden, wie im Video zu hören sind...

‣Andreas•⚖ 00:51, 15. Jan. 2022 (CET)

Ich bevorzuge die französische Aussaprache. Auf Englisch hört sich das halt wie "cash" an -und das ist definitiv etwas anderes. --Fachwart (Diskussion) 00:38, 16. Jan. 2022 (CET)

DNS-Cache

Wäre dankbar, wenn der hier ebf. aufgeführt würde, als Laie habe ich ein Verwechslungs-Problem mit dem Browser-Cache, bin aber wegen verlangsamter Surfgeschw. mit beidem konfrontiert. Nach recht mühsamer Websuche erst stellte ich jetzt fest, dass es wahrscheinlich nicht dasselbe ist, oder? Gruss--62.202.191.73 17:25, 25. Aug. 2024 (CEST)

Sowohl Browser-Cache als auch DNS-Cache sind beides Caches, aber gänzlich verschiedene. Ich hab den Artikel mal etwas ergänzt --BlauerBaum (Diskussion) 17:44, 25. Aug. 2024 (CEST)

Danke. Zwei Bemerkungen: 1) Du schreibst "Folgende....", wobei mir aber scheint, du nennst diese dann nicht, oder? 2) Gehört der DNS-Cache nicht zu den Software-Caches oben? Gruss--62.202.191.73 19:24, 26. Aug. 2024 (CEST)