AMD Ryzen 9 3950X im Test: Der Rolls-Royce unter den CPUs

[derneuemann]

Anhang anzeigen 1069610

Battlefield V: PC graphics performance benchmarks - Quality modes, frametimes, CPUs

8c/8t optimal für 1080p auf einer 2080ti. Der Rest ist rausgeschmissenes Geld. Wer auf die Zukunft setzt nimmt halt mehr.
Steckt das Geld lieber in eine schnelle GPU wenn es nur ums spielen geht. 720p Benchmarks sind völlig irrrelevant.

Wie Du ja zweifelsfrei erkennst ist 8c/16t langsamer!!! Frostbyteengine halt (BF) - weil sie die Cores gut ausnutzt. Der machbare Boostclock@Stock ist dann unter Multithread kaum noch eine Größe. Da mußt Du dann schon mit LLC Profilen und OC reichlich auf die CPU einschlagen - damit sie diese dann all@Core erreicht - wobei dann andere Dinge limitieren (Temp, Watt, Migration, Lebensdauer usw.).



Ich will den gar nicht kaufen - weil er mir zu teuer als Consumer/Gamer CPU ausfällt (schon vergessen?) und für Gaming irrrelevante Coreanzahl und Leistung zur Verfügung stellen würde - die niemand nutzen kann. Ich spiele wenn auf einem OC@6700k - frag dich mal warum? Weil 4c/8t dann genauso schnell rauskommt wie 8c/16t? Einfach mal auf das Bildchen klicken. Unter 4K ist das nämlich völlig wurscht.

Unter 1080p ist er genauso schnell wie deine 8c/16t.

Wer zwingt dich denn in 4k alles auf max zu stellen, oder wie sieht es dann nächstes Jahr mit den neuen GPUs aus, usw...

Klar ist alles über 6 schnellen Kernen aktuell relativ nutzlos, aber erstens nicht ganz und gar, zweitens ändert sich das auch mit den unterschiedlichen Settings und Spielen, sowie demnächst wieder mit neuen GPUs.

 

[lutari]

Seit R2017b ist AVX2 nutzbar. Darunter werden auch AMD Prozessoren mit mehr als 4 Cores genannt - wohl nur nicht richtig erkannt. Das muß nicht mal an Mathworks liegen.

Wieso Insider? Was CPUs vor 15 Jahren unterstützten kannst Du dir selbst ausmalen.

Es gab auch bereits vor 15 Jahren Erweiterungen der Befehlssätze und damals gab es beim Intel Compiler eine einfache Abfrage. Wenn Intel der CPU-Hersteller ist, dann benutze alle möglichen Befehlssätze, bei einem anderen Hersteller wird es nicht benutzt. Wenn man die Herstellerkennung vom AMD auf Intel gesetzt hat, dann wurde es plötzlich deutlich schneller.
Die aktuelle Situation wirkt mit Intel MKL ähnlich. Das hat nichts direkt mit Mathworks zu tun und Intel MKL wird auch von vielen anderen Softwareherstellern benutzt. Dazu braucht es auch keinen Mitarbeiter von Mathworks der das aufdeckt.

 

[RNG_AGESA]

Eco-Mode
wie kann es aktiviert werden?

 

[Snoopy69]

Zu SMT...
Was mich stört, dass weder Intel, noch AMD und MS die Sache mit SMT angeht
Wenn zb Spiel X ohne SMT besser auskommt, dass dieses automatisch deaktiviert wird

Ähnlich, wie beim NVIDIA-Treiber, der (wenn aktuell gehalten) das Optimum aus dem jeweiligen Spiel holt

Warum traut sich da niemand dran?

 

[Grestorn]

@Snoopy69: Das ist nicht Aufgabe von AMD oder MS sondern vom Spieleprogrammierer. Der kann/muss bestimmen, wie seine Threads verteilt werden.

 

[INU.ID]

Wenn zb Spiel X ohne SMT besser auskommt, dass dieses automatisch deaktiviert wird

