News AMD Ryzen 3000: Zen 2 mit 16 Kernen für Sockel AM4 als „ES“ im Umlauf

[R1ng0]

Ist es aber. Wie gesagt, die Berechnung findet einfach neu statt, insofern das Ergebnis nicht schon im lokalen L3 gefunden wird.

Und wie soll das gehen? Es kann doch nicht alles neu berechnet werden. Was, wenn ich in den Knoten meines Baumes die FFT eines Echtzeit-Audiosignals habe, die nicht wiederholt werden kann? Und selbst wenn es nicht so komplex ist, "einfach" etwas neu zu berechnen ist in jedem Fall teuer.
Das erscheint wiederum mir abwegig. Hast Du dazu eine Quelle?

 

[Ned Flanders]

oder du hast die Software per über die CPU Affinität auf diese Kerne "festgeklebt".

Also ganz bescheuert bin ich auch nicht... Selbstverständlich läuft das alles absolut auf standard settings.

Übrigens sehe ich gerade ich hab vergessen den Thread wieder abzuschalten.

Kein Switch in 40 min

 

[yummycandy]

Dann ist es etwas was neu irgendwann durch Microsoft eingeführt wurde oder du hast die Software per über die CPU Affinität auf diese Kerne "festgeklebt".

Der Scheduler wurde ja mehrmals aktualisiert. AFAIK gabs nur das Problem, daß Windows bei NUMA Probleme hatte, die CPU-Architektur, also den Aufbau richtig auszulesen. Übrigens war das auch bei Mehrsockelsystemen der Fall. Das war auch der Grund, warum die Scheduler unter Linux dieses Problem nicht hatten.

Aber wirkliche Bug-Reports inkl. benannte Fixes hab ich nicht gesehen. Jeweils nur ein "Update des Scheduler".

Ergänzung (12. Mai 2019)

Und wie soll das gehen? Es kann doch nicht alles neu berechnet werden. Was, wenn ich in den Knoten meines Baumes die FFT eines Echtzeit-Audiosignals habe, die nicht wiederholt werden kann? Und selbst wenn es nicht so komplex ist, "einfach" etwas neu zu berechnen ist in jedem Fall teuer.
Das erscheint wiederum mir abwegig. Hast Du dazu eine Quelle?

Ist ganz einfach. Der Scheduler versucht die Threads eines Prozesses immer dem CCX zuzuweisen, auf dem der Prozess gestartet wurde. Wenn alle Cores belegt sind, werden die eines anderen CCX benutzt. Insofern gibt es nie das Problem, daß in einem L3 das Ergebnis eines Cores auf einem anderen CCX vorliegt. Sollte es aufgrund von Berechnungswiederholungen doch mal so sein, wird die Berechnung dennoch neu vorgenommen. Die Caches beziehen sich immer nur auf den lokalen CCX.

 

[Ned Flanders]

Und wie soll das gehen?

Lässt man typischerweise bei solchen Programmen die errechneten Ergebnisse einfach in den Victim Cache fallen aus dem sie irgendwann wiederum verschwinden oder öffnet man typischerweise ein File und schreibt die Ergebnisse in dieses?

 

[MK one]

wobei die Frage immer noch im Raum steht ob es bei 4 Kernen pro CCX geblieben ist , oder ob die 8 Kerne eines Chiplet den CCX darstellen , auch das wird sich zeigen müssen

 

[yummycandy]

wobei die Frage immer noch im Raum steht ob es bei 4 Kernen pro CCX geblieben ist , oder ob die 8 Kerne eines Chiplet den CCX darstellen , auch das wird sich zeigen müssen

Das wurde eigentlich schon bestätigt.

 

[xexex]

Sollte es aufgrund von Berechnungswiederholungen doch mal so sein, wird die Berechnung dennoch neu vorgenommen. Die Caches beziehen sich immer nur auf den lokalen CCX.

Das ist aber Quatsch! Natürlich muss die CPU nichts neu berechnen, wie soll das gehen? Der Cache ist nur ein Zwischenspeicher, die Daten landen vom Zwischenspeicher im RAM. Soll ein Kern die Arbeit eines anderen Kerns fortsetzen, müssen die Daten über den langsamen Arbeitsspeicher zu dem anderen Kern gelangen.

Das gleiche gilt natürlich auch, wenn die Ergebnisse eines Kerns, als Quelle für die Berechnung eines anderen Kern dienen. Deshalb gibt es zum Beispiel auch Disziplinen wie Cinebench, wo sich AMD sehr wohl fühlt, hier berechnet jeweils ein Kern sein eigenes "Päckchen", während es andere Lasten gibt, in den die AMD CPUs schlecht abschneiden.

 

[yummycandy]

Das ist aber Quatsch! Natürlich muss die CPU nichts neu berechnen, wie soll das gehen? Der Cache ist nur ein Zwischenspeicher, die Daten landen vom Zwischenspeicher im RAM.

