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

[BraveNeo]

@gastello
Ehrlich, normalerweise müsste man so einen Quatsch melden. Es gibt keine virtuellen Cores einfach so, es gibt virtuelle CPUs unter VMware auch vCPU abgekürzt, die aber keinem logischen Prozessor entsprechen muss. Microsoft gibt einen maximalen Wert von 8:1 dafür an, um die logischen Prozessoren nicht zu überbuchen.

Selbst der Ressourcenmonitor hilft ihm da weiter, weil dort schon steht um was es sich handelt, er versucht sich mit Wortklauberei einfach rauszureden. Virtualisierung bezieht sich dabei nicht auf die CPU, sondern das diese CPU VM beschleunigen kann und es im BIOS aktiviert wurde. Es gibt Tools für das Capacity Management, dann müssten diese Entwickler auch alle falsch liegen. Wenn Windows allein virtualisiert wird, kommt man auf ein Verhältnis von 12:1. Einer vCPU kann man auch mehrere virtuelle Cores zuweisen. Bei einem HT System mit 2x6C/12T CPUs kommt man dann abhängig von der Last auf 192 oder 288 virtuelle Cores. Der Ryzen 3950x kommt auf 256 oder 384 virtuelle Cores. Mehr gibt es dazu auch nicht zu sagen. Als wenn Windows 10 für Gamer ohne Konfiguration irgendwas virtualisiert. Humbug...

Natürlich spricht man bei logischen Prozessoren von Aufteilung, weil man zwei Task auf einem Core gleichzeitig ausführen kann. Es sind physische Cores und logische Prozessoren nichts weiter. Das erfordert parallel arbeitende Pipelinestufen mit Steuerlogik und Ryzen besitzt so ein Frontend.

Er hat ja nicht mal verstanden was SMP ist und schreibt von uns, wer diskutiert hier denn noch mit?

 

[HardwareHighlander]

Da hat jemand Langeweile und Geltungsdrang und spricht am Ende mit sich selbst, das müsste man eigentlich konsequent melden. Doppelaccounts sind verboten.

 

[Grestorn]

Castello / BraveNeo

Zwei aufeinanderfolgende logische Kerne (also 0 und1, 2 und 3, 4 und 5 usw.) gehören immer zu einem physischen Kern, zumindest ist das unter Windows so unter allen mir bekannten Prozessoren. und wie öfter geschrieben, gibt es unter Windows (und jedem anderen modernen OS) API Funktionen, um genau dieses Layout (also die Zuordnung von logischen zu physischen Kernen), abzufragen, wenn man sich nicht auf diese Konvention verlassen will.

 

[Grestorn]

Doppelposting

 

[BraveNeo]

Zwei aufeinanderfolgende logische Kerne (also 0 und1, 2 und 3, 4 und 5 usw.) gehören immer zu einem physischen Kern, zumindest ist das unter Windows so unter allen mir bekannten Prozessoren.

????

API welche soll das sein? Windows ordnet alle logischen Prozessoren einer node zu (CPU Sockelanzahl), die bei einem Einsockelsystem derzeit eine Verwaltung von bis zu 64 logische Prozessoren pro Sockel zulässt.

Der Binärcode für node 0 1f (end) 0000 0000 1111 1111 (begin) bedeutet in dem Fall nicht, dass du festlegst, welcher der logischen Prozessoren den Thread zugewiesen bekommt, wobei du jeden Thread einem logischen Prozessor zuweisen müsstest. Den Quatsch glaubst du doch selbst nicht. Das AMD das SMT Modell mit Zen 2.0 änderte und intern erst alle Cores, also damit auch die logischen Prozessoren eines Chiplets anspricht ist bekannt. Früher hat man die Threads aus Effizienzgründen weit voneinander über die CCX verteilt, um die Arbeitsdichte auf einzelnen CCX zu verringern, was heuer nicht mehr nötig ist. Das dies unter Windows und auf Softwareebene Anpassungen benötigt haben sie mitgeteilt. Viel einfacher ist es daher /affinity 1f und damit alle unter node0 maskierten logischen Prozessoren anzusprechen.

