Diskussion zu: Ryzen-Vierkerner mit "4+0" CPU-Kernen bemerkbar schneller als mit ...

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/ryzen-vierkerner-mit-40-cpu-kernen-bemerkbar-schneller-als-mit-22-cpu-kernen

[cat]

Ryzen-Leistung hin oder her, die IPC zählt, ich wollte einen 4+0 aber wenn es den nicht gibt, warte ich bis Ice-Lake oder Tiger-Lake.

Das honoriere ich nicht, ich will den schnellst möglichen AMD Gaming-Quadcore und keinen Kompromiss.
Aber mal sehen, evtl. doch einen 1600X

Die APU Raven Ridge wird wohl keinen L3-Cache haben, dumm dumm dumm

[Lolly4zomfg]

Es wäre auch interessant zu sehen um wie viel Spiele-Performance ein dual-CPU Board in einer 2+2 im vergleich zu einer 4+0 Konfiguration abschneidet und wie diese Werte im Vergleich zu Ryzen sich verhalten. Auch wäre es interessant, wie hoch die Latenz und Datenrate von CCX zu CCX ist und wie hoch dazu im vergleich die Datenrate und Latenz eines Dual-CPU Boards ist, das die CPUs über QPI verbunden hat. Vielleicht hat ein Programmierer, der sich gut genug auskennt Lust so einen Test zu programmieren (oder vielleicht gibt es so etwas ähnliches ja schon?).

[Timbaloo]

Na dann wissen wir ja wo das Potential für Zen+ versteckt ist.

Oh nein halt, das war ja irgendwie schon lange klar...

[Redirion]

Ryzen-Leistung hin oder her, die IPC zählt, ich wollte einen 4+0 aber wenn es den nicht gibt, warte ich bis Ice-Lake oder Tiger-Lake.

Es wird mit Ryzen 3 im H2 auch nativ mit einem CCX (also quasi 4+0) geben. Die haben dann eben nur 8MB-L3-Cache, während die 2+2 Ryzen 5 je nach Bedarf auch mit vollen 16MB angeboten werden können. Das ist der wichtigste Unterschied. Das hätte in der News auch ruhig so gesagt werden können. Sonst wäre ein Ryzen 5 1500X mit 16MB nicht möglich gewesen. Dementsprechend wird AMD in H2 dann den Ryzen 5 1400 sicherlich auch nativ mit einem CCX bauen. Die Fertigung wird ja prinzipiell mit der Zeit noch besser, so dass noch weniger Ausschuss anfällt, der dann aus einem eigentlichen 8-Core mit 16MB so einen 4-Core mit halbem L3-Cache machen müsste.

[Lolly4zomfg]

Ich frage mich welchen Leistungsunterschied ein größerer L3-Cache macht. Ich denke für die meisten Anwendungen sollten doch 8MB genug sein. Vielleicht kann mehr Cache durch agressiveres prefetching helfen die Cache Miss Rate zu verringern und so die Leistung erhöhen. Es ist aber fraglich ob eine höhere Latenz zwischen den CCX diesen Vorteil nicht überschattet.

[Eldoran]

Ich frage mich welchen Leistungsunterschied ein größerer L3-Cache macht. Ich denke für die meisten Anwendungen sollten doch 8MB genug sein. Vielleicht kann mehr Cache durch agressiveres prefetching helfen die Cache Miss Rate zu verringern und so die Leistung erhöhen. Es ist aber fraglich ob eine höhere Latenz zwischen den CCX diesen Vorteil nicht überschattet.
Es kommt ganz auf die jeweilige Anwendung an. Allerdings ist meines Wissens schon die Angabe 8/16MB irreführend. Es handelt sich um einen exclusiven Victim Cache - der L2 der Cores muss da dazu gerechnet werden (bezüglich der im Cache verfügbaren Datenmenge). Weiters gibt es meines Wissens beim Cache eine faktische Trennung der CCX, also eigentlich 8+8MB L3. Bei starker wechselseitiger Abhängigkeit der Threads dürfte es also relevant sein, auf welchen Cores diese laufen. Bei derartigen Szenarien dürfte MOESI auch einigen Overhead verursachen. Prefetching gibt es beim L3 glaube ich nicht.

[Gast]

