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

[Ned Flanders]

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.

 

[muzafferamg58]

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. '

 

[MK one]

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 .

 

[R1ng0]

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 (12. Mai 2019)

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 ).

 

[VelleX]

Ö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

 

[Taxxor]

Expect X570 boards to be pricey. This might be a reason why AMD is keeping the CPU prices on the low. Don't expect the exact pricing from AdoredTV's leak though, as prices have changed since then. Two weeks to go...

https://www.techpowerup.com/forums/...e-socket-am4-beast.255386/page-8#post-4046497

 

[Iceberg87]

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.

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

 

[Ned Flanders]

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.

 

[R1ng0]

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).

 

[yummycandy]

Ein Core sucht nicht CCX übergreifend in einem anderen L3. Eher wird die Aufgabe neu berechnet, falls er im Cache nicht fündig wird.

 

[Ned Flanders]

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ß.

 

[xexex]

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.

 

[Ned Flanders]

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?

 

[xexex]

Wie häufig passiert das etwa?

Ein paar Millionen mal in der Sekunde.

 

[Ned Flanders]

Ein paar Millionen mal in der Sekunde.

Ach ja?

 

[R1ng0]

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.

 

[xexex]

Ach ja?

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.

Auf einem 16C System sieht das dann so aus.

 

[yummycandy]

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.

 

[Ned Flanders]

Ja!

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.

 

[xexex]

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".