Dazu gehörige Links findet man mit einem Klick.
en.wikichip.org/wiki/amd/microarchitectures/zen
developer.amd.com/wordpres/media/2013/12/55723_SOG_FAM_17h_Processor_3.00.pdf

Das SMT Recouresharing wird dort abgebildet und über WMCI fragt man Device ID, NumberofCore, NumberofLogicalProcessor ab. Eine Zuordnung wird dort nicht vorgenommen. Dort gibt es weder virtuelle Kerne noch wird dort etwas anderes angezeigt als im Taskmanager, wobei man unter diesem auch die Threadanzahl der gestarteten Prozesse einsehen kann. Vom Außerkraftsetzen lokaler Richtlinien, die die maximale Auslastung der CPU durch Apps festlegen, wird klar abgeraten und dies ist nur mit administrativen Zugriff möglich. Keine API überschreibt dort lokale Gruppenrichtlinie. Die dauerhafte Übernahme administrativer Änderungen ist erst ab bestimmten Windows Versionen möglich. Genauso wie die feste Zuweisung logischer Prozessoren auf Serverversionen. Im Taskmanager unter Affinität das Profil Echtzeit auszuwählen, kann bei deaktivieren Gamemode zu einem Absturz führen, wenn Hintergrundprozesse wie zum Beispiel ein einfaches Windowsupdate oder eine Virenprüfung nicht ausreichend Ressourcen zur Verfügung stehen.

Es reicht also bei ressourcenlastigen Spielen völlig aus, den Windows 10 Gamemode zu aktivieren, weil dann dem Spiel die höchste Priorität zugeordnet wird und Hintergrundprozesse automatisch eine niedrigere Priorität erhalten oder für die Spieldauer komplett pausieren.

 

[Grestorn]

????

API welche soll das sein? Windows ordnet alle logischen Prozessoren einer node zu (CPU Sockelanzahl), die bei einem Einsockelsystem derzeit eine Verwaltung von bis zu 64 logische Prozessoren pro Sockel zulässt.

Ihr lest nicht. Ich hab die nun schon zweimal verlinkt. Da kommt man sich schon etwas veräppelt vor. Ich verlinke die Doku ja nicht zum Spaß, sondern um etwas zu vermitteln und meinen Text zu untermauern:

Hier das dritte mal: LOGICAL_PROCESSOR_RELATIONSHIP (winnt.h) - Win32 apps | Microsoft Docs

Und dann fängst Du erneut von "Prioritäten" an, die überhaupt nicht das Thema sind. Es geht darum, dass SMT Nachteile mit sich bringen kann, und das hat nichts mit Game-Modus oder Prios zu tun, sondern einfach mit der Tatsache, dass sich Threads auf dem selben physischen Kern in verschiedenen logischen Kernen gegenseitig ausbremsen können.

 

[gastello]

Und dann fängst Du erneut von "Prioritäten" an, die überhaupt nicht das Thema sind. Es geht darum, dass SMT Nachteile mit sich bringen kann, und das hat nichts mit Game-Modus oder Prios zu tun, sondern einfach mit der Tatsache, dass sich Threads auf dem selben physischen Kern in verschiedenen logischen Kernen gegenseitig ausbremsen können.

