News AMD Epyc: Rome mit 64 Kernen als 9‑Chip‑Prozessor enthüllt

[chithanh]

Bisher brauchte HBM allerdings immer einen Interposer, das macht es wieder teurer.

Naja, bei Kaby Lake G / Vega M reichte ein kleines Stück EMIB welches nur im Bereich des Interface zwischen GPU und HBM in das Package eingelassen war.

Auch gibt es die Möglichkeit, ganz auf einen Interposer zu verzichten (Quelle):

 

[Nixdorf]

Zu "I/O doesn't scale"

Die Medien haben hier einfach die Redner der Veranstaltung nachgeplappert und schreiben, dass die analogen Schaltkreise für I/O sich nicht so gut schrumpfen lassen wie die digitalen der CPU-Kerne. Das stimmt, aber es ist nur ein Teil der Story.

Ein weiterer Punkt ist klar: AMD hat noch das Wafer Agreement mit GlobalFoundries und muss bestimmte Abnahmemengen für 14nm-Chips erfüllen, die man mit den I/O-Dies problemlos erreicht.

Der dritte Punkt wurde aber offenbar vielfach nicht wahrgenommen. Man kann das mit dem nicht skalieren auch anders angehen: Alles, was I/O ist, hat per Definition Anschlüsse. Wenn man PCIe-Lanes und Speichercontroller in das I/O-Die packt, dann müssen die auch mit der Außenwelt kommunizieren. Und das heißt bei allem außer den Infinity-Fabric-Verbindungen, dass es mit Pins auf der Unterseite des Chips verbunden wird. Und diese Verbindungen sind verglichen mit dem Rest makroskopisch. Man kann sie nicht ähnlich beliebig verkleinern wie die Chips selbst.

Hinzu kommt die noch die Sockel-Langlebigkeit. Die Pins für die Sockel TR4 bzw. SP3 sind bereits belegt. Es bringt also wenig, wenn man im aktuellen I/O-Die mehr Lanes oder Speicherkanäle unterbringt, denn man kann sie nicht nach außen führen und für den Rest reicht 14nm einfach. Der Chip ist klein genug. Man müsste für mehr Verbindungen den Sockel wechseln. Und dann müsste sehr wahrscheinlich auch der Sockel weiter wachsen, um mehr Pins anzubieten. Dann wächst automatisch auch das Prozessor-Package, und man hat wieder mehr Platz, kann also auch einen größeren I/O-Die haben oder zwei verbauen.

 

[LawZero]

Einfach nur geil AMD.

 

[Jojo_One]

ich wusste garnicht wie nah ich im Novermber an der Warheit war :-)

 

[Rock Lee]

Irgendwie habe ich keinen passenderen Thread gefunden, also kommt es eben hier rein.
Der Release von Zen2 aka Rome/Matisse rückt immer näher. Auch wenn natürlich noch nicht alle Details bekannt sind, so ergibt sich doch ein relativ klares Bild. Maximale Kernzahl (Rome 64/Matisse 16), Anzahl der Chiplets etc. wurden gezeigt/geleakt und man brauch sich nur noch über Taktraten, Stromverbrauch und IPC den Kopf zerbrechen.

Wozu es bisher aber kaum Infos gab, ist Zen 3. Die Roadmaps zeigen lediglich, dass die 7nm+ (EUV)-Fertigung genutzt wird, sowie einen Releasezeitraum (Ende?) 2020.
Jetzt gab es in den letzten Tagen ein AdoredTV-Video mit vermeidlichen Infoschnipseln und eigenen Spekulationen, an denen ich mich ebenso beteiligen möchte.

User, die beim Hören des Namens "AdoredTV" schon Schaum vorm Mund bekommen und eh alles diskreditieren, dürfen jetzt gerne aufhören zu lesen.

Starten möchte ich aber gerne mit den Infos des bekannten Insiders "Charlie", der bereits vor Monaten den Tod von Intels 10nm Fertigung vorausgesagt hat,was sich im Desktop-Bereich anhand der neuen Roadmaps von Intel als wahr herausgestellt hat.
Die Infos stammen aus einem Investors-Call bei dem Charlie interviewed wurde.

