Cache Assoziativität

[Naitsabes]

Hey ihr,
ich habe da eine etwas allgemeine Frage zur Assoziativität.
Ganz allgemein und grob formuliert ermöglicht eine höhere Assoziativität eine effizientere Nutzung des vorhandenen Caches (am besten wäre natürlich Vollassoziativität). Das ist aufgrund der Komplexität jedoch nicht sehr realistisch, wenn man den Cache auch schnell auslesen können möchte.
Soweit ist alles klar, ABER warum ist dann gerade der L1 Cache meistens mit der geringsten Assoziativität, während der L3 Cache die höchste hat. Allerdings ist doch gerade der L1 Cache klein und sollte daher möglichst effizient aufgefüllt werden. An der möglichen Taktrate kann es nicht liegen, denn bei Intel ist der L3 Cache seit Sandy Bridge gleich dem L1 Cache getaktet.

Warum also erhöht man also im L3, der eh schon groß ist, die Assoziativität, aber nicht im sehr kleinen L1? An der möglichen Taktrate kann es also nicht liegen. Oder wird durch die hohe Assoziativität auch die Latenz erhöht (zusätzlich zur Entfernung von dem Kern)?


Ich hoffe ihr versteht meine Frage :-D

[Coda]

L1 braucht extrem geringe Latenz. Höhere Assoziativät heißt dass man mehr Tags absuchen muss, was die Schaltung komplexer macht und daher auch die Latenz steigt.

Alles nicht so einfach. Die Intel-Caches sind aber schon ziemlich beeindruckend schnell.

[Naitsabes]

Also ist die Taktbarkeit gar nicht so stark von der Assoziativität abhängig wie die Latenz?

[Affinator]

Du kannst "grob" formuliert sagen: Taktbarkeit ist das Gegenteil von Latenz.

Wenn du alles in einem Takt erledigen möchtest (Latenz "perfekt"), dann wird das Design immer größer und komplizierter und die Taktbarkeit geht in den Keller.
Wenn du dagegen dem Design mehrere Takte zum Erledigen einräumst, kannst du das ganze in eine "Pipeline" packen, und damit die Taktbarkeit erhöhen.
Und eine höhere Assoziativität entspricht mehr Vergleichen = mehr Arbeit zu erledigen = mehr Sachen, die du Taktbarkeit kostend in einem Schritt erledigen möchtest.


Ist nur eine grobe Beschreibung, aber als Richtwert kommt das hin.

[del_4901]

Ausserdem sind kleinere Caches weniger anfaellig gegen schlechte Assoziativität, da es weniger warscheinlich ist, dass es zu Kollisionen kommt.

[Affinator]

Bei Instruktionen ziehe ich da mit. Aber bei einem Daten-Cache würde ich das nicht verallgemeinern wollen.

PS: Die Hitrates selbst des L1 sind natürlich schon enorm hoch, allerdings machen hier ja auch schon Promille einen großen Performanceunterschied.

[del_4901]

Wenn man seine Daten so weit ausseinander liegen hat, dann hat man noch ganz andere Probleme.

[Naitsabes]

Aber durch eine geringere Assoziativität steigt doch bei gleicher Blockgröße die Wahrscheinlichkeit, dass man sich den Cache immer wieder trasht, obwohl er nichtmal voll ist.

[Naitsabes]

Ausserdem sind kleinere Caches weniger anfaellig gegen schlechte Assoziativität, da es weniger warscheinlich ist, dass es zu Kollisionen kommt.


Das verstehe ich jetzt nicht. Ich hätte behauptet, dass gerade ein kleinerer Cache anfälliger ist.


Edit.
Sorry wegen Doppelpost.

[Spasstiger]

Ich würde auch sagen, je kleiner und schneller der Cache, desto eher lohnt sich eine hohe Assoziativität. Allerdings ist die aufwändige Vergleichsoperation bei z.B. einem vollassoziativen Cache eher kontraproduktiv, wenn es darum geht, geringe Latenzen zu erreichen. Daher läufts auch bei einem kleinen L1-Cache auf einen sinnvollen Kompromiss heraus.

[PatkIllA]

Aber durch eine geringere Assoziativität steigt doch bei gleicher Blockgröße die Wahrscheinlichkeit, dass man sich den Cache immer wieder trasht, obwohl er nichtmal voll ist.
Das verstehe ich jetzt nicht. Ich hätte behauptet, dass gerade ein kleinerer Cache anfälliger ist.Das würde ein Problem, wenn die Daten wirklich zufällig im Speicher verteilt wären. In der Praxis hat man in der Regel aber eher "größere" Blöcke am Stück die man benötigt. Bei Highperformance-Code optimiert man aufs Datenlayout und Zugriffsmuster in den Algorithmen, damit man den Cache eben nicht dauernd trasht.

[del_4901]

Das würde ein Problem, wenn die Daten wirklich zufällig im Speicher verteilt wären. In der Praxis hat man in der Regel aber eher "größere" Blöcke am Stück die man benötigt. Bei Highperformance-Code optimiert man aufs Datenlayout und Zugriffsmuster in den Algorithmen, damit man den Cache eben nicht dauernd trasht.
exactement

[Gipsel]

Wo hohe Assoziativitäten helfen und auch genutzt werden, ist bei kleinen Caches, mit nicht oder nur sehr schwer zu kontrollierenden Zugriffsmustern, wo zudem die Latenz nicht die übergroße Rolle spielt, also ein paar Takte mehr nicht unbedingt gleich tödlich sind: Texturcaches bei GPUs. Die VLIW-Architekturen von AMD hatten vollassoziative L1-Textur-Caches (weil die nur 8kB groß waren, heißt das 128way mit 128 Cachelines zu 64 Bytes), GCN immerhin noch 64way-assoziative (aber dafür doppelt so große) vektor-L1-Caches.