Prozessoraffinität und Threadpriorität stehen aber im direkten Zusammenhang. Du sprichst immer wieder eine Intel HT Core Topologie- und Threadpaarung an (mit dazugehöriger Siblinglist). Um festzustellen welche physischen Kerne oder logischen Prozessoren für deine Threads deaktiviert werden sollen - mußt Du erst die Threads identifizieren - die auf demselben CPU-Kern ausgeführt werden sollen. Wie willst Du das denn unter Windows feststellen? Dann müsstest Du ja jede Konfiguration kennen? Unter deinem Link kannst Du die Threads dem Prozessor auch komplett zuweisen. In dem Fall kann es passieren - das Du die hohe Prozessorauslastung mit deinem Pinning dann selbst verursachst. Die Affinitätsmaske lässt sich auch dynamisch steuern - das versuche ich Dir seit mehreren Beiträgen zu vermitteln. Für das deaktivieren bekannter Affinitätsmasken - mußt Du die komplette Zeitplanung neu schreiben. Das ist doch überhaupt nicht nötig, wenn genug Kerne vorhanden sind. Windows verteilt ja nicht stur die Threads an einen physischen Kern und seinen logischen Prozessoren. Das ist doch die Aufgabe des Shedulers und der internen Arbitrierung.

AMD hat bei Zen 1 und 2 Teile der dazugehörigen Pipeline dupliziert - das ist nicht virtuell sondern in Hardware gegossen. Unter Zen 3 dann die Cache und die Register erweitert. Den Micro-Op angepasst - was alles dann fast drei mal so groß wie Intels ist.

 

[Grestorn]

Prozessoraffinität und Threadpriorität stehen aber im direkten Zusammenhang.

Nicht, wenn man von durch SMT erzeugte Performance-Nachteile spricht, nein.


Zum Rest: Du gehst die Sache genau verkehrt herum an. Ich muss nicht analysieren, wie die Threads gerade auf einem System verteilt werden. Sondern ich muss als Entwickler nur mein Spiel kennen. Wenn ich weiß, dass ich z.B. 2 Threads habe, die wirklich kritisch sind und deren Laufzeit zu einem ein CPU Limit führen können, dann will ich doch so optimieren, dass diese beiden Threads möglichst performant laufen. Dazu würde ich wie folgt vorgehen:

1. Topologie des aktuellen Rechners abfragen. Das folgende Beispiel geht davon aus, dass immer zwei aufeinanderfolgende logische Kerne auf einem echten Kern laufen.
2. Wenn der Rechner 6 oder mehr echte(!) Kerne hat und SMT eingeschaltet ist, dann optimiere ich das Spiel wie folgt:
- Den ersten Thread (Main Thread) per Affinity Mask 000000000001 auf den ersten echten Kern festnageln
- Den zweiten Thread (der auch noch krititisch ist) per Mask 000000000100 auf den zweiten echten Kern festnageln
- Wenn mein Spiel gut mit SMT zurecht kommt, kann ich die anderen Threads dann auf die restlichen virtuellen Kerne verteilen mit 111111110000
- Wenn mein Spiel mit SMT langsamer wird und ich nicht so viele Threads habe, dann kann ich SMT für mein Spiel praktisch ausschalten, in dem ich die Maske 010101010000 nutze.
3. Wenn der Rechner nur 4 oder weniger Kerne hat, wird das entsprechend anders aussehen, aber das Prinzip ist ähnlich.

Wenn meine Engine so modern ist, dass weder einzelne Threads herausragend kritisch sind oder die Engine problemlos mit SMT harmoniert, dann brauche ich das alles freilich nicht. Die Realität zeigt aber, dass es sauschwer ist, das für Spiele hinzubekommen. Und wenn die Leute danach schreien "Ich will SMT in Windows ohne Booten abschalten können", dann ist eben meine Antwort: "Wenn die Spiele-Enwtickler gleich ihr Spiel so konfigurieren, dass es auch bei eingeschalteten SMT nicht langsamer wird (und wenn es nicht anders geht, dann eben mit ThreadAffinity), dann wäre das erst gar nicht nötig!"

