[...] Das sind Gaming CPUs - Keine fürs Benchen und nicht für Anwendungen [...]
Ganz so einfach ist das bei den beiden 2-CCD-CPUs nicht, da die wenigsten Games mehr als 8 Kerne benötigen und sich daran auch mittelfristig so schnell nichts ändern wird. Wenn sich also jemand für einen 12- oder 16-Kerner entscheidet muss er nicht nennenswert auf die Ressource Geld schauen oder hat noch was anderes mit der CPU vor, also bspw. die Verarbeitung irgendwelcher Productivity-Workloads und hier hinterlassen die beiden oberen Modelle einen zwiespätigen Eindruck, was schlicht in der Natur des Design begründet ist. Sehr viele Workloads können keinen nennenswerten Vorteil von dem überaus großen Cache ziehen, dagegen der zwangsweise verminderte Takt aufgrund der übereinander gestapelten Dies führt dagegen oftmals zu merklichen Leistungsminderungen.
Am Ende wird man abwarten müssen, wie Microsoft das Scheduling optimieren kann. Zum Glück für AMD haben Intel und Microsoft schon viel Vorarbeit geleistet seit 2019.
Entsprechender Cache bedeutet nicht automatisch schneller. [...]
Korrekt, das ist ein Workload-abhängiger Effekt und bspw. 3D- oder Videorendering ziehen keinen nennenswerten Vorteil aus derart übergroßen Caches, dagegen die teilweise Taktminderung macht sich sehrwohl bemerkbar.
[...] Ich bin gespannt wie die Konfiguration für den 12 Kerner ausschaut.
Vermutlich wird der 3DX-Cache an einen CCX gebunden. Somit müsste die Konfiguration fix 8 + 4 sein. Das bedeutet, dass 8-Kerne Zugriff auf den Cache haben. Daher dürfte die Performance nicht besser evtl. sogar schlechter als beim 8-Kerner sein. [...]
Da gibt es keine Spannung oder Vermutungen mehr. Selbst wenn AMD nichts explizit gesagt hätte, zeigen die CPU-Abbildungen ohne Heatspreader, dass jeweils nur ein CCD einen stacked Cache oben drauf trägt. Das bedeutet, dass ein CCD über 96 MB L3 verfügt und das andere CCD nur über die regulären on-chip 32 MB L3. Eine shared Ansteuerung von jedem CPU-Kern aus ist zudem aufgrund der Latenzprobleme bei AMDs Chipletdesign in vielen Fällen nicht angeraten, weil die Latenzen über CCD-Grenzen hinweg um über den Faktor 4 zunehmen beim regulären Zen4 (
beim X3D wird dies absehbar noch geringfügig zunehmen, da der übergroße Cache die Latenz typischerweise noch einmal erhöht auf dem stacked Die). AMD nutzt hier aus Sicht der Software genau so ein heterogenes Design wie Intel, da sich die Kernen auf den unterschiedlichen CCDs in abhängigkeit der Workloads signifikant anders verhalten werden und daher eine explizite Berücksichtigung durch den OS-Scheduler benötigen werden für optimale Performance.
Für deinen beobachteten 12-Kerner bedeutet das du hast 6 Kerne denen 96 MB L3 zur Verfügung stehen und 6 höher taktende Kernen denen nur die regulären 32 MB L3 zur Verfügung stehen werden. Entsprechend muss ein Scheduler bspw. im Gaming die primären Threads sinnvollerweise auf das stacked CCD verteilen, da man sich in diesem Workload am meisten vom Cache versprechen kann und das CCD ohne den Cache wird analog wie bei Intel die E-Cores behandelt, also für nebenläufige, kleinere Threads genutzt werden.
*) Zum Weiterdenken, warum es kein asynchrones 8+4-Layout gibt: Selbst ohne stacked Cache hätte man hierdurch schon ein asynchrones Design, das in Abhängigkeit der Software eine explizite Berücksichtigung erfordern würde (
unters. lokale Cache-Größen, Latenzen, Temp.-Hotspots, Taktraten, ...).
Zudem nicht minderrelevant wäre, dass AMD damit seinen Topchip selbst für irrelevant erklären würde, da die Unterscheide im Gaming bzgl. der beiden CPUs noch deutlich geringer ausfallen würden, wenn beide Chips mit 8 stacked cache Cores arbeiten würden.
Beim 8-Kerner muss ich die Threads nicht speziell schedulen, beim 12- [und 16-]Kerner schon. [...]
Korrekt. Hier wird man sehen, wie gut das klappt, aber wie schon gesagt, hat es AMD hier vergleichsweise einfach durch seinen späten Markteintritt. Intel und Microsoft haben das schon seit Lakefield in Arbeit und sukzessive weiterentwickelt. Die einzige Unbekannte ist, wie gut/optimal der Win-Scheduler hier arbeiten können wird ohne explizite Hardware-Informationen, denn das was Intel mit seinem TD/HDS+ seit Alder Lake implementiert hat, scheint es bei AMD nicht zu geben (oder etwas Vergleichbares, d. h. hier wird der Scheduler auf sich alleine gestellt sein *).
*) In den kommenden Jahren wird sich das weiter verbessern/vereinfachen, da Intel/Microsoft vorsehen, dass Threads zukünftig mit speziellen Flags vom Entwickler versehen werden, die explizit kennzeichnen, wie der Entwickler vorsieht, dass dieser Thread genutzt wird, d. h. hier unterstützt der SW-Entwickler direkt den Scheduler bzgl. einer sinnvollen Verteilung, aber derartige Software dürfte aktuell noch rar sein.
Vll brauche noch Agesa Updates...
Agesa-Updates haben nichts mit dem grundlegenden Design zu tun. Das stacked CCD muss derzeit fertigungs-/packagingtechnisch grundsätzlich langsamer takten i. V. z seinem non-stacked CCD, d. h. das ist ein Design-spezifisches Problem, sprich es ist ein Workload-abhängiger Kompromiss.
Ich hatte vorher ein paar Tagen, mehrfach im Forum gelesen, dass die Taktraten der neuen 3D-Modelle auch angehoben werden sollen. Aber das scheint ja dann nicht zu stimmen. Oder so minimal das es kaum auffällt?
Das "
angehoben" hängt von deiner Sichtweise ab.
Absolut gesehen und verglichen mit der Zen3-Gen, also dem 5800X3D, werden die stacked CCDs bei Zen4 höher takten, relativ gesehen werden diese jedoch signifikant niedriger takten als ihre non-stacked CCDs. Bspw. der 7700X erreicht als Peak-Takt regulär 5,4 GHz, der 7800X3D wird nur 5,0 GHz erreichen, also 400 MHz weniger. In einem Workload wie dem Gaming wird der übergroße L3 den Taktverlust deutlich überkompensieren, sodass der X3D schneller sein wird, in bspw. Workloads wie dem 3D- oder Video-Rendering wird der X3D vermutlich gar leicht langsamer als der 7700X sein.
Bei den 2-CCD-Chips wird man das Scheduling abwarten müssen, da es hier noch etwas komplizierter ist, wobei erste Benchmarks in stark MT-lastigen Workloads (
Games gehören nicht dazu) auch hier eine niedrigere Gesamtperformance skizzieren i.V.z. den regulären CPUs. Das schnelle (non-stacked) CCD wird vermutlich vergleichbar zu dem auf den regulären CPUs sein, dagegen das stacked-CCD wird im Mittel gar etwas langsamer takten als das zweite, langsamere CCD auf den regulären CPUs. Je nach Workload macht sich diese im Mittel niedrigere Gesamttaktung bemerkbar.
Im Gaming dagegen wird der L3 das überkompensieren können, da hier mit kleineren Worksets gearbeitet wird (
immer wiederkehrend pro berechnetem Frame), sodass sich der große L3 auf dem einen CCD besonders auszahlen wird.
