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

[MK one]

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

Ach was , ich kann bei mir im Uefi auch auf 6 /4 oder 2 Kerne runter ...

 

[xexex]

dann muss ich mich fragen ob die versammelte Laienschafft hier nicht Probleme konstruiert die real nicht existieren.

Sorry aber das Problem mit den CCX, getrennten Caches und ungleichen Speicherzugriffen ist alles andere als konstruiert.

Es mag sein, dass Microsoft hier ein paar Workarounds eingebaut hat und die Arbeitsweise vom Scheduler mittlerweile optimiert hat, ändert aber wenig an der Problematik an sich. Nicht jeder Workload lässt sich komplett in mehrere voneinander unabhängige Berechnungen aufteilen und es ist auch nicht garantiert, dass nach einem Kontextswitch wieder der gleiche Kern seine Arbeit fortsetzen kann.

Das Problem hat man doch bis zum Erbrechen bei Phoronix seinerzeit durchgekaut und ist nicht anders, wenn auch kleiner bei den Desktop CPUs vorhanden.

https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows&num=2

Das was du uns gezeigt hast ist praktisch ein optimaler Zustand. Zwei Kerne sind voll ausgelastet, die anderen haben gar nichts zu tun und können die "restlichen" Aufgaben erledigen.

Jetzt stelle dir aber mal vor, alle Kerne wären mit der Applikation ausgelastet. Dann muss das System ja trotzdem noch zig Sachen "nebenbei" erledigen und dann anfangen die Prozesse umzulegen. (Context Switch)

Konstruiert ist hier jedenfalls gar nichts, der ungleiche Aufbau der AMD CPUs, war von Anfang an ein großes Problem sowohl im Client als auch im Serverbereich und nur weil man ein paar Workarounds gefunden hat wie man dieses Problem möglichst umgeht, ändert es nichts an der Problematik an sich.

Hier übrigens viele Informationen und Bilder zu der Zen Architektur.
https://en.wikichip.org/wiki/amd/microarchitectures/zen

 

[Ned Flanders]

@R1ng0 Wenn ich dich verstehe rechnest du an jedem Knoten im Baum die Ergebnisse aus die ein Folgethread dann benutzt um die nächste Stufe zu errechnen?

 

[Heschel]

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.

Das ist doch ein Widerspruch in sich selbst - oder irre ich mich?

Wenn Zen 2 ein 4-Kern CCX auf einem 8-Kern Chiplet besitzt, wieso gibt es eine Möglichkeit (bei 2 Chiplets) ein Chiplet auszuschalten, aber bei 2 CCX auf einem Chiplet (4+4) nicht? Eigentlich dürfte 4+0 gehen, da ein CCX auch abgeschaltet werden kann.

 

[yummycandy]

Wenn Zen 2 ein 4-Kern CCX auf einem 8-Kern Chiplet besitzt, wieso gibt es eine Möglichkeit (bei 2 Chiplets) ein Chiplet auszuschalten, aber bei 2 CCX auf einem Chiplet (4+4) nicht? Eigentlich dürfte 4+0 gehen, da ein CCX auch abgeschaltet werden kann.

Man wird wohl immer ein Chiplet und damit die Hälfte der Cores ausschalten können. Wie das allerdings mit den CCX innerhalb eines Chiplets sein wird, weiß man nicht.

 

[Ned Flanders]

Jetzt stelle dir aber mal vor, alle Kerne wären mit der Applikation ausgelastet. Dann muss das System ja trotzdem noch zig Sachen "nebenbei" erledigen und dann anfangen die Prozesse umzulegen.

Ok, dann wird mein thread Solange unterbrochen bis die high priority Aufgabe erledigt ist und macht dann weiter. Dein Problem tritt doch nur dann auf, wenn der thread auf einem anderen ccx wieder aufgenommen würde wobei ein cache miss zur Folge hätte das die Daten aus dem RAM geholt werden müssen. Das ist vielleicht nicht konstruiert, aber keinesfalls ein typisches Szenario. Und die Daten werden in dem Fall definitiv nicht aus dem distalen l3 geholt, denn die Gefahr daß die Daten dort auch nicht liegen ist ja Gewaltig gross und es gibt keinen Algorithmus der sagt liegen sie nicht hier im l3 liegen sie vielleicht noch dort. Ein Cache Miss ist ein Cache Miss und bedeutet immer RAM.

So schlau sind Zens nicht, ich glaube du überschätzt die da.

 

[xexex]

Das ist vielleicht nicht konstruiert, aber keinesfalls ein typisches Szenario.

Das war bevor Microsoft den Scheduler nicht speziell für AMD CPUs optimiert hat, definitiv ein typisches Szenario. Bis dahin gab es diese Unterscheidung gar nicht und ein Thread konnte und wurde auf einem beliebigen Kern fortgesetzt. Ich habe dir ja bereits ein Bild gezeigt wie es aussieht, wenn eine Applikation auf einer Intel CPU läuft. Da vermeidet man schon alleine deshalb, um Hotspots zu vermeiden, eine Last ständig auf einem Kern zu halten.