Wenn Du mal bei bestimmten Spielen darauf achtest, wie die logischen Prozessoren ausgelastet sind, wirst Du schnell feststellen, dass viele Spiele ihren Hauptthread tatsächlich heute schon auf Kern 0 pinnen. Das kann man sofort sehen. Bei einem Spiel, bei dem das nicht passiert, verteilt sich die Last optisch ziemlich gleichmäßig, es sieht so aus, als wäre kein Kern voll ausgelastet. Tatsächlich ist es aber so, dass der Hauptthread nur ständig von Kern zu Kern verlagert wird, seine Gesamtlaufzeit verringert sich dadurch aber nicht (er läuft ja weiterhin sequentiell, auch wenn er von Kern zu Kern verlagert wird, weil es eben nur ein einzelner Thread ist).

Wenn man den Hauptthread auf einen Kern pinned und die anderen Threads frei auf den restlichen Kernen floaten lässt, ist das für die Gesamtperformance i.d.R. deutlich besser.

 

[BraveNeo]

@gastello
Das liest sicher eher wie Erfahrungen unter einer Java Threadskalierung die ziemlich linear ausfällt. Hier werden nur Ideal Prozessoren definiert. Das Ausweichen bei manuellen Affinitätsmasken auf nicht ideale Prozessoren ist dann nicht möglich. Da HT und SMT dann wegen der höheren Verwaltung zu Leistungsverlusten führt, argumentiert er genau auf dieser Basis. Parallele Hardware braucht dann eine aufwendige manuelle Verteilung und Zuordnung.

 

[Grestorn]

Jetzt redet er schon mit sich selber...

 

[gastello]

Wenn man den Hauptthread auf einen Kern pinned und die anderen Threads frei auf den restlichen Kernen floaten lässt, ist das für die Gesamtperformance i.d.R. deutlich besser.

Ist es nicht und wer hier mit wem redet - ist noch fraglich. Es gäbe den UMS Mode und Microsoft rät davon ab - das Applikationssheduling abzuändern. Bei Nutzung der API und Set Ids bleibt im ungünstigen Fall die Anfrage an einen Kern - den Du mit deinem Pinning nicht zuordnest - unbeantwortet. Das ist doch völlig kontraproduktiv. Zen hat ausreichend Kerne und Intel auch.

Ich weiß ehrlich nicht was Du in diesem Zusammenhang für ein Theater um SMT oder HT unter Spielen veranstaltest. Es gibt genug Spiele die davon profitieren und Spiele die es nicht tun. Im Mittel gehts da 50/50 zu. Ich würde es derzeit aus Sicherheitsgründen deaktivieren, wobei AMD da Vorteile hat. Wer keine 4C/8T im Rechner hat - muß es eingeschaltet lassen - weil das sonst einen Haufen Performance kostet. Zwischendurch kommst Du noch mit deinem Pinning.

Kritische User-Threads haben mit dem Wert 31 die höchste Priorität laut Windows Sheduler (erzähl hier bitte nicht das dies mit der Affinität nichts zu tun hätte). Dieser verteilt diese User-Threads nicht auf gleiche Kerne und auch nicht auf logische Prozessoren auf einem Kern. Sollte ein kritischer Kernel-Thread dazwischen funken, wird dieser so lange wie möglich zurückgestellt. Du hast altbackene Ansichten. Dann mußt man die dazugehörige API überarbeiten. Wenn Du den Hauptthread an einen Kern pinnst - brauchst Du keine Multitasking fähige CPU. Das machen heute die wenigsten - nicht mal mehr auf Konsolen - warum immer Du meinst das sei gefälligst allgemein. Der Großteil geht dazu über - zu nutzen was einem die IHVs und Mircosoft/KhronosGroup usw. mittlerweile hardwarenah bieten. Dann gehörst Du eben nicht dazu.

 

[Grestorn]

Sagt der, der noch nicht mal meine Beiträge überhaupt liest. Und Da Du Deine Ansicht auch nicht weiter begründest ist hier EOD für mich.

