News Intel Diamond Rapids: 256 Kerne, 16 CPU-Tiles, vier Cache-Dies und zwei I/O-Tiles

[Volker]

Dann habe ich entweder die Folien falsch in Erinnerung, oder man hat darauf ein bisschen zu sehr das Blaue vom Himmel versprochen: in meiner Erinnerung wollte man mir EMIB doch genau die 2 Dinge eliminieren: Latenz und Verbrauch wie bei IF(AMD)

Ja das Problem war halt EMIB plus UPI dann in einem Dual-Sockel-System. Das addierte und multiplizierte sich so krass hoch .. 1 UPI-Hop und 4 EMIB-Hops um von ganz hinten nach ganz vorn zu kommen .. wurde damals mehrfach untersucht. Die Latenzen und auch der Stromverbrauch waren mitunter dann aus der Hölle und schlechter als bei AMD
Hier mal ein Beispiel: https://jprahman.substack.com/p/sapphire-rapids-core-to-core-latency

Dass sie DMR nun nochmal umbauen mussten gegenüber Xeon 6 war auch klar, da der innenliegende dritte CPU-Tile den weitesten Weg zu I/O hatte - auch wieder doof. Nun sind alle Base Tiles mit aufliegenden CPU-Kernen gleich weit weg.

 

[stefan92x]

Nun sind alle Base Tiles mit aufliegenden CPU-Kernen gleich weit weg.

Naja... wir haben jetzt zwei Fabric Hub Dies in der Mitte. Da gibt es doch immer noch ein dichter dran/weiter weg, je nachdem ob man auf dem direkt angebundenen bleibt oder auf den zweiten springen muss?

Je mehr über Diamond Rapids bekannt wird, umso enttäuschender wird es. Noch vor 9 Monaten hat CB DMR für dieses Jahr erwartet, jetzt rutscht es weit ins nächste Jahr. UCIe fühlt sich zumindest mehr nach Rückschritt an als nach Fortschritt. Doch 256 Kerne ist zwar eine positive Nachricht, aber puh... Das sieht wieder danach aus, dass erst Coral Rapids mit Zen 6 konkurrieren kann - zu einem Zeitpunkt, wenn bereits Zen 7 erscheinen könnte.

 

[Volker]

Ja das DMR nicht wirklich konkurrenzfähig wird war aber lang erwartet worden und ist nicht neu. Das sie den verschoben haben war es dann aber, letztes Jahr hieß es noch der Zeitplan stimmt, nun aber seit diesem Jahr es könnte sogar Ende 2027 erst werden - das wäre wohl der Extremfall. Ich denke mal erstes Halbjahr nächstes Jahr wird es .. mit dann kurzer Lebensspanne zu CRP. Und klar, konkurrenzähig wird dann auch für Coral schwer, imemrhin aber mit SMT dann^^

 

[stefan92x]

@Volker eben, die Verschiebung macht es jetzt zum größeren Problem. Mein Eindruck war lange, dass DMR ein blaues Auge mit Ansage wird. Wenn Intel aber Coral schnell genug nachschieben könnte (so wie es ja auch oft als Ziel gesetzt würde), dann hätte Intel damit die Chance gehabt, wieder wirklich auf Augenhöhe zu kommen.

Coral gegen Florence klingt hingegen schon wieder nach Desaster...

 

[person unknown]

bin schon gespannt, was, nachdem sie diese News abgewartet hat, Frau Su in den nächsten Tagen vorstellen wird 😉

 

[Araska]

Ich bin mal auf den Preis gespannt...

"If you need to ask, you don't have to know"

 

[HOT]

Und zack sieht das Ding aus wie ein Epyc .

 

[stefan92x]

bin schon gespannt, was, nachdem sie diese News abgewartet hat, Frau Su in den nächsten Tagen vorstellen wird 😉

Nichts vergleichbares. AMD hat zur diesjährigen Hot Chips tatsächlich nichts zum Thema CPUs mitgebracht, sondern spricht ausgiebig über die MI400 und ein bisschen über FPGAs.

Aber AMD hat ja auch kürzlich eben die Zen 6 Epyc vorgestellt, die ja auch im Laufe der nächsten Monate nach und nach in den Markt starten, hat also sowieso vorgelegt.

Und zack sieht das Ding aus wie ein Epyc .

Wie ein wilder Mix aus Zen 6 (zwei zentrale IOD), Zen 4 (mehrere Core Dies auf einem Cache Die wie bei MI300C/Epyc 7V64) und Zen 2-5 (der generelle Aufbau mit zentralem IOD und übers Substrat angebundenen Core-Dies).

 

[Volker]

Nichts vergleichbares. AMD hat zur diesjährigen Hot Chips tatsächlich nichts zum Thema CPUs mitgebracht, sondern spricht ausgiebig über die MI400 und ein bisschen über FPGAs.