Es müsste ja nicht mal deaktiviert werden (was afaik eh nur über das BIOS/einen Reboot geht), es reicht ja eigentlich schon wenn das Betriebssystem dem Spiel (ggf. nach Aufforderung) nur "echte" Kerne zuweist, bzw. HT/SMT einfach nicht benutzt wird. Ich versteh auch nicht was daran so schwer umzusetzen sein soll.

 

[Grestorn]

Es müsste ja nicht mal deaktiviert werden (was afaik eh nur über das BIOS/einen Reboot geht), es reicht ja eigentlich schon wenn das Betriebssystem dem Spiel (ggf. nach Aufforderung) nur "echte" Kerne zuweist, bzw. HT/SMT einfach nicht benutzt wird. Ich versteh auch nicht was daran so schwer umzusetzen sein soll.

Nochmal: Der Spieleprogrammierer muss das tun. Er kann mit den Windows API Funktionen GetSystemInfo() und GetLogicalProcessorInformationEx() Informationen über die vorhandenen Kerne abrufen und jeden seiner Threads entsprechend zuweisen. Das ist schlicht nicht Aufgabe des OS, das nicht wissen kann, was die Software genau braucht.

 

[Snoopy69]

Könnte jmd von euch oder jmd, der einen guten Draht zu Spieleentwicklern hat, mal anfragen, ob das geht?

 

[Grestorn]

Na, bei einigen Spielen siehst Du doch, dass SMT keine oder nur positive Auswirkungen hat. Bei anderen eben nicht. Daran siehst Du, wie gut der jeweilige Entwickler sein Produkt auf die PC Prozessor-Landschaft angepasst hat.

Natürlich muss man aber auch sagen, dass ältere Spiele da im Nachteil sind. Die Welt hat sich halt weitergedreht, seit diese Spiele programmiert wurden, und wenn, dann hat der Programmierer vielleicht geprüft, ob es 2 oder 4 echte Kerne gibt. Aber auf der anderen Seite sollten solche Spiele auch nicht mehr von modernen Prozessoren ausgebremst werden, egal ob SMT an oder aus ist.

 

[BraveNeo]

@lutari
Du meinst eine seit 2018 im answer Forum von Mathworks verfügbare batch ist schlechter Code und verboten. Änder einfach den debug-cpu-typ wenn eine AMD CPU im Sockel steckt. Die Anleitung stammt übrigens von dem gleichen Nedflenders wie auf reddit.

Selbstverständlich wird Intel nicht dafür sorgen das MKL auf AMD Prozessoren mehr als SSE aktiviert. Darum muss sich AMD sicher selbst kümmern. Bisher hat Intel kein Veto dagegen eingelegt, warum auch. MKL liest die Vendor ID aus und Matlab unterstützt auch andere Hardware wie Arm, IBM, Nvidia, Apple und viele mehr. Mit dem Compiler hat das überhaupt nichts zu tun. Der ist in dem Fall auf CPU Erweiterungen wie SSE4 oder AVX und AVX2 optimiert. Warum sollte er auch nicht wenn die Libary von Intel entwickelt wurde?

@grestorn
Seit wann kann man Spielen unter Windows task priority zuweisen. Das glaubst du doch bloß selbst. Was hat die reine Abfrage der Hardware diagdx mit der Zuweisung von processor resscouren zu tun? Der Entwickler wird sich hüten einem Spiel so und so viele Core fest zuzuordnen. Die processor queue wird von Windows verwaltet. Dafür gibt es das thread scheduling. Solange dieser Sheduler die Hardware nicht verwalten kann, weil er sie nicht kennt, solange bleiben auch Ressourcen liegen.

 

[Grestorn]

Seit wann kann man Spielen unter Windows task priority zuweisen. Das glaubst du doch bloß selbst. Was hat die reine Abfrage der Hardware diagdx mit der Zuweisung von processor resscouren zu tun? Der Entwickler wird sich hüten einem Spiel so und so viele Core fest zuzuordnen. Die processor queue wird von Windows verwaltet. Dafür gibt es das thread scheduling. Solange dieser Sheduler die Hardware nicht verwalten kann, weil er sie nicht kennt, solange bleiben auch Ressourcen liegen.

Damit kann man das tun:

SetThreadAffinityMask function (winbase.h) - Win32 apps | Microsoft Docs