Das meiste davon betrifft zwar Rome und Intel, dennoch sehr interessant.
Die wichtigste Info ist, dass Milan 15 Chiplets haben soll.
Jetzt rufen wir uns nochmal das Rome package in Erinnerung. Dieses hat 9 Chiplets.

Wie soll das Ganze als mit 6 weiteren Chiplets aussehen? Ist damit das Package, oder das System gemeint?
Jim zerbricht sich in den folgenden Minuten im Video darüber den Kopf, grade weil seine Quellen bezüglich der maximalen Kernzahl unterschiedliche Aussagen tätigen. Die einen sagen 64 Kerne, die anderen 80 Kerne.

Am Ende kommt er durch die offiziellen Folien zum neuen Frontier-Super Computer zu folgendem Ergebnis:

(10 * 8C CPU Chiplets + 4 GPU Chiplets + 7nm IO-Chiplet = 80 Kerne & 15 Chiplets )
Klingt erstmal logisch. Er erwähnt außerdem 2*HBM 2 Chips, die aber nicht zählen, weil es Chips aber keine Chiplets sind(!?). Aber so platzsparend ist die 7nm+-Fertigung dann doch nicht:
Das IO-Die skaliert kaum mit der neuen Fertigung, so dass vielleicht 2 weitere 8C-Chiplets aber auf keinen Fall noch weitere GPU-Chiplets auf das Package passen. Auf den Folien wird von "Radeon Instinct GPUs" gesprochen.
Ich gehe daher davon aus, dass es sich um vollwertige GPUs und nicht um Chiplets handelt, evtl. auf einem Custom Board direkt verlötet und deshalb verbunden durch die Infinity Fabric.

So und nun zu meiner Analyse
Beginnen wir mal mit einem Bezahlartikel, deren Inhalt ich nicht kenne, aber durch die Überschrift dennoch Hinweise gibt:
https://semiaccurate.com/2019/04/15/amd-to-differentiate-cores/

• AMD to differentiate cores
• it looks like AMD is going to split up their CPU designs once again

Zum einen wird davon geredet, dass AMD ihre CPU Design weiter aufspaltet.
Die Folien des Frontier Supercomputers geben durch ihr Wording bereits einen Hinweis darauf.

1. Custom coherent fabric
2. Custom AMD Epyc processor optimized for HPCa and AI

Zum anderen wird eben von einer "Differenzierung der Kerne" gesprochen. Damit verstehe ich CPU-Kerne.
Sieht man sich so ein 8-Kerne Rome-Chiplet einmal an, so sind alle Kerne homogen. Sie unterscheiden sich in ihren Spezifikationen nicht.
Wir sind mittlerweile in der Lage durch immer kleinere Fertigungstechniken 64 Kerne auf einem Package unterzubringen. Dies hat für hochparallele Anwendungen große Vorteile.
Mit Matisse erleben wir wohl 16 Kerne im Mainstream-Desktop. Wer hätte das vor 3 Jahren erwartet?
Nun ist es aber in Spielen, aber auch vielen Anwendungen der Fall, dass nicht alle Kerne genutzt werden können. Viele Benchmarks zeigen auch, dass ein 8700k schneller ist als ein 2700k, aber der 9900k von seinen 8 Kernen trotzdem in diesem Spiel profitiert und noch schneller ist als der 8700k? Woran liegt das?
Viele Spiele hängen sehr stark von Hauptthread ab, der besonders viel Singlecore-Leistung benötigt, die Intel eben durch den höheren Takt bietet.
Mehr Kerne bringen zwar ebenfalls mehr Leistung, aber eben nicht so viel wie durch die schwächere Singlecore-Leistung im Hauptthread verloren geht.

Zu Zeiten von Singlecore-Prozessoren lief es immer nach dem gleichen Schema-> Bessere Fertigung= mehr Taktpotential = mehr Platz für IPC-Erhöhungen im Sinne von Cache oder den Memory-Controller in das CPU-Die zu holen. Nur der Aufwand, um die IPC zu erhöhen, wurde mit der Zeit immer schwieriger oder aber flächenhungriger, so dass man erst Hyperthreading brachte und es dann mehr Sinn gemacht hat einen Dualcore zu fertigen mit Beispielsweise 2*2Ghz als einen Singlecore mit 1*3Ghz.
Die zunehmende Parallelisierung machte erst Singlecores und dann Dualcores nahezu überflüssig.
Aber es gibt eben auch hier Grenzen.
Wozu einen teuren 16-Kern Prozessor kaufen, wenn es auch der 6-Kerner für 150 Euro genauso gut tut? Die Kerne sind grundsätzlich die Gleichen.
Zen2 erhöht für eine bessere IPC zB auch den L3-Cache.
Könnte man mit 7nm+ und Zen3 doch auch machen?