Das Bild was du bei dir siehst, ist ein Workaround, damit die Leistung auf AMD CPUs nicht in den Keller geht.

So sieht bei mir Prime mit 6 Threads aus.

Die Last wird dabei in "Timeslices" aufgeteilt und mehr oder weniger willkürlich auf die Threads verteilt.

Es gibt von Microsoft übrigens ein schönes Tool mit dem man sich ein paar Interessante Grafiken anzeigen lassen kann.
https://www.microsoft.com/de-de/p/windows-performance-analyzer/9n0w1b2bxgnz?activetab=pivotverviewtab#

https://docs.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis

 

[Ned Flanders]

Das Bild was du bei dir siehst, ist ein Workaround, damit die Leistung auf AMD CPUs nicht in den Keller geht.

Fair enough, mit der Änderung am scheduler ist der Drops jetzt aber gelutscht. Ne top Lösung ist das aber auch bei den Intels nicht, den jeder Kern hopp von denen es ja so viele gibt ist auch da erstmal ein Cache Miss im l1, dann im l2 und dann muss die schosse auch dort wieder aus dem langsamen, shared last Level Cache geholt werden.

Und das alles nur als workaround für die Hotspots durch TIM...

Gute Nacht.... Ich bin im Bett

 

[Heschel]

Man wird wohl immer ein Chiplet und damit die Hälfte der Cores ausschalten können. Wie das allerdings mit den CCX innerhalb eines Chiplets sein wird, weiß man nicht.

Das Wegfallen von 4+0 macht überhaupt keinen Sinn. Es macht nur einen Sinn, wenn es 8 Kerne in einem CCX sind - anderenfalls könnte man auch keinen ganzen Chiplet ausschalten. Warum sollte man das eine beibehalten und das andere weglassen?

 

[xexex]

Fair enough, mit der Änderung am scheduler ist der Drops jetzt aber gelutscht.

Nein ist er nicht! Das Problem bleibt ja bestehen, Kerne die auf Daten eines andere Kerns zugreifen wollen, müssen es noch immer über den langsamen Speicher oder die Infinity Fabric tun. Deshalb sind die AMD CPUs auch so vom schnellen Speicher abhängig, während du bei einer Intel CPU selbst mit DDR4 2666 kaum Leistung verlierst.

Mit dem Workaround hat man ein Problem umgangen, andere Probleme bleiben aber bestehen und die Ursachen dafür lassen sich nur in der Hardware beheben.

 

[Ned Flanders]

Deshalb sind die AMD CPUs auch so vom schnellen Speicher abhängig, während du bei einer Intel CPU selbst mit DDR4 2666 kaum Leistung verlierst.

Das ist ein weiteres unbelegtes Märchen. Weder AMD noch Intel profitieren von einer Erhöhung des RAM taktes. Beide profitieren von einer Verkürzung der Latenzen zum RAM. AMD von letzterer deutlicher, Intel aber auch substantiell.

Hier: wo ist sie denn eure Skalierung mit dem IF Takt by komplexen workloads.

https://www.computerbase.de/artikel/prozessoren/amd-ryzen-cpu-ddr4-test.66703/seite-2

 

[xexex]

AMD von letzterer deutlicher, Intel aber auch substantiell.

Dann frage dich doch einfach mal wieso das so ist! Weil bei AMD wesentlich mehr Daten über den Speicher geschaufelt werden müssen, weil sie nicht im Cache vorliegen, Zudem hängt bei AMD aber auch noch die IF an den Speichertakt während bei Intel der Ring- oder Meshtakt komplett unabhängig vom Speicher läuft.

Beides sind eben Faktoren die AMD angehen kann um die IPC der eigenen CPUs zu verbessern.

 

[Ned Flanders]

Dann frage dich doch einfach mal wieso das so ist!

Weil der größte Teil der Softwarewelt auf Intels Sprungvorhersage optimiert ist. Speziell jene Loads, die am schlechtesten auf Zen laufen, gewinnen am meisten durch kurze Latenzen zum RAM.

Die Gewinne werden nicht schmäler bei einer 4+0 konfig als bei einer 2+2 config.

Dazu kommt noch das AMDs Perceptron nicht ganz so gut ist wie Intels TAGE.

Mit context switching jedenfalls wie du es hier weiss machen willst hat das nachweislich nichts zu tun. Schon gar nichts mit Zugriffen auf distale L3s.

 

[xexex]

Mit context switching jedenfalls wie du es hier weiss machen willst hat das nachweislich nichts zu tun.

Da du außer deiner zweifelhaften Aussagen keine Quellen für deine Behauptungen vorbringst, spare ich mit hier einen weiteren Kommentar darauf. Ich glaube es haben dir mehrere Personen hier heute erklärt, wieso vier voneinander unabhängige Caches zum Leistungsnachteil führen und wieso es so ist.

Wenn du einer anderen Meinung bist, dann ist dem so.

 

[MK one]

Warten wir es mal ab , Zen2 wurde an vielen Stellen aufgebohrt , Caches , Pipelines , FPU , AVX2 und Sprungvorhersage zudem wollte AMD nochmals die Latenzen senken , in 6 - 8 Wochen ist es soweit , in 2 Wochen bekommen wir einen ersten Einblick bei der Computex , da wird AMD es krachen lassen meiner Meinung nach , Lauch steht kurz bevor , also braucht man auch nichts zurückhalten und bekommt zudem kostenlose Publicity

 