Wenn Du Dein Gegenüber für dumm hinstellst, solltest Du von der Materie schon etwas Ahnung haben.

Das Wort "Task Priority" ist etwas daneben, es geht nicht um die Priorität (das wäre, wie viel Zeitscheiben ein Thread bekommt) sondern darum, auf welchen virtuellen oder echtern Kernen ein Thread laufen darf, also auf welche Kerne das OS den Thread verschieben darf. Die Prio könnte aber auch geändert werden mit:

SetThreadPriority function (processthreadsapi.h) - Win32 apps | Microsoft Docs


Und warum sollte ein Entwickler nicht diese Methoden nutzen, um dafür zu sorgen, dass bestimmte Threads nicht auf dem selben Core in zwei virtuellen SMT Kernen zu liegen kommen, wenn er weiß, dass das die Threads ausbremsen würde? Das ist eine ganz normale Optimierungsmöglichkeit, die natürlich auch genutzt werden sollte - und auch wird. Nicht umsonst ist bei den meisten modernen Spielen die Hauptloop auf Kern 0 fixiert.

 

[HardwareHighlander]

Man kann die Prozesspriorität auf Echtzeit stellen, während der Prozess gestartet ist. Windows merkt sich das aber nicht dauerhaft, wer will kann sich hier ein batchfile schreiben, wenn du das meinen solltest.
Also das geht theoretisch schon und grestorn hat hier schlicht recht, unabhängig des thread sheduling des Betriebsystemes gibt es für Spieleentwickler Möglichkeiten das besser zu steuern.
Zum anderen:

I am hoping to get more specific detail in the coming days, but it would seem very likely that Oxide was able to properly handle the more complex core to core communication systems on Ryzen and its CCX implementation. We demonstrated early this month how thread to thread communication across core complexes causes substantially latency penalties[COLOR=rgba(38, 38, 38, 0.9)], and that a developer that intelligently manages threads that have dependencies on the core complex can improve overall performance. I would expect this is at least part of the solution Oxide was able to integrate (and would also explain why Intel parts are unaffected)

 

[gastello]

Man kann die Prozesspriorität auf Echtzeit stellen, während der Prozess gestartet ist. Windows merkt sich das aber nicht dauerhaft, wer will kann sich hier ein batchfile schreiben, wenn du das meinen solltest.
Also das geht theoretisch schon und grestorn hat hier schlicht recht, unabhängig des thread sheduling des Betriebsystemes gibt es für Spieleentwickler Möglichkeiten das besser zu steuern.
Zum anderen:

Du kannst sie nicht höher setzen als "Windowssystem-Task" - das würde zum kritischen Absturz führen oder man verliert merklich Leistung. Was macht das für einen Sinn? Der Entwickler fragt die Coreanzahl ab - nicht wie viele Cores er einem Spiel fest zuordnen darf.

Oxide Games konnte die IF schon richtig ansprechen um das anfängliche Latenzproblem zu umgehen - das hat nichts mit der Threadanzahl zu tun.

 

[gastello]

Nicht umsonst ist bei den meisten modernen Spielen die Hauptloop auf Kern 0 fixiert.

Bei modernen Spielen fixiert man sie eben nicht dort.

 

[Grestorn]

Bei modernen Spielen fixiert man sie eben nicht dort.

Sondern?

Ich gebe nur meine Beobachtung wieder. Bei vielen Spielen springt der Mainthread offensichtlich von Kern zu Kern, bei einigen (ich sage modernen) Spielen bleibt die Hauptlast aber permanent auf Kern 0. Das ist ein klares Anzeichen.

Das ist übrigens auch gut, damit der Prozessor den einen Kern entsprechend hoch takten kann, ohne die anderen Kerne ebenso hoch takten zu müssen. Auch ein klarer Performance-Vorteil.

 

[gastello]

Du kannst sie einfach mit SetPriorityClass in den Hintergrund verschieben, so das der Sheduler die Priorität weiterhin dynamisch anpassen kann. Du würdest sonst den Priorityboost zu stark einschränken. Windows 10 braucht seine Basispriorität - um dabei andere Prozesse in den Hintergrund zu schieben. Die Moduswertverarbeitung für die Prioritätserhöhung erfolgt direkt. Unter älteren Systemen mußte man sie anpassen.