Nun ja, 7nm+ bringt nur einen Flächenvorteil von 15% und wozu in allen Kernen den Cache erhöhen, wenn wie gesagt nicht viele Programme davon profitieren. Warum also nicht auf die Holzhammermethode verzichten und das Problem punktuell angehen?

Meine pure Spekulation daher:
Ein 5-Kerne CCX!

Dem ganz normalen CCX wird ein sogenannter "Prime Core", wir könnten ihn auch einfach "Zen X" nennen, hinzugefügt. Dieses ist ein high-clock, high-IPC Kern, welcher dies durch großen Platzbedarf auf dem Chip erreicht und den Flächenvorteil der 7nm+Fertigung mehr als zunichte macht.
Ich könnte mir vorstellen, dass dieser Kern auf jeden Fall SMT-4 spendiert bekommt. Denn je größer die einzelne Kernleistung, desto größer profitiert man prozentual gesehen auch durch SMT.

Die Kerne im CCX wären untereinander durch die Infinity Fabric verbunden und innerhalb eines Chiplets nochmal zwischen den Prime-Cores, was insgesamt 10 Kerne (2+8) innerhalb eines Chiplets ergibt.

Wenn wir bei einem Desktop-Package wie Matisse jetzt davon ausgehen, dass die Chiplets miteinander verbunden sind, würde ich sagen, dass nur die Prime-Cores jeweils untereinander verbunden sind und 4 "normale" Kerne jeweils mit den Prime-Cores.
Man hätte also insgesamt 20 (16+4) Kerne, die durch die Infinity Fabric so verbunden sind, dass egal aus welcher Betrachtungsweise eine Kommunikation zwischen 2 Kernen maximal über zwei zusätzliche Stationen läuft. Eine Chiplet-zu-Chiplet-Verbindung soll es ja schon bei Matisse geben.

Jetzt habe ich mir sowas wie "Prime Cores" nicht völlig aus den Fingern gesaugt.
Bei den Smartphone CPUs gibt es schon schon länger.
Siehe Kryo 485, dessen Pime Core höher taktet und doppelt soviel Cache besitzt.

Wenn wir nun wieder das Gerücht von 80 Kernen bei Milan aufgreifen, so brauchen wir nicht mal das Chiplet-Layout von Rome verändern: Im Gegensatz zu AdoredTVs These könnte es nicht 10*8C Chiplets sondern 8*10C-Chiplets geben. Bleiben wir mal bei der Rechnung von AdoredTV mit dem Frontier Supercomputer und nehmen das IO-Die und 4 GPUs dazu, dann haben wir 13, statt 15 Chips. Aber im Gegensatz zu AdoredTV könnte man die 2 HBM2-Chips dazurechnen und schon ist man bei 15.
Man kann sich also alles schönrechnen
Was mit den Quellen ist, die von 64 Kernen sprechen? Vielleicht braucht es für hochparallele Anwendungen keine Prime Cores und es gibt unterschiedliche Milan-Designs? Das ist in der Tat ein Widerspruch.

Ich wollte mit diesem Beispiel nur eine Möglichkeit aufzeigen, wie man aktuelle Trends in der Halbleiterbranche miteinander verknüpfen kann, um seine Stärken (Parallelisierung) auszubauen und gleichzeitig an seinen Schwächen (Singlethreadleistung in wenig parallelisierten Anwendungen) arbeitet. Ich habe keine Quellen und spekuliere nur. "Grain of salt" und so

Tl;dr: Unterschiedliche Kerne für unterschiedliche Anwendungen.

 

[yummycandy]

Btw. Intel bringt mit Lakefield wohl auch ein Big Little Konzept raus. So neu wäre das mit Milan also nicht.

 

[Colindo]

