Die Sache mit den Caches aktueller CPUs

[steinschock]

Kommt ziemlich auf die Anwendung an bez. wie die optimiert ist.

Der L3 ist immer noch wesentlich schneller wie Ram.
Und die einfachst Lösung die Kerne zu verbinden.
Bei Intel INclusiv, also alle Daten des L1+L2 sind auch im L3, das kostet zwar Platz ist aber schneller wie jeden Kern/Cache abzufragen.
Und man kann nicht genutzte Kerne einfach abschalten.

 

[PhenomII-Fan]

Kommt ziemlich auf die Anwendung an bez. wie die optimiert ist.

Genau das ist es ja, eine ganze Menge Spiele und Anwendungen profitieren fast gar nicht, oder nur minimal vom zusätzlichen L3-Cache und dann gibts Sachen wie Anno 1404, oder der Cinebench, die dann enorm vom L3 Cache profitieren - deshalb meine Aussage, dass es da anscheinend seitens der Software noch Optimierungsbedarf gibt.

Der L3 ist immer noch wesentlich schneller wie Ram.

Also das Verhältnis der Geschwindigkeit zwischen Cache und RAM ist mMn in den letzten Jahren gesunken. Sprich die Leistung des RAMs ist mehr angestiegen, als die des Caches - korrigiert mich, wenn ich da falsch liege!

Und die einfachst Lösung die Kerne zu verbinden.
Bei Intel INclusiv, also alle Daten des L1+L2 sind auch im L3, das kostet zwar Platz ist aber schneller wie jeden Kern/Cache abzufragen.

Jaja, das ist mir schon klar, nur ist der L3- gegenüber seinen Cache-Brüdern deutlich langsamer (aber halt auch größer, woe wir wieder beim Thema wären ).

Ich glaube es war der K6, oder schon der Athlon, da wurde auf einmal der der L2-Cache mit der Taktfrequenz des Kernes betrieben und man bemerkte eine beachtliche Leistungssteigerung ->...!

Und man kann nicht genutzte Kerne einfach abschalten.

Wobei das doch theoretisch auch ohne L3-Cache möglich ist, nur, da gebe ich Dir recht, würde es dann viel länger dauern, ehe die Daten des brachliegenden Kernes über den Speichercontroller in den L2-Cache des anderen Kernes "gewandert" sind. Da ist der L3-Cache wirklich hilfreich.

Wobei ich hier wieder sagen muss, dass der L2-Cache nicht zwingend Kern-exklusiv sein muss, was ja Intel bei seiner Core-Architektur bewiesen hat - was das jetzt für Auswirkungen auf die Leistung hat -> Keine Ahnung.

Aber wie will man das denn genauer Beleuchten, man kann ja nicht einfach ein Prozessor nehmen und diesen dann mit Unterscheidlichen Cache-Varianten durchtesten und schauen wie sich das ganze auf die Leistung verhält (ich meine jetzt nicht AMD & Intel, sondern die Endanwender, bzw. eine Fachzeitschrift wie die PCGH).

 

[Skysnake]

Oh man Leute Ich glaub da gibts nen paar Defizite was Caches angeht

Dann will ich mal für etwas Aufhellung sorgen.

Also allgemein, wurden hier einige falsche, einige halb falsche, halb richtigen und auch einige richtigen Aussagen getätigt. Daher fass ich mal einfach nen paar Punkte zusammen, die man so nicht wirklich stehen lassen kann.

1. Ne CPU wird in der Regel in EINER Fertigungstechnologie/Struckturgröße hergestellt. Wenn nicht, dann sind es halt unterschiedliche DIE´s die zusammengeschlossen werden, aber auf einem DIE wird man keine zwei Struckturgrößen vorfinden.

2. Nen Cache hat also auch keine feinere Strucktur als der Rest von der CPU

3. Nen schneller Cache ist nicht "teurer". Das ist so ne Halbwahrheit. Es kommt nämlich drauf an wie man teuer definiert. Die Kosten für nen einzelnen Transistor von nem schnellen oder langsamen Cache sind gleich groß. Is ja auch logisch eigentlich. Was sich allerdings ändert ist die Anzahl an Transistoren die du brauchst. Allgemein kann man sagen, ein schneller Cache benötigt mehr Logic, also mehr Transistoren für die gleiche Datengröße, und damit auch mehr DIE Fläche, die nunmal begrenzt ist. Daher ist nen schneller Cache auch "teurer" im Sinn von, er verbraucht mehr Ressourcen (DIE-Fläche) um die gleiche Datengröße zu erreichen wie ein langsamer.