Vielleicht kann mehr Cache durch agressiveres prefetching helfen die Cache Miss Rate zu verringern und so die Leistung erhöhen. Es ist aber fraglich ob eine höhere Latenz zwischen den CCX diesen Vorteil nicht überschattet.

Der L3 in Ryzen ist ein Victim-Cache, der wird nicht für Prefetching verwendet.

Zusätzlich ist er exclusiv einem CCX zugeordnet, ein Zugriff vom anderen CCX ist nicht möglich, auch nicht mit höherer Latenz/geringerer Bandbreite.

Ob 2+2 oder 4+0 schneller ist hängt stark von der verwendeten Software ab.
Wenn Threads viele Abhängigkeiten haben wird 4+0 schneller sein.
Wenn die Cache-Größe oder Bandbreite das Limit ist wird 2+0 schneller sein und wenn weder das eine noch das andere zutrifft ist es ziemlich egal dann wird 4+0 und 2+2 gleich schnell sein.

[Dino-Fossil]

Allerdings sieht man auch hier wieder, dass die Zusammensetzung der getesteten Spiele extrem über das Abschneiden entscheidet - im Falle der beiden Artikel zw. kaum messbar und erst recht nicht spürbar und zwar deutlich messbar aber in der Praxis wohl immer noch kaum spürbar.
So gesehen sollte man das auch wieder nicht überbewerten.

[danarcho]

Der L3 in Ryzen ist ein Victim-Cache, der wird nicht für Prefetching verwendet.

Zusätzlich ist er exclusiv einem CCX zugeordnet, ein Zugriff vom anderen CCX ist nicht möglich, auch nicht mit höherer Latenz/geringerer Bandbreite.

zu 1) Das dürfte recht egal sein. prefetch data kommt direkt in den L2, wofür dann etwas (länger nicht benötigtes) in den L3 rutscht. Das könnte sogar effektiver sein als ein prefetch in den L3.

zu 2) Das ist falsch. Der L3 gehört zwar zu jeweils einem CCX, aber Bus-Requests werden direkt über Snooping beantwortet. Also exakt mit etwas höherer Latenz, aber noch deutlich schneller als ein Hauptspeicherzugriff.
Blöde wirds, wenn zwei cores auf unterschiedlichem CCX die gleiche Cache-Line bearbeiten, da dann dauernd der jeweils andere Eintrag invalidiert wird. Aber das Problem hat man auch auf dem gleichen CCX, nur etwas weniger heftig.

[Trap]

Ryzen-Leistung hin oder her, die IPC zählt, ich wollte einen 4+0 aber wenn es den nicht gibt, warte ich bis Ice-Lake oder Tiger-Lake.

Du kannst bei einem Ryzen 7 dein gewünschtes 4+0 einstellen.

[Gast]

zu 2) Das ist falsch. Der L3 gehört zwar zu jeweils einem CCX, aber Bus-Requests werden direkt über Snooping beantwortet.

Das Snooping liefert dir nur die Information ob eine Cacheline in einem anderen Cache dirty ist, und das logischerweise über alle Cache-Level in allen Cores.
Trotzdem kann kein Kern auf den L2/L1 eines anderen Kerns direkt zugreifen und auch die Kerne eines CCX nicht auf den L3 des anderen.

Ein Datum kann trotzdem immer nur aus einem gemeinsamen Last-Level-Cache geladen werden, innerhalb eines CCX ist das der L3, über alle CCX der DRAM.


Also exakt mit etwas höherer Latenz, aber noch deutlich schneller als ein Hauptspeicherzugriff.
Blöde wirds, wenn zwei cores auf unterschiedlichem CCX die gleiche Cache-Line bearbeiten, da dann dauernd der jeweils andere Eintrag invalidiert wird. Aber das Problem hat man auch auf dem gleichen CCX, nur etwas weniger heftig.
Du widersprichst dir ja selbst. Wenn die selbe Cacheline in beiden CCX benötigt wird, müssen diese sie jeweils extra aus dem DRAM laden und wenn einer schreibend darauf zugreift ist das Datum im anderen logischerweise ungültig.
Dann muss einerseits gewartet werden, bis der eine CCX die Daten wieder in den DRAM geschrieben hat damit der andere sie lesen kann.