Das Theater ist übrigens nur daraus entstanden, dass sich hier einige gewünscht haben, man könne SMT on the fly in Windows abschalten. Darauf hin habe ich nur geschrieben, dass das gar nicht nötig wäre, wenn die Spiele SMT korrekt berücksichtigen würde und beschrieben, wie das geht. Und wie gesagt, es machen ja offensichtlich auch genügend Spiele.

Dass Du schon wieder mit Priority kommst, beweist nur, dass Du überhaupt nicht verstanden hast, worum es geht.

So, jetzt reichts.

 

[BraveNeo]

Aber du sicherlich.

Du kannst nicht mal virtuell, logisch und physisch auseinanderhalten!

Ist ja auch normal bei Typen wie dir, obwohl man dir dieses Geschwafel schon zu oft in anderen Foren um die Ohren gehauen hat. In jedem zweiten Satz schreibt du das dir als Softwareentwickler eine 4C CPU reicht. Mach dir nichts draus, aber der typische grestorn wird sich nie ändern und nur weil er glaubt hier sind nur Idioten unterwegs muss nicht stimmen was er denkt, glaubt und meint. Wie oft er dabei betont Softwareentwickler zu sein ist schon fast lächerlich. Man kann es nicht mehr zählen. Zuweilen kommt da nur provokanter Quark. Einfach ignorieren.

Beispiel: News - UserBenchmark: AEnderung des CPU Speed Index sorgt fuer viel Kritik| Seite 31 | ComputerBase Forum

Ja toll....

Du kommst mir vor wie schaffe89 der immer wenn er etwas geliefert bekommt schnell nachliest und dann irgendein Haar in der Suppe findet über das er herfällt. Früher war sowieso alles besser. Was du verlinkt hast ist eigentlich schon gelöst wenn du dir die Mühe machen würdest mal etwas weiter zu klicken. Nur genau das willst du nicht.

EoD besser ist es auch!

 

[Grestorn]

Nice try

 

[gastello]

Nice try

Ich habe mir jetzt die Mühe gemacht - nachzustellen was ich schon geschrieben habe. Der Sheduler funktioniert wie er soll. Erst wenn keine physischen Core mehr verfügbar sind - fängt er an logische Prozessoren zu beschicken (dazu habe ich ein Coreparking erzwungen - was AMD anfänglich auch wegen fehlerhafter P-States und Problemen beim HPET-QPC/TSC-Synchronisationsmodus plagte). Es lag also nie an SMT selbst.

Die Profile und Kernauslastung sind jeweils von dem Energieprofil unter Windows 10 abhängig. Man kann bei einem 8 Core also SMT getrost aktiviert lassen, weil die Spiele die SMT nicht unterstützen darunter auch nicht leiden. Wenn sie es unterstützen - ist es wichtig ein passendes Energieprofil auszuwählen.

Du kannst gerne das Gegenteil beweisen. Kern 0-2 werden im Idle von Windows beansprucht (ich habe die Kern-Topologie extra berücksichtig) - unter SMT dann Kern 0-2-4. Die Auslastung Windows+Game subsumiert sich daher. Insgesamt war die CPU zu 60% ausgelastet. Spiel in 1080p. Kein Corepinning und Gamemode off.



Einen 6C/12T habe ich leider nicht hier. Ich glaube aber das es auch dort kaum relevant ist.

SMT dient ja in erster Linie dazu Energie zu sparen - weil die Kerne weniger hoch getaktet aber effizienter ausgelastet werden und höher getaktete Kerne viel Energie benötigen.

 

[Grestorn]

Das ist doch gar nicht der Punkt. Natürlich werden die virtuellen Kerne erst genutzt, wenn es keine freien physischen mehr gibt. Windows kann das, seit es SMT-aware ist. Also irgendein XP glaub ich.

Wenn ein Spiel genügend Threads hat, hilft das nur nicht.

Beantworte doch eine Frage: Wieso hat SMT bei einigen Spielen einen negativen Effekt?

Ne lass mal. Ich sagte EOD und sollte es dabei belassen.

 

[HardwareHighlander]

