Test AMD-Ryzen-Benchmarks: Spiele unter Windows 7, Core Parking und HPET analysiert

[(_LoCuTuS_)]

Sehr interessant die bisherige Entwicklung. Ohne dafür einen Beweis zu haben glaube ich dass AMD wahrscheinlich wieder mit Ryzen 2 (oder +) eine rundere CPU abliefern wird. Man denke nur an etliche vorherige Generationen.

Offtopic:
Greife mal die Frage eines anderen Forenmitglieds auf:
Wann soll es (endlich) mal Board Tests geben?
Mir ist durchaus klar dass es Lieferengpässe gibt, aber man findet ja im gesamten Netz quasi nix.
Würde gerne mal ein B350 (z.B. Das ASRock AB 350 Pro 4) gegen eine x370 Platine sehen, vorallem was bei einem 1700er an OC möglich ist.

 

[Krautmaster]

Die Frage ist ob es möglich ist dass MS dem Scheduler das Hirn mitzugeben das folgendes unterscheidet:

Bis zu 8 Threads die viel miteinander "reden" und über den Cache kommunizieren:
-> lege sie auf ein CCX
-> widerspricht eigentlich dem klassischen MST Sheduling

Bis zu 8 Threads die für sich eigenständige Aufgaben lösen (zb viele Benchmarks / Rendering use):
-> lege 4 Threads auf die 4 physical Core auf CCX 1 und die anderen 4 Threads auf je einen physical Core auf CCX2


Die DIE zeigt das Problem ja auch gut:

Bei Intel kleben alle Kerne beieinander. Die Kern zu Kern Kommunikation über den Cache ist bei allen 10 Kernen gleich schnell, aber etwas langsamer als bei AMDs Kern zu Kern Kommunikation innerhalb eines CCX.

Kommuniziert man aber CCX übergreifend wirds bei AMD deutlich träger, was in Einzelfall wohl die Performance einbrechen lässt.


Was kann man also tun?

-> Windows Sheduling so aufbohren dass es sieht "okay is schneller wenn ich diese Threads auf einen CCX lege" -> dynamisches optimizen.
-> In der Anwendung - wenn ich weiß ich rede viel von Thread zu Thread -> explizit diese auf einen CCX zuweisen, auch wenn ich >4 Threads brauche was man eigentlich auf alle physikalischen Kerne verteilen würde

 

[Taxxor]

Sehe auch kein Problem in der Umsetzung, wenn der Scheduler weiß, dass CPU 0-7 im ersten CCX liegen und dahingehend angepasst wird, möglichst die Daten innerhalb dieser CPUs zu belassen und gleichzeitig voranging CPU 0, 2, 4 und 6 auszulasten.

 

[Krautmaster]

Woher die Gewissheit? Der Scheduler müsste nur einen vorgefertigten Zahlencode von der jeweiligen Software genannt bekommen um zu wissen wie er diese ideal behandelt. Der kann dabei dumm bleiben wie er will.

keine Gewissheit, nur müsste nun von jetzt auf nachher jeder Programmierer bei den Threads noch mitgeben müssen ob es innerhalb eines CCX Sinn macht oder nicht - was in der Praxis sicher selten umgesetzt wird.

Die Frage ist eher ob das Windows irgendwie "erkennen" kann und dann das zur Laufzeit optimiert. Also das Scheduling agil gestaltet.

 

[duskstalker]

Mag ja alles sein, aber das kann auch leicht überprüft werden:

1. Ryzen mit langsamen RAM vs. Ryzen mit schnellem RAM.
Das müsste, anders als bei intel, viel größere Auswirkungen haben.

2. Ryzen auf 1 CCX beschränken und nur 4 Cores verwenden
Dann "müsste" die Performance bei Spielen, die z. B. nur 4 Kerne nutzen, nach oben gehen.
Damit wäre dann belegt, dass es an der Verteilung liegt und das kann aber wieder vom Scheduler von Windows beeinflusst werden.

https://www.youtube.com/watch?v=DQilK2dOJTg

1 ccx ohne smt vs "volle" ryzen cpu.

 

[v_ossi]

Hier z.B.Anhang anzeigen 612341

Und auch in Witcher 3 liegt ein i5 7400 an der Spitze

Wenn alle CPUs schnell sind, ist dann überhaupt ein Baum umgefallen. Entschuldige bitte, aber das Beispiel ist einfach nur lächerlich. Da sind doch offensichtlich alle CPUs entweder im Grafikkarten Limit oder es ist aus welchem Grund auch immer egal, was man verwendet. Das ernsthaft als Argument zu benutzen...

 

[valnar77]

