News AMD Ryzen 9 7950X3D & 7900X3D: Beta-BIOS von Asus erlaubt Eingriff in die CCD-Priorisierung

[trouble]

Bin eigentlich optimistisch dass das ohne großes Gepolter über die Bühne geht.
Wie Alder Lake mit P und E Cores, klar gab es da paar Probleme am Anfang, aber Gesamt betrachtet war der Launch recht reibungslos.

Auf der anderen Seite, wenn es Software Seitig was zu verkacken gibt, dann ist AMD leider oftmals gerne ganz vorne mit dabei.

Ich wünsche es absolut nicht und hoffe das alles reibungslos funktionieren wird... aber ich hab da so ein komisches Bauchgefühl...

Bin auf die Tests sehr gespannt.

Na schlimmer als Intel kann man bei Software eigentlich nicht verkacken. Mit fast jedem Wifi Treiber fixen sie Blue Screens (seit 2015). Über CPUs sprechen wir erst gar nicht. Da ist die Liste der letzten Jahre viel zu lang. Grafik Treiber werden immerhin langsam besser. Aber auch da gibt es noch viel Nachholbedarf im Vergleich zu Nvidia und AMD.

 

[brabe]

Nicht dort wo Zen 4 maximalen Takt braucht um konkurrenzfähig zu sein und zusätzliche Zwischenspeicher keine oder nur geringe Vorteile bringen.

Ich bin echt gespannt, ob ein 78003D oder 79003D für Spiele besser sein wird. Davon hängt dann wohl unser aller Kauf ab. Zumindest diejenigen, welche einen neuen 3D kaufen wollen

 

[Zerbich]

Hmm.. meint ihr das bleibt ASUS exklusiv?

Möchte nichts mehr von ASUS kaufen.

 

[incurable]

Möchte nichts mehr von ASUS kaufen.

Asus dankt Dir für Übernahme ihrer präferierten Schreibweise.

 

[C.J.]

Da profiliert sich wieder ein Mainboard-Hersteller mit einem unnoetigen Feature. Zumindest unter Linux kann ich mit

taskset -c

angeben, auf welchen cores ein Prozess laufen soll. Und ich gehe davon aus, dass es unter Windows auch solche Moeglichkeiten gibt.

Schon, aber eine Zuweisung auf Anwendungsebene bedeutet a) auf ewig einen Mehraufwand, um neue Anwendungen einzupflegen und b) ist die Granularität schlecht. Spätestens wenn eine Anwendung mehr als 8 Kerne benutzt, reicht es nicht aus, eine Anwendung auf ein bestimmtes CCD zu pinnen, sondern die einzelnen Threads der Anwendung müssen nochmal aufgeteilt werden. Das kann schon einen Unterschied machen, welcher Thread wo läuft. Oder auch wenn zwei Anwendungen parallel laufen, die bevorzugt das selbe CCD benutzen. Wenn beide viele Kerne brauchen, will ich natürlich beide CCDs nutzen, auch wenn eine Anwendung dann nicht auf dem optimalen CCD läuft.

In den Treiber und Windows-Scheduler habe ich da wenig vertrauen, da die wahrscheinlich sehr allgemeingültig ausfallen werden, mit entsprechender Fehlerquote.

Intel hat zumindest den Thread-Direktor (Hardwarebasis) um Abhilfe zu schaffen. Hat AMD ähnliches?

Grundsätzlich halte ich es für die sauberere Lösung, wenn das Betriebssystem anhand von Daten, die ihm die CPU zur Verfügung stellt, allgemeine Scheduling-Regeln aufstellt. So ist man abhängig von handgepflegten Listen (man denke an die Zukunft und an Linux). Intel hat offiziell damit geworben, dass die Prozesse zur Laufzeit analysieren und dem OS dann Empfehlungen geben, was wo laufen sollte. Von AMD kam bisher nur die Aussage zu den Whitelists. Die neuen BIOS-Einstellungen lesen sich so, als würde da auch auf HW-Ebene eine Heuristik arbeiten, die anhand von Cache-Misses oder Cache-Last abschätzt, welcher Prozess wie sehr von welchem CCD profitiert. Ich finde das erstmal positiv, allerdings könnte es noch sehr unausgereift sein, wenn man sich genötigt fühlt den User dran rumporkeln zu lassen. Eigentlich müsste man da im Labor mal "optimale" Thresholds ausloten und die dann überall anwenden. Sofern die Heuristik was taugt bzw. überhaupt an sinnvolle Datenpunkte aus den Kernen kommt. Irgendwo muss sowas wie eine Cache-Missrate ja herkommen.

 

[Shio]