Mit Berechnungswiederholung meine ich eine Berechnung, die im Laufe vom Programmablauf schon irgendwann mal berechnet wurde und sich noch durch Zufall im Cache eines anderen CCX befindet. Davon hat der lokale Kern ja nichts und berechnet das neu. Das war gemeint.

 

[R1ng0]

Wenn alle Cores belegt sind, werden die eines anderen CCX benutzt. Insofern gibt es nie das Problem, daß in einem L3 das Ergebnis eines Cores auf einem anderen CCX vorliegt.

Das ist aus meiner Sicht ein Widerspruch.

Sollte es aufgrund von Berechnungswiederholungen doch mal so sein, wird die Berechnung dennoch neu vorgenommen.

Wie gesagt, dazu würde mich die Quelle interessieren. Meine Auffassung ist:

• Viele Berechnungen lassen sich nicht neu vornehmen, weil die Ausgangsdaten nicht mehr vorhanden sind weil sie z.B. inplace überschrieben wurden.
• Berechnungen basieren auf Daten, die ebenfalls im anderen CCX vorgehalten werden.
• Berechnungen können sehr teuer sein. Niemand möchte für Minuten etwas neu berechnen, nur weil das schon berechnete Ergebnis im falschen L3 liegt.

Alles in allem klingt das für mich nicht nur abwegig sondern schlicht unmöglich. Aber man lernt ja nie aus, deswegen fragte ich nach der Quelle.

 

[xexex]

Mit der Aussage komme ich genauso wenig klar. Im Cache werden keine "Berechnungen" gespeichert, dort befinden sich nur Teile des langsameren Arbeitsspeichers.

Wenn du 1000 mal eine Multiplikation durchführen muss, dann muss du die 1000 mal durchführen und die Ergebnisse in den Speicher schreiben und kannst nicht sagen 2x2 habe ich schon woanders berechnet.

Einfach ausgedrückt geht es so...

In Speicherzelle xyz liegen Daten, diese Daten sollen mit 2 multipliziert werden und ich Speicherbereich zxy gespeichert werden. Wenn jetzt der gleiche Kern direkt danach den Inhalt von zxy durch 5 teilen soll, braucht er nicht auf den Speicher zugreifen, die Daten liegen in seinem Cache.

Wenn aber nun Kern 2 diese Berechnung durchführen soll, muss das Ergebnis der Berechnung von Kern 1 erst in den RAM und von dort aus in den Cache von Kern 2.

 

[MK one]

https://www.techpowerup.com/253954/...reveals-new-options-for-overclocking-tweaking
CAKE, or "coherent AMD socket extender" received an additional setting, namely "CAKE CRC performance Bounds". AMD is implementing IFOP (Infinity Fabric On Package,) or the non-socketed version of IF, in three places on the "Matisse" MCM. The I/O controller die has 100 GB/s IFOP links to each of the two 8-core chiplets, and another 100 GB/s IFOP link connects the two chiplets to each other. For multi-socket implementations of "Zen 2," AMD will provide NUMA node controls, namely "NUMA nodes per socket," with options including "NPS0", "NPS1", "NPS2", "NPS4" and "Auto".

Sieht so aus als wären die Chiplets auch direkt verbunden

The "Matisse" processor will also provide users with finer control over active cores. Since the AM4 package has two 8-core chiplets, you will have the option to disable an entire chiplet, or adjust the core-count in decrements of 2, since each 8-core chiplet consists of two 4-core CCX (compute complexes), much like existing AMD designs. At the chiplet-level you can dial down core counts from 4+4 to 3+3, 2+2, and 1+1, but never asymmetrically, such as 4+0 (which was possible on first-generation Zen). AMD is synchronizing CCX core counts for optimal utilization of L3 cache and memory access. For the 64-core Threadripper that has eight 8-core chiplets, you will be able to disable chiplets as long as you have at least two chiplets enabled.

ja , bleibt wohl bei 4 Kernen pro CCX , aber wie sieht das synchronisieren wohl aus ?

 

[yummycandy]

Sieht so aus als wären die Chiplets auch direkt verbunden

ja , bleibt wohl bei 4 Kernen pro CCX , aber wie sieht das synchronisieren wohl aus ?

1. sieht man hier ganz gut

2. Wie die Synchronisierung läuft, weiß man bisher nicht, da gibts nur viele Vermutungen. Es kommt auch darauf an, wieviel Logik im i/o Die verbaut ist.

 

[R1ng0]

Das ist aber Quatsch! Natürlich muss die CPU nichts neu berechnen, wie soll das gehen? Der Cache ist nur ein Zwischenspeicher, die Daten landen vom Zwischenspeicher im RAM. Soll ein Kern die Arbeit eines anderen Kerns fortsetzen, müssen die Daten über den langsamen Arbeitsspeicher zu dem anderen Kern gelangen.