4. Ja RAM ist im Vergleich zum Cache in den letzten Jahren schneller geworden, allerdings sind das auch ganz andere Welten was die Zugriffszeiten angeht. Der RAM ist wenn ichs richtig imKopf hab so ca 2-3 Größenordnungen langsamer als der Cache. Die Festplatten etwa nochmal so viel langsamer als der RAM. Daher tut nen Cachemiss auch RICHTIG weh, und nen RAMmiss ist ne mittlere Katastrophe.

5. Was auch noch ein sehr wichtige Aspekt ist, ist das Caches assoziativ sind. Kurz gesagt ohne tiefer einzugehen, je höher die assoziativität des Caches ist, umso mehr Register des Caches sind x-fach dem RAM geordnet. Das heist, wenn wir z.B. 2xassoziativen Cache haben, und wir schreiben was in nen Register (so heisen die speicherblöcke im Cache) und arbeiten damit, brauchen nun aber nach nen Cachemiss Daten aus dem RAM, die wir dann in den Cache schreiben, so überschreiben wir z.B. das Register 1, im nächsten Rechenschritt, brauchen wir aber eben diese Daten wieder, also wieder Daten aus dem RAM holen, die halt ungünstig liegen und WIEDER in Register 1 geschrieben werden müssen, und so geht das weiter und weiter. So kannst du Situationen schaffen, in denen du JEDE CPU auf die Rechenleistung von nem Taschenrechner ausbremst.

6. ein gemeinsamer Cache ist für das herunterfahren von einzelnen Cores sehr von Vorteil, da man dadurch die Konsistenz der Daten leicht gewährleisten kann. Man spart sich dann nämlich die Zeit zum umschreiben der Register. Ebenso hat man den Vorteil das alle Cores den Cache nutzen können, und somit der Cache effektiver genutzt wird. Man nehme nur das Beispiel eines Dualcores, Core 0 ist leicht ausgelastet, brauch kaum Cache, Core 1 ist voll ausgelastet und benötigt sehr viel Cache, hier ist ein gemeinsamer Cache SEHR von Vorteil. Es gibt allerdings auch Nachteile eines gemeinsamen Caches, da ein gewisser overhead entsteht, da man ja den Cache verwalten muss, was auch Probleme mit sicht bringt. Man muss ja die Datenkonsistenz gewährleisten.

7. Es kann sehr von Vorteil sein, lieber einen größeren als einen Schnellen Cache zu haben, denn wenn das Problem nicht mehr ganz in den Cache passt, dann ist man um größenordnungen langsamer durch den Ramzugriff. Der Unterschied zwischen L2 und L3 sollte da um einiges geringer sein.

Sodele ich glaub das wars im großen und ganzen. Solltet ihr noch nähere Infos wünschen, dann schreibt das bitte möglichst genau hin, was ihr wissen wollt, dann kann ich veruschen euch die Konzepte und Probleme verständlich zu machen.

Wenn ich ganz gut drauf bin such ich vielleicht sogar meine alten Unterlagen raus

EDIT:

8. Es sollte eigentlich kein Problem sein bei einer CPU die Cachegröße anzupassen. Allerdings nur verkleinernd. Man muss halt "nur" direkt in die Register Werte reinschreiben und sie sperren, was spätestens mit assembler möglich sein sollte/muss. So kann man den Cache einfach durch reservieren/belegen für das Programm verkleinern. Ich wüsste grad wirklich nicht, warum dies nicht möglich sein sollte auf irgendeine Art und Weise. Es könnte halt nur mehr oder weniger kompliziert werden, wenn man wirklich assembler nutzen muss.

 

[PhenomII-Fan]

Erstmal großes Lob an Dich.

3. [...] Allgemein kann man sagen, ein schneller Cache benötigt mehr Logic, also mehr Transistoren für die gleiche Datengröße, und damit auch mehr DIE Fläche, die nunmal begrenzt ist. Daher ist nen schneller Cache auch "teurer" im Sinn von, er verbraucht mehr Ressourcen (DIE-Fläche) um die gleiche Datengröße zu erreichen wie ein langsamer.

Aha, das wusste ich nicht, dass die schnelleren L1 & L2 Caches mehr Fläche pro KB brauchen als der L3. Im Prinzip ja auch logisch, da ja irgendwoher die schnellere Leistung "herkommen" muss.