für Gaming reichen die 8 Kerne mit 3D Cache locker aus. An sich muss ja nur der Render-Thread auf dem V-Cache liegen und alle weiteren Kerne sind Bonus mit nur wenig Zusatzperformance.

Das Problem ist, das du mit den CPUs auf OS/BIOS angewiesen bist um den VCache nutzen zu können.
Wenn deine Zielsoftware jetzt mehr als 8 Kerne oder der Scheduler nicht ordentlich priorisiert könnte es kritisch werden.

Wie gesagt, wenn alles einwandfrei klappt.

Genau da habe ich Bedenken.

Wenn der scheduler funktioniert ist die Lösung ziemlich optimal.

Naja, optimal wäre es wenn alle Cores den VCache hätten.
Im Endeffekt müssen wir abwarten, wird sicherlicher ähnlich ablaufen wie damals die Sache mit den P und E Cores.

 

[MehlstaubtheCat]

Ich bin echt gespannt, ob ein 78003D oder 79003D für Spiele besser sein wird. Davon hängt dann wohl unser aller Kauf ab. Zumindest diejenigen, welche einen neuen 3D kaufen wollen

Ich kann mir vorstellen das der 7950X3D besser performt in Games als der 7900X3D.
WENN, der 7900X3D je CCD 6Kerne und 12 Threads hat.

 

[Novasun]

Am Anfang für Tester interessant... Später denke ich aber unnütz...

 

[t3chn0]

Guten Morgen,

woher bekomme ich denn die notwendige Transparenz um zu sehen ob der Schedulerx korrekt arbeitet oder nicht? Woher weiß ich, dass der FS2020 gerade auf dem korrekten CCD mit Cache läuft und nicht auf dem ohne?

Der Scheduler kann ja auch Mal falsch liegen und auf einmal verpuffen 20-30% Mehrleistung im Nichts und niemand bemerkt es.

Alleine das ist für mich schon Horror, weil ich vor jedem Spiel Start den Zwang verspüren würde das kontrollieren zu müssen und dann auch nochmal zu prüfen ob das Spiel wirklich eher von Cache oder von Takt profitiert.

CS Go läuft übrigens auf einem 7950X 60 FPS schneller als auf einem 7950X3D.

Wie kann das sein?

Denn eigentlich sollte CS Go dann auf dem non Cache CCD laufen und die gleichen Frameraten erzeugen da beide den gleichen Takt haben.

Scheinbar läuft CS Go jedoch dennoch auf dem Cache CCD und somit langsamer..... gemäß Leak.

 

[Taxxor]

Scheinbar läuft CS Go jedoch dennoch auf dem Cache CCD und somit langsamer..... gemäß Leak.

Ist mir auch sofort aufgefallen, dass da wohl die Zuteilung bereits versagt hat.

Um das zu kontrollieren müsstest du eben das Spiel nacheinander auf je einen CCD pinnen und schauen wo es schneller ist, und dann das ganze wieder auf Standard setzen und schauen, ob die Performance passt.

 

[t3chn0]

@Taxxor

Genau davor graut es mir. Überleg Mal, wenn selbst eines der beliebtesten Spiele schon falsch zugeordnet wird. Als wenn niemand CS Go auf diese Whitelist gepackt hat. Daher sind die 6% mehr als schwammig. Gehen wir davon aus, dass CS Go normalerweise gleich schnell sein sollte, würde alleine hier schon der Abstand zumindest mal auf 8% wachsen ggü. dem 13900K. Wer weiß wo sie noch alles gepennt haben.

Damit sind die MCCD 3D Modelle etwas für Bastler die wissen was sie tun. Der 0815 Kunde muss sich blind in den Raum werfen und darauf vertrauen dass das Scheduling passt.

Passt es nicht, war der Aufpreis zum normalen X Modell rausgeworfenes Geld.

 

[LGTT1]

Ich glaube das viele User leicht enttäuscht sein werden, was den Performancegewinn durch den Cache angeht. Bei Zen 3 war der ja ziemlich hoch wenn man 5500 vs 5600 vs 5809X3D ( gibt leider keinen 6 Kerner) vergleicht, da Zen 4 aber so schon mehr Leistung hat aber die Verbesserung gleich bleibt geh ich von weniger Vorteil als noch bei der Vorgängergeneration aus. Außerdem werden der Sheduler und die Treiber vermutlich zum Anfang wenig damit anfangen können.

 

[cha0shacker]

Naja, optimal wäre es wenn alle Cores den VCache hätten.

Könnte AMD bestimmt machen, das Problem ist hier nur das dann 700MHz an Takt verloren gehen und dann Anwendungen welche nicht Cache sensitiv sind deutlich langsamer laufen als auf den normalen Zen 4 Prozessoren. Und das wollte AMD wohl vermeiden.

 

