News Ryzen 9000: AMD bestätigt zukünftige CPU-Serien per Treiber

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Ryzen 9000: AMD bestätigt zukünftige CPU-Serien per Treiber

Lange wurde darüber spekuliert, ob die zukünftigen CPU- und auch APU-Serien auf Basis von Zen 5 unter dem Namen Ryzen 9000 laufen werden, jetzt bestätigt AMD diese Bezeichnung mit dem neuesten Ryzen-Chipsatztreiber ganz offiziell.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Ryzen 9000: AMD bestätigt zukünftige CPU-Serien per Treiber

 

[Maddoc6]

Die einzige Frage die mich wirklich beschäftigt ist, wir es einen 16 Kerner mit 3D Cache auf beiden CCDs geben! Der 7950X3d ist in seiner jetzigen Form absolut unbrauchbar, da das Scheduling hinten und vorn absolut unzureichend funktioniert.

 

[danyundsahne]

Die einzige Frage die mich wirklich beschäftigt ist, wir es einen 16 Kerner mit 3D Cache auf beiden CCDs geben! Der 7950X3d ist in seiner jetzigen Form absolut unbrauchbar, da das Scheduling hinten und vorn absolut unzureichend funktioniert.

Das ist doch Quatsch. Pcgh und CB hat den Scheduler als sehr gut bezeichnet. Er macht in den allermeisten Fällen den richtigen Job wie wie er es soll.
In den wenigen Ausnahmen muss man eben Hand anlegen oder man lässt es halt.
Aber "hinten und vorn absolut unzureichend" ist natürlich "hinten und vorn absolut" übertrieben von dir ausgedrückt.

Und klar, ein 9950X3D mit vollem Cache für beide CCDs würde den Job natürlich noch besser machen.

 

[Maddoc6]

Das ist doch Quatsch. Pcgh und CB hat den Scheduler als sehr gut bezeichnet. Er macht in den allermeisten Fällen den richtigen Job wie wie er es soll.

Nein tut er nicht. Er parkt sinnlos Cores obwohl sie benötigt werden oder er parkt keine obwohl es nötig wäre. Ich hab nicht ohne Grund nach 2 Wochen von 7950X3D auf den 7800X3D gewechselt.

 

[danyundsahne]

Nein tut er nicht. Er parkt sinnlos Cores obwohl sie benötigt werden oder er parkt keine obwohl es nötig wäre. Ich hab nicht ohne Grund nach 2 Wochen von 7950X3D auf den 7800X3D gewechselt.

Aber das macht er doch nicht im Energieplan Höchstleistung, oder? Das macht er doch nur bei Balanced?!

 

[ToZo1]

Nein tut er nicht. Er parkt sinnlos Cores obwohl sie benötigt werden oder er parkt keine obwohl es nötig wäre. Ich hab nicht ohne Grund nach 2 Wochen von 7950X3D auf den 7800X3D gewechselt.

Und genau das habe ich befürchtet bei dieser Hybrid-Konstruktion 7950X3D, weshalb ich von Anfang an gleich auf den 7800X3D gegangen bin. Der ist aktuell in Punkto Gamingleistung unschlagbar und für mein bissel Anwendungsbedarf vollkommen ausreichend, daß ich die 16 Kerne nicht wirklich brauche. Und er gibt null Huddeleien mit dem Scheduler, weil man eben diesen Kernauswahl- und Park-Scheduler garnicht braucht. Ich habe den Lobhudeleien, daß das alles perfekt funktionieren würde, nie so recht getraut. Dazu bastle ich schon viel zu lange an PCs rum.

 

[The_Invisible84]

Ja hab mich deswegen auch nur für den 7800x3d entschieden, immer volle Leistung und keine scheduling Probleme. Reicht auch für mein Home-Office (DevOps, dev) völlig

 

[Jaffech]

