Diskussion zu: Hardware- und Nachrichten-Links des 2. Februar 2017

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-2-februar-2017

[Entropy]

sondern gleich mit satten 1 MB Level2-Cache pro CPU-Kern bei gleichzeitig aber nur noch 1,375 MB Level3-Cache pro CPU-Kern. Die Cache-Menge pro CPU-Kern bleibt nominell ähnlich – vorausgesetzt natürlich, das die Cache-Struktur dann nicht mehr "inklusiv"
Obwohl alles "Cache" heisst, haben diese Speicher oft unterschiedliche Aufgaben.

L1 dient als erweitertes Register-Set, sowas wie add eax,[esi+8] ist genau so schnell wie add eax,ebx, wenn es "hot data" ist. Ohne L1 wäre die CPU bei den meisten Algorithmen (bzw deren Implementation) nicht in der Lage voll ausgelastet zu sein, weil die Daten nicht nachkommen. Entsprechen wurde für AVX und jetzt für AVX512 die Bandbreite zu L1 jeweils verdoppelt.
L2 dient als "Working Set" cache. Hier sollten die Daten hin die verarbeitet/transformiert werden.
L3 (eigentlich besser LLC) sollte der Intra-Prozessor-Kommunikation dienen. Dabei geht es nicht (nur) um Atomics, sondern eher um kleine Datenbroken die hin und hergeschoben werden (was Atomics nur signalisieren/synchronisieren), aus diesem Grund ist bei Intel auch die iGPU am LLC.

Das erklärt auch die inklusivität. Die Idee ist nicht, dass L1 und L2 und LLC dasselbe, nur verschieden schnell machen, entsprechend könnte der LLC auch kleiner als L2 sein, es geht dabei ja nicht darum die kompletten Daten zu spiegeln, sondern um den Übergang der Daten von einem Status zum anderen. Also dass Daten die erst im L2 vorbereitet wurden, dann an andere Stellen des Prozessor weitergegeben werden.

Beispiel 1 L1 - L2: Motion Estimation. Bei H265 gibt es bis 64x64 Pixel-Blöcke, also 4 KB, zu denen das Gegenstück in einem weiterem Bereich des vorherigen Bildes, z.B. (256+64)x(256+64) 100 KB gesucht wird. Bei der Suche wird nicht nur Pixel zu Pixel verglichen, sondern auch halb-pixel (half-pel). Natürlich kann der Programmierer jetzt diese Interpolation an den L2 daten bei jedem "Load" machen, was sehr redundant ist. Er kann sich aber auch vom 64x64 Block 3 vorgefilterte Versionen (+12 KB) abspeichern, die er zum Jeweiligen L2 Block vergleicht.
L1 wird dann 4 mal gelesen pro 1 mal Lesen aus dem L2.

Beispiel 2 L1 - L2: "Matrix Palette Skinning" von 3D Punkten. Jeder Punkt eines Drahtgitters kann auf n Matrizen verweisen die zu seiner Transoformation genutzt werden. Jeder Vertex wird einmal transformiert, kann also im L2 bis zur Weiterverarbeitung verweilen. Matritzen werden hingegen sehr oft referenziert, sind im L1.

Beispiel 1 L2 - LLC: Ein Kernelement von H265 ist die Entropycodierung mittelst CABAC. Das ist recht sequentiel, deswegen sollte sich ein einziger Kern in "Vollzeit" darum kümmern. Die Daten, z.B. Motion Vectors kommen von den anderen Kernen. Das sind z.B. pro 64x64, 32x32, 16x16 usw. nur <= 8 Byte. Im besten Fall bei einem 4k Bild nur 2 KB. Das zu transferieren braucht nicht viel Bandbreite, wenn das aber von einem zum anderen Kern muss, wäre immer ein L2 Cachemiss mit Transfer von einer Cacheline per "FSB". Die wertvolle CABAC-Verarbeitungszeit wäre ständig mit diesen unausweichlichen z.B. 200 Cycle Unterbrechungen durchsetzt. ... und dank LLC nicht.

Beispiel 2 L2 - LLC: Jedes Spiel was 3D Objekte zeichen will, muss herausfinden welche und sie vorbereiten. Anschliessend wird ein Commandbuffer (oder im Fall von Direct3D 12 sogar viele kleine Commandbuffer) and die iGPU geschickt. Die Datenmenge ist nicht redenswert, jedoch muss auch das Kommuniziert werden. Wenn du also keinen expliziten L2-Flush haben willst, brauchst du die Daten im LLC. (Dazu muss der LLC auch inklusiv sein). Snooping wird zwischen iGPU und den L1/L2$ der Cores eher nicht stattfinden.

