News BIOS-Updates für Ryzen: Asus' Turbo Game Mode schaltet 2. CCD und SMT ab

Ganz ehrlich, wer sich einen 16 Core X3D kauft und dann den zweiten CCD pauschal abschaltet inkl. SMT hat richtig hart einen am Sender !

Entweder benötige ich keine 16 Core X3D CPU, dann kaufe ich einen 8 Core X3D.
Oder ich benötige die CPU aus gewissen Gründen, dann schalte ich kein kompletten CCD und SMT ab.

Die 16 Core X3D CPU's sind für bestimmte Personen mit bestimmten Ansprüchen und entsprechendem Wissen und Fähigkeiten und sind meiner Meinung nach nur als Gaming CPU von Personen zu nutzen die wissen was sie machen und wie sie es machen.
Mindestens 50% der 16 Core X3D Käufer wären besser mit einer 8 Core X3D bedient gewesen aber sie wollten einfach auf die Kacke hauen und wissen dann nicht wie sie das Teil richtig nutzen.

Meiner Meinung nach gehört auf ein 16 Core X3D System ProcessLasso und dann erstellt man sich entsprechende CPU Sets/Regeln und testet entsprechend in allen Spielen/Programmen wie es am besten läuft und fügt jedes Spiel/Programm dann der entsprechenden Regel hinzu.
So holt man aus einem solchen Prozessor das maximum heraus.
Das übersteigt aber die Fähigkeiten eines normalen Nutzers was mich zu meiner Aussage von oben führt.
 
  • Gefällt mir
Reaktionen: Spawn182, Pilstrinker, SSD960 und 2 andere
Nagilum99 schrieb:
Nur dass du jetzt ausgelassen hast, dass der Scheduler nicht wissen kann ob eine Anwendung auf dem Die mit mehr Cache oder höherer Frequenz laufen soll.
Ich habe das nicht ausgelassen, das war hier nicht das Thema.

Ich habe es in anderen Threads angesprochen, wo es darum ging ob 2 CCDs mit VCache Sinn machen. Das macht viele Scheduler Hacks obsolete machen.
Ergänzung ()

Nagilum99 schrieb:
Bei Multisockel Systemen geht es um NUMA und schon lange vor allem darum die Daten im jeweils lokal angebundenen RAM zu halten.
Und auch das hast du wieder nicht verstanden. Es geht um Cache Lokalität, nicht nur um den Speicher. Und der Windows (Desktop) Scheduler glänzt auch nicht mit gutem NUMA Support (siehe Threadripper 29xx).
 
@Creeper777 Wer denkt sich sowas aus und findet, es sei eine gute Idee? WTF?😅
Die, die sowas machen wollen, brauchen diese extra Option dafür letztlich auch nicht ..

Man kann froh sein, wenn die Nutzer wissen, was das XMP Profil ist und/oder wie sie es aktivieren.
 
Was soll das? Die CPU ist, zumindest bei mir, nicht das Problem. Und ich weiß man muss es nicht aktiviert werden. Aber warum kauf ich 16 Kerne wenn ich diese wieder Reduziere? Dann gleich einen 8 Kerner!
 
  • Gefällt mir
Reaktionen: THi.DELTA und Spawn182
Was ein Käse, ihr habt doch größtenteils schon weit über 100fps, was wollt ihr denn noch?
 
  • Gefällt mir
Reaktionen: Spawn182
Erst irgendwelche "dubioses" Tests mit speziellen Treiber Windows Builds Kombinationen, damit ja 5% mehr erscheinen und dann so ein Kunstgriff um noch mal ein paar mehr FPS zu bekommen.

Am Ende geht es scheinbar nur darum in Reviews den Längsten zu haben, dass geht langsam ins Lächerliche. Als ob es noch CPU Bottlenecks unter real life Bedingungen gibt. Es gibt höchsten Programmiere, die nen Bottleneck im Hirn haben und ihre Games nicht gut coden.

Kommt weg von diesen synthetischen Benchmarks, testet wieder auf Funktion und Qualität. Support der Hersteller ist auch was nettes, aber all diese Balken-Längenvergleiche können sich auch nur die Herren der Schöpfung ausdenken.

Solang dieses "Feature" nicht per Software realisierbar ist, können sie es behalten.