Beim 7950x3D einfach Process Lasso verwenden, falls es mal Probleme geben sollte, was PCGH/CB ja ehr nicht sehen.
Ist generell bei 2 CCD Chips sinnvoll (auch ohne 3D Cache), da manche Spiele wie Doom Eternal keine Intercore Latenzen mögen.

 

[PCGH_Torsten]

Die einzige Frage die mich wirklich beschäftigt ist, wir es einen 16 Kerner mit 3D Cache auf beiden CCDs geben! Der 7950X3d ist in seiner jetzigen Form absolut unbrauchbar, da das Scheduling hinten und vorn absolut unzureichend funktioniert.

Weiterhin unwahrscheinlich:
Anwendungen, die Compute-limitiert sind, profitieren wenig von zusätzlichem Cache (der limitiert halt nicht), aber 1:1 von höherem Takt. Selbst wenn AMD die Stromversorgung jetzt getrennt organisiert, sodass der Vcache keine Vcore-Bremse mehr darstellt, hätte ein damit bestückter CCD immer ein etwas geringeres Taktpotenzial. Man könnte für diese Zusatzinvestition somit kaum einen Aufpreis verlangen, im Gegenteil. Umgekehrt profitiert Software, die nicht durch die Rechenleistung limitiert ist, sondern durch Speicherzugriffe, nicht von weiteren Kernen mit gutem Caching. Der Überschneidungsbereich zwischen beiden Gruppen ist minimal und zusätzlich müsste eine derartige Software auch noch mit den Inter-CCD-Latenzen klarkommen.

Solange AMD die Verbindungen innerhalb des MCMs nicht massiv aufbohrt (idealerweise so, dass der gesamte L3 von jedem Kern sinnvoll genutzt werden kann), lohnt sich eine Doppelbestückung also kaum. Hat AMD laut eigenen Aussagen auch genau so in Vorversuchen festgestellt. Endanwender führen halt, im Gegensatz zu ...-X-Servern nicht einfach dutzende Instanzen ein und desselben Programms parallel aus, sodass sie 16 Kerne für >16 speicherlastige Tasks bräuchten.

 

[Maddoc6]

Weiterhin unwahrscheinlich:
Anwendungen, die Compute-limitiert sind, profitieren wenig von zusätzlichem Cache (der limitiert halt nicht), aber 1:1 von höherem Takt. Selbst wenn AMD die Stromversorgung jetzt getrennt organisiert, sodass der Vcache keine Vcore-Bremse mehr darstellt, hätte ein damit bestückter CCD immer ein etwas geringeres Taktpotenzial. Man könnte für diese Zusatzinvestition somit kaum einen Aufpreis verlangen, im Gegenteil. Umgekehrt profitiert Software, die nicht durch die Rechenleistung limitiert ist, sondern durch Speicherzugriffe, nicht von weiteren Kernen mit gutem Caching. Der Überschneidungsbereich zwischen beiden Gruppen ist minimal und zusätzlich müsste eine derartige Software auch noch mit den Inter-CCD-Latenzen klarkommen.

Solange AMD die Verbindungen innerhalb des MCMs nicht massiv aufbohrt (idealerweise so, dass der gesamte L3 von jedem Kern sinnvoll genutzt werden kann), lohnt sich eine Doppelbestückung also kaum. Hat AMD laut eigenen Aussagen auch genau so in Vorversuchen festgestellt. Endanwender führen halt, im Gegensatz zu ...-X-Servern nicht einfach dutzende Instanzen ein und desselben Programms parallel aus, sodass sie 16 Kerne für >16 speicherlastige Tasks bräuchten.

Das ist wirklich schade. Da kann man nur hoffen, das die normalen 9000er im Gaming ordentlich zulegen und der 9950X zumindest vor einem 14900K liegt. 8 Kerne sind mir für mein nächste Upgrade einfach zu wenig. Und die non 3D CPUs von AMD sehen im Gaming derzeit leider keinen Stich.

 

[PCGH_Dave]