[Don_Tralle]

ich verstehe nicht so ganz warum man den cache nur auf einen ccd packt. der 7950x3d z.b. ist ja dann in anwendungen die nicht vom cache profitieren trotzdem langsamer als der 7950x......ist ja nur die hälfte der kerne die schneller ist. und ob das beim video rendern sinn macht. aus gamer sicht ist das was anderes, da reichen 8 kerne mit cache, da kann man die anderen 8 ohne cache als bonus sehen. aber aus nongamer sicht sieht das komisch aus. vielleicht muss man das anders betrachten. ich als gamer hab z.b. noch nie gedacht: jetzt ein paar kerne mehr die auch noch schneller sind, das wärs.

vielleicht wäre es eine gute lösung den cache soweit zu verringern, dass der takt nicht leidet, dann könnte man ihn gleichmäßig verteilen. so oder so ist mir der 7800 x3d sympathischer

 

[incurable]

vielleicht wäre es eine gute lösung den cache soweit zu verringern, dass der takt nicht leidet

So lang der zusärtliche Zwischenspeicher über ein aufgesetztes die realisiert wird, werden Nachteile in der Wärmeabfuhr der Rechenwerke inheränt bleiben.

so oder so ist mir der 7800 x3d sympathischer

Weil der in Anwendungen, die nicht von zusätzlichen Zwischenspeichern profitieren, immer langsamer ist als sein günstigerer Bruder?

 

[0xffffffff]

Schlechte Entwicklung. Als Nutzer habe ich weder Zeit noch Lust selber dafür sorgen zu müssen, dass alles Erwartungsgemäß läuft. Das ist Aufgabe des Schedulers und damit des OS, anstatt irgend ein Gefummmel im Bios.

 

[foofoobar]

Schon, aber eine Zuweisung auf Anwendungsebene bedeutet a) auf ewig einen Mehraufwand, um neue Anwendungen einzupflegen und b) ist die Granularität schlecht. Spätestens wenn eine Anwendung mehr als 8 Kerne benutzt, reicht es nicht aus, eine Anwendung auf ein bestimmtes CCD zu pinnen, sondern die einzelnen Threads der Anwendung müssen nochmal aufgeteilt werden. Das kann schon einen Unterschied machen, welcher Thread wo läuft. Oder auch wenn zwei Anwendungen parallel laufen, die bevorzugt das selbe CCD benutzen. Wenn beide viele Kerne brauchen, will ich natürlich beide CCDs nutzen, auch wenn eine Anwendung dann nicht auf dem optimalen CCD läuft.

Es ist auch naiv davon auszugehen das eine Instanz eines Threads (unter Linux wäre das die PID) immer die selbe Aufgabe hat.
Thread-pooling ist kein Verfahren welches nur in Nischen Anwendung findet.

Ergänzung (25. Februar 2023)

Schlechte Entwicklung. Als Nutzer habe ich weder Zeit noch Lust selber dafür sorgen zu müssen, dass alles Erwartungsgemäß läuft. Das ist Aufgabe des Schedulers und damit des OS, anstatt irgend ein Gefummmel im Bios.

Primär muss sich die Anwendung drum kümmern, denn nur die weiß halbwegs was dort vor sich geht.

Ergänzung (25. Februar 2023)

So lang der zusärtliche Zwischenspeicher über ein aufgesetztes die realisiert wird, werden Nachteile in der Wärmeabfuhr der Rechenwerke inheränt bleiben.

Die bisherigen konkreten Produkte zeigen allerdings das dieser Nachteil in bestimmten Anwendungen mehr als nur kompensiert wird.

Ergänzung (25. Februar 2023)

Grundsätzlich halte ich es für die sauberere Lösung, wenn das Betriebssystem anhand von Daten, die ihm die CPU zur Verfügung stellt, allgemeine Scheduling-Regeln aufstellt.

Hast du schon einen Patch für den Linux-Kernel eingereicht?

 

[incurable]

Die bisherigen konkreten Produkte zeigen allerdings das dieser Nachteil in bestimmten Anwendungen mehr als nur kompensiert wird.

Es ging um die Frage ob man den Zwischenspeicher so weit reduzieren kann, dass es keine Nachteile beim Takt mehr gäbe.

 

[foofoobar]

Größerer Cache bedeutet quasi immer weniger Takt. Das ist ein klassischer Tradeoff.

 

[incurable]

In der Regel umgeht man sowas durch höhere Latenzen, anstatt an der Taktschraube der Rechenwerke zu drehen.

Und spezielle hier geht es nicht um die Größe der Zwischenspeicher sondern um die physikalischen Realitäten von gestapelten dies.