Fand die Darstellungen von Jim auch sehr interessant. Wird spannend sein, Ende des Jahres oder Anfang 2020 mehr über Milan zu erfahren.
Der 5-core CCX ist eine nette Idee, bin mir aber nicht sicher, ob AMD von der Architektur eines Chiplets noch viel abändert. Jim's Idee, dass einige Chips GPU-Chiplets sind, fand ich da intuitiver.

 

[yummycandy]

Jim's Idee, dass einige Chips GPU-Chiplets sind, fand ich da intuitiver.

Der Chiplet-Baukasten wurde doch indirekt schon lange vorgestellt. Ob das mit Milan kommt, weiß man noch nicht. Danach gehts mit Stacked Dies und anderen Materialien weiter. Insofern ist also bei 3nm noch lange nicht Schluß.

 

[MK one]

Stacked Cpus für den Desktop sehe ich erst mal nicht , denn man hat für den Sockel + externes Ram + externe GraKa genug Platz , bei APU s hingegen könnten 4 GB DDR6 schon Wunder bewirken - auch wenn der CPU Teil dann nicht mehr so hoch takten würde , der Vorteil durch den Grafikspeicher würde das allemal wettmachen .
Stacked Chips sehe ich vor allem im Mobile und Embedded Bereich = möglichst klein , möglichst geringer Verbrauch und kein Bedarf an sehr hohen Taktraten .

 

[.Sentinel.]

@Rock Lee
Das mit dem "prime core" ist seit Jahren meine Idee bzw. meine Forderung. Auch singelcore- lastige Anwendungen haben einen parallelisierbaren Anteil.
Der Prime- Core könnte für eine homogene Auslastung ALLER Cores sorgen, indem der Mainthread das Gesamtpaket nach oben zieht.

Wäre stark, wenn das kommt. Möglichst auch so flexibel bzw. programmierbar, dass die Entwickler volle Entscheidungsmöglichkeiten haben, was über diesen Core dann abgewickelt würde.

LG
Zero

 

[rg88]

Wäre stark, wenn das kommt. Möglichst auch so flexibel bzw. programmierbar, dass die Entwickler volle Entscheidungsmöglichkeiten haben, was über diesen Core dann abgewickelt würde.

Gerade das hoffe ich, dass nicht passiert. Sonst wird wieder mit Compilern getrickst oder die Entwickler kümmern sich nicht drum und es kommt eine zähe Sache dabei raus.
Das ist Aufgabe des Schedulers und das sollte es auch bleiben.

 

[.Sentinel.]

@rg88
Der Scheduler kann keine physikalischen Gegebenheiten umgehen bzw. keine Rechenkraft dort rauszaubern, wo ein Core sowieso schon 100% Last durch nicht verteilbare Aufgaben erfährt....

Gegen einen ausgelasteten Mainthread, der die Subthreads bremst, ist ein Scheduler kein Heilmittel, egal wie "optimiert", außer er wäre auch direkt durch die Programmierer ansprechbar. Dann ginge wohl noch ein wenig mehr.
Die Hardwarelösung funktioniert diesbezüglich IMMER, gerade wenn der Prime- Core unabhängig des Schedulers individuell ansprechbar ist.

LG
Zero

 

[rg88]

Der Scheduler kennt aber die Threads die er verteilt. Insofern kann er Threads die viele andere Threads losschicken höher priorsieren und auf den Performancekern legen. Die Unterthreads dann auf die langsamen. Die Ergebnisse die die Threads liefern können dann schneller entgegengenommen und weiterverarbeitet werden. Das wäre doch genau der Sinn dieser unterschiedlich schnellen Kerne.
Dass Entwickler sich darum kümmern, wird nicht passieren. Das hat man in der Vergangenheit oft genug gesehen. Das würde nur passieren, wenns eine Intel-Technik und notwendigkeit wäre. Für AMD optimiert niemand die Software. Diese würde ja dann auf Intel-System eventuell sogar schlechter laufen, als ohne die AMD-spezifischen Anpassungen.
Genau deshalb muss man die Lösung für sowas dann beim Scheduler sehen.

 

[R1ng0]

