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

Wir machen nichts anderes als Kaffeesatz lesen...

Bei allem Optimismus muss man die Kirche auch mal im Dorf lassen. Zen2 wird sicher gut, aber was manche erwarten und bei den Erwartungen die geschürt werden kann das Ding bei Release ja bald nur noch enttäuschen.
 
  • Gefällt mir
Reaktionen: Kalsarikännit, DonL_, Chaos Theory und 3 andere
Ned Flanders schrieb:
Wir machen nichts anderes als Kaffeesatz lesen...

Bei allem Optimismus muss man die Kirche auch mal im Dorf lassen. Zen2 wird sicher gut, aber was manche erwarten und bei den Erwartungen die geschürt werden kann das Ding bei Release ja bald nur noch enttäuschen.
Ich war noch nie so heiß auf einen Prozessor, wie jetzt. Ich vermute aber, dass die CPU schon ganz schön hoch takten wird: Auszug von der 7nm Seite von TSMC: 'TSMC set another industry record by launching two separate 7nm FinFET tracks: one optimized for mobile applications, the other for high performance computing applications. '
 
Das wichtigste ist erst mal der Takt , der wird über 4 Ghz Base liegen ( 16 Kerner bleibt abzuwarten in welche TDP der gepackt werden soll ) , beim Boost hat bisher nichts meine Meinung erschüttern können , der wird bis zu den werbewirksamen 5 GHz gehen bei den Spitzenmodellen .
Amd hat gesagt sie würden auch beim Zen2 / Ryzen 3xxx an den Latenzen arbeiten , das wie ist erst mal uninteressant , das wieviel wird sich in Tests zeigen müssen .
Da der Ryzen 3xxx der erste Prozessor mit Chiplet(s) und I/O Die sein wird kann man eigentlich nur raten , meiner Meinung nach sollte bereits der verdoppelte L3 Cache ausreichen um die Latenzen zu senken

@über mir
alter Hut : Der ryzen 3xxx wird im 7nm HPC ( = High Performance Computing ) gefertigt , damit sollen 13% höherer Takt erreicht werden .
 
Hmmm, interessant. Vieleicht ist der AM4 Sockel schlicht zu klein für so viel L4?
Was ist denn mit Threadripper, ist der Sockel größer?
Ergänzung ()

MK one schrieb:
Da der Ryzen 3xxx der erste Prozessor mit Chiplet(s) und I/O Die sein wird kann man eigentlich nur raten , meiner Meinung nach sollte bereits der verdoppelte L3 Cache ausreichen um die Latenzen zu senken
Das gilt aber doch nur für den jeweiligen CCX, oder? Sobald die Daten im L3 des anderen CCX sind oder gar im anderen Chiplet, dürfte doch die Größe des L3 unerheblich sein.
Nach meinem Verständnis ist das Problem, dass es nicht einen L3 gibt, sondern mehrere (C / 4 ).
 
Öhm, so ein bisschen größer schon. Also ungefähr doppelt so groß ^^
Ich sag mal so: Threadripper 4094 pins, AM4 1331 Pins

EDIT: Bzw ca. 40x40mm Ryzen vs 75x58mm Threadripper
 
Zuletzt bearbeitet:
R1ng0 schrieb:
Vieleicht ist der AM4 Sockel schlicht zu klein für so viel L4?


Nö, das wäre überhaupt kein Problem ;). Es gab ja schon einmal einen Desktopprozessor mit L4-Cache (Intel Broadwell):

https://pics.computerbase.de/6/5/6/6/0/1-1080.1313303517.jpg

Ich glaube da waren sogar 128MB eDRAM drin. Der AM4-Sockel wäre also groß genug.

R1ng0 schrieb:
Nach meinem Verständnis ist das Problem, dass es nicht einen L3 gibt, sondern mehrere (C / 4 ).

Ja, so ist es auch. Von daher wäre es sinnvoll einen L4-Cache zu haben. Inwieweit sich so etwas in der Praxis umsetzten läßt steht auf einem anderen Blatt Papier. Ist eh alles nur Spekulatius. Ich denke, in 3 Wochen sind wir wieder ein bischen schlauer :).

Fest steht für mich, daß AMD mit Sicherheit am "Latenzproblem" weitergearbeitet hat. Da hat sich ja von Zen zu Zen+ schon einiges getan.

Lg,

Ice
 
R1ng0 schrieb:
Sobald die Daten im L3 des anderen CCX sind oder gar im anderen Chiplet, dürfte doch die Größe des L3 unerheblich sein.

Warum zum Henker sollte ein Core Daten im Victim Cache eines anderen suchen (und finden) die er in seinem eigenen Cache nicht findet? Das musst du mir nochmal erläutern.
 
  • Gefällt mir
Reaktionen: SVΞN
Ned Flanders schrieb:
Warum zum Henker sollte ein Core Daten im Victim Cache eines anderen suchen (und finden) die er in seinem eigenen Cache nicht findet? Das musst du mir nochmal erläutern.
Ach Ned, dass Thema hatte wir vor einem Jahr schon. Leider habe ich das meiste wieder vergessen. Das Alter..

Aber nehmen wir folgendes Scenario:
Threads auf CCX_0 und CCX_3 arbeiten mit denselben Daten. Dann sehe ich schon, zumindest wenn es auch Schreibzugriffe gibt, einen gewissen Synchronisierungsbedarf.