THi.DELTA schrieb:
Meiner Meinung nach gehört auf ein 16 Core X3D System ProcessLasso und dann erstellt man sich entsprechende CPU Sets/Regeln und testet entsprechend in allen Spielen/Programmen wie es am besten läuft und fügt jedes Spiel/Programm dann der entsprechenden Regel hinzu.
So holt man aus einem solchen Prozessor das maximum heraus.
Das übersteigt aber die Fähigkeiten eines normalen Nutzers was mich zu meiner Aussage von oben führt.

Das habe ich ja bereits geschrieben. Die sollen lieber vernünftige Scheduler entwickeln, die auf aktuelle Prozessoren zu geschneidert sind. Dazu die passenden Tools und ne API für die Programmierer, damit die ihren Games/Apps die besten Profile zuordnen können. Hatte Cyberpunk nicht schon so einen Ansatz?

ProcessLasso wird klein Fritz und Ottonormalo überfordern.
 
Spawn182 schrieb:
Das habe ich ja bereits geschrieben. Die sollen lieber vernünftige Scheduler entwickeln, die auf aktuelle Prozessoren zu geschneidert sind. Dazu die passenden Tools und ne API für die Programmierer, damit die ihren Games/Apps die besten Profile zuordnen können. Hatte Cyberpunk nicht schon so einen Ansatz?

Ja das wäre wünschenswert, wird aber ohne das zutun der Spieleentwickler nicht funktionieren.
Wenn wirklich jeder ein Profil für den Scheduler in seinem Spiel hinterlegen würde, dann müsste es ja für jede Hardware Konfiguration ein Profil geben.
Das kann vielleicht ein großes Studio oder vielmehr Publisher leisten aber keine Indie Devs oder kleine Studios, wo es dann wieder am Nutzer selber hängen bleibt.

Spawn182 schrieb:
ProcessLasso wird klein Fritz und Ottonormalo überfordern.

Da bleibt weiter die Frage, warum klein Fritz oder der Ottonormalo überhaupt so einen Prozessor glaubt zu brauchen. Wenn einfach jeder das kauft was zu ihm passt, dann wäre damit schon viel geholfen.


Für mich bleibt es also weiterhin eine Sache wo manuell auf das jeweilige Programm/Spiel angepasst werden muss. Natürlich kann es diesbezüglich auch einfachere Programme als ProcessLasso geben.

In der Theorie sehe ich aber hier auch AMD in der Pflicht, die wollen sich ja mehr auf Software konzentrieren.
Warum also nicht diese Funktionen in den Ryzen Master integrieren oder zusätzlich eine Software anbieten von mir aus "Ryzen Gaming Tool" womit man.

  • CCD/Core Zuteilung
  • Energieprofil Wechsel
  • SMT On/Off

für jeden Prozess einzeln anlegen und automatisieren kann und das dann mit einer modernen Oberfläche.
 
  • Gefällt mir
Reaktionen: Spawn182 und Crassus88
@Spawn182

So sieht es aus, dass die ganzen "Nerds" sich mit der Balkenjagerei selbst auch teilweise die Preise in die Höhe treiben mal abgesehen.
 
  • Gefällt mir
Reaktionen: Spawn182
WinnieW2 schrieb:
Sorgt aktiviertes SMT dafür dass CPU-Kerne nicht den max. Turbotakt erreichen oder nicht?
Das ist hier offenbar der Beweggrund des Herstellers den sog. Game Turbo Mode zu implementieren. Weshalb sollte Asus das sonst machen wenn es keinen Unterschied gibt?
Das hängt davon ab, wie stark die CPU mit den SMT-Kernen ausgelastet wird. Natürlich würden mehr Kerne zu weniger Frequenz führen. Die Rechenleistung wird dadurch (höchstwahrscheinlich) höher liegen - ob das aber zu insgesammt flüssigerem Verhalten führt ist schwer zu sagen und wird stark von der Codequalität abhängen.
 
Hate01 schrieb:
Ich habe das nicht ausgelassen, das war hier nicht das Thema.
Exakt darum geht es aber: Der Scheduler kann nicht wissen ob mehr Cache oder höhere Frequenz besser für eine Anwendung ist.