@ Krautmaster
Exakt so!

Die Frage ist, ob die Spiele Desinger nicht einfach so die CPU-Affinität binden können, und es entsprechend tun, je nach zurück gemeldeter CPU-ID.
Der Nachteil ist natürlich, dass dies von jeder Enginge gemacht werden müsste.

 

[Krautmaster]

Sehe auch kein Problem in der Umsetzung, wenn der Scheduler weiß, dass CPU 0-7 im ersten CCX liegen und dahingehend angepasst wird, möglichst die Daten innerhalb dieser CPUs zu belassen und gleichzeitig voranging CPU 0, 2, 4 und 6 auszulasten.

Bisher konnte der Scheduler rein nach der Anzahl gehen. Hast du 8 Threads war es in JEDEM FALL schneller diese auf die 8 physikalischen Kerne zu verteilen da bei den Intel CPU es vollkommen irrelevant ist ob bei 3 Threads CPU 0, 2 , 4 oder 4 6 8 belastet wird. (solange die Zuweisung auf physikalische Kerne erfolgt)

Bei AMD passt die Zuordnung auch - nur dass je nach "Arbeit im Thread" - was der Sheduler kaum wissen kann, der letzte Fall (4 6 8) zu Problemen führen würde, da die 4 in CCX 1 liegt und 6 / 8 in CCX 2. Und dann können diese Threads nur langsamer miteinander kommunizieren als wenn sie gemeinsam dem CCX1 zugewiesen würden, also zb 0 2 4 (sofern das die physikalischen Kerne sind).

 

[cruse]

Ich bin alt weil ich es erinnern kann

seht her ich bin alt

 

[Taxxor]

@v_ossi: Wieso? Wenn das Spiel nur 4 Threads voll nutzen kann liegt der i3 mit seinem hohen Takt natürlich vorne.

Und die min fps liegen beim i3 bei 143, beim i7 bei 134, 7% höher, es hat also nichts mit einem GPU Limit zu tun.

 

[flappes]

https://www.youtube.com/watch?v=DQilK2dOJTg

1 ccx ohne smt vs "volle" ryzen cpu.

Kann man aber schlecht vergleichen, in beiden Fällen hätte SMT aus sein müssen, damit man ein CCX-Kommunikationsproblem ausschließen hätte können.

Im schlimmsten Fall dürfte es bei den FPS kaum Unterschiede geben, wenn es Spiele sind, die nur 4 Kerne benutzen.
Im besten Fall müsste der 4C schneller sein, da CCX-Wechsel entfällt, was er aber anscheinend nicht ist.

 

[Ap2000]

Keine Sorge: Wenn die Core Parking können, brauchen die auch keine Säge um sie zu deaktivieren.

Warum Sorge?

 

[aldaric]

Entschuldige bitte, aber das Beispiel ist einfach nur lächerlich. Da sind doch offensichtlich alle CPUs entweder im Grafikkarten Limit oder es ist aus welchem Grund auch immer egal, was man verwendet. Das ernsthaft als Argument zu benutzen...

Den Thread verfolgt? Es ging ihm darum, dass einige meinten das ein 4-Kerner in Spielen keinen 8-Kerner schlagen dürfen. Was natürlich quatsch ist. Zusätzlich hat hier sogar einer mit Indie-Spielen angefangen welche nur einen Kern nutzen, diese wären ja die Zukunft des Gamings...

 

[Taxxor]

@flappes: Deus Ex scheint doch enorm von reinen 4 Kernen gegenüber 8/16 zu profitieren, wenn auch als einziges Spiel.

Und ein CCX Kommunikationsproblem hättest du auch wenn du mit 8/8 arbeitest, da die physischen Kerne ja trotzdem auf 2 CCX sitzen.

 

[Ned Flanders]

Die Frage ist eher ob das Windows irgendwie "erkennen" kann und dann das zur Laufzeit optimiert. Also das Scheduling agil gestaltet.

Ja schön wärs natuerlich, aber der Scheduler hat ja keine einsicht in die Performance die er produziert. Am einfachsten ist wie gesagt wenn Software X for release mit 10 von AMD vorgefertigten Schemen gebenched wird und dann einfach einen Tag erhält der dem Scheduler sagt wie es Software X handelt. Es gibt da ja nicht beliebig viele Möglichkeiten.

Eventuell kann man sowas auch in einen Compiler einbringen.

Also 0 Hoffnung und unmöglich ist etwas überstürzt und übertrieben. Außerdem stellt sich ja gerade raus das die CPU Rangliste in Spielen und der Ryzen Test was Spiele angeht Makulatur sind. Das ganze kann bei DDR4 3200MHz-4000MHz und ausgeschaltetem Core Parking auch einfach ein sehr selten auftretendes Problem sein. Leider sagen sie in dem Video ja nicht mit welchem RAM Takt sie die Latenzen gemessen haben.

 