Der Scheduler kennt aber die Threads die er verteilt. Insofern kann er Threads die viele andere Threads losschicken höher priorsieren und auf den Performancekern legen. Die Unterthreads dann auf die langsamen. Die Ergebnisse die die Threads liefern können dann schneller entgegengenommen und weiterverarbeitet werden. Das wäre doch genau der Sinn dieser unterschiedlich schnellen Kerne.
Dass Entwickler sich darum kümmern, wird nicht passieren. Das hat man in der Vergangenheit oft genug gesehen. Das würde nur passieren, wenns eine Intel-Technik und notwendigkeit wäre. Für AMD optimiert niemand die Software. Diese würde ja dann auf Intel-System eventuell sogar schlechter laufen, als ohne die AMD-spezifischen Anpassungen.
Genau deshalb muss man die Lösung für sowas dann beim Scheduler sehen.

Das Problem ist nur, dass der Thread der die anderen "Unterthreads" spawnt dann in der Regel dem Scheduler signalisiert, dass er auf die Ergebnisse der gespawnten Threads wartet, was sofort einen Context Switch auslöst womit der spawnende Thread dann aus seinem Kern verdrängt wird.

@Rock Lee
Das mit dem "prime core" ist seit Jahren meine Idee bzw. meine Forderung. Auch singelcore- lastige Anwendungen haben einen parallelisierbaren Anteil.
Der Prime- Core könnte für eine homogene Auslastung ALLER Cores sorgen, indem der Mainthread das Gesamtpaket nach oben zieht.

Bei big.LITTLE geht es meines Wissens darum, Energie zu sparen und entweder läuft die eine Seite oder die andere, aber nicht beide zusammen.
Und wie sollte denn der AMD-Kern auf einmal aussehen, der noch schneller ist als die bisherigen? Eher gäbe es Kerne, die deutlich langsamer, aber energieparender sind, als die bisherigen.
Auf dem Desktop würde das aber kaum etwas bringen und das Ergebnis wäre langsamer, nicht schneller.

So schön es klingt, ich kann mir das im Moment nicht vorstellen.

 

[Iapetos]

big.LITTLE kann mittlerweile auch mit Upstream-Linux (so wie auch Android/Linux) dynamisch leistungssteigernd genutzt werden, je nachdem, welche Vorgaben dem Scheduler gemacht werden. Dabei werden die Kerne genutzt, die am sinnvollsten sind, also auch langsame und schnelle Kerne parallel.

Abgesehen davon ist das für stationäre Geräte mit dauerhafter Energieversorgung natürlich wenig bedeutsam - es sei denn, man hat die Kerne sowieso brach liegen; dann kann man sie natütlich zusätzlich nutzen. Spielt für Epyc aber keine Rolle.

 

[rg88]

Das Problem ist nur, dass der Thread der die anderen "Unterthreads" spawnt dann in der Regel dem Scheduler signalisiert, dass er auf die Ergebnisse der gespawnten Threads wartet, was sofort einen Context Switch auslöst womit der spawnende Thread dann aus seinem Kern verdrängt wird.

Ich sagte ja nicht, dass der Windows-Scheduler schon so arbeitet
Ich sehe halt die Zuständigkeit bei diesem, WENN so CPUs mal auftauchen sollten. Klar muss der erst entsprechend von MS dann angepasst werden

 

[Rock Lee]

Bei big.LITTLE geht es meines Wissens darum, Energie zu sparen

Der Effekt der Energieersparnis ist das Ergebnis. Der Prozess ist den Big Core so schnell wie möglich eine Aufgabe abarbeiten zu lassen, damit danach wieder in den Hintergrundmodus geschaltet werden kann. Das ist bei Smartphones mit begrenzter Akkukapazität enorm wichtig. Niemand sagt aber, dass dieses Konzept im Desktop nicht auch funktionieren kann, wenn der Big Core zB bei einem Spiel am wichtigen Hauptthread arbeitet, der alles koordiniert und die anderen Kerne Hintergrundthread, zB KI-Gegner

Und wie sollte denn der AMD-Kern auf einmal aussehen, der noch schneller ist als die bisherigen? Eher gäbe es Kerne, die deutlich langsamer, aber energieparender sind, als die bisherigen.