Es würde ja schon reichen, wenn AMD nicht vehement auf die Kern-Last schauen würde. Sie sollten es so wie Intel machen: die zusätzlichen Kerne einfach als "mehr Kerne" betrachten und nicht als "falscher Core Cluster, der jetzt gar keine Last mehr abbekommen soll". Ein 7950X3D, der 12 Kerne belastet, wovon die Hälfte oder mehr mit 3D-V-Cache bestückt sind, dürfte trotz Taktreduktion der 3D-Kerne immer noch schneller sein, als ein normaler 7950X. Aber diesen Weg hat AMD nicht gewählt. Es kann daher nur besser werden, denn ich warte seit Monaten auf eine Stellungnahme von AMD zum Thema Core Parking Bug. Da kommt nichts mehr. Überzeugt mich nicht gerade, muss ich ganz ehrlich sagen.

 

[ssj3rd]

Ich hoffe nur das die X3D Prozessoren nicht wieder erst (viel) später kommen als die regulären…

Im Endeffekt interessieren mich die regulären Teile absolut null und nada seitdem es X3D gibt.

 

[Snowhack]

Das ist wirklich schade. Da kann man nur hoffen, das die normalen 9000er im Gaming ordentlich zulegen und der 9950X zumindest vor einem 14900K liegt.

Das wird spannend 🧐- wenn dann aber nur um Haaresbreite - in Games trennen 7950X und 14900k 32%.

 

[PCGH_Torsten]

Es würde ja schon reichen, wenn AMD nicht vehement auf die Kern-Last schauen würde. Sie sollten es so wie Intel machen: die zusätzlichen Kerne einfach als "mehr Kerne" betrachten und nicht als "falscher Core Cluster, der jetzt gar keine Last mehr abbekommen soll". Ein 7950X3D, der 12 Kerne belastet, wovon die Hälfte oder mehr mit 3D-V-Cache bestückt sind, dürfte trotz Taktreduktion der 3D-Kerne immer noch schneller sein, als ein normaler 7950X. Aber diesen Weg hat AMD nicht gewählt. Es kann daher nur besser werden, denn ich warte seit Monaten auf eine Stellungnahme von AMD zum Thema Core Parking Bug. Da kommt nichts mehr. Überzeugt mich nicht gerade, muss ich ganz ehrlich sagen.

AMD verliert doch bereits an Geschwindigkeit, wenn sie die 12 Kerne eines 7900X gleichmäßig auslasten statt der 8 Kerne eines 7700X. Bei Anwendungen, die viel auf den geteilten Cache zugreifen, kann man sich das nicht erlauben; mehrere CCDs pro Task zu nutzen geht nur mit stark Compute-limitierten Aufgaben. Vollständig lösen lässt sich dieses Problem nur, wenn man das CCD-IOD-Konzept aufgibt und nach Intel-Vorbild den gesamten Compute-Bereich monolithisch ausführt. Aber das hat bringt halt viele andere Nachteile mit sich. Schon die recht flotten und vor allem direkten Verbindungen zwischen den Xeon-XCC-Tiles sind nicht annähernd in der Lage, mit dem Desktop-Ring-Bus mitzuhalten. AMDs langsameren Links durch das Substrat und der Umweg über einen dritten Chip machen "mehr Kerne einfach mitnutzen" wie bei den Core-i schlicht unmöglich.

Ich für meinen Teil wäre schon froh, wenn AMD die IF-Links verbreitern und das Datenmannagement aufbohren würde, damit wenigstens der Cache-Pool des zweiten CCDs als eine Art L4 genutzt werden kann, parallel zu Arbeitsspeicher-Zugriffen. Für alles jenseits des lokalen L3 gleich in DRAM zu gehen und einen kompletten zweiten Achtkerner im Prinzip nur für Hintergrundtasks nutzen zu können, ist eine ziemliche Siliziumverschwendung. Aber zumindest ein Teil der Gerüchte sagt ja, dass Granite Ridge den bestehenden IOD weiternutzt; sich also am IF nichts ändert.