Ich habe es in anderen Threads angesprochen, wo es darum ging ob 2 CCDs mit VCache Sinn machen. Das macht viele Scheduler Hacks obsolete machen.
Es gibt nunmal ein entweder-oder, dass AMD so entschieden hat, dass man ein Die zugunsten höherer Frequenzen ohne V-Cache nimmt.

Und auch das hast du wieder nicht verstanden. Es geht um Cache Lokalität, nicht nur um den Speicher. Und der Windows (Desktop) Scheduler glänzt auch nicht mit gutem NUMA Support (siehe Threadripper 29xx).
Und weil ich nichts verstanden habe, ignorierst du, dass die Cachelokalität ein hochkomplexes Thema ist und grundsätzlich nur machbar ist, wenn die Anzahl der Threads der direkt angebundnen Kernzahl nicht überschreitet. Anwendungen die NUMA-Optimiert sind und sich über mehrere Cache-Gruppen optimieren, sind sehr rar.
Ich hatte die Gelegenheit das mit einem Server (EPYC, 1. Generation) durchzutesten. Das ergebnis war: Scheiß auf Cachelokalität, der Durchsatz war erheblich langsamer, weil die Anwendungen dann auf den jeweiligen Cluster begrenzt wurden und viele Threads brach lagen.
Natürlich war das andersrum nicht optimal, aber der Durchsatz trotzdem erheblich höher.
Inzwischen steckt da die 2. Generation drin, die durch das gemeinsame IOD viel Komplexität wegnimmt.
(Und sich gezeigt hat, dass die Anwendung sehr gut auch auf mehr Kerne skaliert)
 
Hatte spaßeshalber gestern SMT bei meim 5800X3D deaktiviert.
In Helldivers2 hat mich das von 110-120fps auf 70-80fps zurück geworfen.

Kann das "Feature" nicht empfehlen^^
 
Krik schrieb:
SMT kann bis 80% Vorteil bringen bei passenden Workloads.
selbst hochoptimiert bringt SMT max 20-25% mehr. Und in der Realtität ist es immer weniger.
 
Azeron schrieb:
Kann man das nicht auch im Betriebsystem irgendwie regeln? Würde mir ziemlich auf den Nerv gehen jedes mal ins BIOS zu müssen um das umzustellen wenn sich mein Anwendungsfall ändert.

geht leider nicht.
Man kann z.B. mit Taskmanager oder Process Lasso die Kerne auswählen aber leider gibt es diverse Spiele die das gar nicht mögen.
Und MS hat leider immer noch das Problem das die echten Kerne bei genügender Anzahl nicht priorisiert werden. Allerdings gibt es genügend Spiele und Anwendungen die von SMT deutlich profitieren.
City Skylines 2 läuft mit über 400 Threads und reizt bei 2 Mio Einwohner sogar einen Threadripper 7970 zu 80-90% aus
 
mscn schrieb:
Die, die sowas machen wollen, brauchen diese extra Option dafür letztlich auch nicht ..
Doch als Hersteller kann man so Benchmarks beeinflussen und keiner kann mehr nachvollziehen, wie diese Zahlen zustande kommen. Diese Presets können auch Youtuber und Test Plattformen zugesteckt werden.
Am Ende sieht alles super toll aus. Aber eben nicht mit den Bios Tunes, die bei vielen Benchmarks nachher auch nicht mehr angesprochen werden.
 
Hatte ich wohl leider überlesen, könnte das nur auf nem 9900K versuchen nachzustellen.
@foofoobar , Ich lag mit den 1,25 beim deinem compile-Versuch gar nicht so falsch. :D
 
alexx_pcfreak schrieb:
Hatte ich wohl leider überlesen, könnte das nur auf nem 9900K versuchen nachzustellen.
Gerne, wenn du Hilfe bei der Anpassung an die Gegebenheiten deiner CPU benötigst, sagt Bescheid.
Mit
Code:
lscpu
oder
Code:
sudo true; for i in $(find /sys/devices/system/cpu/cpu[0-9]* -type f | grep -e shared_cpu_list -e /size -e /type -e freq | sort); do printf '%-70s %s\n'  $i $(sudo cat $i); done
sollten sich die IDs der verschiedenen Cores/Threads finden lassen.
 
Zurück
Oben