AW: AMD: Neue Details zu Milan, kein SMT4 für Zen 3-Prozessoren
[...]Wenn AMD SMT4 in Zen einbauen wöllte müsste sie auch die Speicherbandbreite und die Caches entsprechend vergrößern.[...]
Ja, das wäre wohl eine Konsequenz, bzw. vielleicht könnte man einen Mittelschritt gehen mit einem großen L4-HBM2E-Cache *). Entsprechende Anpassungen am Speichersubsystem waren auch in vielen Quellen bei meinen Recherchen nachzulesen, zzgl. zu Erweiterungen wie Instructionpointer, Stack, ALUs, usw.
Schlussendlich ist das Design von IBM jedoch nicht mit dem SMT-Design von Intel/AMD vergleichbar, denn letzteres steigert im wesentlichen die Effizienz/Auslastung der existierenden Funktionseinheiten. IBM dagegen hat als kleinste funktionelle Recheneinheit einen Slice definiert, der einen Thread verarbeiten kann und Einheiten für INT/FP- , Skalar- und Vektor-Operationen bietet. Die SO/SMT4-Variante kombiniert 4 Slices zu einem Rechenkern, dagegen die SU/SMT8-Variante kombiniert 8 Slices zu einem Kern und da es ersteren mit bis zu 24 und letzteren mit nur bis zu 12 Kernen gibt, kommt man am Ende für beide Varianten bei etwa 8 Mrd. Transistoren und maximal 96 parallele Threads raus. **) Im Unterschied zu Intel/AMD kommt hier also jeder hinzugenomme Thread mit einem festen Verhältnis an zusätzlichen Ausführungseinheiten daher und das erklärt natürlich, warum der POWER9 auch mit "SMT4/8" recht effizient arbeitet und eine wohldefinierte Leistung pro Thread auf die Straße bringt.
Mit einem etwas unbedarfteren Blick auf SMT in Verbindung mit x86 verstehen viele diese Art der Steigerung von Instruction Level Parallelism jedoch in der Art, dass man den Kernen einfach nur die Verwaltungsmöglichkeiten geben muss, damit sie anstatt der bisher zwei Threads bspw. auch vier Threads verwalten und differenzieren können (IP, Stack, Cache, usw.) und schon hat man mehr Leistung hinzugewonnen und genau das wird eben nicht der Fall sein. Die auf x86 beobachteten Best Case Szenarien von 20 % bis gar in Einzelfällen 30 % Durchsatzsteigerung mittels SMT2 dürfte wohl schon nahezu eine optimale/maximale Auslastung der x86-Funktionseinheiten (in realistischen Workloads) darstellen, d. h. SMT4 wird ohne zusätzliche Funktionseinheiten (ALUs/Vektoreinheiten, etc.) nur in seltenen Fällen überhaupt einige wenige Prozent zusätzlich bringen. Auf x86 müssten also die Kerne deutlich "breiter" werden ... demgegenüber ist AMD mit Zen2/Rome den anderen Weg gegangen und hat stattdessen die Kernzahl erhöht.
Zum Vergleich, weil es hier gerade passt:
IBM System S924
2 x POWER9 SU/SMT8 (je 12 Kerne, 3,4/3,9 GHz, 120 MiB L3 eDRAM)
2 x rd. 8 Mrd. Trans., 693 mm2 in 14 nm
bis zu 344 GiB/s Speicherbandbreite
SPEC 2017 CPU INTrate = 213 Punkte
AMD Epyc 7402P
1 x 7402P SMT2 (24 Kerne, 2,8/3,35 GHz, 128 MiB L3)
ca. 19,1 - 21,8 Mrd. Trans., 528 - 667 mm2 in 7 nm/14 nm (effektive Nutzung)
bis zu 205 GiB/s Speicherbandbreite
SPEC 2017 CPU INTrate = 170 Punkte
Das POWER9-System ist hier nur 25 % schneller wobei dessen deutlich höherer Takt, der doppelt so große L3-Cache sowie die deutlich höhere Speicherbandbreite zu berücksichtigen ist.
AMD hat also einen recht guten Job gemacht. (Der 12-Kerner Epyc 7272 als Dual-Socket-System taugt nicht zum Vergleich, da ein solches Dual-Socket-System auch nur 128 MiB L3 hätte und eine kumulierte Speicherbandbreite von gar nur 170 GiB/s.)
[...]denke, dass das Kernrennen im Consumerbereich sicher dort endet[...]
Wenn man Consumer wörtlich nimmt (also abseits von Spezialanwendungsfällen wie bspw. 3D-, Video- und Sound-Editing und -Rendering) endete das Rennen wohl (zumindest für die nächsten Jahre) bereits mit der Ankündigung des 3950X und dessen 16 Kernen. Desktop und Office interessiert diese Kernzahl i. d. R. grundsätzlich nicht und auch das Gaming tut sich schwer sich in diese Richtung zu bewegen und die neuen Konsolen mit ihren 8 Zen2-Kernen werden hier für die nächsten Jahre einen "natürlichen Bremsklotz" darstellen.
*) Samsung sitzt gerade daran den JESD235B-Standard vollständig umzusetzen und 12-Lagen-HBM2E zu fertigen (12 oder 24 GiB) und SK Hynix kündigte bereits 3,6 Gbps-Chips für 2020 an. Mit nur zwei Stacks wären damit bereits 48 GiB und 920 GiB/s (inkl. ECC) möglich.
**) Eine höhere Effizienz bzgl. spezifischer Workloads bleibt dennoch zu vermuten, denn ansonsten hätte sich IBM die unterschiedliche Kern-Zusammenfassung der SO- und SU-Versionen sparen können.