Aber AMD hat ja auch kürzlich eben die Zen 6 Epyc vorgestellt, die ja auch im Laufe der nächsten Monate nach und nach in den Markt starten, hat also sowieso vorgelegt.

Ja AMD hat quasi ihren AI Day aus dem letzten Monat zu Hot Chips wiederholt, da war gar nix neu.
Auf die echte Epyc-Präsi warten wir also noch ne Weile

 

[Volker]

Grad nochmal in die Q&A reingehört von heute Nacht: Es ist durchaus eine Design-Entscheidung bei der CPU und man wollte "mehrere Hops" über EMIB verhindern - also genau wie vermutet, da das die Latenz killt

Jeder Kern kann via Base Tile und UCIe-S dann beide IODs ansprechen .. mit EMIB wäre das die Hölle. Passend dazu hat Intel selbst ja im Frühjahr schonmal geteasert, das sowas problemlos über 30 mm Länge mit UCIe-S funktioniert. UCIe-A hätte das gleiche Problem wie EMIB gehabt, man hätte doppelt springen müssen zu zwei IODs, die Alternative wäre sonst gewesen, man hätte pro Kern/Cache-Block nur den halben Speicher ansprechen können. Also ein Single-IOD-Chip hätte EMIB oder UCIe-A nutzen können.

 

[stefan92x]

Jeder Kern kann via Base Tile und UCIe-S dann beide IODs ansprechen

Ah... das hatte ich so noch gar nicht verstanden. Dann ist es ja tatsächlich kein Latenzunterschied, wenn man von "links" nach "rechts" im Package muss, wenn für jeden Base Die jeweils direkte Verbindungen zum linken und zum rechten Fabric Hub Die bestehen.

 

[Volker]

Ja, wurde mir auch erst jetzt so klar
Man muss einige Dinge da drei Mal hören (so wie ich jetzt^^)

Es geht halt wirklich darum, dass die Kerne mit Cache gute Latenzen zum gesamten Speicher haben. Und das war bei dem Design nur so möglich, die Wege sind "zu weit". UCIe-A/EMIB hat bei Bandbreite und anderem Kram viele Vorteile, aber du musst die Chips auf 2mm aneinander packen. Mit zwei IODs geht das schlicht nicht, und mehrere Hops sind eben total scheisse.

 

[Convert]

UCIe-A/EMIB hat bei Bandbreite und anderem Kram viele Vorteile, aber du musst die Chips auf 2mm aneinander packen. Mit zwei IODs geht das schlicht nicht, und mehrere Hops sind eben total scheisse.

Statt zwei IODs hätte man auch ein größeres machen können und schon hätte man die EMIB nutzen können, dass viele Vorteile gegenüber der Verdrahtung im Substrat hat. Einziger Nachteil: Die Lösung wäre teurer.

Ergänzung (25. August 2026)

Dann ist es ja tatsächlich kein Latenzunterschied, wenn man von "links" nach "rechts" im Package muss, wenn für jeden Base Die jeweils direkte Verbindungen zum linken und zum rechten Fabric Hub Die bestehen.

Wie ist es eigentlich bei Zen 6? Ist jedes Chiplet mit beiden IODs verbunden oder jeweils nur mit dem angrenzenden? AMD hat doch mit der nahen Verbindung und zwei IODs das gleiche Problem, wie Intel mit EMIB, oder nicht?

AMD scheint es nur nicht so wichtig zu sein, wenn der eine Chiplet nur ein IOD ansprechen kann und damit nur die Hälfte vom Arbeitsspeicher mit nur 8-Channels....

https://pics.computerbase.de/1/2/3/9/2/8-ea4adadde68b2dd0/34-1080.b45a471b.jpg

 

[stefan92x]

AMD hat doch mit der nahen Verbindung und zwei IODs das gleiche Problem, wie Intel mit EMIB, oder nicht?

Davon gehe ich auch aus. Die spannende Frage ist aber, wie AMD die Chiplets wirklich verbindet und wie da die Topologie der ganzen CPU insgesamt aussieht.

 

[Philste]

Statt zwei IODs hätte man auch ein größeres machen können und schon hätte man die EMIB nutzen können, dass viele Vorteile gegenüber der Verdrahtung im Substrat hat. Einziger Nachteil: Die Lösung wäre teurer.

Naja ich glaube man unterschätzt, wie groß die Dinger sind. Ich glaube sowohl bei Diamond Rapids als auch bei Venice wäre man nicht weit vom Reticle Limit weg. Bei Venice in N6 wäre das scvon Wahnsinn, aber einen 800mm² Die in Intel 3 nur für IO wäre der Wahnsinn in jeglicher Hinsicht.

Zusammengefasst: Ich sehe einen einzigen IO-Die weder bei Diamond Rapids, noch bei Venice als sinnvolle Alternative. Dafür hat man mittlerweile mit 16 RAM Channels, PCIe 6.0 und co. Einfach zu viel Kram drin.