[Caramelito]

Warten wir es mal ab , Zen2 wurde an vielen Stellen aufgebohrt , Caches , Pipelines , FPU , AVX2 und Sprungvorhersage zudem wollte AMD nochmals die Latenzen senken , in 6 - 8 Wochen ist es soweit , in 2 Wochen bekommen wir einen ersten Einblick bei der Computex , da wird AMD es krachen lassen meiner Meinung nach , Lauch steht kurz bevor , also braucht man auch nichts zurückhalten und bekommt zudem kostenlose Publicity

Ich hoffe, dass du recht hast.

Ich hätte nen SEHR günstigen 9900k haben können, aber ich vertraue in dem Fall AMD - Auch wenn der 9900k dann 5% schneller bleiben sollte - 4 Kerne + sind 4 Kerne + für die restlichen Aufgaben des PCs

 

[Ned Flanders]

Da du außer deiner zweifelhaften Aussagen keine Quellen für deine Behauptungen vorbringst, spare ich mit hier einen weiteren Kommentar darauf.

Skaliert die Spiele-Performance von Ryzen über den IF Takt? Yes/No

(Oben extra verlinkt)

Sollte sie das, wenn context switching über ccx Grenzen hinweg bei Gaming workloads ein real passierendes Problem wären? Yes/No?

Ich kann jede Aussage die ich gemacht hab logisch mit Daten belegen. Du hast bislang garnichts belegt und warst auch noch überrascht das deine Infos zum scheduler seit einem Jahr veraltet sind. Also komm mir nicht mit zweifelhaft.

So, jetzt aber gute Nacht.

 

[xexex]

Skaliert die Spiele-Performance von Ryzen über den IF Takt? Yes/No

Ja! Je nach "Applikation" jedoch unterschiedlich stark.

Die Kommunikation zwischen den beiden L3-Blöcken erfolgt bei Zen ebenfalls mit Speichertakt (32 Byte bidirektional pro Zyklus, ergo 42 GByte pro Sekunde bei DDR4-2667). Das könnte den Chip etwas bremsen - denkbar sind aber auch hohe Latenzen zwischen den Clustern. Wir haben daher die beiden CCX per UEFI-Einstellung umkonfiguriert: Einmal als 4+0-Variante, also einen Quadcore mit 8 MByte bestehend aus nur einem aktiven CCX, und einmal als 2+2, also zwei Kerne pro CCX und insgesamt 16 MByte. Die Leistung in Anwendungen und Spielen unterscheidet sich leicht, in der Spitze ist Ashes of the Singulary mit der 4+0-Konfiguration rund 9 Prozent schneller.
https://www.golem.de/news/ryzen-7-1800x-im-test-amd-ist-endlich-zurueck-1703-125996-6.html

Am Ende ist es letztlich beides, die CPUs profitieren von besseren Latenzen UND von einem höheren Takt, vor allem DX12/Vulkan Spiele scheint es zu betreffen, auch wenn ich den letzten Abschnitt unbestätigt einfach wiedergebe.

And - crucially - this characteristic is enhanced even further on the modern graphics APIs, DX12 and Vulkan, which positively encourage producing rendering commands in a multithreaded manner. Perhaps you've noticed how RoTR and AotS are more strongly disadvantaged by running on Ryzen (compared to an Intel CPU or even an older AMD CPU) when running on the modern API than the older one they support.
https://www.reddit.com/r/Amd/comments/601828/how_the_windows_high_performance_mode_is_limiting/

 

[MK one]

https://en.wikichip.org/wiki/amd/microarchitectures/zen#Floating_Point

Ja , kann sie , über den IF ...
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).

wobei wir beim IF2 wären , der hat doppelte Bandbreite - auch doppelten Takt ? das würde die Latenzen deutlich senken ... , schon die recht geringe Übertaktung durch den Ram ( 200-300 Mhz ) bringt da deutlich etwas , wenn der IF2 jetzt den doppelten Takt erhält ...
IF = 1500 ? = DDR4 2933 , bis 1800 = DDR4 3600 kann es gehen
Stiege der IF 2 Takt auf 3000 wäre das ein deutlicher Schub , nicht nur in Sachen Bandbreite ( von 50 auf 100 GB /s ) sondern auch bei der Verringerung der Latenz

 

[xexex]

wobei wir beim IF2 wären , der hat doppelte Bandbreite - auch doppelten Takt ? das würde die Latenzen deutlich senken ...

Das kann man letztlich nur hoffen, da die "Problematik" mit einem zweiten Die nicht weniger wird. Bei einem 16C Ryzen hast du ja 4x4 Kerne mit jeweils eigenem L3 Cache und es müssen Daten sowohl zwischen den Caches als auch zum Speicher und IO geschoben werden.

Deshalb auch die vermutete Verbindung zwischen den beiden Dies, weswegen ich auch nicht mehr so wirklich an einen L4 Cache im IO Chip glaube.