lynx007 schrieb:
Unabhängig davon, macht der 3D V-Cache auch nur bei einem CCD sinn! Denn was macht der v3D Cache. Er verhindert das Daten aus über den weit entfernten IO, aus dem langsamen Ram geholt werden müssen.
Das ist so nicht vollständig richtig. Im Endeffekt puffert der Cache Daten. Das hat nicht zwingend was mit dem RAM zu tun. Das ist auch nicht nur ein Cache für das holen, sondern auch für das Ablegen.
Was noch dazu kommt, es ist keine zusätzliche Stufe wie seinerzeit der L4 Cache bei Broadwell. Sprich die Aussage, es macht nur auf einem CCD Sinn ergibt keinen Sinn, da der X3D Cache lediglich die eh vorhandenen 32MB pro CCD L3 Cache auf Faktor 3 erweitert. Das ist kein Ersatz, sondern einfach nur mehr. Entsprechen "Sinn" ergibt das natürlich überall, weil überall die selben Anforderungen gelten.
Warum AMD das im Consumer Markt primär auf einem CCD macht ist wohl viele her dem Kosten/Nutzen Faktor geschuldet. Denn mehr wie eine primäre Tätigkeit werden die wenigsten mit ihrem PC Zuhause fabrizieren.
lynx007 schrieb:
Wichtig für Gaming, wo es einen Hauptthread gibt, der auf ein einen CCD läuft. Macht also keinen Sinn den auf mehrer zu kleben!
Doch schon, der Cache bringt immer was, wenn Daten über die IF geholt werden müssen, weil er dafür sorgt, dass sie dann lokal verfügbar im CCD sind. Ob das jetzt einen gleich hohen Nutzen hat oder nicht, hängt am Ende vom Anwendungsszenario ab.
Gaming profitiert halt extrem, weil die Art und Weise der Benchmarkmessung dazu beiträgt, dass der Cache stark Punkte bringt. Man will das quasi immer nahezu gleiche möglichst oft pro Sekunde berechnen. Paradebeispiel für Cacheskalierung.
Das heißt aber nicht, dass andere Threads verteilt über mehrere CCDs nicht auch davon profitieren würden, wenn der Cache bei allen CCDs drauf wäre.
lynx007 schrieb:
Die profesionellen alternativen Threadripper wie auch Epic verfügen ja ohnehin über deutlich mehr cache (256-768mb) on die.
Die bestehen halt aus mehr CCDs was folglich zu mehr L3 Cache führt. Allerdings ist die Rechnung "falsch". Sprich das wird technisch nicht addiert. Es bleibt bei 32MB pro CCD. Im großen 128C Zen4 Epyc sind es eben 16x32MB. Der Cache sitzt zwischen RAM bzw. IF und den Cores und federt die Zugriffe über die langsame IF ab. Ein Thread, egal ob jetzt Consumer Ryzen oder TopEnd Epyc kann nur von dem Cache gepuffert werden, der ihm am nächsten liegt. Von den 512MB L3 Cache total des regulären non Huckepack Cache Epyc bleiben auch nur 32MB pro CCD. Mehr Cache wird dort hingegen trotzdem verbaut, weil der Anwendungsmix in so einem Umfeld viel viel größer ist. Wo haufenweise verschiedene Tasks parallel auf dem selben Prozessor laufen, ist auch mehr Kram dabei, was von größeren Caches profitiert. So einen riesen Trümmer kauft man in aller Regel nicht für exakt eine Aufgabe (wie Gaming), bestenfalls noch als Cloud Instanz für Remote Gaming. Dann sinds halt 16x8 Cores mit fixem Pinning der Instanzen pro CCD.
Bei den Zen5c CCDs sind es pro CCD auch 32MB, dafür aber 16 Cores pro CCD und bei 192 Cores in Total damit 384MB pro Sockel.
Packt man jetzt auf die regulären 32MB ähnlich der X3D Ryzen 64MB huckepack oben drauf, ergibt das 96MB pro CCD.
da bin ich einer der wenigen menschen die nur profitieren will. ich hab was davon, der käufer hat was davon und beide sind glücklich