Auf die Schnelle habe ich nur dies gefunden (wikichip.org), allerdings nicht ganz passend zum o.a. Scenario:
This design choice allows for the scaling up to large high-performance multi-core system (i.e., high scalability, particularly in the server segment, through high core count and large bandwidth) but it does mean that systems making use of Zen processors have to treat every CPU Complex as a processor of its own - i.e., schedule tasks using cache-coherent non-uniform memory access (ccNUMA-aware) scheduling. This is important to ensure that threads are not moved from one CCX to the other as doing so will likely incur unnecessary performance penalties (as cache data would need to be communicated over via the fabric from one CCX to the next which has additional overhead latency and lower bandwidth).

While specific worst-case scenario performance tests have shown that rapid inter-CCXs data movement incur a substantial performance penalty, real world tests have shown the penalty is rather small in practice as the operating system (e.g. Windows) knows how to do the right thing. Additionally performance can be improved with faster memory kits which in turn increases the frequency of the fabric as well (see § Clock domains).
 
Ein Core sucht nicht CCX übergreifend in einem anderen L3. Eher wird die Aufgabe neu berechnet, falls er im Cache nicht fündig wird.
 
  • Gefällt mir
Reaktionen: Ned Flanders
R1ng0 schrieb:
Threads auf CCX_0 und CCX_3 arbeiten mit denselben Daten. Dann sehe ich schon, zumindest wenn es auch Schreibzugriffe gibt, einen gewissen Synchronisierungsbedarf.

Ich bin da auch nur Laie, aber in einem Victim Cache findet man afaik keine Ergebnisse, sondern Daten die aus Platzmangel aus dem L2 herausgeschoben sind. Und wenn ich auf meinem Ryzen einen Thread starte, dann klebt der aber sowas von auf einem Kern... da wird nix verschoben - ganz sicher nicht in einem performancekritischen Maß.
 
Zuletzt bearbeitet:
MK one schrieb:
Da der Ryzen 3xxx der erste Prozessor mit Chiplet(s) und I/O Die sein wird kann man eigentlich nur raten , meiner Meinung nach sollte bereits der verdoppelte L3 Cache ausreichen um die Latenzen zu senken

Der verdoppelte L3 Cache hilft aber wenig gegen die Problematik, die die bisherigen Zen CPUs, vor allem in Verbindung mit Windows haben. In einem 16C Ryzen hast du dann 4x16MB L3 Cache und bei einem Switch von einem Kern auf ein anderes CCX oder Die, müssen die Daten aus dem Speicher nachgeladen werden.

Ein gemeinsamer L4 Cache, der die Inhalte aller L3 Caches spiegelt, würde das Problem beheben.
 
xexex schrieb:
Der verdoppelte L3 Cache hilft aber wenig gegen die Problematik, die die bisherigen Zen CPUs, vor allem in Verbindung mit Windows haben. In einem 16C Ryzen hast du dann 4x16MB L3 Cache und bei einem Switch von einem Kern Thread auf ein anderes CCX oder Die, müssen die Daten aus dem Speicher nachgeladen werden.

Wie häufig passiert das etwa?
 
Zuletzt bearbeitet:
xexex schrieb:
Ein paar Millionen mal in der Sekunde.

Ach ja?

781320
 
Niemand hier weiß es genau.
Aber wie wäre es z.B. damit:
Ich berechne eine binäre Baumstruktur. Und weil ich ein guter Entwickler bin, mache ich das nicht auf einem Kern, sondern auf allen, da sich das "Problem" gut parallelisieren läßt. Bei hinreichender Problemgröße ist mein Baum dann auf allen L3s verteilt.
Wenn ich dann auf einen Kern einen Thread starte, der mal auf diesen Teil des Baumes zugreift, mal auf jenen, müssen die Daten aus dem "entfernten" L3 ja irgendwie in den lokalen L1.
Das erscheint mir jetzt nicht völlig abwegig.
 
Ned Flanders schrieb:

Ja!
Games are a different kettle of fish altogether. Instead of a bunch of identical threads running identical code on different sections of (broadly similar) data, threads in a modern game engine are very heterogeneous, each producing data in vast quantities to be consumed by another and reprocessed to be passed further on still, and eventually fed back to the beginning again. It's even common for "worker threads" to randomly pick up any job, of any type, on any data, which happens to be ready to run - so the flow of data between threads is downright chaotic. This, in itself, leads to a lot of inter-CCX traffic if some of the threads are on one CCX and some on the other.
https://www.reddit.com/r/Amd/comments/601828/how_the_windows_high_performance_mode_is_limiting/

Es mag sein, das mittlerweile Microsoft das Verhalten etwas angepasst hat, damit die AMD Prozessoren nicht mehr so schlecht abschneiden. Würde erklären wieso bei dir die Last anscheinend gar nicht verteilt wird. Bei mir sieht die Sache jedenfalls so aus, wenn ich nur zwei Threads auslaste.
781323



Auf einem 16C System sieht das dann so aus.
781330
 
Zuletzt bearbeitet:
R1ng0 schrieb:
Wenn ich dann auf einen Kern einen Thread starte, der mal auf diesen Teil des Baumes zugreift, mal auf jenen, müssen die Daten aus dem "entfernten" L3 ja irgendwie in den lokalen L1.
Das erscheint mir jetzt nicht völlig abwegig.
Ist es aber. Wie gesagt, die Berechnung findet einfach neu statt, insofern das Ergebnis nicht schon im lokalen L3 gefunden wird.
 
xexex schrieb:

Nein, denn ich habe dir auf einem Ryzen System eben gezeigt dass dem nicht so ist. Nicht ein einziger Switch innerhalb von mehr als 4 Min.
 
Ned Flanders schrieb:
Nein, denn ich habe dir auf einem Ryzen System eben gezeigt dass dem nicht so ist. Nicht ein einziger Switch innerhalb von mehr als 4 Min.

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".
 
Zurück
Oben