Ich weiß ehrlich nicht was das hier zu suchen hat. Die reine Ressourcenabfrage hat ja nichts mit der direkten Zuweisung zu tun.

 

[Grestorn]

Was willst Du schon wieder mit der Priorität? Darum geht es doch gar nicht. Das ist voll am Thema vorbei. Es geht darum, dafür zu sorgen, das bestimmte Threads sich im SMT Betrieb nicht gegenseitig ausbremsen, also eben nicht auf dem selben physischen Kern liegen.

Wenn ich weiß, dass SMT auf dem aktuellem PC an ist (was ich über die oben beschriebenen Methoden ermitteln kann), dann lege ich für den Thread eine Affinity Mask an, bei dem jedes nur zweite Bit gesetzt ist. Damit sorge ich dafür, dass dieser Thread immer nur auf einem der virtuellen Kernen 0, 2, 4, 6, usw. läuft. Da zwei aufeinanderfolgende virtuelle Kerne sich einen physischen Kern teilen, sorge ich so dafür, dass solche Threads nie im SMT auf einem physischen Kern gleichzeitig laufen.

Wenn ich das für alle meine Threads mache, schalte ich für meine Anwendung SMT quasi ab. Wenn ich das denn wollen würde als App-Entwickler.

 

[gastello]

Und Du weißt unter Windows 10 welcher Thread deines Spiel auf welchem Core ausgeführt wird?

Ein Thread_Ideal_Process ist überhaupt nicht garantiert und genau das beschreibt Microsoft genauso. Unter 64 kannst du lediglich eine Prozessorgruppe zuweisen - wobei der Sheduler entscheidet welchem Kern etwas zugeordnet wird - wenn dort eine Ressource frei ist und dein Eintrag gilt lediglich als Hinweis, muß aber keinerlei Beachtung finden. Genau deshalb pappt man heute nichts mehr an einen Core. Ist nutzlose Arbeit.

Schreib bitte nicht weiter und lies das erstmal nach.

Thread affinity forces a thread to run on a specific subset of processors. Setting thread affinity should generally be avoided, because it can interfere with the scheduler's ability to schedule threads effectively across processors. This can decrease the performance gains produced by parallel processing.

 

[HardwareHighlander]

Du kannst sie nicht höher setzen als "Windowssystem-Task" - das würde zum kritischen Absturz führen oder man verliert merklich Leistung.

Wieso sollte man die den höher als elementare Windows System Tasks setzen wolen? Das ergibt doch gar keinen Sinn, das passiert auch nicht, wenn man das macht, versuche doch nicht allen immer Wörter in den Mund zu legen, die da nicht existierten.
Für Benchmarks stelle ich die Spiele exe per batch datei immer auf die höchste Priorität, das bringt teilweise einen Leistungsschub -jedenfalls sagen mir das meine Beobachtungen, weil man doch nebenbei noch Software mitlaufen hat, die dazwischenfunken kann.

Oxide Games konnte die IF schon richtig ansprechen um das anfängliche Latenzproblem zu umgehen - das hat nichts mit der Threadanzahl zu tun.

Es geht nicht um die Thread anzahl, sondern darum welche Threads ausgelastet werden damit man nicht ständig Daten über die IF schubst, sondern die möglichst lange in einem CCX behält.
Und solche Zusammenhänge kann man wohl je nachdem welche CPU Architektur in System steckt, abfragen und als Spieleentwickler berücksichtigen, genauso eben auch die Last auf nicht auf die logischen Kerne zu legen, warum sollten sonst Spieleenwickler patches für ihre Sofware für die Eigenheiten von Zen herausbringen, wenn das doch alles angeblich durch die OS-SOftware gelöst wird?

 

[lutari]

@lutari
Du meinst eine seit 2018 im answer Forum von Mathworks verfügbare batch ist schlechter Code und verboten.

Falsche Person erwischt? Von mir stammt die Aussage auf jeden Fall nicht und der restliche Text passt auf meine Aussagen auch nur, wenn man meinen Text nur oberflächlich überflogen hat und nicht verstanden hat.