Das gleiche gilt natürlich auch, wenn die Ergebnisse eines Kerns, als Quelle für die Berechnung eines anderen Kern dienen. Deshalb gibt es zum Beispiel auch Disziplinen wie Cinebench, wo sich AMD sehr wohl fühlt, hier berechnet jeweils ein Kern sein eigenes "Päckchen", während es andere Lasten gibt, in den die AMD CPUs schlecht abschneiden.

So sehe ich das auch. Entweder über den Arbeitsspeicher oder aber "IF Magic" worauf @MK one letzter Beitrag hindeutet. So ganz einfach scheint das aber auch nicht zu sein...

Das Problem mit Cinebench und ähnlichen Benchmarks ist genau das, das die Workload in der Regel homogen ist und sich ausgezeichnet parallelisieren läßt.
In anderen Diziplinen (Spiele, hust), ist die Workload aber heterogen, wie in dem von Dir verlinkten Reddit-Beitrag beschrieben, und die Threads machen alle unterschiedliche Sachen. Deswegen sind Spiele auch nicht beliebig und vor allem nicht trivial parellelisierbar. Deswegen ist Single-Thread-Performance weiterhin König.

 

[xexex]

ja , bleibt wohl bei 4 Kernen pro CCX , aber wie sieht das synchronisieren wohl aus ?

Steht doch im Text! Mit synchronisieren ist gemeint, dass auf allen CCX immer die gleiche Anzahl Kerne aktiv sein wird damit nicht ein Kern mehr L3 Cache zur Verfügung hat wie der andere.

synchronizing CCX core counts

 

[Ned Flanders]

Der Hauptvorteil von shared Cache Hierarchien ist das man Volumen und damit Fläche spart wenn mehrere Kerne an den gleichen Daten rechnen.

Und überhaupt, wie kommen denn jetzt die Echtzeit Audiodaten aus Knoten A1 in den fremden, distalen Cache? Ich verstehe es noch immer nicht.

 

[xexex]

Hier mal eine technische Erklärung

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Und hier die Kinderversion

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Jetzt stelle man sich vor der Becher müsste immer wieder zum Sekretariat gebracht werden, damit eine andere Person es bei sich weiter berechnen kann, dann hat man ungefähr das Problem, das man bekommt, wenn kein gemeinsamer Cache (Tisch) existiert.

 

[R1ng0]

Since the AM4 package has two 8-core chiplets, you will have the option to disable an entire chiplet, or adjust the core-count in decrements of 2, since each 8-core chiplet consists of two 4-core CCX (compute complexes), much like existing AMD designs. At the chiplet-level you can dial down core counts from 4+4 to 3+3, 2+2, and 1+1, but never asymmetrically, such as 4+0 (which was possible on first-generation Zen).

Warum sollte man Kerne deaktivieren wollen? Oder ein ganzes Chiplet? Das hört sich für mich nach Problemen à la Threadripper an.

Und überhaupt, wie kommen denn jetzt die Echtzeit Audiodaten aus Knoten A1 in den fremden, distalen Cache? Ich verstehe es noch immer nicht.

Cache-Miss im lokalen Cache, also werden die Daten aus dem RAM geholt. Da sie dort aber veraltet sind, müssen sie zuerst aus dem distalen L3 zurückgeschrieben werden. Oder aber der Memory/Cache-Controller weiß, dass die Daten im distalen L3 liegen und schiebt sie über IF in den lokalen L1.
Reine Spekulation meinerseits, bin kein Fachmann. Ich tippe mal auf Variante 2, wozu sollten die CCX/Chiplets sonst miteinander über IF verbunden sein?

 

[muzafferamg58]

Und hier die Kinderversion

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Die zweite Frau war langsamer als die Erste. Da hatte ich den Prozessor gekündigt und einen neuen geholt

 

[Ned Flanders]

bin kein Fachmann.

Das sind wir fürchte ich alle nicht. Wenn ich mir aber Volkers RAM Artikel anschaue bei dem praktisch kein Performance + durch Takten der If von 2933Mhz auf 3600Mz rauskommt, dann muss ich mich fragen ob die versammelte Laienschafft hier nicht Probleme konstruiert die real nicht existieren.

Das dein Echtzeit Audiostream aus einem distalen victim Cache kommt klingt in meinen Ohren wirklich maximal absurd.

 

[R1ng0]

Das dein Echtzeit Audiostream aus einem distalen victim Cache kommt klingt in meinen Ohren wirklich maximal absurd.

Der Echtzeit Audiostream war doch nur ein Beispiel bezüglich der "neu berechnen" Thematik, zugegebenermaßen kein gutes.

Aber eine Datenstruktur wie einen Baum maximal parallel zu berechnen macht doch Sinn oder?
Und dann diese Datenstruktur auch zu benutzen macht doch auch Sinn?
Was also wenn nun Daten im distalen L3 liegen, was ist denn daran abwegig?