5. Was auch noch ein sehr wichtige Aspekt ist, ist das Caches assoziativ sind. Kurz gesagt ohne tiefer einzugehen, je höher die assoziativität des Caches ist, umso mehr Register des Caches sind x-fach dem RAM geordnet. Das heist, wenn wir z.B. 2xassoziativen Cache haben, und wir schreiben was in nen Register (so heisen die speicherblöcke im Cache) und arbeiten damit, brauchen nun aber nach nen Cachemiss Daten aus dem RAM, die wir dann in den Cache schreiben, so überschreiben wir z.B. das Register 1, im nächsten Rechenschritt, brauchen wir aber eben diese Daten wieder, also wieder Daten aus dem RAM holen, die halt ungünstig liegen und WIEDER in Register 1 geschrieben werden müssen, und so geht das weiter und weiter. So kannst du Situationen schaffen, in denen du JEDE CPU auf die Rechenleistung von nem Taschenrechner ausbremst.

Das hab ich im Prinzip verstanden, nur was bewirkt es jetzt genau, wenn der Cache (z.B. der L2) jetzt 4x oder 8x assoziativ ist?

6. [...]Man nehme nur das Beispiel eines Dualcores, Core 0 ist leicht ausgelastet, brauch kaum Cache, Core 1 ist voll ausgelastet und benötigt sehr viel Cache, hier ist ein gemeinsamer Cache SEHR von Vorteil. Es gibt allerdings auch Nachteile eines gemeinsamen Caches, da ein gewisser overhead entsteht, da man ja den Cache verwalten muss, was auch Probleme mit sicht bringt. Man muss ja die Datenkonsistenz gewährleisten.

Wie gesagt ich bringe da gerne das Beispiel der Core Architektur, da teilten sich auch 2 Core einen L2-Cache.
Bei Nehalem hat Intel den L2-Cache sehr stark verkleinert und dafür einen großen L3-Cache eingebunden, der auch von mehreren Cores (also alle) genutzt wird.
Intel wird sich ja nicht ohne Grund gegen den L2 und für den L3-Cache entschieden haben. Wird aber wahrscheinlich, wie Du schon gesagt hast, wegen der Größe des Caches und der "Transistorenverbrauch" sein.

AMD hat noch nie einen L2-Cache für 2 Core benutzt, sondern immer Kernexklusiv - das muss doch auch einen Grund haben (wenn es doch scheinbar besser wäre ein L2-Cache für 2 Kerne zu nutzen, z.B. bei den AthlonII-Prozessoren, welche sowieso keinen L3-Cache haben.)!?!

Intel hat beim Pentium EE (Prescot, glaube 3,6GHz + HT) einen 2MB großen L3-Cache verbaut, ob der wirklich etwas gebracht hat, wage ich zu bezweifeln, da HT damals noch kaum genutzt wurde.

7. Es kann sehr von Vorteil sein, lieber einen größeren als einen Schnellen Cache zu haben, denn wenn das Problem nicht mehr ganz in den Cache passt, dann ist man um größenordnungen langsamer durch den Ramzugriff. Der Unterschied zwischen L2 und L3 sollte da um einiges geringer sein.

Das leuchtet allerdings ein.

8. Es sollte eigentlich kein Problem sein bei einer CPU die Cachegröße anzupassen. Allerdings nur verkleinernd. Man muss halt "nur" direkt in die Register Werte reinschreiben und sie sperren, was spätestens mit assembler möglich sein sollte/muss. So kann man den Cache einfach durch reservieren/belegen für das Programm verkleinern. Ich wüsste grad wirklich nicht, warum dies nicht möglich sein sollte auf irgendeine Art und Weise. Es könnte halt nur mehr oder weniger kompliziert werden, wenn man wirklich assembler nutzen muss.

Warum hat das dann (meines Wissensstandes) noch keiner gemacht zwecks Tests und Benchmarks?

 

[Skysnake]

Warums keiner macht liegt wohl daran, das es 1. einen gewissen Aufwand mit sich bringt so nen Testprogramm zu schreiben, auch wenn du kein Assembler nutzt, und wenn dus nutzen musst, dann übersteigt der nötige Aufwand jedwede Ressourcen eines Magazins, bzw einfach auch die nötigen Kenntnisse um das selbst zu machen. Sowas kannste nicht einfach mal hinklatschen. Da musste schon sehr genau wissen was du machst, und wie du es machst, damit du auch wirklich verstehst, was die Ergebnisse ausdrücken.

Allein die Zeitmessungen beim benchen von Caches ist nicht trivial zu lösen. Da musste spezielle Bibliotheken dazu verwenden etc. Hab hier selbst nen Programm von der Uni rumliegen zum auslesen der Cachelines, also Cachegröße und Zugriffszeit. Leider nicht im Quellcode, aber nach den Ausführungen des Profs. ist die Zeitmessung nen ziemlicher Scheis......