Das ganze ist auch eine etwas andere Situation bei 4 Cores gegen 32 Cores. Ein LLC wird nicht nur von der Speichermenge geteilt, sondern auch von der Bandbreite und Latenz. Wenn das "Working Set" im LLC wäre weil der L2 überläuft, ist es Egal, ob der L2 1MB oder 100MB hat, die 4 Cores und 32 Cores werden relativ gleich abschneiden. Das impliziert, dass LLC auch sehr lange gleich klein bleiben könnte.

Noch ein kleiner Gedanke, mit der Verdopplung vom Cache, steigt die Latenz meistens eine Hierarchystufe. 1MB sollten also 14+ Cycle sein.

[Setsul]

Nachdem ich das Ganze in die Welt gesetzt habe, sollte ich wohl darauf antworten.

Es wäre mir lieber die Diskussion im Skylake Thread zu halten, aber das lässt sich jetzt auch nicht mehr ändern.

Erstmal vorneweg, wenn man könnte, würde man einfach 10MB L1 pro Kern hinwerfen und gut ist's.
Die jetzige Organisation ergibt sich aus der Notwendigkeit. Man versucht die Größe von "hot data" und das working set entsprechend klein genug zu halten, damit sie in den entsprechenden Caches bleiben, nicht umgekehrt. Wenn man z.B. 4 Takte Latenz halten will, dann kann es sein dass man eben nicht höher gehen kann als 8-way VIPT und mit 4kiB pages ist dann bei 32kiB eben Ende der Fahnenstange.

iGPU ist auch ein denkbar schlechtes Beispiel für CPUs ohne iGPU.

Mit der Latenz wäre ich vorsichtig. Skylake braucht 12 Takte, 1 mehr als Haswell obwohl der Cache 4-way statt 8-way ist. Es kann sein, dass Intel die Latenz für wichtig genug hält um sie bei den größen Dies gleich zu halten, kann aber genauso gut sein, dass man um den Verbrauch etwas auszugleichen sogar zu noch höherer Latenz bereit ist. Also alles zwischen 12 und 16 Takten ist möglich mMn.


Ich habe jetzt keine aktuellen Daten zur Duplikation bei 1MB L2 Caches, aber was bleibt realistisch vom L3 übrig? 0,5MB pro Kern? Es rechtfertigt bei Weitem nicht den Aufwand im Vergleich zu größeren Cache Controllern im L2 um das ganze Snooping zu handlen.

Der LLC muss nicht inklusiv sein, bloß weil Intel das seit über einem Jahrzehnt so macht. Bei AMD ist der LLC schon mindestens genauso lange nicht inklusiv.

Bei Intel geht nebenbei die LLC Bandbreite auch mit der Anzahl der Slices linear nach oben. Da wird nichts geteilt. Latenz bleibt bei gleicher Entfernung auch gleich, nur die maximalen Entfernungen werden größer.


Generell ist die Faustregel unter 8-facher Größe macht man einen Cache nicht inklusiv.

Also Kurzform:
-LLC muss nicht inklusiv sein.
-Größere Cache Controller sind billiger als 1MB duplizierter Cache.

Gegenargumente?

[Gast]

man muss gar nicht so viel im Detail spekulieren.

Die Faustregel seit Intel Core 2 ist, dass Intel die Vorteile bei der Prozesstechnologie immer durch schnellere und grössere Cache-Konzepte konsequent ausgenutzt hat. Die Softwareindustrie hat dafür gesorgt, dass das jeweils auch in Performance umgesetzt wurde, entsprechend war AMD mit anderen Konzepten und zu wenig Chipfläche für Caches abgehängt.
Man versucht das Spiel hier einfach weiter zu wiederholen, nachdem AMD mit Ryzen sowohl in Strukturgrösse als auch Cache-Konzept und -Grösse aufgeschlossen hat. Spannend wird, ob die Software/Compiler das entsprechend in Code giessen, bestehender Code wird nicht sonderlich davon profitieren, der ist schon auf die aktuellen Cache Grössen optimiert.

[Setsul]

Intel hat die Cache Größe und Latenz über 4 nodes bzw. 8 Jahre hinweg unverändert gelassen.

Bulldozer verwendet mehr Chipfläche für Cache als Intel.

Der meiste "alltägliche" Code ist nicht hart auf exakte Cachegrößen optimiert.

Auch alter Code profitiert von schnelleren Caches.

Ich verstehe das Argument nicht.