Andererseits sind in so einem Fall sowieso Synchronisationspunkte notwendig und eine parallele Verarbeitung nicht wirklich möglich, da ja nicht automatisch sichergestellt ist dass der schreibende Thread überhaupt fertig ist bevor der lesende zugreift.
Für eine gute Skalierung muss man solche Fälle also eh so gut es geht vermeiden, da dürfte das zusätzliche Penalty durch die CCX-Struktur nicht mehr groß ins Gewicht fallen.

[danarcho]

Das Snooping liefert dir nur die Information ob eine Cacheline in einem anderen Cache dirty ist, und das logischerweise über alle Cache-Level in allen Cores.
...
Dann muss einerseits gewartet werden, bis der eine CCX die Daten wieder in den DRAM geschrieben hat damit der andere sie lesen kann.

Darüber sind moderne cache coherence Protokolle weit hinaus. Selbstverständlich beantwortet der Cache, der eine gültige cache line besitzt, eine Anfrage direkt ohne den Umweg über den DRAM.
Bei nur lesenden Zugriffen, wird die cache line genau einmal aus dem DRAM geholt und dann an den zweiten cache geschickt. Schreibzugriffe invalidieren den jeweils anderen Block, aber gleichzeitig kann die cache line dann immer zwischen den caches hin- und hergeschickt werden. Der DRAM kommt erst wieder ins Spiel, wenn der Block evicted wird. Das ist immer noch langsam genug, aber weit entfernt von einem Datenaustausch über den Hauptspeicher.
Schau dir mal MOESI (https://de.wikipedia.org/wiki/MOESI) an, welches die Grundlage der aktuellen CC-Protokolle bildet und nach meinem Wissen auch bei AMDs Hypertransport verwendet wird.

[Eldoran]

danarcho hat Recht, AMD nutzt bei Zen MOESI mit weitgehend exclusiven Caches. Bei intel und glaube auch bei Bulldozer, werden Daten über den gemeinsamen Last-Level-Cache ausgetauscht.
Innerhalb eines CCX ist die Angelegenheit ziemlich klar - bei einen Miss im L2 wird per MOESI bei den anderen L2 bzw L3 geschaut und ggf. Daten direkt übertragen. Bei einem Hit im L3 kommt es zu einem Tausch einer Cache Line von L2 und L3.
Allerdings muss wenn es lokal im CCX nicht aufgelöst werden kann, auch auf den weiteren CCX des Systems abgeglichen werden - wegen den MCP bei Naples auch bei nur einem Socket. Sonst würde ja die Kohärenz verloren gehen.
Allerdings habe ich bei mindestens einem Review gelesen, dass der L3 nur mit den L2 des selben CCX im Datentausch steht. Ich finde allerdings die Quelle nicht mehr.

[Gast]

Mir verbrauchen die Ryzen in Wirklichkeit alle zu viel, die 65 oder 95w TDP sind doch nur Platzhalter (typisch AMD). Keiner dieser CPUs ist in Spielen deutlich schneller als Intel 4 Core. Interessiert mich daher überhaupt nicht. Zudem soll man sich schlechter ausgestattete B350 Platinen kaufen. Ich warte weiter, Zen 1 ist für nicht kein Erfolg - habe deutlich mehr erwartet. Alles über 200 Euro ist auch nicht gerade wenig...

Da hole ich mir lieber eine Z68 Platine mit einem i7 2600k und lass den mit 3.8-4.0 Ghz laufen, der ist wohl genauso schnell unter Spielen wie ein 1600. Wo ist da der versprochene Fortschritt? Die Kombi kostet nicht mal soviel wie eine einzelne CPU von AMD! Alles nur Abzocke für irgendeine Anwendungsperformance...die mit Faktor 2 zu 1 in die Reviews mit eingerechnet wird. Das interessiert Zocker doch nicht die Bohne.

Könige des Mainstream, ja du mich auch. OC verballern diese CPUs alle über 150w und mehr.

[Gast]

Darüber sind moderne cache coherence Protokolle weit hinaus. Selbstverständlich beantwortet der Cache, der eine gültige cache line besitzt, eine Anfrage direkt ohne den Umweg über den DRAM.
/QUOTE]

[quote]It is worth noting that a single CCX has 8 MB of cache, and as a result the 8-core Zen being displayed by AMD at the current events involves two CPU Complexes. This affords a total of 16 MB of L3 cache, albeit in two distinct parts. This means that the true LLC for the entire chip is actually DRAM

http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700