[Krautmaster]

Ich kenne mich nicht mit dem Windows Sheduler aus. Wenn der wirklich smart genug für diese CCX Thematik ist, dann kann man in Einzelfällen wirklich auch ohne Zutun der Software Entwickler Performance Gain sehen.

Dazu muss er eben wirklich zur Laufzeit erkennen welche Threads man entgegen der SMT Thematik doch lieber innerhalb eines CCX platziert und welche nicht.

Wir sprechen hier aber wie gesagt von Einzelfällen da das Problem beim 8 Kerner ja nur relevant wird, wenn man mehr als 4 Threads belastet - also der Sheduler vor der Wahl steht "Pack ich die weiteren zb 2 Threads besser mit auf die SMT Kerne oder besser in das weitere CCX".

 

[duskstalker]

Kann man aber schlecht vergleichen, in beiden Fällen hätte SMT aus sein müssen, damit am ein CCX-Kommunikatinosproblem ausschließen hätte können.

Im schlimmsten Fall dürfte es bei den FPS kaum Unterschiede geben, wenn es Spiele sind, die nur 4 Kerne benutzen.
Im besten Fall müsste der 4C schneller sein, was er aber anscheinend nicht ist.

???? hast du das video auch angeschaut?

wieso hätte smt aus sein müssen für CCX? ob mit oder ohne smt, immer 50% der kerne/threads sind im anderen ccx. und weil win10 wahllos verteilt, macht das auch keinen großen unterschied.

in deus ex und in doom ist der 4c/4t deutlich (!) schneller, was wohl daran liegt, dass in diesen spielen die threads miteinander kommunizieren, und da nicht der infinity fabric im weg steht, außerdem gibts keinen platz um "balancen", weil alle threads auf 100% laufen. soweit mal die theorie.

die anderen spiele ziehen halt wenigstens n bisschen nutzen aus der 4-fachen threadanzahl, was den nachteil der inter ccx kommunikation scheinbar mehr als aufwiegt.

 

[VikingGe]

Die Frage ist eher ob das Windows irgendwie "erkennen" kann und dann das zur Laufzeit optimiert.

Geht bestimmt irgendwie, wenn man sich dabei auf OS-gestützte Locking-Primitiven beschränkt, die Frage ist nur, ob der zusätzliche Overhead das rechtfertigt.

Bei Thread Pools muss die Anwendung am besten selbst zusehen, dass sie ihre Worker-Threads selbst an einzelne Kerne pinnt und das Scheduling ihrer Jobs selbst übernimmt. Das ist kein Hexenwerk, erfordert aber natürlich Anpassungen an die jeweilige CPU-Topologie, und dürfte spätestens dann für Probleme sorgen, wenn noch ein paar Fixed-Purpose-Threads mitlaufen. Ich hab selbst noch Code rumfliegen, der entsprechende Anpassungen gut gebrauchen könnte.

 

[flappes]

Und ein CCX Kommunikationsproblem hättest du auch wenn du mit 8/8 arbeitest, da die physischen Kerne ja trotzdem auf 2 CCX sitzen.

Genau, darum ginge es mir ja, dann könnte man genau feststellen ob es ein CCX-Problem ist.
Wenn ein Spiel auf max 4 Kerne festgelegt ist, dann könnte man prüfen ob der Scheduler falsch verteilt und damit die CCX-Zeitspanne das Problem ist.

Ich bin mir ziemlich sicher, dass Microsoft nun an einem etwas intelligenterem Scheduler arbeiten wird, der kommt natürlich nicht nächste Woche raus. Ich glaube nämlich nicht, dass man sich auf die Anwendungssoftware verlassen wird, dass die dem Betriebssystem mitteilen sollen, welche Verteilung sie gerne hätte.

Wie gesagt, alles unter der Annahme, dass dies wirklich die Probleme sind, aber logisch wäre es.

 

[Krautmaster]

@Ozzy83

naja, Ryzen wird dadurch kein Stück langsamer. Im Gegenteil. Ich würde den 1700 jeder Zeit dem i7 vorziehen da er manchmal in wenigen Spielen vielleicht irrelevante 10% langsamer ist (was mit der Zeit weniger werden wird) - bei arbeitsintensiven Sachen aber locker mal 30-80% Mehrleistung hab. Je nach Anwendung.

Der 4 Kern Ryzen mit vermutliche einem CCX wird das "Problem" eh nicht haben.