Beantworte doch eine Frage: Wieso hat SMT bei einigen Spielen einen negativen Effekt?

Es gibt Spiele die mit SMT on, trotz aktuellem Windows 10 derbe einbrechen, weil Last fälschlicherweise auf die logischen Prozessorkerne gelegt wird, sheduler hin oder her, das lässt sich wunderbar in Spielen mit dem Afterburner beobachten.
Es kann aber auch sein, dass der Verwaltungsaufwand für die CPU steigt, wenn SMT aktiviert ist und somit im Mittel 3% Leistung kostet, teilweise ist das wie schon gesagt aber deutlich mehr , Kommunikation über die IF außerhalb eines CCX hin oder her.

SMT kann aber auch massiv helfen, etwa in RDR2. Das Spiel ist auf allen Prozessoren ohne SMT unspielbar, es sei denn man besitzt 8 Kerne, hier merkt man die Konsolenoptimierung.
6c6t führen bereits zu massiven Einbrüchen.

 

[gastello]

Und wieso hat es bei einigen Spielen keinen negativen Effekt? Frage dich mal ob das an Optimierungen des Compilers liegt. Es werden keine kritischen Threads an logische Prozessen auf einem Kern in Folge zugeteilt.

Unter AMDs SMT werden die Threads trotz Dublizierung - NACHEINANDER - ausgeführt - weil SMT nicht HT ist und es replicated, partitioned und shared gibt.

Es gibt Spiele die mit SMT on, trotz aktuellem Windows 10 derbe einbrechen, weil Last fälschlicherweise auf die logischen Prozessorkerne gelegt wird, sheduler hin oder her.

Was sind fehlerhafte P-States bei Dir? Und wieso sollte der Sheduler richtig funktionieren wenn er bei freien physischen Kernen logische Prozessoren beschickt? Das Windows HPET konnte vorher nicht mit der hohen Anzahl an Kernen umgehen.

Was ich grestorn mit seine Core0-Pinning aufzeigen will ist - das er die kritischen Kernel-Threads mit seinem Pinning auf andere Kerne verdrängt und wenn schon 6c/6t nicht reichen - tun sie es dann bei 3 Kernen die Windows sich genehmigt schon lange nicht mehr. Wenn ein Windowsdienst an einen Kern gepinnt ist - was der Fall zu sein scheint (0/1/2, 0/2/4) dann wird dieser Thread auch nicht bearbeitet - er wird unbeantwortet abgewiesen und muss warten - der Kern ist diesem Dienst dann nicht mehr zugewiesen.

Du kannst dazu im Taskmanager einfach auf die jeweilige .exe klicken und die Warteschlange abfragen.

 

[Ion]

6c6t führen bereits zu massiven Einbrüchen.

"Massive" Einbrüche würde ich anders beschreiben, allerdings gebe ich dir in Teilen recht, dass RDR2 erst ab einem flotten Hexa- respektive Octacore Spaß macht.
Ein 8700K beispielsweise hat außerhalb vom Gammelram, wie du es so gerne beschreibst Schaffe, mit etwas mehr Takt noch genügend Dampf für (alle) aktuelle Spiele.

 

[gastello]

Ein 8700K beispielsweise hat außerhalb vom Gammelram, wie du es so gerne beschreibst Schaffe, mit etwas mehr Takt noch genügend Dampf für (alle) aktuelle Spiele.

Das ist eine reine Erfindung von ihm selbst. Zwischen 2666 und 3200 gibt es kaum messbare Unterschiede. Intel hängt überhaupt nicht am Ramtakt. Das kann nur bei speicherlastigen Anwendungen vom Vorteil sein. 0,5ms da ist drauf gesch***en. Wobei der 2666 auch mal schneller sein kann.

YouTube

Der Vorteil ist das 3200 eher billiger ausfällt - weil er mittlerweile zum Standard geworden ist. Dann kann man auch den kaufen.