Cache-Schreib-/Lesezeiten?

Aus architektonischer Sicht hängt es davon ab, welche Richtlinie Ihr Cache verwendet.

Bei der Write-Through- Strategie wird das Ergebnis jeder Operation im selben Zyklus im Cache und im physischen Speicher gespeichert; daher dauert die Schreiboperation länger, während die Leseoperation vom Vorhandensein des Datenblocks im Cache abhängt.

Bei der Write-Back- Policy wird das Ergebnis nur im Cache gespeichert und nur dann in den physikalischen Speicher kopiert, wenn derselbe Datenblock benötigt wird. Daher können Schreiben und Lesen mit der gleichen Geschwindigkeit erfolgen, oder beide können langsamer sein.

Mehr Info.

Dies variiert stark zwischen den Architekturen. Es gibt wahrscheinlich keine brauchbare Faustregel. Die in heutigen Speichern verwendete Technologie sieht im Allgemeinen die gleiche Lese- und Schreibzeit vor. Dies ist historisch definitiv nicht wahr und wird in Zukunft möglicherweise nicht mehr wahr sein. Beispielsweise sind Kernspeicher von Natur aus schneller zu schreiben als zu lesen.

Die Dinge werden komplizierter, wenn Cache-Speicher verwendet wird. Heutzutage können Sie sich wahrscheinlich vorstellen, dass der Cache-Speicher eine feste Zykluszeit hat, unabhängig davon, ob es sich um einen Lese- oder einen Schreibvorgang handelt. Überlegungen auf Systemebene ändern jedoch, wie teuer ein Lese- oder Schreibvorgang insgesamt ist.

Bei einem Lesevorgang muss irgendwo ein Speicher physisch gelesen werden, und es kann nichts getan werden, bis dieses Ergebnis zurückgegeben wird. Wenn sich die Daten im Cache befinden, sind sie möglicherweise so schnell verfügbar, wie der Prozessor sie verwenden kann. Wenn es sich nicht im Cache befindet, muss etwas den Esel aufsatteln, zum weiter entfernten und langsameren Speicher traben, einen Lesetermin festlegen, auf das Ergebnis warten und mit den Daten zurück zum Prozessor traben. Beachten Sie, dass es mehrere Cache-Ebenen geben kann, wobei die Latenz für weiter entfernte Ebenen viel länger wird. Wenn virtueller Speicher verwendet wird (eigentlich nur eine andere Form des Cachens) und die Daten derzeit ausgelagert werden, kann der Lesevorgang so lange dauern wie ein Festplattenzugriff (oder was auch immer Ihr Massenspeichergerät ist).

Schreibvorgänge haben den Vorteil, dass die Aktion initiiert werden kann, aber Sie müssen nicht warten, bis sie abgeschlossen ist. Dies erhöht jedoch die Komplexität, sodass nicht alle Systeme auf diese Weise funktionieren. Etwas muss nachverfolgen, was nicht wirklich geschrieben wurde, falls eine Leseanforderung kommt, bevor der Schreibvorgang abgeschlossen ist. Der Lesevorgang kann dann anhalten oder den Wert irgendwo teilweise durch den Schreibprozess abrufen. Hier gibt es viele Möglichkeiten zur Beschleunigung, aber sie gehen mit Komplexität und zusätzlicher Hardware einher. Es gibt daher viele verschiedene Implementierungen da draußen. Beispielsweise kann ein Schreibvorgang immer garantieren, dass in den First-Level-Cache geschrieben wird, bevor die Operation abgeschlossen ist, oder ein Lesevorgang kann folgen. Aber was ist, wenn der gesamte Cache bereits mit verschiedenen Adressen belegt ist? Dies kann das Schreiben eines Cache-Chunks in den Speicher der nächsten Ebene erfordern, bevor das Schreiben in den Cache der ersten Ebene abgeschlossen wird. Auch hier gibt es viele Kompromisse.

Schreibvorgänge werden möglicherweise sofort schneller angezeigt, da sich der Prozess mit der nachfolgenden Ausführung überschneiden kann, sie können jedoch insgesamt kostspieliger sein. Das Schreiben neuer Daten in einen beliebigen Cache bewirkt, dass dieser Abschnitt des Caches als "dirty" markiert wird. Dies bedeutet, dass es mindestens in die nächste Ebene des langsameren Speichers geschrieben werden muss, bevor es wiederverwendet werden kann, um einen anderen Teil des globalen Konzeptspeichers zwischenzuspeichern.

Insgesamt würde ich nicht versuchen zu erraten, ob Schreib- oder Lesevorgänge auf einem modernen High-End-Universalcomputer schneller sind, da viele ausgefallene Zwischenspeicherungen und Vorabrufe und überlappendes Schreiben stattfinden könnten. Die Antwort ist nicht deterministisch und kann davon abhängen, wie lang eine Schleife ist, was sonst noch vor sich geht und sogar, wie der Code, der Ihnen wichtig ist, zufällig im Speicher ausgerichtet ist.

Fahgeddaboudit.

"Was dauert länger?" ist eine sehr vage Frage, und die Antwort hängt davon ab, was Sie optimieren möchten.

Wenn Sie die Gesamtleistung eines Systems betrachten, machen Sie sich in den meisten Fällen Sorgen darüber, dass die Ausführungspipeline in der CPU blockiert wird. In diesem Sinne dauern Ladevorgänge immer länger als Speicher, in dem Sinne, dass Speicher keine zukünftigen Operationen haben, die von ihnen abhängen, während Ladevorgänge dies tun.

Mit anderen Worten, bei einer Speicheroperation senden Sie die Adresse und die Daten an die Speicherhierarchie und vergessen sie im Grunde. Bei einer Ladeoperation senden Sie jedoch die Adresse und müssen dann auf die Daten warten. Der Compiler und/oder Hardware-Scheduler kann in der Zwischenzeit nützliche Arbeit finden oder auch nicht, aber es besteht eine gewisse Wahrscheinlichkeit ungleich Null, dass die Pipeline anhalten muss, wenn sie zu einer Operation gelangt, die von den geladenen Daten abhängt.

Es kann andere Engpässe in der Speicherhierarchie geben, abhängig von der Anzahl der Cache-Ebenen, ihrer Größe, ihren Zugriffszeiten, ihren Rückschreibrichtlinien, den Bandbreiten der sie verbindenden Busse usw. Bei mehreren Kernen und gemeinsam genutzten Speichern, Cache-Synchronisierungsstrategie wird auch zum Thema. All diese Dinge können möglicherweise eine Verzögerung bei einer Ladeoperation verursachen.

Die einzige Möglichkeit, wie ein Speicher einen Stillstand erzeugen kann, besteht darin, dass die Schreibpuffer in der Speicherhierarchie voll sind, wodurch sie daran gehindert werden, einen anderen Speicher aus der Ausführungspipeline zu akzeptieren.