OK, ich versuche meine Erklärungen vom vorherigen Post nochmal auszuweiten:
Wir nehmen jetzt mal einen einzigen Zen1 Kern und verdoppeln den L3 Cache und nennen ihn Zen2. (ich weiss es gibt noch mehr Änderungen aber es soll möglichst einfach sein).
Der L3-Cache nahm vorher die Hälfe der Fläche eines Kerns ein und durch das Verdoppeln wäre der Kern bei gleicher Fertigung um den Faktor 1,5 größer, wird aber nur um den Faktor 1,15 schneller.
Ich könnte aber auch 2 Zen-Kerne nehmen und hätte dann mit doppelter Fläche im Optimalfall auch doppelte Leistung.
Durch stetig kleiner werdende Fertigungsstrukturen hat man zu Singlecore-Zeiten erst immer die Kerne weiter aufgebohrt. Aber es wurde immer schwieriger die zusätzlichen Transistoren auch in Leistung umzuwandeln
(Stichwort: diminishing returns). Der Dualcore war geboren und natürlich hat man weiterhin die Kerne selbst verbessert, aber es war immer einfacher einfach einen zusätzlichen Kern dazuzupacken, um in parallelisierten Anwendungen Leistung zu gewinnen.

Mit Zen2 bekommen wir wohl 16 Kerne im Mainstream-Desktop.

Das Thema Chiplets mal aussen vor gelassen. Wie soll mit Zen3 noch die Leistung erhöht werden?
24 Kerne? OK, und welche Mainstream-Desktop Anwendungen profitieren davon?
7nm+ ist gegenüber 7nm 15% dichter gepackt. Viel dürfte da eh nicht machbar sein.
Warum zu den normalen Kernen des CCX nicht jeweils einen Prime Core ergänzen, über den die Cross-CCX und Cross-Chiplet Kommunikation läuft und sagen wir mal um den Faktor 1,8 größer ist und Faktor 1,2 Singlethreadleistung eines normalen Kern bringt? Womit ? Mehr Cache, breitere (weniger dicht gepackte) Transistoren für weniger Leckströme und höheren Takt, keine Ahnung.

Man könnte sogar für Spiele, die wenig Threads nutzen einen 20-Kerner(16+4) gegenüber einem 10(8+2) vermarkten aufgrund der höheren Anzahl an Prime Cores

So schön es klingt, ich kann mir das im Moment nicht vorstellen.

Klar ist es nur eine Idee meinerseits. Ich habe nur versucht zu spekulieren, was Charlie mit der Überschrift "AMD differenziert Kerne" meint und wie Zen3 sich gegenüber Zen2 verbessern kann.
Und was mit "Zen X" gemeint ist. So ein 5-Kern CCX sieht mir sehr nach einem "X" aus

Aber grundsätzlich hast du recht: "zu schön um wahr zu sein", oder "too good to be true" ist meistens unwahr. Andererseits wurde das auch schon zu 16-Kernen bei Zen2 gesagt

 

[yummycandy]

Ooch, man braucht sich nur das Schaltbild (leider nur Zen1) anzuschauen, dann sieht man was man tun kann.

 

[R1ng0]

@Rock Lee
Der Artikel auf SemiAccurate ist schon über einen Monat alt, wenn es da um so etwas spektakuläres wie big.LITTLE gegängen wäre, dann sollte das inzwischen die Runde gemacht haben, Paywall hin oder her. Ich konnte aber nur zwei Threads dazu finden (Anandtech and Reddit), die nicht wirklich ergiebig waren, bzw. schnell ausfransten.
Ich denke es geht eher darum die Kerne für bestimmte use cases auszudifferenzieren, wie es auch Intel macht (z.B. größerer L2 vs kleinerer L3 für Server-Anwendungen).
Ich könnte mir auch Spezialfälle oder vielleicht (Semi-) Custom-Lösungen vorstellen, insbesondere in Bezug auf eine integrierte GPU, z.B. für KI.

 

[raphe]

Wie Guru3D berichtet ist jetzt in der SiSoft-Datenbank ein Engeneering Sample aufgetaucht

ZS1711E3VIVG5_24/17_N (32C 64T 2.4GHz/1.7GHz 40% OC, 733MHz IMC, 32x 512kB L2, 8x 16MB L3)


https://ranker.sisoftware.co.uk/show_run.php?q=c2ffcee889e8d5e2daead2e6d1f785b888aecbae93a385f6cbf3

und das ist erst die Hälfte der möglichen Kerne 🤩🤩