Ganz stark vereinfacht und verallgemeinert:
Vier Jahre. Und damit alles andere als aussagekräftig. Ich weiß nicht mehr, was ich dir vor vier Jahren gesagt hatte, aber womöglich, dass wir nach Spec testen und derlei experimentelle Optimierung höchstens in Tuning-Specials anwenden. Damals hat das CPU-Tuning aber noch Stephan gemacht. Das ist heute anders, denn ich habe hier das Zepter übernommen. Da ich derzeit jedoch einen 9950X3D optimiere und dort das Deaktivieren von CCD1 zu Problemen führt, werde ich das nicht ohne Weiteres testen können. Da AMD aber vermutlich weiter am CCD-Aufbau festhält, wird das Thema mit Zen 6 eine Renaissance erfahren.
Das l,iegt aber auch schon Jahre zurück das sowas passiert ist. Mittlerweile können ja alle Engines super mit SMT/HT umgehen und dies zu deaktivieren ist eher weniger clever.
Nun Intel hat je nach Spiel eigene Probleme mit ihren P/E cores und dem sheduling
Hatte, nicht hat. Anfänglich gab es Schwierigkeiten bei Alder Lake (weil Hybrid neu war) und ebenso anfänglich bei Arrow Lake, weil Intel die P- und E-Cores durch den Tile-Aufbau durcheinander gebracht hat. Aber wenige Monate nach dem Launch war das gegessen. Bei AMD hingegen kann man automatisch davon ausgehen, dass jedes neue Spiel erst einmal auf dem falschen CCD landet. Das ist das, was mich stört. Falls Intel jemals "3D-Cache" CPUs hat, werde ich AMD wohl den Rücken kehren, sollten sie nicht bald eine bessere Lösung in petto haben.
Immerhin werden es ja bei AMD schon mehr Kerne pro CCD also die CCD´s größer.
Wo ist eigentlich die Bestätigung dafür?Immerhin werden es ja bei AMD schon mehr Kerne pro CCD also die CCD´s größer.
Die Probleme würden sich durch einen "Thread Director", wie Intel ihn nutzt, auch bei AMD mit 8-Core-CCD in Luft auflösen.
Habt ihr das nicht in den letzten Wochen und Monaten immer geschrieben?Wo ist eigentlich die Bestätigung dafür?
Es gibt wohl mehrere Lösungswege.
Hmm? Wir können das logischerweise nicht selbst bestätigen. Die Berichterstattung fußt auf einem einzelnen Beitrag bei X, der schon über ein Jahr alt ist, und ist ein Gerücht. Nicht mehr.Habt ihr das nicht in den letzten Wochen und Monaten immer geschrieben?
Die da wären?Es gibt wohl mehrere Lösungswege.
Wirklich? Das wäre schade. Ich dachte die Info wäre offiziell und gesichert.
Naja, das mit den größeren CCD und das was du geschrieben hattest. Wobei das mit dem CCD aber auch nur für den 12 Kerner gelten würde. Wenn wirklich 12 Kerne pro CCD kommen. Für den 24 Kerner nicht.
Oder mehr SMT, wie es bei der Power-Architektur gemacht wird. Power11 fährt 8-fach SMT (bzw. gibt es die SMT-8 Option seit Power8).
Wenn ein Spiel zwölf Kerne nutzen kann, kann ich mir schon vorstellen, dass sechs Kerne langsamer sind als zwölf, auch wenn da ein Kommunikationsoverhead dazukommt. Eine 1:1-Skalierung steht ja gar nicht im Raum.
So wie das aussieht, sind bei Intel alle Kerne auf einem Tile, das löst natürlich das Problem der Latenzen zwischen den Tiles. Auf lange Sicht wäre vielleicht besser, wenn AMD dieses pauschale, automatische Parken, wenn ein Spiel erkannt wird, sein lässt. Das hat jetzt zwar in den meisten Fällen zu einem besseren Ergebnis geführt, mit steigender Parallelisierung ist aber abzusehen, dass das keine Lösung bleiben wird. Da müsste es dann schon für jedes Spiel ein Profil geben, bei dem vorher getestet wurde, ob es mit einem oder zwei CCDs besser läuft und das ganze auch noch in Abhängigkeit davon, wie viele Kerne jedes CCD hat.
Doch das tut es.
Das Problem ist aber das gleiche oder zumindest sehr ähnlich, denn bei Intel gibt es ja mehr als einen Typ CPU Kern. Wenn der Thread Director also den falschen Prozess/Thread auf einen E-Kern legt, hat man nur noch die Performance von vor 5 Jahren.
Eines der Gründe, warum z.B. die Raptor Lake basierenden Xeon ohne E-Cores daherkommen. VMs und Datenbanken machen sich in die Hose, wenn auf einmal ein wilder E-Core dazukommt oder im laufenden Betrieb auf einmal von P auf E Cores gewechselt wird.
Du kannst es ja deaktivieren. Es ist übrigens ganz normal, dass ein Kern mehrere Threads bearbeitet. Du kannst ja spaßeshalber mal schauen, wie viele Threads auf deinem System so laufen und das mit der Kernzahl deiner CPU vergleichen. Mit SMT können allerdings zwei Threads gleichzeitig die Ressourcen der CPU nutzen, was den Durchsatz insgesamt erhöht. Allerdings kann es passieren, dass zwei schwere Threads auf einem Kern laufen, wodurch einer davon langsamer läuft, was wiederum eine Anwendung ausbremsen kann, wenn die Threads voneinander abhängen. Festzustellen, welche Threads schwer oder leicht sind, ist aber nicht trivial und ändert sich auch gerne mal spontan.
Das stimmt wohl.
Ist halt die Frage, ob das so viel bringt. Wenn mehrere Prozesse sich um die starken Kerne streiten, ist halt doch nicht trivial, ob es jetzt schneller wäre, da Wartezeiten inkauf oder mit einem schwächeren Kern vorlieb zu nehmen.
