Zen 3, 7 nm, 2020 (Vermeer, Cezanne, Genesis Peak & Milan)

[w0mbat]

Da mit Zen 2 jetzt die Katze aus dem Sack ist, kann es hier ja gleich mit den Spekus zu Zen 3 weiter gehen :biggrin:

Was wir bisher wissen:
- Zen 3
- 2020
- 7nm+
- Milan (Server), Vermeer (Desktop)
- Ryzen 4000 serie (?)
- AM4 mit X670 (?)

[KarlKastor]

Da mit Zen 2 jetzt die Katze aus dem Sack ist, kann es hier ja gleich mit den Spekus zu Zen 3 weiter gehen :biggrin:

Was wir bisher wissen:
- Zen 3
- 2020
- 7nm+
- Milan (Server), Vermeer (Desktop), Renoir (APU)
- Ryzen 4000 serie (sehr wahrscheinlich)
- AM4 mit X670 (?)
Ist Renoir wirklich Zen3?

[w0mbat]

Stimmt, kann sein, dass Renoir noch 12nm Zen+ ist. Die APUs hinken ja immer hinter her.

Weiß es jemand sicher?

[][immy]

Ich würde ja erst mal mit einem Zen2+ rechnen ;)

[HOT]

Picasso ist 12nm Zen+. Renoir wird 7nm EUV sein, aber "nur" Zen2.

[maximus_hertus]

[immy;12006009']Ich würde ja erst mal mit einem Zen2+ rechnen ;)

Zen3 ist für 2020 angekündigt....

[robbitop]

Ich glaube, was er meint, dass er erwartet, dass Zen3 eher eine Art Zen2+ sein könnte. Also eher ein Refresh. AMD hat nur 1x Designteam und 1 Jahr ist recht wenig für eine Iteration.
Ich würde auch tendenziell davon ausgehen, dass Zen3 ein optimierter Zen2 mit 7nm+ oder 6nm ist. Ggf. mit einem DDR5 IO.

[HOT]

War es nicht so, dass AMD mittlerweile 2 Designteams hat?

[][immy]

Würde es eigentlich theoretisch was bringen den IO chip auch auf 7nm zu bringen?

Ich glaube, was er meint, dass er erwartet, dass Zen3 eher eine Art Zen2+ sein könnte. Also eher ein Refresh. AMD hat nur 1x Designteam und 1 Jahr ist recht wenig für eine Iteration.
Ich würde auch tendenziell davon ausgehen, dass Zen3 ein optimierter Zen2 mit 7nm+ oder 6nm ist. Ggf. mit einem DDR5 IO.
jep. Für große Neuerungen ist innerhalb eines Jahres eigentlich nicht viel Platz.

[Zergra]

War es nicht so, dass AMD mittlerweile 2 Designteams hat?

Irgendwie war da was, ich meine das es ein Hauptteam war und ein kleines für kleine Verbesserungen Zb. für einen Refresh.

[robbitop]

War es nicht so, dass AMD mittlerweile 2 Designteams hat?
2x Implementierungsteams habe ich gehört. Die braucht man auch bei der Vielzahl an Dice pro Jahr. APU, CPU, HEDT, custom, GPUs etcpp
Aber nur 1x CPU Design Team.

[immy;12006147']Würde es eigentlich theoretisch was bringen den IO chip auch auf 7nm zu bringen?

Wohl weniger als bei den eigentlichen Cores, weil es Strukturen gibt, die nicht so gut shrinken. Dinge wie PHYs, die einen nicht unwesentlichen Teil des I/O Kerns ausmachen. Wenn 7nm günstiger und besser verfügbar wird, wird man aber wahrscheinlich (IMO) umsteigen.

[Thunder99]

Waren nicht die Kontakte so langsam am Ende? Könnte für einen neuen Sockel sprechen, AM5 ;). Siehe dazu auch Analyse/Spekulation des X570.

[robbitop]

Zumindest könnte man mit einem neuen Sockel mal ein paar mehr PCIe Lanes liefern. Ob die Kontakte selbst für die Taktraten von DDR5 limitieren ist für mich offen.
Rein auf den ersten Blick hat sich da (als Laie mit nacktem Auge zumindest) wenig getan seit Sockel754/939.
Ggf. wechselt man ja auch irgendwann mal auf LGA. Aber bis dato schien es noch nicht nötig zu sein oder in der Praxis doch keine groß genugen Vorteile zu bringen.

[JVC]

Lasst doch mal Zen 2 ankommen ^^

Was danach bei AMD wann kommt, hängt von Intel ab ;)

Wenn Intel "nix" bringt, dann könnte es einen "Zen2+" geben und der "Hammer" wird aufgehoben...

m.f.g. JVC

[Ravenhearth]

TSMC's 7nm+ EUV is in production, improves performance by 10% (https://www.techspot.com/news/80237-tsmc-7nm-production-improves-performance-10.html)
N7+ has identical yield rates to N7 and will steadily improve, while also offering a 20% increase to transistor density. There’s also a 10% performance uplift or 15% power efficiency increase. AMD will take advantage of the former in their fourth-gen Ryzen which they’ve confirmed to use TSMC’s 7nm+
Ryzen 4000 dann mit 5 GHz ? :D

Edit: Außerdem könnten sie dann einen 16-Kerner in 105W TDP quetschen, indem sie von der 15% höheren Effizienz bei gleichem Takt Gebrauch machen und den Basistakt zusätzlich auf ~3,6 GHz absenken (3900X: 3,8 GHz). Turbo kann ja trotzdem 5,0 GHz sein.

[Unicous]

Dir ist schon klar, dass AMD das schon vor "Ewigkeiten" bestätigt hat?:confused:

https://images.anandtech.com/doci/12233/x86_to_2020.jpg

[Ravenhearth]

Dir ist schon klar, dass AMD das schon vor "Ewigkeiten" bestätigt hat?:confused:
7nm+, ja. Aber nicht dass sie die 10% 'performance uplift' nutzen werden. Das habe ich so konkret noch nicht gelesen.

[HOT]

Könnt mir aber doch vorstellen, dass ein Zen3 eingeschoben wird, der kein Zen2+ ist und zwar wegen AVX512 und weiteren Befehlssatzerweiterungen. Kann sogar sein, dass dieses Die dann erst mal nur für Server reserviert ist.

[Nightspider]

Durch den verbesserten Produktionsprozess (bessere Yields) und 20% höhere Transistordichte könnte man bei 7nm+ auch locker 10 Kerne pro Die packen. Dann gäbe es:

Gamer: 10C
Enthusiasten 20C
Threadripper: 40C
EPYC 3: 80C

^^

[Ravenhearth]

5 Kerne pro CCX? Schwierig :D
Und höhere Taktraten könnte man dann vergessen

[Nightspider]

Ob man noch lange an der CCX Bauweise festhalten wird? Ich weiß ja nicht.

[w0mbat]

Was soll die Option zu CCX sein?

[prinz_valium]

Durch den verbesserten Produktionsprozess (bessere Yields) und 20% höhere Transistordichte könnte man bei 7nm+ auch locker 10 Kerne pro Die packen. Dann gäbe es:

Gamer: 10C
Enthusiasten 20C
Threadripper: 40C
EPYC 3: 80C

^^
Wird zu 100% keine 10Cores pro CCX geben.
Mehr Cores als jetzt erwarte ich frühestens mit Ryzen 5000. Wahrscheinlich aber erst mit der 6000er Serie.

[Brillus]

Wird zu 100% keine 10Cores pro CCX geben.
Mehr Cores als jetzt erwarte ich frühestens mit Ryzen 5000. Wahrscheinlich aber erst mit der 6000er Serie.

Ich erwarte die 16 mit der 4000er Reihe.

[prinz_valium]

Ich erwarte die 16 mit der 4000er Reihe.
16 gibt es doch jetzt schon. Ich rede von technisch mehr Kerne umgesetzt.

[Nightspider]

Mehr Kerne gibts spätestens mit 5nm EUV und das sollte doch 2021 marktreif sein laut TSMC, also mit der 5000er Serie.

Die risk production davon lief ja schon an. Sollte in 2 Jahren also chiplet-tauglich sein, denk ich.

https://www.golem.de/news/auftragsfertiger-tsmc-startet-5-nm-risk-production-1904-140486.html

[bun]

https://www.youtube.com/watch?v=il5Zl3vGvVw


AMD Zen 3 Early Whispers: Another Huge Upgrade in 2020!

There have been "whispers" of what Zen 3 brings to the table for a while, but it wasn't until a couple days ago that the greater picture clicked into place.

[robbitop]

Ob man noch lange an der CCX Bauweise festhalten wird? Ich weiß ja nicht.
Das macht man nicht aus Spaß. Sieht man übrigens auch bei vielen ARM Designs auch so.

Da man immer mehr Komponenten an die Fabrics ankoppelt und auch der Corecount hoch geht, braucht man eine Fabric, die gut skaliert. Und das ist nunmal diametral mit deren Latenz.
Um diesen Effekt bestmöglich einzudämmen gibt es diese core count complexes in verschiedensten modernen SoCs. Innerhalb dieser Einheiten sind die Latenzen zwischen den Komponenten immernoch sehr schnell (core-to-core; Cache Zugriff).

Die CCX Größe ist wie immer auch ein Kompromiss. Mehr Teilnehmer im CCX heißt expotenziell steigender Verdrahtungsaufwand (wenn jeder mit jedem verbunden werden soll wie im CCX) bzw/und/oder wieder mehr Latenz.

Die CCX sind der logische Kompromiss guter Latenz, wo sie hilft und guter Skalierbarkeit.

Bei Intels 8C Ringbus sieht man bereits steigende Latenz im Latenzdiagramm (die 16 MiB sind nicht so schnell wie der ersten 8 MiB) und der ist irgendwann am Ende, so dass man mehrere Ringbusse kaskadieren kann - das kostet wie man bei HSW-E sieht aber auch schon gute 10 ns.
Früher oder später wird man da auch auf eine moderne Fabric wie das Mesh wechseln.

Ich gehe davon aus, dass man diesen Effekt immer mehr mit Datenlokalität kompensieren wird (größere Caches).

https://www.youtube.com/watch?v=il5Zl3vGvVw
Hört man ja immer wieder. Mal sehen, ob es so kommt. Wäre ein nicht unwesentlicher Eingriff und völlig überraschend, 1 Jahr nach Zen 2, der ja bereits tiefe Eingriffe beinhaltete.
Damit das auch richtig was bringt, müsste man so ziemlich alles wesentlich breiter machen. Ob sich das lohnt, gegenüber einfach mehr CCX zu verbauen? (Transistoren)

[bun]

Hört man ja immer wieder. Mal sehen, ob es so kommt. Wäre ein nicht unwesentlicher Eingriff und völlig überraschend, 1 Jahr nach Zen 2, der ja bereits tiefe Eingriffe beinhaltete.
Damit das auch richtig was bringt, müsste man so ziemlich alles wesentlich breiter machen. Ob sich das lohnt, gegenüber einfach mehr CCX zu verbauen? (Transistoren)

Naja ich würde erwarten das man nun den Server wieder 1x pausiert, Desktop und Mobile bekommen einen Refresh auf 7nm+ mit leichten Verbesserungen, sofern sinnvoll umsetzbar, und dann erst kommt die Zen 3 Architektur. Dann hat das cpu core team ungefähr die gleiche Zeit für eine Generalüberholung wie von Zen 1 zu Zen 2.
Die Zen2 basierten Server Chips sind ja laut Aussage von AMD breit als Sample verteilt worden, da ist das core team schon ziemlich lange mit fertig.

Ob sich SMT4 gegenüber mehr CCX lohnt, kann ich nicht beurteilen. IBM macht SMT4 SMT8 nun schon recht lange im Server Markt, und AMD ist stark auf den Server Markt fokussiert.

Als Laie habe ich die Vorstellung, das SMT generell die Auslastung des Kerns erhöht, wenn dieser signifikant brachliegende Ausführungseinheiten hat. SMT4 wäre dann logischerweise Etwas das AMD dann implementiert, wenn man den Kern soweit verbreitert, das SMT4 sinnvoll wird. Die Verbreiterung des Kerns wird dann ja aber von etwas anderem Getrieben, und SMT4 ist nur die logische Konsequenz um diese Breite auch in anderen Szenarien zu nutzen?

[mboeller]

https://semiaccurate.com/2019/04/15/amd-to-differentiate-cores/

https://semiaccurate.com/2019/04/01/how-many-die-does-amds-milan-have/

Charlie halt... aber vielleicht ein wenig Treibstoff für eine Diskussion "into the wild blue yonder" :)

[w0mbat]

https://semiaccurate.com/2019/04/01/how-many-die-does-amds-milan-have/

Charlie halt... aber vielleicht ein wenig Treibstoff für eine Diskussion "into the wild blue yonder" :)

Note: Not too many moles were harmed in the making of this April Fool’s day story. Those that were ended up in a very nice dish so it is all good.

Ein Aprilscherz.

[robbitop]

Naja ich würde erwarten das man nun den Server wieder 1x pausiert, Desktop und Mobile bekommen einen Refresh auf 7nm+ mit leichten Verbesserungen, sofern sinnvoll umsetzbar, und dann erst kommt die Zen 3 Architektur. Dann hat das cpu core team ungefähr die gleiche Zeit für eine Generalüberholung wie von Zen 1 zu Zen 2.
Die Zen2 basierten Server Chips sind ja laut Aussage von AMD breit als Sample verteilt worden, da ist das core team schon ziemlich lange mit fertig.
Verstehe ich nicht. Zwischen Design done und Produktlaunch liegt eigentlich immer in etwa die gleiche Zeit. Grob 1 Jahr. Da die immer gleich ist, ist diese ja nur als Offset zu sehen.

Entsprechend waren es 2 Jahre zwischen Zen/Zen2 (2017/2019 launch und vermutlich 2016/2018 design complete).
Zen 3 ist für 2020 vorgesehen. Also nur 1 Jahr nach Zen 2. Zen2 design complete 2018, launch 2019. Zen3 design complete vermutlich 2019 und launch vermutlich 2020.
Ich sehe da keine zusätzliche Pause oder mehr Zeit.


Ob sich SMT4 gegenüber mehr CCX lohnt, kann ich nicht beurteilen. IBM macht SMT4 SMT8 nun schon recht lange im Server Markt, und AMD ist stark auf den Server Markt fokussiert.

Als Laie habe ich die Vorstellung, das SMT generell die Auslastung des Kerns erhöht, wenn dieser signifikant brachliegende Ausführungseinheiten hat. SMT4 wäre dann logischerweise Etwas das AMD dann implementiert, wenn man den Kern soweit verbreitert, das SMT4 sinnvoll wird. Die Verbreiterung des Kerns wird dann ja aber von etwas anderem Getrieben, und SMT4 ist nur die logische Konsequenz um diese Breite auch in anderen Szenarien zu nutzen?
Die POWER mArchs sind dafür auch extrem breit. Schau dir mal die Decoder und das Backend an. Klar, dass SMT4 und zT SMT8 auch noch etwas bringt.
Dafür ist der Kern entsprechend schlecht ausgelastet, wenn es nicht genug Last durch andere Threads gibt. Ein so breiter Kern kostet bestimmt mächtig Transistoren. Die man auch einfach in mehr CCX investieren könnte. Ist am Ende sicherlich ein Vergleich zwischen Oportunitäten.

[mboeller]

Ein Aprilscherz.

Ahh... das hatte ich auf die schnelle nicht mitbekommen.

[Windi]

Naja ich würde erwarten das man nun den Server wieder 1x pausiert, Desktop und Mobile bekommen einen Refresh auf 7nm+ mit leichten Verbesserungen, sofern sinnvoll umsetzbar, und dann erst kommt die Zen 3 Architektur. Dann hat das cpu core team ungefähr die gleiche Zeit für eine Generalüberholung wie von Zen 1 zu Zen 2.
Die Zen2 basierten Server Chips sind ja laut Aussage von AMD breit als Sample verteilt worden, da ist das core team schon ziemlich lange mit fertig.

Für Zen3 muss es ja keine gigantischen Änderungen geben.
Nur wenn man 7nm+ verwenden will, dann muss man eh eine neue Maske anfertigen. Dann kann man auch ein paar Bugfixes und kleinere Verbesserungen einpflegen.
Ich gehe davon aus, das AMD ständig seine Chiplets aktualisieren wird, sobald es sich lohnt. Einfach weil man nur ein Chiplet für alle Prozessoren benötigt. Und dann wird man auch die Zen-Nummer erhöhen. Das ist einfach übersichtlicher und gut fürs Marketing.

[bun]

Verstehe ich nicht. Zwischen Design done und Produktlaunch liegt eigentlich immer in etwa die gleiche Zeit. Grob 1 Jahr. Da die immer gleich ist, ist diese ja nur als Offset zu sehen.

Entsprechend waren es 2 Jahre zwischen Zen/Zen2 (2017/2019 launch und vermutlich 2016/2018 design complete).
Zen 3 ist für 2020 vorgesehen. Also nur 1 Jahr nach Zen 2. Zen2 design complete 2018, launch 2019. Zen3 design complete vermutlich 2019 und launch vermutlich 2020.
Ich sehe da keine zusätzliche Pause oder mehr Zeit.

Naja, man muss auch auf die Monate schauen. Wenn 2020, dann würde ich Q4 erwarten?

Zen Tapeout Oktober 2015

https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/36904-amd-k12-und-zen-feiern-tape-out.html

Funktionierendes Zen 1 Silizium gab es wohl im November 2015

https://www.extremetech.com/computing/217664-globalfoundries-announces-14nm-validation-with-amd-silicon

https://www.overclock3d.net/news/cpu_mainboard/amd_tests_zen_cpus_met_all_expectation_with_no_significant_bottlenecks_found/1

Ryzen 1000 kam März 2017
Epyc Juni 2017
APUs November 2017

Hat Jemand noch Daten für Zen 2? Google ist gerade unwillig.

Vielleicht kann AMD ja jetzt auch zaubern, es hieß ja 2018 schon das man an Zen 5 arbeitet.

Für Zen3 muss es ja keine gigantischen Änderungen geben.

Zen 3 ist der Codename für die mArch.

Ryzen 1000 und Ryzen 2000 basieren auf Zen 1, Ryzen 3000 basiert auf Zen 2.

Wenn man Ryzen 3000 refreshed, genauso wie Ryzen 1000, was ich durchaus erwarte ?! Dann würde ich aber immer noch die gleiche mArch erwarten.

[Windi]

Zen 3 ist der Codename für die mArch.

Ryzen 1000 und Ryzen 2000 basieren auf Zen 1, Ryzen 3000 basiert auf Zen 2.

Wenn man Ryzen 3000 refreshed, genauso wie Ryzen 1000, was ich durchaus erwarte ?! Dann würde ich aber immer noch die gleiche mArch erwarten.
Bei Ryzen 1000 und Ryzen 2000 gibt es ja auch nicht die geringste Änderung. Nicht einmal Bugfixing. Anscheinend könnte man einfach die 14nm Maske für 12nm übernehmen.

Für 7nm+ braucht es aber eine neue Maske und AMD gibt auf ihrer Roadmap für das Jahr 2020 Zen3 an. Von Zen2+ steht dort kein Wort.
Intel gibt auch jedem kleinen Update einen neuen Namen.
Eine neue Maske, ein neuer Herstellungsprozess, ein paar Bugfixes und ein paar Verbesserungen sollten für einen neuen Namen reichen.

Ob jetzt bei Zen3 noch mehr kommt? Keine Ahnung.
Ich glaube aber, das es jedesmal wenn TSMC einen neuen sinnvollen Fertigungsprozess hat, auch ein neues Chiplet mit einem Update der mArch geben wird. Und damit auch einen neuen Namen.

[w0mbat]

Bei Ryzen 1000 und Ryzen 2000 gibt es ja auch nicht die geringste Änderung. Nicht einmal Bugfixing. Anscheinend könnte man einfach die 14nm Maske für 12nm übernehmen.
Komisch, dass die cache Latenzen und der MC ohne jeglich Änderungen verbessert wurde :wink:

[Gipsel]

Komisch, dass die cache Latenzen und der MC ohne jeglich Änderungen verbessert wurde :wink:Die Cachecontroller sind per Firmware konfigurierbar ;).
Gab ja schon bei Zen (ohne plus) im Threadripper deutlich niedrigere Latenzen.

[w0mbat]

Und AMD hat bei Zen1 einfach mal gesagt, nö, so gut müssen die jetzt noch nicht sein?

[Gipsel]

Und AMD hat bei Zen1 einfach mal gesagt, nö, so gut müssen die jetzt noch nicht sein?War zum Marktstart noch nicht fertig validiert, so daß die zuerst in einer Art Failsafe-Modus liefen (sonst hätte man Ryzen verschieben müssen). Gab irgendwo glaube ich mal ein Interview dazu oder so. Bei Threadripper konnte dann die L2-Latenz signifikant (von 20 auf 12 Takte oder so) und die L3-Latenz glaube ich auch noch etwas gesenkt werden. Bei völlig identischem Silizium. Bei Zen+ in 12nm hat man dann noch durch Feintuning einen weiteren Taktzyklus bei der L2-Latenz sparen können. Und man hat wohl einen im Schnitt etwas besseren Algorithmus für die way-prediction des L1-D$ aktiviert, der die Genauigkeit der Vorhersage etwas steigerte (minimal gesenkte effektive L1-Latenz).

[w0mbat]

Und dass der MC bei Zen+ deutlich weniger rumzickt?

[Gipsel]

Und dass der MC bei Zen+ deutlich weniger rumzickt?Keine Ahnung, wieviel davon Firmware-Konfiguration oder stabilerer Betrieb durch die etwas anderen Schalteigenschaften der Transistoren im besseren 12nm-Prozeß sind.

[megachip800]

https://semiaccurate.com/2019/04/15/amd-to-differentiate-cores/

https://semiaccurate.com/2019/04/01/how-many-die-does-amds-milan-have/

Charlie halt... aber vielleicht ein wenig Treibstoff für eine Diskussion "into the wild blue yonder" :)

OT: weiss eigentlich einer warum das Forum auf Semiaccurate nicht mehr erreichbar ist?

[Langlay]

Und dass der MC bei Zen+ deutlich weniger rumzickt?

So gross sind die Unterschiede imo nicht. Mit aktuellem Bios nimmt sich das alles nicht so viel. Ein guter Zen1 MC ist besser als ein schlechter Zen+ MC. Allerdings werden die Zen+ im Schnitt sicherlich etwas besser laufen, aber alles in allem nix Welt bewegendes.

[reaperrr]

OT: weiss eigentlich einer warum das Forum auf Semiaccurate nicht mehr erreichbar ist?
Ja, Charlie hat damit größere technische Probleme gehabt und da er fast alles selbst macht (obwohl er in dem Bereich nicht gerade Profi ist), aber wegen Computex & Co zuletzt zu wenig Zeit hatte, hat sich da noch nichts getan.

Und AMD hat bei Zen1 einfach mal gesagt, nö, so gut müssen die jetzt noch nicht sein?
Siehe Gipsel, wobei man schon sagen muss: Wäre nicht der Zen+ Refresh für knapp ein Jahr später angesetzt gewesen, hätten sie die ~2 Monate wahrscheinlich noch abgewartet und direkt mit den niedrigeren Latenzen gelauncht, haben schließlich zumindest in Spielen noch einiges gebracht.

[Opprobrium]

Ich pack das einfach mal hier rein, auch wenn es teilweise noch um Zen 2 und teilweise schon um Zen 4 geht, und auch Navi etc. mit drin sind:

Anandtech (https://www.anandtech.com/show/14568/an-interview-with-amds-forrest-norrod-naples-rome-milan-genoa) spricht mit AMD über alles mögliche :smile:

Ein paar Zitate:


From day one, I always said to the team that Naples doesn't matter if we don't deliver Rome, if we can't look at our customers and say Rome is on time. By the way, Rome doesn't matter if we don't look at our customers and say Milan is on time, or it doesn't matter if we don't tell customers that we're ready to deliver Genoa. I'm going to stop there because otherwise I'm going to giveaway code names we haven't said yet!

DDR5 is a different design. It will be on a different socket. We've already said Milan is a mid-2020 platform, and we've already said that's socket SP3, so DDR4 will still be used for Milan.

Frontier is not Milan. It’s a custom CPU.

[mironicus]

Kann sich jemand folgendes für Zen 3 vorstellen? Wenn AMD den IO-Chio in der Fertigung auf 7 nm shrinkt, würden im AM4-Package doch locker 3 Chiplets reinpassen, das heißt es gibt dann maximal 24 CPU-Kerne.

AMD verbaut ja bis zu 8 Chiplets um die IO-Chip herum, was bis zu 64 Kerne pro CPU ermöglicht. Aber ob man 1,2 oder 3 verwendet sollte doch eigentlich egal sein, oder? Ein Ryzen 4950x mit 24 Kernen und 105 Watt TDP...? :D

[JVC]

Da glaub ich noch eher an 6+6 Pro Chiplet in 5nm ...
(und vielleicht sogar auf 8+8 in 3nm)

M.f.G. JVC

[HOT]

In 5nm wird man 3 CCX verbauen und fertig. Ich glaub nicht, dass Zen3 und 4 eine andere Topologie hat.

[MSABK]

Wie hoch stehen die Chancen, dass es USB 4 (TB3) geben wird? Gerade im mobilen Bereich wäre das der Durchbruch um mit Intel gleichzuziehen bei den Anschlüssen.

[JVC]

Mit 6+6 könnte man relativ einfach 8 und auch 10Kerne anbieten.
Wenn es soweit ist wird der 8Kerner vermutlich schon unterste Stufe sein...

M.f.G. JVC

[anddill]

Kann sich jemand folgendes für Zen 3 vorstellen? Wenn AMD den IO-Chio in der Fertigung auf 7 nm shrinkt, würden im AM4-Package doch locker 3 Chiplets reinpassen, das heißt es gibt dann maximal 24 CPU-Kerne.

AMD verbaut ja bis zu 8 Chiplets um die IO-Chip herum, was bis zu 64 Kerne pro CPU ermöglicht. Aber ob man 1,2 oder 3 verwendet sollte doch eigentlich egal sein, oder? Ein Ryzen 4950x mit 24 Kernen und 105 Watt TDP...? :D

Wird nicht viel Sinn machen, I/O braucht Fläche und Treiberleistung, da kannst Du nur Buffer und ein bisschen Logik schrumpfen.
Das nächste i/O-Die wird evtl 12nm sein, wenn überhaupt.
Und mehr Kerne macht bei 2 Speicherkanälen auch keinen Sinn mehr. Wenn man sich die ersten geleakten Benchmarks des r9-3950 anschaut dann hat der schon Probleme auf seine 32 Threads noch vernünftig zu skalieren.

[Pirx]

Was macht auf AM4 egtl. überhaupt noch Sinn über den 3950X hinaus? Na gut die Leistung eines CPU-Kerns kann man immer verbessern, so noch möglich.

[Ravenhearth]

Wird nicht viel Sinn machen, I/O braucht Fläche und Treiberleistung, da kannst Du nur Buffer und ein bisschen Logik schrumpfen.
Das nächste i/O-Die wird evtl 12nm sein, wenn überhaupt.
Ist er doch jetzt schon. ;)

[Hammer des Thor]

Und mehr Kerne macht bei 2 Speicherkanälen auch keinen Sinn mehr. Wenn man sich die ersten geleakten Benchmarks des r9-3950 anschaut dann hat der schon Probleme auf seine 32 Threads noch vernünftig zu skalieren.


Ich dachte Zen 4 kommt auf AM 5 mit DDR 5, dass sollte die Speicherbandbreite auf Dauer auf fast den selben Leven wie DDR4 4-Kanal hieven.

[JVC]

Ich dachte Zen 4 kommt auf AM 5 mit DDR 5
Danach sieht es aus.
Aber es geht eigentlich um Zen 3 hier.
Der vermutlich bei 16Kernen bleibt und "nur" IPC und Tackt steigert.
(vage Gerüchte sprechen von bis zu ~+30% in summe)

M.f.G. JVC

[mironicus]

Einfach mehr L3-Cache, das löst das Problem mit der Latenz. Oder vielleicht ein Stacked-L4 Cache mit HBM, dann limitiert DDR4 auch nicht. :D

[Hammer des Thor]

Danach sieht es aus.
Aber es geht eigentlich um Zen 3 hier.
Der vermutlich bei 16Kernen bleibt und "nur" IPC und Tackt steigert.
(vage Gerüchte sprechen von bis zu ~+30% in summe)

M.f.G. JVC


Dass Zen 3 bei 20% höherr Packdichte bei max. 16 Kernen bleibt sollte doch klar sein. Ev. AVX 512 und Detailverbesserungen sollten auch mehr Transistoren schlucken.

[Narolf]

Kann sich jemand folgendes für Zen 3 vorstellen? Wenn AMD den IO-Chio in der Fertigung auf 7 nm shrinkt, würden im AM4-Package doch locker 3 Chiplets reinpassen, das heißt es gibt dann maximal 24 CPU-Kerne.

AMD verbaut ja bis zu 8 Chiplets um die IO-Chip herum, was bis zu 64 Kerne pro CPU ermöglicht. Aber ob man 1,2 oder 3 verwendet sollte doch eigentlich egal sein, oder? Ein Ryzen 4950x mit 24 Kernen und 105 Watt TDP...? :D
Ist imo falsch herum gedacht. Der IO-Chip wird imo in etwa die gleiche Größe behalten, auch wenn er irgendwann in 7nm gefertigt wird. Viele Dinge, die zu IO gehören, lassen sich anscheinend nicht besonders gut shrinken und die Flächenersparnis, die man doch noch durch 7nm bekommt, wird man wohl eher in zusätzliche Features/Cache/eine minimale GPU investieren.

Die CPU-Chiplets werden imo erst mit dem nächsten Fullnodesprung (5nm?) mehr Kerne bekommen. Dann wird das Chiplet 3 oder 4 CCX haben, also 12 oder 16 Kerne. Ich kann mir auch nicht vorstellen, dass sie mehr als 4 Kerne in ein einzelnes CCX packen, der Verdrahtungsaufwand erhöht sich damit viel zu schnell (exponentiell). Einfach mehr CCX auf ein Chiplet zu packen ist der deutlich einfachere Weg und die Scheduler von Linux und Windows kommen mit dem CCX-Aufbau ja mittlerweile auch klar.

[HOT]

Den I/O-Chip braucht man für Vermeer auch gar nicht erneuern. Das wird derselbe sein, ist ja auch für AM4. Aber für Zen4 wird man für AM5 natürlich auch nen neuen I/O-Chip benötigen.
Dank der Chiplets kann Zen3 ja trotzdem größere Architekturupdates erhalten.

[anddill]

Ist er doch jetzt schon. ;)

Ach so? Ich dachte das ist 14nm.

[Thunder99]

14nm ist der X570

[iuno]

Den I/O-Chip braucht man für Vermeer auch gar nicht erneuern.
Wenn man kein USB4 will nicht.

Ach so? Ich dachte das ist 14nm.
Laut Anandtech sollen Rome I/O und X570 14, Matisse I/O 12nm sein.

[HOT]

Der wird auch kein USB4 haben. Sicherlich aber der X670, der dann ja wieder von ASMedia kommt.

iuno
Das ist wohl Absicht so, weil sich in 12nm der Speichercontroller höher takten lassen soll.

[mboeller]

IMHO:

der IO-Chip wird sowieso gestrichen und durch einen aktiven Interposer ersetzt.

Damit passen max. 4 Chiplets drauf bzw. 2 Chiplets + 2x HBM

oder eben für Laptops dann 1 Chiplet + 1 GPU + 2 HBM

[mironicus]

Es gibt Thunderbolt 3 (= USB 4) doch als Luxus-Ausstattung auf mehreren X570-Boards, da kann man jetzt schon zugreifen, wenn man es braucht.

[Screemer]

Es gibt Thunderbolt 3 (= USB 4) doch als Luxus-Ausstattung auf mehreren X570-Boards, da kann man jetzt schon zugreifen, wenn man es braucht.
bisher hab ich noch von evtl. validierung und gelesen, um dann die zusatzkarten wie die ASUS ThunderboltEX 3 nutzen zu können. das da jetzt wirklich schon was fix ist wäre mir neu. hast du da mal nen link?

[mironicus]

Da Intel jetzt Thunderbolt 3 für alle freigegeben hat, ist die Implementierung auf AMD-Boards kein Problem mehr. Das hatte mich auch schon sehr gewundert, dass mindestens 4 Boards mit Thunderbolt 3 kommen sollen. Hier steht mehr:
https://www.heise.de/newsticker/meldung/X570-Mainboards-mit-Wi-Fi-6-Thunderbolt-3-und-luefterlos-4435487.html

Einige X570-Boards bieten Thunderbolt 3, Intel Wifi 6 als auch Intel LAN. Die ganzen Sahnestücke die Intel bietet gibt es jetzt auch bei AMD. :D

[iuno]

Ich vermute eher mal, dass da ganz normale Intel Alpine Ridge verbaut sind, es mit der "Oeffnung" also weniger zu tun hat. Die hat Intel ja sowieso ausgelassen und es gleich als USB4 an die USB-IF uebergeben.
Alpine Ridge verkauft Intel ja schon laenger. Das gibt's auch auf PCIe Erweiterungskarten.

Interessanter fuer AMD wird es natuerlich, wenn man es im Soc integriert hat.

[Screemer]

Alpine Ridge verkauft Intel ja schon laenger. Das gibt's auch auf PCIe Erweiterungskarten.
Da müssten aber die Boards dafür freigegeben sein. Soweit ich mich erinnere sogar mit Whitelist.

[iuno]

Meinst du gerade fuer festes Verbauen der OEMs oder kann es tatsaechlich sein dass ich mir so eine PCIe Karte kaufe und die nicht laeuft, weil das Board nicht "freigegeben" ist?

[davidzo]

IMHO:

der IO-Chip wird sowieso gestrichen und durch einen aktiven Interposer ersetzt.

Damit passen max. 4 Chiplets drauf bzw. 2 Chiplets + 2x HBM

oder eben für Laptops dann 1 Chiplet + 1 GPU + 2 HBM

Das glaube ich nicht, ein Interposer in 12 oder 14nm in der Größe wäre viel zu teuer. Interposer haben zudem meist nur wenige Layer, glaube kaum dass es für hochfrequenzlogik wie den Speichercontroller und PCI4.0 reicht...

[Piefkee]

Ein Aprilscherz.

Der Aprilscherz war, das es keiner war...:)
Die Gerüchte sagen Milan hat 15 Dies. Was man auch immer unter Dies verstehen kann.

[JVC]

Was man auch immer unter Dies verstehen kann.
Kleine Glitzer Steinchen die du überall hin kleben kannst :smile:
(das Design ist fertig, jetzt wird nur noch geschrumpft und perfektioniert)
(5nm "peilen 3 oder gar 4 Dies an"?)

M.f.G. JVC

[prinz_valium]

Ryzen 4000 is my new best friend.

[Tobalt]

Ryzen 4000 is my new best friend.

AM4
B/X 3/400 ?

[prinz_valium]

AM4
B/X 3/400 ?
X370

Gehe davon aus Ryzen 4000 wird ein ähnlicher Sprung wie Ryzen 2000
Leichte Verbesserungen und vor allem mehr Takt.
Genau das fehlt mir noch. Die IPC gains mit Ryzen 3000 waren ja gewaltig. Auch der core count Sprung.

Das werden wir nicht noch mal so schnell sehen.

[JVC]

"Das" werden wir nicht noch mal so schnell sehen.

M.f.G. JVC

[KodeX]

Gibt es schon irgendwelche Infos zum Release der Zen-2-basierten APUs?

[Ravenhearth]

Renoir steht für 2020 auf der Roadmap (vmtl. wieder zum Jahresbeginn), wobei bisher noch nichtmal sicher ist, dass der wirklich Zen 2 und 7nm bekommt. Bei der GPU sah es nach letzten Leaks nach Vega aus...

[w0mbat]

Optimal wäre natürlich "einfach" ein GPU chiplet dort wo beim 3900X das zweite CPU chiplet ist. Und dann noch Navi/RDNA. Warten wirs einfach ab :)

[HOT]

a.) Zen3 ist eine neue Architektur. Das wird also kein Sprung wie bei Zen+ sondern mehr. Ich würd mal mit AVX512 rechnen z.B, das wird sicherlich besonders für Serverworkloads Verbesserungen bieten.
b.) Renoir ist extrem sicher Zen2+RDNA, wahrscheinlich 14CUs und natürlich monolithisch.

[Nightspider]

Wie hoch steht die Chance für RDNA2 in Renoir?

[dildo4u]

Zen 3 ist ein + Refrech die Roadmap hat ihn schon für 2020.

https://www.pcgameshardware.de/AMD-Zen-Architektur-261795/News/CPU-GPU-Roadmaps-Navi-Next-Gen-1256516/

Das neue Design ist Zen 4 in 5nm.

[Nightspider]

Zen 3 ist eben kein refresh

[robbitop]

Bitte daran denken, dass AMD nur 1x Design- und 2x Implementationsteams hat. Wie hoch ist da die Chance für jedes Jahr eine verbesserte mArch? Selbst Intel hat das zu besten Zeiten nur alle 2 Jahre gemacht.

Gab vor ~1 Jahr ja auch diesen AMD Tick-Tock Plan.
https://www.google.com/url?sa=i&source=images&cd=&ved=2ahUKEwjw0-Gqm8jjAhVBNOwKHYDfC9QQjRx6BAgBEAU&url=https%3A%2F%2Fwccftech.com%2Famd-desktop-zen-roadmap-2018-2020%2F&psig=AOvVaw0yh6ljL2Z41jX3THTnJ3qh&ust=1563874147015126

Optimization -> Inflection.

Zen 1 / Summit Ridge steht da unter "Inflection"
Zen + / Pinnacle Ridge steht da unter "Optimization"
Zen 2 / Matisse steht da unter "Inflection"
Zen 3 / Vermeer steht da unter "Optimization"

IMO gibt es bis dato keinen handfesten Grund, da deutlich mehr zu erwarten als angekündigt und was bisher möglich war. Wie gesagt: selbst Intel hat zu besten Zeiten nur alle 2 Jahre deutliche Änderungen an der mArch vorgenommen.
Und dummerweise werden die mArchs expotenziell komplexer und teurer, um noch etwas ggü dem bestehenden herausholen zu können. (Gesetz des sinkenden Grenzertrages).


Ich tippe bei Zen 3 auf kleinere Optimierungen und vor allem (da ist ja noch ordentlich Potenzial): mehr Takt. Neben der Memorylatency einer der wenigen nennenswerten "Schwächen" von Zen 2. Ggf. kann man das Layout nochmal etwas auf Takt optimieren und den leichten Shrink von 7nm+/6nm nicht mitnehmen aber im Gegenzug die erhöhte Performance genießen. (siehe Zen+ - da hat 12 nm ähnliche Effekte gebracht)

[HOT]

Zen1 und 2 sind auch weitgehend parallel gelaufen, das wird sich jetzt nicht ändern. Zen+ ist ne Ausnahme gewesen.

[Nightspider]

Das Ding wird aber nicht umsonst nicht Zen2+ heißen.

[amdfanuwe]

Für den Desktop würde ich mir mit ZEN3 nicht zuviel erwarten. Etwas mehr Takt durch bessere Fertigung in 7nm+ und ein paar Bugs behoben. Die Änderungen dürften eher für den HPC Bereich interessant sein. Da wird man sich die ausstehenden Wünsche zu ROME angehört haben und entsprechend berücksichtigen. KI Erweiterungen etc.

[HOT]

Ne, Zen3 wird eben mMn in erster Linie Zen auf Serverebene auf das Featureniveau von Intel hieven. Zen4 wird dann die passenden Performanceverbesserungen in 5nm bringen, beispielsweise größere L1D und L2-Caches.
Wie gesagt gibts ja nur ein Architekturdesignteam, die werden Zen also suksessive weiterentwickeln. Der nächste Schritt ist mMn echte Server-Kapabilität. AMD wird die RTG für die Funktionsebenen als Basis genommen haben um auch kleinere Verbesserungen schnell serienreif zu bekommen. Dank Chiplets ist das ja jetzt kein Drama mehr.

[Lehdro]

Der nächste Schritt ist mMn echte Server-Kapabilität.
Was meinst du damit genau? Zen (2) wird doch für "echte" Server schon benutzt.

[HOT]

Na alle wichtigen vorhandenen und kommenden Intel-Features (inklusive Icelake SP und Cooperlake) aufholen und eigene hinzufügen, das prominenteste ist AVX512.

[Screemer]

die da wären? avx-512?

[Lehdro]

[...]das prominenteste ist AVX512.
Ich denke das wird für Zen 3 gesetzt sein, was auch wichtig ist, da stimme ich dir zu. Aber bitte von AMD nix halbgares Eigenes bringen, in das man dann Unmengen an Geld und Zeit reinsteckt und es dann trotzdem nicht gegen Intel in den Markt drücken kann. Sowas hatten wir schon einmal (3DNow) und sowas ist zum Scheitern verurteilt wenn man nicht die Marktmacht oder die massiv überlegene oder gar einzigartige Technologie besitzt um das durchzusetzen (x64).

[HOT]

Solange man Erweiterungen zusätzlich bringt ist das doch gut. Und mit steigendem Marktanteil wären auch eigene Befehlssatzerweiterungen interessant.

[iuno]

Ich denke das wird für Zen 3 gesetzt sein, was auch wichtig ist, da stimme ich dir zu.
Sicher?

AMD hat gerade eine "GPU" in der Pipeline, die keine 3D Engine hat. Waere es nicht denkbar, dass man hier doch nochmal den Weg forciert und statt auf so eine fette FPU mit AVX512 auf ein GCN chiplet setzt? Ich meine, wie verbreitet ist AVX512 da draussen? Fuer GCC wird z.B. gerade an GPU offloading fuer GCN gearbeitet, vielleicht schafft man es so sogar ohne explizite GPGPU API.
Ausserdem koennte man dann auch weiterhin von Ryzen mobile bis Epyc dieselben CPU Bloecke benutzen.

[gmb]

Von Zen 3 würde ich mir wünschen, dass sie zu Intels gaming performance aufschließen. Dazu bräuchten sie +15% mehr Leistung. 5% mehr IPC und 10% mehr Takt sollten drin sein mit dem refresh.

[HOT]

Das ist Schwachsinn. Und was für einer :freak:... Die Intels sind aufgrund des Ringbusses vorne bei Spielen, die IPC ist bei Zen2 ja jetzt schon besser. Das hat sich mit der neuen Konsolengeneration eh erledigt, die dafür vorgesehenen Titel werden sowieso CCX-optimiert werden müssen.

[ChaosTM]

6% reichen lt. 3DCenter`s Metascore. :)

[mczak]

Waere es nicht denkbar, dass man hier doch nochmal den Weg forciert und statt auf so eine fette FPU mit AVX512 auf ein GCN chiplet setzt?
AVX-512 macht die FPU kaum fetter, wenn AMD das so implementiert wie ich vermute. Nämlich einfach wieder die 512bit Befehle zerlegen in 2x256bit. Klar es gibt ein paar neue Befehle, und die Logik mit den Maskenregistern will auch implementiert sein, aber flächenmässig dürfte das kaum zu Buche schlagen. (Deshalb bin ich auch eher überrascht dass Zen2 256bit SIMD-Einheiten hat aber kein AVX-512, weil die 256bit Einheiten kosten definitiv Fläche.)

[Lehdro]

AMD hat gerade eine "GPU" in der Pipeline, die keine 3D Engine hat. Waere es nicht denkbar, dass man hier doch nochmal den Weg forciert und statt auf so eine fette FPU mit AVX512 auf ein GCN chiplet setzt?
Kann man machen, Hauptsache man kann das Feature am Ende irgendwie performant abhaken. Nativ wäre aber eigentlich ein Checklistenfeature - vielleicht reicht dann auch 1/2 Performance, wie AVX2 bei Zen 1.

Ich meine, wie verbreitet ist AVX512 da draussen?
Im 08/15 Computing natürlich derzeit eher gar nicht, wenn es wissenschaftlich kann es sehr interessant werden. Langfristig wird es sich sicherlich auch in diversen Encodern seine Nützlichkeit finden, analog zu AVX 2.

Ausserdem koennte man dann auch weiterhin von Ryzen mobile bis Epyc dieselben CPU Bloecke benutzen.
Das kannst und solltest du je nach Implementation auch so - immerhin kommt AVX 512 auch für Intels mobile CPUs mit Ice Lake. Features bestimmten Produktlinien vorzuenthalten ist ja auch eher eine Intel Strategie.

[Sunrise]

AMD wird sich überlegen müssen ob AVX512 wirklich in die CPU muss, denn spätestens mit 5nm steht wohl wieder eine Verdopplung an, aber wenn man die Cores zu stark aufbläst bin ich mir da nichtmehr so sicher.

[gmb]

6% reichen lt. 3DCenter`s Metascore. :)


Kommt ja auch hin wenn man GPU limtierte Tests mit einbezieht und von DDR-2666 ausgeht. Ich meine natürlich CPU limitierte Spiele und den gleichen RAM für die Intel. Hier müsste AMD etwa 15% zulegen, damit sie aufschließen, also zum 9700k oder 9900K.

[Bambuslooter]

Ob es zwischen 7nm+ und 6nm überhaupt einen spürbaren Unterschied geben wird? Könnten doch glatt 7nm+ überspringen, wenn man für Zen4 eh schon mit den Zahlenspielen AM5, 5nm, DDR5 um die Ecke kommt.
Taktanhebung in Richtung 5Ghz, wenn auch nur 1 Kern wäre für das Marketing natürlich schön.

[Complicated]

AMD sollte sich nicht mit AVX512 selber Konkurrenz für Ihre Server-Beschleuniger GPUs machen.
Wenn man so liest wie sich AVX512 vs. GPGPU-Implementationen schlägt, so kommt schnell der Eindruck auf es ist obsolet und schon längst überholt.
verschiedene Meinungen dazu kann hier mal lesen...und das ist schon 2 Jahre her:
https://news.ycombinator.com/item?id=15987796

Zumal AMD gerade eine reine Server-GPU-Reihe ohne Grafik-Ausgabe angekündigt hat mit Arcturus: https://www.computerbase.de/2019-07/amd-arcturus-vega/

Ich würde sagen hier besteht kein Druck AVX512 zu nutzen wenn schon iGPUs die selbe oder bessere Beschleunigungen bringen. Es ist wie immer eine Frage des Ansatzes den die Software-Leute wählen. Der größte Vorteil für AVX ist hier wohl die umfangreiche Software-Unterstützung durch Intel. Irgendwie eine ähnliche Situation wie bei Gameworks von Nvidia vor einer Weile im Grafikkartenmarkt.

Ob es zwischen 7nm+ und 6nm überhaupt einen spürbaren Unterschied geben wird? Könnten doch glatt 7nm+ überspringen, wenn man für Zen4 eh schon mit den Zahlenspielen AM5, 5nm, DDR5 um die Ecke kommt.
6nm kommen erst nach 7nm+ in 2021 und bringt in erster Linie massive Kostenverbesserungen. Wer 7nm+, wie AMD, nutzt kann mit 6nm vielleicht ab 2022 noch laufende 7nm DUV Designs kostensparend auf 6nm portieren wie der 14nm->12nm Step. Nur sehe ich kein Produkt bei AMD in 7nm das in 2022 noch für 6nm in Frage kommen könnte. Vega20 und Ryzen 1/2 werden bis dahin auslaufen und sich kaum lohnen noch für einige Jahre weiter produziert zu werden. Allerdings könnten die Pro-Versionen der Zen-CPUs/APUs dafür Kandidaten sein, wenn man denn nicht auf Halde produzieren möchte für die 2 Jahre Liefer-Garantie der PRO-Versionen. Aber auch hier fraglich ob in 3 Jahren noch irgendetwas unterhalb von Zen2 benötigt/gefragt wird im Markt, das dann noch 2 weitere Jahre einen extra-günstigen Prozess für die Masse benötigt. Embedded vielleicht.

[Unicous]

"6nm" bringt zwar eine Flächenreduktion, bei 7nm+ ist diese nominell aber höher und zusätzlich gibt es eine Reduktion der Leistungsaufnahme.

6nm wird vermutlich etwas günstiger sein, aber nicht "besser" als 7nm+.

[robbitop]

Wie wichtig ist denn AVX512 überhaupt in der Anwendung aktuell?

Ich bleibe weiterhin skeptisch was Zen 3 angeht. AMD schreibt nicht aus Spaß „Optimization“ in die Roadmap.
Zen+ hatte ja wirklich null Änderungen in der HW. Ich tippe mal darauf, dass ab jetzt die Optimizations zumindest geringe HW Änderungen wie die Intel Ticks bringen werden. Vgl IVB, BDW, CNL

Das würde ggf auch eine andere Zahl rechtfertigen.

[dildo4u]

Kommt ja auch hin wenn man GPU limtierte Tests mit einbezieht und von DDR-2666 ausgeht. Ich meine natürlich CPU limitierte Spiele und den gleichen RAM für die Intel. Hier müsste AMD etwa 15% zulegen, damit sie aufschließen, also zum 9700k oder 9900K.
Zen 2 wird in keinem Fall mit 3600 gebencht vs Intel mit 2666.
3200 ist bei AMD genau wie 2666 bei Intel nicht ideal Konfig.

[maximus_hertus]

Kommt ja auch hin wenn man GPU limtierte Tests mit einbezieht und von DDR-2666 ausgeht. Ich meine natürlich CPU limitierte Spiele und den gleichen RAM für die Intel. Hier müsste AMD etwa 15% zulegen, damit sie aufschließen, also zum 9700k oder 9900K.

Läuft ausnahmslos JEDE Board/CPU/RAM Kombi immer mit 3600 MHz stabil? Ich meine wirklich IMMER, nicht 99%, sondern 100%. Ziemlich sicher nicht.

Sogar garantiert nicht. Nur Z Boards können über 2667 MHz gehen. Ergo die Minderheit der Boards. Sogar deutlich die Minderheit.

Am Ende weiß Intel wohl am besten, dass es über 2667 MHz zu Problemen kommen könnte. Vielleicht nur extrem selten. Aber sie sind ja nicht komplett dämlich und lassen einfach so Performance liegen.

[Piefkee]

Kommt ja auch hin wenn man GPU limtierte Tests mit einbezieht und von DDR-2666 ausgeht. Ich meine natürlich CPU limitierte Spiele und den gleichen RAM für die Intel. Hier müsste AMD etwa 15% zulegen, damit sie aufschließen, also zum 9700k oder 9900K.

Boa kannst du nicht einfach dein fanboy dreck wo anders abliefern. Es nervt einfach.

[Piefkee]

Wie wichtig ist denn AVX512 überhaupt in der Anwendung aktuell?

Ich bleibe weiterhin skeptisch was Zen 3 angeht. AMD schreibt nicht aus Spaß „Optimization“ in die Roadmap.
Zen+ hatte ja wirklich null Änderungen in der HW. Ich tippe mal darauf, dass ab jetzt die Optimizations zumindest geringe HW Änderungen wie die Intel Ticks bringen werden. Vgl IVB, BDW, CNL

Das würde ggf auch eine andere Zahl rechtfertigen.

Ich glaube am Core wird man nichts machen. Aber man wird einiges am IO machen. Der zieht aktuell 12Watt (CPU und x570 Mainboard). Ich denke für Desktop wird Zen 3 so aussehen:
CPU chiplet = 7nm+ (kleine Optimierungen + 200-300Mhz)
IO Die = 7nm DUV ( kleiner/Stromverbrauch)

[basix]

Die Worst Case Latenz zwischen den Cores wurde recht stark gesenkt veeglichen zu Zen 1 (glaube von 110ns auf 75ns). Bei den Best Case Latenzen ist man sogar deutlich unter Intel. Habe einen Link mit passender Aufbereitung der Daten gefunden: https://www.reddit.com/r/Amd/comments/calue1/intercore_data_latency/

Kommt AMD mit "moderaten" Anpassungen auf <60ns und das selbe beim RAM wäre das schon ein massiver Sprung. Da noch etwas Takt und IPC drauf und man hat ein Design ohne wirkliche "Schwächen".

[robbitop]

Ggf schon ein DDR5 IMC im neuen IO. Der Großteil vom Verbrauch kommt ja vom IO - also von den PHYs. PHY vom IF, PCIe, IMC. Das skaliert eigentlich nicht so besonders mit einem Shrink. Weder von der Fläche noch vom Verbrauch. Ggf kann man aber irgendwann mit einem Shrink noch einen L4 verbauen. Damit der was bringt, müsste die Latenz aber besser <40 ns sein.

Ich tippe auf vor allem etwas Optimierung für den Takt. Ggf kann man auch noch ein bisschen Latenz rauskitzeln. Ich tippe auf <+5% mehr taktnormierte Leistung und auf rund 10% mehr Takt.

[Th3o]

Boa kannst du nicht einfach dein fanboy dreck wo anders abliefern. Es nervt einfach.
Man sollte für die Intel Boyz einen Thread mit dem Namen "Ätschi Bätschi ich habe den längsten" einrichten, damit sie darin rumschwadronieren können.

[Locuza]

DDR4 ist für Zen3 bzw. genauer Milan (EPYC Server) von AMDs Forrest Norrod bestätigt:
PCWatch: Support for DDR5?

Forrest Norrod: DDR5 is a different design. It will be on a different socket. We've already said Milan is a mid-2020 platform, and we've already said that's socket SP3, so DDR4 will still be used for Milan.
https://www.anandtech.com/show/14568/an-interview-with-amds-forrest-norrod-naples-rome-milan-genoa?utm_source=twitter&utm_medium=social

Wenn die ersten Einträge von AIDA64 stimmen, dann wird Zen3 auch zumindest AVX512-F unterstützen:
https://st.overclockers.ru/images/news/2017/12/19/zen2_01.png
https://translate.google.de/translate?sl=ru&tl=en&u=https%3A%2F%2Foverclockers.ru%2Fhardnews%2Fshow%2F88556%2Faida64-gotova-k-rabote-s-processorami-amd-pokoleniya-zen-2

[HOT]

Soviel zu "kleinem Update" oder "Zen2+". Das I/O-Die wird sich nicht ändern. Das wird erst bei Zen4 erneuert, da dort ja AM5 zu erwarten ist. Vermeer wurde glasklar für AM4 angekündigt.

[MSABK]

Man sollte für die Intel Boyz einen Thread mit dem Namen "Ätschi Bätschi ich habe den längsten" einrichten, damit sie darin rumschwadronieren können.

Ich verstehe auch nicht warum man da drauf rumreitet, dass Intel immer noch schneller ist.

Ja Intel mag in Games schneller sein, aber AMD schläft nicht und auch wenn man 2020 "nur" 15% (als Beispiel) schneller als der 9900K wäre, wäre das immer noch ein Erfolg für das Tot geglaubte AMD.

[w0mbat]

Vor allem ist Intel nur noch in Spielen, und auch dort nicht mehr in allen, schneller. In Anwendungen war schon Zen(+) auf oder über Intel-Niveau, Zen2 zersägt hier Intel.

Zen2 hat einfach wirklich mehr IPC, das gleich den etwas geringeren Takt gut aus. In Spielen liegt CFL meistens noch etwas vorne, da es eben noch eine alte ringbus Architektur ist.

[reaperrr]

Ich glaube am Core wird man nichts machen. Aber man wird einiges am IO machen. Der zieht aktuell 12Watt (CPU und x570 Mainboard). Ich denke für Desktop wird Zen 3 so aussehen:
CPU chiplet = 7nm+ (kleine Optimierungen + 200-300Mhz)
IO Die = 7nm DUV ( kleiner/Stromverbrauch)
Der IO-Die wird m.E. der gleiche sein wie bei Matisse.
Etwaige Einsparungen wird man mMn anders bewerkstelligen:

Es gibt ja das 1. April-Gerücht von semiaccurate (https://www.semiaccurate.com/2019/04/01/how-many-die-does-amds-milan-have/), dass Milan 15 Chiplets haben soll, also 1 IO + 14 CCDs (ich tendiere nach wie vor dazu, dass nur das Drumherum ein Scherz war, die Zahl selbst aber nicht). Da die Flächeneinsparung durch 7nm+ dafür auf keinen Fall reichen würde, würde ich mit Charlie Demerjians Spekulation (hinter der Paywall) mitgehen, dass AMD auf Zen3-Chiplets nur noch 6 Kerne verbaut und (jetzt kommt meine eigene Speku) zwar in nur einem CCX, genauer gesagt dass das CCX-Prinzip wegfällt und es im Grunde nur noch CCDs (CoreComplexDies) geben wird.

Dadurch könnte man je Chiplet ~1/4 der Kernfläche und 1/2 der IF-Fläche einsparen, und den IF-Verbrauch je Chiplet halbieren. Ein bisschen davon wird in Kernverbesserungen re-investiert, der Rest geht in Flächen- und Verbrauchsreduktion je Chiplet.

Im Server-Bereich käme man dadurch immerhin auf bis zu 20 zusätzliche Kerne bei 2 weniger IF-Links (14x1 statt 8x2), bei Vermeer wären die 6C-Modelle noch günstiger zu produzieren und würden zudem komplett von der CCX-Strafe für Thread-Wechsel zwischen 2 CCX befreit werden, und Modelle mit 2 CCDs würden nicht nur 12C und 8C erlauben, sondern auch 10C, was vorher mit 4 CCX nicht ging (da wohl je CCX immer gleich viele Kerne deaktiviert werden müssen).
Mit Ausnahme der 8C-Modelle hätte dann alles bis hinauf zu 12C noch weniger Silizium-Fläche als bei Zen2, bei reduziertem IF-Overhead (und -Verbrauch).

Und den 3950X könnte man evtl. durch ein 18C-Modell mit 3 CCDs ersetzen, wenn sie die CCDs auf ~55-50mm² runterkriegen, sind 3 CCD kaum bis gar nicht größer als 2 Zen2-CCDs, bei immer noch einem IF-Link weniger (3 statt 4).


Zu den Kernen selbst: Im Interview mit Ian Cutress auf anandtech (https://www.anandtech.com/show/14568/an-interview-with-amds-forrest-norrod-naples-rome-milan-genoa) hat Forrest Norrod von AMD gesagt, die ursprüngliche Planung (als man noch davon ausging, dass Intel 10nm und Ice Lake normal hinkriegt) sah vor, dass man mit Zen3 IPC-Gleichstand (oder besser) in allen Workloads erreichen wollte.
Nun kann es natürlich sein, dass AMD in seinen Planungen nicht mit 18%, sondern nur ~10-12% mehr IPC für Ice Lake gerechnet hat, dass man wirklich an Ice Lake's IPC rankommt kann ich mir auch nicht vorstellen.
Aber: Danach, dass Zen3 nur ein verkappter Zen2+ mit vllt. 2-3% mehr IPC und ~200-300 MHz mehr Takt ist klang das jetzt nicht gerade, sondern eher danach, dass auch Zen3 durchaus größere IPC-Verbesserungen bringen könnte, zumindest für manche Workloads. Und wenn man "IPC parity (or better) across all workloads" mit ICL erreichen wollte, ist AVX512 eigentlich Pflicht, nebst weiteren Verbesserungen in anderen Bereichen.

Edit: OK, durch Locuza's Beitrag geninja'd. Ist dann wohl doch nur Zen2+(+). Wobei für AVX512 trotzdem noch weitere Änderungen an der Pipeline vorgenommen werden müssten, außer es ist nur "half-rate" AVX512 (also nur Support, aber nicht voller Durchsatz wie bei ICL).

[mczak]

DWobei für AVX512 trotzdem noch weitere Änderungen an der Pipeline vorgenommen werden müssten, außer es ist nur "half-rate" AVX512 (also nur Support, aber nicht voller Durchsatz wie bei ICL).
ICL (zumindest die Client-Version) hat auf keinen Fall full-rate avx512. Das offizielle Diagramm lässt da einiges im Unklaren, aber der Chip kann auf jeden Fall nur 1x512bit fma pro Takt (wahrscheinlich parallel dazu noch 1 256bit fma). "Einfache" ALU-Operationen sollten 2x512bit sein (gegenüber 3x256bit).
Da AMD ja prinzipiell 4 SIMD Pipes hat (gegenüber 3 von intel) wäre man da eventuell auch mit half-rate avx 512 schon recht nahe dran (wobei schon klar, diese 4 Ausführungseinheiten können auch nicht alle alles).

[robbitop]

Soviel zu "kleinem Update" oder "Zen2+". Das I/O-Die wird sich nicht ändern. Das wird erst bei Zen4 erneuert, da dort ja AM5 zu erwarten ist. Vermeer wurde glasklar für AM4 angekündigt.
Du Opportunist. :D
Wer sagt denn, was kleine und was große Änderungen sind? Single Cycle 512bit AVX wäre aber IMO schon eine recht große. Double Cycle hingegen...?

[HOT]

Missverständnis: CCD mindestens mittelgroße Änderungen, I/O 0 Änderungen. Sprich man verlötet statt 7nm-Matisse-Dies einfach 7nm-Vermeer-Dies, rest bleibt gleich. Problem: Neuer µCode erforderlich. Lösung: Support erst ab 570 (oder MSI-MAX-Serie).

[N0Thing]

Wie wichtig ist denn AVX512 überhaupt in der Anwendung aktuell?

Ich bleibe weiterhin skeptisch was Zen 3 angeht. AMD schreibt nicht aus Spaß „Optimization“ in die Roadmap.
Zen+ hatte ja wirklich null Änderungen in der HW. Ich tippe mal darauf, dass ab jetzt die Optimizations zumindest geringe HW Änderungen wie die Intel Ticks bringen werden. Vgl IVB, BDW, CNL

Das würde ggf auch eine andere Zahl rechtfertigen.

Ich habe den Link leider nicht parat, aber ein AMD-Mitarbeiter hat doch in einem Interview zu Zen2 gesagt, dass sie einige Elemente, die für Zen3 vorgesehen waren, vorgezogen und in Zen2 implementiert haben.
Zusammen mit der Aussagen, dass man sich bei Zen2 auf die Serverperformance konzentriert habe, was Abstriche bei den Taktraten zur Folge hatte, würde ich für Zen3 eher einen kleineren Schritt bei der Architektur erwarten und in Kombination mit 7nm+ auf höhere Taktraten bei evtl. leicht erhöhtem Power-Budget spekulieren.
Dass Zen+ quasi keine Änderungen bei der Hardware bekommen hat, würde ich der Fokussierung auf die termingerechte und möglichste fehlerfreie Einführung von Zen zuschreiben.
Mit Zen4, neuem Speicherinterface und neuem Sockel, hat AMD eh schon genug für die nahe Zukunft zu tun, als dass man sich bei Zen3 weit aus dem Fenster lehnen könnte.

[Nightspider]

Das IO Chiplet wurde doch primär wegen der geringen Kosten im alten Fertigungsverfahren hergestellt.
Ich könnte mir schon vorstellen, dass das bei Zen 3 geshrinked wird mit kleinen Anpassungen um mehr Platz für Chiplets, kürzere Signalwege und vielleicht bessere Frequenzen/Latenzen zu erreichen, unter anderem auch weil eh Fertigungskapazitäten bei 12nm und 10nm frei werden und dort die Kosten eventuell stark genug fallen.

[Unicous]

Es sind nicht nicht nur die Herstellungskosten bei 12nm. "I/O" skaliert nicht so gut bei node shrinks, die Flächeneinsparungen wären also deutlich geringer, ergo hätte man einen großen Die der zudem auch noch viel kostet.

Außerdem wird der Chip wahrscheinlich sehr warm und durch die größere Fläche kann die Wärme besser abgeführt werden.

Es ist eher wahrscheinlich, dass man bis auf Weiteres bei 12nm bleibt.

[robbitop]

So ist es. Interfaces shrinken kaum und Energietransfers kosten numal Leistung. DDR, ettliche PCIe Lanes, IF.
Weniger Fläche hieße dann mehr Energiedichte. 12/14nm ist schon sinnvoll und günstiger. Andererseits könnte man mit 7nm ggf nochmal einen L4 einbauen. (aber wahrscheinlich reine Wunschvorstellung) eher stackt man irgendwann mal DRAM oben drauf.

[amdfanuwe]

Hier gibt es ein paar Dieshoots zu Matisse
https://www.flickr.com/photos/130561288@N04/with/48304518017/

[basix]

Sind schon etwas länger online, nur die letzten paar sind neu & bearbeitet. Aber wie immer erstklassige Arbeit von ihm.

[Screemer]

Was für eine Monster apu

https://pbs.twimg.com/media/EArRLgaUwAAj7ew?format=jpg&name=large (https://twitter.com/Underfox3/status/1155966262809264129)

[amdfanuwe]

Hier die Studie von 2016 dazu:
http://www.computermachines.org/joe/publications/pdfs/hpca2017_exascale_apu.pdf

[Screemer]

Schönen Dank. Geht's auch noch herablassender? Mir war nicht bekannt, dass es so alt ist. Kam heut im Tweet zu "neuen" amd Patenten.

[amdfanuwe]

Sorry, sollte nicht herablassend sein. Habs geändert.

[Screemer]

Hab ich wohl in den falschen als bekommen. Entschuldigung!

[amdfanuwe]

Schon OK, war blöd formuliert.

[BoMbY]

Ist zwar nicht ganz der passende Thread, aber hat jemand eine Ahnung was für ein System da in diesem Frontier-Video (https://vimeo.com/334502343) gezeigt wurde:



https://i.imgur.com/BqkeLDW.jpg

https://i.imgur.com/hKeR7f4.jpg

https://i.imgur.com/HkkvPfO.jpg

https://i.imgur.com/5F6OeH4.jpg

https://i.imgur.com/eo2EFDj.jpg

https://i.imgur.com/AuQIGMF.jpg

[Complicated]

Sind doch die Shasta-Nodes von Cray für den Frontier 1,5 Exaflop:
https://www.servethehome.com/cray-and-amd-win-big-contracts-for-1-5-exaflop-frontier-supercomputer/
Dieses Bild scheint mir mit den beiden letzten von dir übereinzustimmen:
https://www.servethehome.com/wp-content/uploads/2018/11/Cray-Shasta-AMD-EPYC-Node.jpg

[BoMbY]

Ja, der Heat Spreader auf den ersten Bildern sieht jedenfalls irgendwie nach AMD aus, wobei das ja nichts heißt, aber die die Einschübe dort scheinen 4 HE zu haben, und kein RAM direkt neben den CPUs. Und laufen die wirklich ohne Kühlkörper?

[mironicus]

Bestimmt wird das ganz lustig, wenn Zen 3 einen noch höheren Infinite Fabric-Takt unterstützen wird und dann auch RAM jenseits der 4000 MHz im 1:1-Modus laufen kann. Das könnte ein Großteil der FPS-Steigerungen in Spielen ausmachen.

[tm0975]

Die Ryzen 4000-Vorstellung liegt nun nicht mehr in der Hand des berühmt-berüchtigten AMD-Marketing-Praktikanen:

https://www.wuv.de/agenturen/tbwa_london_sichert_sich_kreativetat_von_amd

[davidzo]

Ja, der Heat Spreader auf den ersten Bildern sieht jedenfalls irgendwie nach AMD aus, wobei das ja nichts heißt, aber die die Einschübe dort scheinen 4 HE zu haben, und kein RAM direkt neben den CPUs. Und laufen die wirklich ohne Kühlkörper?

Definitiv laufen die nicht ohne Kühlkörper, der Heatsink wird volle 4HE haben und als Towerkühler in dem Luftstrom der Lüfter liegen die man da oben sieht.

Die wollen mit dem Video nur andeuten dass sie diesmal echte HPC RAS-features haben, a la IBM und Intel z.T. Also CPU + RAM hot swap.


Dass man keinen RAM sieht ist erstaunlich, genauso wenig sieht man aber PCIe oder GPUs direkt.
Das könnte daran liegen das man ganz auf HBM on Package setzt und die GPUs ja auch on Package liegen.

Eine andere Erklärung wäre dass dieses nur der 4x GPU-Teil ist und die CPU direkt gar nicht sichtbar ist, bzw. weiter vorne zwischen den RAM Slots liegt. AMD würde somit auf gesockelte GPUs mit HBM on Package wechseln, wie das Intel mit Knights Mill ja auch getan hat.
Die Steckbaren Module neben den Sockeln sind mit Chokes vollgepflanzt, das deutet auf extreme Stromstärken hin.

Der Shasta Blade unten sieht aber ganz anders aus, viel eher nach einer All-CPU Lösung. Ist das nicht vielleicht ein Stock-foto von irgendwelchen aktuellen Shasta blades?

[Karümel]

https://www.pcgameshardware.de/CPU-CPU-154106/News/Zen-3-verlaesst-die-Designphase-Arbeiten-an-Zen-4-haben-begonnen-1307266/
AMD: Zen 3 verlässt die Designphase.....
Während Zen 2 aktuell gerade erst im Handel durchgestartet ist, habe man bei AMD bereits die Designphase der Nachfolge-Architektur, Zen 3, abgeschlossen. Der geplante Markstart wird unverändert für das nächste Jahr und damit 2020 in Aussicht gestellt, womit AMD der eigenen Roadmap treu bleibt. Man sei "on track", heißt es auf den Präsentationsfolien. Die Desktop-Prozessoren für den Mainstream-Bereich auf Basis von Zen 3 tragen den Codenamen Vermeer. Die Fertigung erfolgt unterdessen im verbesserten 7nm-Verfahren. AMD wolle bei Zen 3 zudem verstärkt auf Extreme-Ultraviolet (EUV) setzen.

[MSABK]

Das liest sich doch wunderbar. Wenn Amd jetzt konsequent noch einige % zulegt, dann sind sie auch in den Spielen durchgängig schneller. Bis 2020 wird Intel nicht viel bringen außer 14+++++nm.

[Benutzername]

Die Ryzen 4000-Vorstellung liegt nun nicht mehr in der Hand des berühmt-berüchtigten AMD-Marketing-Praktikanen:

https://www.wuv.de/agenturen/tbwa_london_sichert_sich_kreativetat_von_amd

"AMD-Marketing-Praktikant"? :confused:

[Unicous]

Ist natürlich Bullshit. AMD hat schon seit Jahren eine externe Marketing-Firma, aber natürlich machen die nicht alles, da ging es eher um die generelle Strategie. Und wie in der PM zu lesen ist, waren diese Maßnahmen wohl auch eher auf die USA beschränkt.

Jetzt scheint man es komplett outsourced zu haben. Wir werden sehen, ob es so etwas wie The Fixer noch einmal geben wird.:wink:

[M4xw0lf]

Nichts gegen den Fixer, hmkay :freak:

[Blediator16]

Den Fixer wird es eher bei Intel geben :cool:

[Zossel]

Den Fixer wird es eher bei Intel geben :cool:

Quatsch, die koksen alle :-)

[MSABK]

Hoffentlich implementieren sie direkt USB4/TB3 noch in den CPU.

[Complicated]

Ende 2020 kommen die ersten Geräte mit USB4:
https://www.anandtech.com/show/14526/usb-if-usb4-coming-in-late-2020

Und AMD hat gar keinen USB mehr in den CPUs integriert, sondern in dem I/O Chiplet ;)
Ich bin ja gespannt ob hier AMD einfach ein neues I/O-Chiplet in seinem eigenen Rhythmus mit Interconnects ausstattet - das wäre mal etwas neues, wenn CPUs einfach mit den aktuellen I/Os ein Zwischen-Refresh machen können ohne irgendetwas an der Produktion der CPU zu ändern. Man müsste da nur abwägen ob sich das lohnt von den Kosten und dem Mehrwert im Markt.

[y33H@]

Man könnte Refresh Chipsets und somit Boards auflegen, joa.

[Locuza]

With Rome having just launched, Su remained tight-lipped about Milan's expected performance gains. But she did say that AMD is pleased with what it has done with its Zen 3 CPU core microarchitecture, which will power Milan as well as future Ryzen PC CPUs and just saw design work conclude. Su also said that both Zen 3 and a successor microarchitecture known as Zen 4 will feature "plenty of ideas" that AMD engineers came up with based on what they learned from Naples and Rome. "We'll talk more about it as we get closer," Su said.

Su also said AMD will share more later about its plans for using Taiwan Semiconductor's (TSM) next-gen, 5-nanometer (5nm), manufacturing process, which is set to enter volume production during the first half of 2020. Notably, Milan won't be using TSMC's 5nm process, but rather a 7nm+ process that recently entered volume production and delivers moderate improvements relative to the 7nm process used by Rome.
https://www.thestreet.com/technology/amd-ceo-lisa-su-data-center-alliances-strategy-15052368

Bei Zen3 erwarte ich spekulativ Half-Rate AVX512-Support, offensichtlich eine bessere IPC.
Es wird gemunkelt das AMD mit Milan sogar noch mehr Chiplets an ein I/O-Die verbinden wird (Charlie von SA meinte 15 Chiplets), womit man auch die Vermutung anstellen kann, dass die CCX-Größe vielleicht geändert wird.
Aktuell ist es in gewisser Weise ein Problem das Rome 16 CCX hat und alle über den I/O-Die kommunizieren.
Ebenso ist der L3$ entsprechend als 16x16MB partitioniert.
Um das nicht weiter zu eskalieren, wird AMD vielleicht die Kernzahl innerhalb eines CCX erhöhen.

Frontier könnte dabei ein Custom-Cores basierend auf Zen3 sein, mit Full-Rate AVX512-Support und/oder mehr Instruktionen.


PS: Zen 4 launched vermutlich am 05.05.2021, mit DDR5- und PCIe5-Support, hergestellt unter 5nm. :freak:

[rentex]

😂👍

[tm0975]

Nichts gegen den Fixer, hmkay :freak:

ich finde das hier legandär!

https://www.youtube.com/watch?v=1DPQW0e9ufM

[HOT]

Hm ein Träger mit nur noch 3 CCX und maximal 18 Cores für AM4? Hört sich lustig an. I/O-Die würde ja gleich bleiben, dann wäre nur ein CCX nicht angeschlossen.
Für Server gilt da ähnliches, statt 16 CCX könnte man 14 6-Kern-CCX anbinden, wäre man bei 84 Kernen max.

[basix]

Ich tippe ja eher auf 8C CCX und dass ein Chiplet nur noch 1x CCX beinhält. Wäre für mich schlüssiger. Möglichst viele Daten auf dem Chiplet vorhalten und Out-of-Chiplet Kommunikation niedrig halten ist vermutlich schon der Weg, den man gehen muss. Das 4C CCX Design hat allerdings den Vorteil, dass die 4 Kerne mit einer geringen Anzahl Verbindungen direkt miteinander kommunizieren können. Die grosse Frage ist dann, wie man bei 6C oder 8C das macht, ohne das Interface aufzublähen. Ringbus? :D

Was viel bringen würde und zudem über die gesamte CPU skaliert sind weitere Optimierungen am IF. Kann man hier z.B auf 2/3 gesenkte Latenzen optimieren und das selbe beim pJ/bit ergäbe das eine massive Verbesserung. Zudem profitieren alle Produkte von Mobile, Desktop und Server davon. Mobile und Server vor allem von Perf/Watt. Desktop / Gaming aber auch gewisse Serverapplikationen von Latenz.

[Complicated]

Man könnte Refresh Chipsets und somit Boards auflegen, joa.
Ja, das wäre aber ja nicht sonderlich neu. Eine zusätzliche Option ist einfach den I/O-Die auf Version USB4 zu refreshen und nahtlos im Packaging zu verwenden für die CPU. Die Kosten sind verglichen zu früheren Refreshes, die ja immer ein kompletter CPU-Refresh waren, enorm geringer und könnten einen schnelleren Update-Rhythmus bedeuten. Man hat die eigenen CPU-Designs von diesen Peripherie-Entwicklungen entkoppelt und kann nun deutlich schneller die CPU-Architektur voran treiben.

Stell dir zu neuen Mainboards mit Chipset auch einfach neue SoCs mit integriertem USB4 vor, die in den bisherigen Bords auch laufen. So wie jetzt PCIe4 mit Zen2 gern gesehen werden würde auf den 3xx/4xx-Chipsets-AM4 Plattformen. Die Mainboardhersteller waren jedenfalls schärfer drauf dies auf alten Boards zum laufen zu bringen als man erwarten könnte, für Unternehmen deren Interesse es eher ist neue Boards zu verkaufen. Für USB4 könnte dies machbar sein, da weniger Sprung in der Leistungsaufnahme zu befürchten ist. Dazu weitere Verbesserungen zum I/O-Controller, IF-Upgrade und was sonst noch alles verbessert werden kann auf dem I/O.
- Neues Board und dein 16-Core ist mit dem Chipset besser ausgerüstet.
- Neue CPU und deine Plattform erhält über den SoC ein Upgrade.
Es gibt immer einen Zeitpunkt wo das eine dem anderen gegenüber bevorzugt wird - so hat jeder die Wahl und die Bindung an die Plattform verstärkt sich durch die Flexibilität.

[HOT]

Ich tippe ja eher auf 8C CCX und dass ein Chiplet nur noch 1x CCX beinhält. Wäre für mich schlüssiger. Möglichst viele Daten auf dem Chiplet vorhalten und Out-of-Chiplet Kommunikation niedrig halten ist vermutlich schon der Weg, den man gehen muss. Das 4C CCX Design hat allerdings den Vorteil, dass die 4 Kerne mit einer geringen Anzahl Verbindungen direkt miteinander kommunizieren können. Die grosse Frage ist dann, wie man bei 6C oder 8C das macht, ohne das Interface aufzublähen. Ringbus? :D

Was viel bringen würde und zudem über die gesamte CPU skaliert sind weitere Optimierungen am IF. Kann man hier z.B auf 2/3 gesenkte Latenzen optimieren und das selbe beim pJ/bit ergäbe das eine massive Verbesserung. Zudem profitieren alle Produkte von Mobile, Desktop und Server davon. Mobile und Server vor allem von Perf/Watt. Desktop / Gaming aber auch gewisse Serverapplikationen von Latenz.

Ich glaub nicht, dass man einen Ringbus macht. Das würde die ganze Idee ad absurdum führen. Deshalb denke ich auch nicht, dass es ein 8C CCX geben wird fürs erste. 6 C erhöht die Komplexität schon enorm, aber vielleicht gut machbar, ohne die Latenz wirklich merklich über 25ns springen zu lassen. Dafür dann 24 oder 32MB L3$ verbauen wär grad in Server-Workloads hilfreich. Vielleicht gibts ja 6C bei Zen3 und 8C bei Zen5 (dann in 3 oder 4nm).

Potenzielles AM4-Lineup für so eine Lösung:
4500/4600(X) -> 6C (1/2 CCX) (salvage)
4700(X) -> 8C (2 CCX) (salvage)
4800X -> 12C (2 CCX)
4900X -> 18C (3 CCX)

[Der_Korken]

Wodurch wird eigentlich bestimmt, dass unter jedem L3-Slice genau ein Kern hängt? Oder was würde passieren, wenn man einfach zwei Kerne an jeden Slice hängt? Zu wenig Durchsatz, weil sich dann im Schnitt zwei Kerne die Lese-/Schreibrate teilen?

[Zossel]

Die grosse Frage ist dann, wie man bei 6C oder 8C das macht, ohne das Interface aufzublähen. Ringbus? :D

Ich tippe darauf das Ringbus langsamer wäre als die bisherige Vollvermaschung.

[Setsul]

Wodurch wird eigentlich bestimmt, dass unter jedem L3-Slice genau ein Kern hängt? Oder was würde passieren, wenn man einfach zwei Kerne an jeden Slice hängt? Zu wenig Durchsatz, weil sich dann im Schnitt zwei Kerne die Lese-/Schreibrate teilen?
Geometrie.
Das sind keine unabhängigen Slices wie bei Intel wo jeder Kern erstmal seine "eigene" Slice hat die auch dafür zuständig ist Inklusivität zu wahren sondern dass ist ein großer L3 bei dem je ein Viertel der Adressen in jeder Slice landen.

Man könnte das teilweise oder ganz zentralisieren, aber es bringt keinen Vorteil. Wenn ein Kern eine Anfrage an einen monolithischen L3 schickt dann muss der L3 zentral alle tag checks bearbeiten und der Kern muss bei der Latenz vom Schlimmsten ausgehen. Schließlich ist die Chance 75% dass die Daten näher an einem anderen Kern liegen. Der geviertelte L3 muss an 4 Stellen nur ein Viertel der Anfragen bearbeiten und der Kern kann schon an der Adresse ablesen wohin die Anfrage geht, also auch wie lange sie brauchen wird.
Endergebnis ist dann dass bei Zen 1 der L3 nicht immer 43 Takte braucht sondern 40+-3. 37 für die "eigene" Slice, 39 für den Nachbarn, 41 gegenüber und 43 diagonal.

Also würde man lieber mehr Slices machen. Probleme machen natürlich die quadratisch steigende Anzahl der Verbindungen und die Geometrie. Bei 2x2 sind die Diagonalen ähnlich lang, bei 2x3 (wobei da die Adressen sich nicht so elegant aufteilen lassen) und erst recht 2x4 steigt der Durchschnitt und Varianz natürlich stark an.

4 Kerne sind an sich ideal für einen CCX. Nur wenn man mehr als 4 Kerne braucht hat man ein Problem.
Man muss sich da immer vor Augen halten dass AMD bei MCMs bleiben wird und dadurch nie komplett gleichförmige Skalierung von 1 bis x Kernen liefern kann. Die Frage ist, ob es wert ist die Leistung mit 1-4 Kernen zu verschlechtern um dafür bei 5-6 (oder 5-8) etwas besser dazustehen. Ehrlich gesagt was bis 16 Threads skaliert, skaliert meistens auch bis 32 Threads (oder noch mehr). Es ist meiner Meinung nach die bessere Option einfach mehr Chiplets/Kerne insgesamt zu liefern und damit die etwas schlechtere Skalierung überzukompensieren anstatt sich direkt nach dem man zu Intel in single threaded performance aufgeschlossen hat sich selbst ein Handicap aufzuerlegen.

[Der_Korken]

Geometrie.
Das sind keine unabhängigen Slices wie bei Intel wo jeder Kern erstmal seine "eigene" Slice hat die auch dafür zuständig ist Inklusivität zu wahren sondern dass ist ein großer L3 bei dem je ein Viertel der Adressen in jeder Slice landen.


OK, das macht 6 Kerne pro CCX relativ unwahrscheinlich, weil die Adressaufteilung dann ziemlich aufwändig wäre.


Man könnte das teilweise oder ganz zentralisieren, aber es bringt keinen Vorteil. Wenn ein Kern eine Anfrage an einen monolithischen L3 schickt dann muss der L3 zentral alle tag checks bearbeiten und der Kern muss bei der Latenz vom Schlimmsten ausgehen. Schließlich ist die Chance 75% dass die Daten näher an einem anderen Kern liegen. Der geviertelte L3 muss an 4 Stellen nur ein Viertel der Anfragen bearbeiten und der Kern kann schon an der Adresse ablesen wohin die Anfrage geht, also auch wie lange sie brauchen wird.

[...]

Also würde man lieber mehr Slices machen. Probleme machen natürlich die quadratisch steigende Anzahl der Verbindungen und die Geometrie. Bei 2x2 sind die Diagonalen ähnlich lang, bei 2x3 (wobei da die Adressen sich nicht so elegant aufteilen lassen) und erst recht 2x4 steigt der Durchschnitt und Varianz natürlich stark an.


Man kann also sagen: Wenig "Slices" haben wenig Verdrahtungsaufwand, dafür aber eine hohe erwartete Antwortzeit (immer worst case), viele "Slices" haben viel Verdrahtungsaufwand (quadratisch) dafür aber eine geringere erwartete Antwortzeit, wobei diese allerdings auch stärker variiert. Das klingt so, als wäre die Anzahl der Kerne und die Anzahl der "Slices" gar nicht so eng gekoppelt oder wo genau kommt bei der Anzahl der Kerne die Geometrie ins Spiel?

Es könnte ja sein, dass sich mit steigender Kernzahl der Sweetspot für die CCX-Größe verschiebt. Nehmen wir mal die beiden Extrema:

1 Kern pro CCX: Sehr simple CCX, sehr schlechte L3-Ausnutzung für wenige (einen) Thread, sehr häufiger Datenverkehr über IF
Alle Kerne in ein CCX: Sehr langsamer L3-Cache, weil alle Kerne dranhängen, dafür optimale L3-Nutzung, minimale IF-Kommunikation

Die goldene Mitte liegt irgendwo dazwischen. Bei 32 Kernen waren 4er CCX vielleicht noch gut, bei >64 muss es aber nicht mehr so sein.

[Windi]

Für Zen2 haben auch schon viele über einen 8 Kern CCX pro Chiplet spekuliert.
Es ist aber bei 4 Kernen geblieben.
Die CCX auf einem Chiplet können noch nicht einmal direkt miteinander reden. Ganz zu schweigen von den Chiplet-Pärchen, die es bei Epyc gibt. Es läuft immer alles über das IO-Die.

Die Latenzen innerhalb des CCX scheinen einfach wichtiger zu sein.
Bei 8 Kernen im CCX müßte man nacher wirklich eine Art Ringbus im Chiplet verwenden. Dann sinkt die Leistung des einzelnen Kernes nochmals. Das wäre nicht gut. Vor allem wenn Intels neue Architektur +18% bessere IPC bringen könnte. (Und irgendwann kriegen die auch die Fertigung wieder in den Griff)

Es macht auch keinen Sinn, jedes Jahr die Anzahl der Kerne zu erhöhen. Was AMD momentan hat, scheint erst einmal Ideal zu sein.
Für eine günstige APU mit 4 Kernen reicht ein CCX.
Für Normalo CPUs mit 6 oder 8 Kernen genügt ein Chiplet.
Für normale Highend CPUs nimmt man halt 2 Chiplet.
Und für alles darüber gibt es Threadripper und Epyc mit bis zu 64 Kernen.

Es macht keinen Sinn 2020 schon die Anzahl der Kerne pro Chiplet auf 12 oder noch mehr zu erhöhen. Im Preisbereich von 200€ sind wir gerade einmal bei 6 Kernen. In ein oder zwei Jahren wird sich dies sicherlich auf 8 erhöhen. Aber das deckt man problemlos mit einem normalen Chiplet ab. Ansonsten müßte man nur wieder viel zu viel deaktivieren.

Die Software muss auch erst einmal hinterher kommen. AMD hat hier vorgelegt und bietet im Mainstream bis zu 16 Kerne. Intel bietet gerade einmal 8, die zukünftigen Konsolen ebenfalls 8 und AMDs 200€ Prozessor hat nur 6 Kerne. Da wird es noch laaange dauern, bis die meiste Software einen wirklichen Nutzen aus mehr als 32 Threads zieht.

Keiner sagt, das wir in Zukunft nicht mehr Kerne haben wollen. Aber es macht keinen Sinn die Anzahl der Kerne in die Höhe zu treiben, wenn die Nachteile die Vorteile deutlich übersteigen. Es würde nur die Singel Thread Leistung sinken und die Software würde mit den ganzen Kernen nicht zurecht kommen.


Meine Prognose:
Bei Zen 3 und 4 bleibt es bei 8 Kernen pro Chiplet (4 pro CCX)
Das reicht erst einmal.
In der Zwischenzeit kann man sich auf andere Dinge konzentrieren und die neue Architektur weiter optimieren.
Bei Zen 5 könnte man dann pro Chiplet 3x CCX verbauen. Oder baut wieder alles nochmals komplett um.
Bis 2021 reicht das im Desktop einfach aus.

Für Server könnte man ja einen neuen Sockel mit PCIe 5.0, DDR5 und einem größeren IO-Die bringen, der mehr als 8 Chiplets unterstützt.
Wobei man das Ganze leiber auf 2 Sockel aufteilt. Einen Sockel für Threadripper und kleine Server und Workstations. Und Einen für die ganz großen Server.

[JVC]

...3x CCX verbauen. Oder baut wieder alles nochmals komplett um.
Bis 2021 reicht das im Desktop einfach aus.

Denke ich auch :)

M.f.G. JVC

[Setsul]

@Der_Korken:
Nicht ganz. Cache tendiert in Richtung Quadrat um die Latenz optimal auszunutzen und weil die Arrays eben rechteckig sind. Das sieht man auch schön auf den Die-Shots. Logik und Tags in die Mitte, außenrum 4 quadratische SRAM Arrays. Gleiche Latenz in jede Ecke.
Slices halbieren bringt nichts weil man dann nur die eine Seite halbiert, aber die andere gleich lang bleibt und damit auch die höchste Latenz.
Man müsste also wieder Quadrate bauen, nur eben kleiner, aber wie ordnet man die an? Wieviele Cache-Quadrate kann man wie aneinanderlegen, dass der Abstand zu den Kernen und damit die Latenz im Durchschnitt möglichst klein wird? Vier.

Man könnte fürchterliche Basteleien versuchen und für 4 Kerne 6 (aber nicht schön) oder 8 Slices verwenden, aber man gewinnt da verhältnismäßig wenig im Vergleich zum Verdrahtungsaufwand. Also 4 Slices sind sinnvoll.
Natürlich könnte man an je zwei Seiten einen Kern hängen anstatt nur an eine, aber dann ist der CCX kein Rechteck mehr, sondern hat Aussparungen an den Ecken. Außer man macht aus den Kernen Trapeze aber dann müsste man die Ecke sinnvoll verwenden die weit ab vom Schuss ist und ruiniert sich die Latenz innerhalb des Kerns.
4 Kerne, 4 Slices gibt am meisten Sinn, obwohl die Slices nicht zu einem bestimmten Kern gehören.


Also mehr Slices bei gleicher Größe = theoretisch niedrigere Latenz, aber geometrisch nur bis 4 praktikabel ohne fürchterliche Verrenkungen.
Mehr Slices für größeren L3 = höhere Latenz = Leistung geht runter, außer eben für Programme die exakt so viele Threads brauchen dass sie sonst nicht in einen CCX gepasst hätten, jetzt aber schon. Aber keinen einzigen Thread mehr, sonst war alles für die Katz und die Leistung ist schlechter als vorher.

Alle Kerne in einen CCX geht nicht wegen MCM.
1 Kern ist praktisch sinnlos weil IF mit Verbindungen von jedem Kern zu jedem anderen zusammenbricht. Da muss man dann etwas reduzieren und einen Ring (jeder Kern mit 2 anderen verbunden) oder ein Mesh (4 Verbindungen) oder etwas anderes bauen.

Wenn man vereinfachend immernoch von quadratischen Slices ausgeht ist alles unter 4 sinnlos weil Lücken bleiben und die Latenz sich von 2 bis 4 kaum ändert.
Realistisch sind die Optionen 4, 6 oder 8. 6 ist nicht schön für die Adressen, Quadcores und Hexacores aus 12 core Dies zu schnitzen ist nicht gut fürs Geschäft, 5 chiplets für 60 Kerne sind auch nicht toll, aber 6 core chiplets sind auch nicht das Gelbe vom Ei und so weiter.

Im wesentlichen bleibt:
4 Kerne, CCX für APUs einfach kopieren (evtl. wieder mit L3 Modifikation) und die schlechtere Skalierung ab 4 Kernen einfach dadurch ausgleichen dass man 12 Kerne für soviel verkauft wie Intel für 8 will.
oder
8 Kerne, für APUs braucht man trotzdem wieder einen 4 Kern CCX, ST ist niedriger und ab 8 Kernen hat man nichts gewonnen. Man steht also bis zum 9900K in MT, wo man eh schon gewinnt, besser und in ST schlechter da. Mehr Aufwand für nichts Sinnvolles.


EDIT:
Mehr als 4 wird dann sinnvoll wenn AMD die Zeit und das Geld hat auf größere Blöcke zu gehen. 8 Kern CCX ist zwar nett, aber dafür ist ein CCX geometrisch eigentlich falsch. 8 Kerne mit Ringbus sind toll, aber nur dafür einen Ringbus zu entwickeln ist zu teuer. Für 16 Kerne kann man darüber reden, weil niedrige Latenz zwischen 4 oder zwischen 16 Kernen ist dann schon spürbar. Mehr ist auch nicht realistisch wegen der Entfernungen. Intel selbst empfiehlt ja SNC weil auch das Mesh bei 28 Kernen keinen Spaß mehr hat. Also so um die 12-16 Kerne scheint die maximale sinnvolle Größe für die Zone niedriger Latenz zu sein. Bei 5nm, wenn AMD die ganzen Kinderkrankheiten des IF los ist und wieder die Ressourcen hat ein neues Interconnect zu basteln und gleichzeitig 16 Kerne auf einem Chiplet sinnvoll sind, wäre wohl ein guter Zeitpunkt umzustellen.

[Der_Korken]

Danke für die Erklärungen, Setsul. Klingt alles schlüssig und nachvollziehbar :).

[Zossel]

Danke für die Erklärungen, Setsul. Klingt alles schlüssig und nachvollziehbar :).

So ein Quad ist wie früher ein Core.

[HOT]

Klar kann man das geometrisch lösen :freak:.
Die Frage ist eher, ob das auch in der Chiptechnik so einfach geht.

[Setsul]

Einfach Stapeln :biggrin:
Wir upgraden den CCX zum Würfel. Der hat 8 Ecken, alles ez pz.
Für den 16 Kern CCX gibts dann Hyperwürfel. Einfach eine Dimension mehr ans Universum kleben.

[HOT]

Hexagonanordnung? Oktagonanordnung? Selbstvertständlich geht das geometrisch. Aber an der Chiptechnik wirds scheitern. wüsste nicht, dass jemand sowas versucht hat, lassen die Designrules wahrscheinlich auch nicht zu.


Aber mal was anderes. Jetzt ist ja bekannt geworden, dass die XBox APU DXR und DirectML auf auf der CPU unterstützen kann, na kommt was für Spiele sehr interessantes vielleicht auch was für Zen3?

[Setsul]

Aus Sechsecken ein Sechseck zu bauen ist ungleich schwieriger als aus Rechtecken ein Rechteck zu bauen, um nicht zu sagen unmöglich. Aber ja, solange man rechteckige Zellen baut und jetzt mit 1D/2D design rules erst recht, gewinnt das Rechteck.

Gibts für das XBox Zeug eine echte Quelle oder ist das alles nur pastebin?

[Zossel]

Einfach 4 Quads vollvermaschen. Also ein Quad aus Quads.

[HPVD]

aus:
A Deep Dive Into AMD’s Rome Epyc Architecture

Clark said that AMD was looking at possibly doing 512-bit vectors in future Epyc chips, but at this point was not convinced that just adding wider vectors was the best way to use up the transistor budget. For one thing, Clark added that there are still a lot of floating point routines that are not parallelizable to 512 bits – and sometimes not even to 256 bits or 128 bits, for that matter – so it is a question of when moving to 512 bits on the vector engines in the Epyc line makes sense. AMD will probably be a fast follower and do something akin to the DLBoost machine learning inference instructions, we reckon. Perhaps that capability is already in the architecture, waiting to be activated at some future date when the software stack is ready for it.

https://www.nextplatform.com/2019/08/15/a-deep-dive-into-amds-rome-epyc-architecture/

[mironicus]

Gerücht: Milan mit HBM2-Cache.

https://www.pcgameshardware.de/AMD-Zen-Architektur-261795/News/Milan-Geruechte-um-HBM2-als-Cache-1331985/

In welchen Bereichen würde ein potentieller Zen 3 für AM4 profitieren, wenn man dem Chip einen L4-Cache mit 2 bzw. 4 GB HBM2-Speicher hinzufügen würde?

[robbitop]

Für eine GPU sinnvoll. Ich fürchte, dass die Latenz vom CPU Core über IF zum IO Die zum HBM nicht wesentlich besser wäre als zum RAM. Der Großteil der Gesamtlatenz zum Hauptspeicher kommt vom IF. Man schaue mal auf die inter Core Latenz.
So ist das nunmal mit Fabrics - Geschwindigkeit und Skalierbarkeit sind diametral. IMO kann man dagegen, wenn das Paradigma der Fabric so bleiben soll, eigentlich nur mit mehr lokalem Cache und nich besserem Prefetching was machen. Also die lokale Hitrate erhöhen.

[Setsul]

Wieso sollte die Latenz überhaupt besser sein? HBM ist ganz normaler DRAM mit gemächlichen 2-2,4 GT/s. Man könnte genauso gut 16 Channels untertakteten DDR4 DRAM nehmen, von der Latenz nimmt sich das nichts. Es bräuchte nur viel mehr Platz und Strom.

HBM ist ein reiner Bandwidth-Cache, im Gegensatz zu eDRAM kann man da bei der Latenz gar nichts gewinnen. Für eine GPU ist das immernoch toll, für eine CPU dann wenn sie mehr Bandbreite braucht und nutzen kann. AMD verkauft auch 8 Kerne mit den vollen 8 DDR4 Channels, also kann man sich denken dass es mit 10 (oder noch mehr) Kernen pro Channel etwas knapp wird.
IF2 liegt mit 1600 MHz Takt nominal bei 102,4 GB/s bidirektional. Wobei die Aufteiling im Gegensatz zum RAM fest 50/50 ist, bei 2:1 Reads:Writes kommen also eher 2/3 nutzbare Bandbreite raus. Dann müsste man noch Coherency-Traffic abziehen und schlimmstenfalls 204,8 GB/s falls ständig mit voller Bandbreite vom und zum DDR4 verschoben werden.
Aber generell wären 4-6 Stacks mit je 204,8-307,2 GB/s (wobei 1,6 bis maximal 2,0 GT/s für die Effizienz besser sind und völlig ausreichen sollten) für 10 Chiplets mit je 102,4 GB/s roher Bandbreite nicht völlig abwegig.

Die Frage ist eher bringt man das in der TDP sinnvoll unter? Mit 6 Stacks reichen schon 1,6 GT/s für 1228,8 GB/s, also kein Grund mit 2,4 GT/s Strom zu verbrennen. Die Frage ist ob die zusätzliche Bandbreite den niedrigeren Takt durch niedrigere TDP pro Kern ausgleicht. Es ist ja nicht nur HBM + Interface, auf dem I/O-Die müssen dann ein Haufen Daten rumgeschoben werden.

Das größte Hindernis wäre wohl das ganze überhaupt noch auf einem SP3 Package unterzubringen.
https://i.imgur.com/o4d30iW.png
Wenn der I/O-Die nicht schon 10 IFOP Links und 6144-bit HBM2 Interface hat wird der nochmal größer. Leider gibts keinen Dieshot.
Wenn man alle Kondensatoren verschwinden lässt (bzw. auf die Unterseite versetzt) obwohl man mit 10+6 Chiplets eher mehr davon braucht, dann könnte man gerade so die 4 Chiplet-Paare nach oben bzw. unten und etwas nach außen verschieben und dazwischen ein Chiplet und einen HBM Stack pro Seite unterbringen. Dann noch oben und unten je zwei Stacks an den I/O-Die und man hats. Wobei auch das verdammt knapp wird. HBM2 Stacks sind etwas größer als die 8C Chiplets und bei der hellen Klebelinie ist definitiv Ende Gelände.

[HOT]

Wenn dann sind das eh nur 2 HBM-Stapel. Das wäre dann eher 4x3 Chiplet-Design mit 7nm-I/O-Die und 2 Stapeln.

[BoMbY]

Vermutlich wurde da nur was mit dem EHP für Frontier & Co. verwechselt/vermischt.

[amdfanuwe]

Welche Möglichkeiten hat AMD denn überhaupt nächstes Jahr?
Ich meine, wie weit sind aktive Interposer, 3D Stacking etc.?
Wäre es möglich den I/O Die in mehrere kleinere Chips aufzuteilen? Also PCIe und MMC auf eigene 14nm Chips und IF Logik in 7nm mit L4 Anbindung?
Außer das die CPU Chiplets in 7nm+ kommen und Milan noch Sockel Kompatibel bleiben soll, habe ich keine Vorstellung davon was AMD noch machen könnte.

[Setsul]

@HOT:
Was soll 7nm für den I/O-Die bringen?
2 Stapel passen nicht zur Gesamtzahl der Chips in dem Gerücht und wenn man die Bandbreite zwischen DDR4 und HBM abzieht bleibt auch nicht viel mehr als DDR4 alleine liefert. Für 2x theoretische Bandbreite baut niemand einen Cache weil das in der Praxis nie so perfekt abläuft.

@BoMbY:
Es kommt darauf an wieviel Glauben man dem "15 Chips"-Gerücht schenkt. 112 Kerne gehen beim besten Willen nicht mehr in die TDP und mit "nur" 8x DDR4 macht das auch keinen Spaß.
Also man könnte natürlich wie Intel auf 400W TDP gehen und hoffen dass es rechtzeitig DDR5 gibt, aber das scheint nicht allzu wahrscheinlich.

[reaperrr]

@BoMbY:
Es kommt darauf an wieviel Glauben man dem "15 Chips"-Gerücht schenkt. 112 Kerne gehen beim besten Willen nicht mehr in die TDP und mit "nur" 8x DDR4 macht das auch keinen Spaß.
Also man könnte natürlich wie Intel auf 400W TDP gehen und hoffen dass es rechtzeitig DDR5 gibt, aber das scheint nicht allzu wahrscheinlich.
Laut semiaccurate (hinter Paywall) sind's weiter 8 CPU Chiplets, + 6 HBM Stacks (+ IO, natürlich).

Bei Rome hatte Charlie ja auch recht mit den 64 cores, und so weit weg ist Milan auch nicht mehr, unwahrscheinlich dass 1 Jahr vor Launch noch niemand die echten Specs hat.
Und wenn WTFTech nicht selbst von Charlie abgeschrieben und die Info wirklich aus eigenen Quellen haben, hätten wir jetzt schon zwei Speku-Seiten, die beide auch schon öfter richtig lagen, die die selben Specs nennen.

Es soll außerdem auch weiter ein "normales" Modell ohne HBM geben, allein schon aus Kostengründen.

Übrigens plant Intel ähnliches, gab da schon vor Jahren einen Artikel mit der Info, dass es von Ice Lake ein Server-Modell mit 4 HBM-Stacks geben wird (ob's noch aktuell ist, ist ein anderes Thema). Gut möglich, dass AMD genau aus dem Grund auf 6 geht, um Vorteile bei der Bandbreite und Kapazität des HBM zu haben.

[Nightspider]

Ich frage mich eh warum man nicht auch eDRAM verbaut.
Bei Intel hieß es damals 50€ Mehrkosten in der Herstellung, wenn ich mich nicht irre.

Lasst es halt mal 4 eDRAM Chips mit zusammen 2GB sein. Kleine eDRAM Chips in 7nm sollten bezahlbar sein.
Wenn halt bei den TopDog Server-CPUs Herstellungskosten von 200-300 Euro dazukommen spielt das doch keien so große Rolle, wenn die am Ende eh für 2000-3000 Euro verkauft werden oder?

Wenn dadurch am Ende 20% mehr Leistung pro Kern herauskommen, wäre das doch gewaltig.


Und was den Platz betrifft: Könnte man den IO Chip nicht in 2 Chips aufteilen und diese stapeln, wenn die eh nicht sehr warm werden?
Wenn man IO Chips nicht gut shrinken kann, kann man sie ja größer machen, aufteilen und stapeln.

Eventuell könnte man sogar ein Cache Slices (eDRAM) auf den IO Chip stapeln und hätte sogar noch kürzere Wege.

[Setsul]

Dazu müsste jemand 7nm eDRAM anbieten.
Ich glaube auch nicht dass eDRAM auf 7nm so toll ist. Leakage wird schlimmer, Kondensator wird kleiner -> retention time wird viel schlechter. Entweder noch tiefere Gräben graben (und IBM musste bei 14nm schon ziemlich tief) und noch teurere und dickere Isolation dazwischen, was die Dichte runter und die Kosten hochtreibt oder noch mehr Leistung durch Refreshes verlieren.

Ich glaube es gibt keine Kalkulation in der doppelte Herstellungskosten einfach so egal sind.

20% kommen aber nicht raus. Bei Broadwell warens eher 2%.

I/O-Dies stapeln bringt nichts, wo schließt man dann den I/O an?

Caches zu stapeln ist bis jetzt noch Zukunftsmusik.

[Nightspider]

Ist es so schwer/teuer eDRAM fertigen zu lassen bei TSMC?

Intel hats ja auch einfach für sich selbst produziert.


Kamen da echt nur 2% bei rum bei Anwendungssoftware?

Gut aber das waren damals auch nur 2-4 Kerne. Jetzt sind es 64 Kerne aufwärts bei Zen 3.

[robbitop]

Dank der langsamen IF würde auch eDRAM im I.O Die nicht so besonders viel bringen.

[Setsul]

TSMC bietet keinen eDRAM auf 7nm an also ja, sehr schwer um nicht zu sagen unmöglich.

Intel hat Fabs. AMD hat keine Fabs. AMD kann nicht für sich selbst produzieren.

Ja. Außer du glaubst Broadwell hat 20% niedrigere IPC als Haswell und das wird nur vom eDRAM ausgeglichen.

Wieso sollte sich der Nutzen verzehnfachen bei 64 Kernen?

@robbitop:
Ging doch um externe eDRAM Chips. IF hat nichts damit zu tun, das wäre wie HBM ein Bandbreiten-Cache. Nicht besser als HBM in der Hinsicht, nur eben teurer und kleiner.

[robbitop]

Ich denke dass viele bei edram an den 5775c denken, wo es ja wirklich Performance in Spielen brachte. Aber eben dadurch, dass man 40 ns Latenz hatte.

Bei Zen muss ja alles was außerhalb des CCX ist erstmal über den IF.

Für IGPs wäre so ein externer hbm/edram cache sinnvoll. Als L4 für die CPU zu lahm.

Solange AMD diese Fabric nutzt, macht L4 wenig Sinn.

[Setsul]

Wie gesagt, wenn dann wäre das für Bandbreite. Eben genau der Grund wieso man HBM/eDRAM bei GPUs verbaut.
Ein HBM-Cache wird auch nicht mehr oder weniger sinnvoll wenn das IF 0ns Latenz hat. DRAM ist DRAM, der bringt niemals Latenzvorteile gegenüber DDR4.

[gmb]

Ich denke dass viele bei edram an den 5775c denken, wo es ja wirklich Performance in Spielen brachte. Aber eben dadurch, dass man 40 ns Latenz hatte.



Es hat auch deswegen was gebracht, weil man Broadwell ja auch nur mit DDR3 betreiben konnte. Ich glaube offiziell ging nur DDR3-1600, mit OC hat man auch 2133 gesehen. Hätte man damals Haswell mit DDR4-3200 betreiben können, würde das anders aussehen. Mit Skylake-K hat man OC DDR4 nehmen können und hat den Spieleboost auch so bekommen. Für die Intel Plattform ist das auch heute noch gültig.

[gravitationsfeld]

DRAM ist DRAM, der bringt niemals Latenzvorteile gegenüber DDR4.
Es gibt bei Intel einen deutlichen Latenzvorteil fuer den eDRAM gegenueber den DDR-Kanaelen.

[Nightspider]

Wollt ich auch gerade schreiben. Damals hieß es doch das eDRAM auch Latenzvorteile bringt:

https://www.eetimes.com/author.asp?section_id=36&doc_id=1323410#

Hier steht es auch in einem Satz.

"Moreover, having a separate DRAM die in the same package as the processor reduced chip interface delay, compared with external DRAM in a different package. "

Wenn man will lässt sich aus DRAM bestimmt mehr herauskitzeln als bei handelsüblichen Modulen mit XX Chips und einem handelsüblichen DRAM Controller.

Ist bestimmt auch einfacher einen direkt angebundenen einzelnen Chip hoch takten zu lassen als 2-8 ganze Module mit jeweils zig Chips.

[Setsul]

Lest doch die ganze Zeile.

Ein HBM-Cache wird auch nicht mehr oder weniger sinnvoll wenn das IF 0ns Latenz hat. DRAM ist DRAM, der bringt niemals Latenzvorteile gegenüber DDR4.

Natürlich ist eDRAM anders. Man kann eDRAM auch als on-Die Cache verwenden, auf 4 GHz hochprügeln und schon hat man einen großen L3 mit ganz normaler Latenz.

Es geht mir um dieses Argument "HBM kann nichts bringen weil die IF-Latenz zu hoch ist". Das IF hat damit nichts zu tun.

Siehe letzte Seite.
Wieso sollte die Latenz überhaupt besser sein? HBM ist ganz normaler DRAM mit gemächlichen 2-2,4 GT/s. Man könnte genauso gut 16 Channels untertakteten DDR4 DRAM nehmen, von der Latenz nimmt sich das nichts. Es bräuchte nur viel mehr Platz und Strom.


Bei eDRAM würde das IF die Latenz ruinieren, deshalb gibt es praktisch keinen Vorteil gegenüber HBM in diesem Fall. EDRAM ist nur teurer und kleiner.
Aber bei HBM ist das IF völlig egal. Die Latenz ist so oder so nicht besser. 2000 MHz DRAM hat nicht plötzlich umwerfende Latenzen, ein Bruchteil derer von DDR4 RAM mit 3200 MHz, bloß weil man ihn gestapelt hat.

[robbitop]

Wie gesagt, wenn dann wäre das für Bandbreite. Eben genau der Grund wieso man HBM/eDRAM bei GPUs verbaut.
Ein HBM-Cache wird auch nicht mehr oder weniger sinnvoll wenn das IF 0ns Latenz hat. DRAM ist DRAM, der bringt niemals Latenzvorteile gegenüber DDR4.
So ist es. Wollte es nur auch für alle anderen klarstellen, da sich die wenigsten hier für IGPs interssieren und den Fokus auf CPU Leistung haben. Die denken immer an den Vorteil vom L4 auf Spieleleistung für CPUs. :)

[robbitop]

Es hat auch deswegen was gebracht, weil man Broadwell ja auch nur mit DDR3 betreiben konnte. Ich glaube offiziell ging nur DDR3-1600, mit OC hat man auch 2133 gesehen. Hätte man damals Haswell mit DDR4-3200 betreiben können, würde das anders aussehen. Mit Skylake-K hat man OC DDR4 nehmen können und hat den Spieleboost auch so bekommen. Für die Intel Plattform ist das auch heute noch gültig.
Ja das brachte Latenz. Haswell liegt mit regulärem DDR3 1600 bei rund 60 ns. BDW mit eDRAM bei 40 ns in den L4.
Skylake mit schnellem DDR4 kommt auch locker auf 40 ns. Ich bin mir sehr sicher, dass das einen nicht unwesentlichen Teil der Leistung in Spielen von Skylake ausmachte. IMC Takt bringt bei den Ringbus CPUs schon bis zu einem gewissen Punkt einiges an Latenz.
Mit DDR3-2400 mit geschärften Latenzen habe ich meinen Haswell von 60ns auf 45 ns gebracht. Im GTA5 Benchmark brachte das >20% mehr fps im CPU Limit (1080ti auf 2 ghz und 800x600).

Da Intel bei Skylake ff dank Ringbus mit anständigem RAM schon auf dem Latenzniveau ist wo BDW mit eDRAM war, müsste, wenn man das wieder eiführen wollte, der eDRAM eine ganze Ecke höher takten als damals.

Bei AMD dank IF wäre das ganze Konzept wirkungslos. Da würde wirklich nur noch mehr L3 und noch besseres Prefetching helfen. Die 16 MiB L3 haben da in Spielen ja schon ordentlich geholfen. Und der bessere IMC der jetzt höhere Taktraten erreicht. (wobei das Auslagern des IMCs in den IO Die bei gleicher Speichertaktrate zu Zen+ ja schon gute 5-10 ns gekostet hat - die holt man gerade so/wenn überhaupt durch die höhere RAM Taktrate (von der Latenz her) wieder rein).
Ich meine Zen+ hat man auch knapp und 60 ns geprügelt bekommen (58...59 ns). Jetzt liegt man mit Ach und Krach in dem Mitte 60ern.

[Zossel]

Mit DDR3-2400 mit geschärften Latenzen habe ich meinen Haswell von 60ns auf 45 ns gebracht. Im GTA5 Benchmark brachte das >20% mehr fps im CPU Limit (1080ti auf 2 ghz und 800x600).

Ich denke kaum das es bei einem weiteren Cache bei Server-CPUs um Performance in Spielen geht, und das erst recht nicht bei Auflösungen aus dem letzten Jahrtausend.

[Windi]

Robbitop und Setsul wollen anscheinend nur darauf hinweisen, das ein weiterer Cache, den man am IF anschließt, von den Latenzen her nicht wirklich schneller sein wird.
Das hilft vor allem bei der Speicherbandbreite. Aber die meisten Programme sind in dem Bereich kaum eingeschränkt. Profitieren würden vor allem leistungsstarke APUs und spezielle Serveranwendungen. Es ist nur fraglich, ob AMD für diese Bereiche extra Chips entwickeln will. Weil ihre momentanen Geschäftsbereiche decken sie problemlos ohne ab. Und das bedeutet halt wieder extra Kosten, die wieder eingespielt werden müssen.

Man muss einfach abwarten, was AMD bringen wird. Vielleicht war das nur ein Gedankenexperiment und es kommt garnichts. Oder es wird wirklich etwas integriert, das aber bei den meisten CPUs deaktiviert bleibt. Beides ist möglich.

[Sunrise]

Es ist nur fraglich, ob AMD für diese Bereiche extra Chips entwickeln will. Weil ihre momentanen Geschäftsbereiche decken sie problemlos ohne ab. Und das bedeutet halt wieder extra Kosten, die wieder eingespielt werden müssen...

Hust...

"Forrest explained that the CPU is not Milan – it is actually a fully custom design CPU specifically for this project."
AMD Confirms Zen 4 EPYC Codename, and Elaborates on Frontier Supercomputer CPU (https://www.anandtech.com/show/14419/amd-confirms-zen-4-epyc-codename-and-elaborates-frontier-cpu)

[robbitop]

Ich denke kaum das es bei einem weiteren Cache bei Server-CPUs um Performance in Spielen geht, und das erst recht nicht bei Auflösungen aus dem letzten Jahrtausend.

Ich kann mir gut vorstellen, dass es auch Serverworkloads mit eingeschränkter Hitrate gibt, so dass die CPU auf Daten wartet.

Auflösung: im CPU Limit testen -> somit kann man Relationen bewerten. Es ist sinnvoll, eine Komponente in einer Situation zu messen, wo sie den Flaschenhals darstellt.

@forrest
Wir werden sehen, wie sehr anders die CPUs sein werden. Wie oft stellt sich sowas am Ende als Halbwahrheit (je nach Bewertungsmaßstab) heraus.

[Windi]

Mal abwarten, wie viel Custom da wirklich drin stecken wird.
Die heutigen Epycs können auch schon ihre PCIE Lanes auf IF umschalten, sonst wären 2 Sockel Systeme gar nicht möglich.
Die andere Frage ist, wozu benötigt die CPU solch einen Bandbreiten-Booster, wenn die meisten Berechnungen auf den GPUs ausgelagert wurden. Außerdem hat die CPU ja auch noch 8 Speicherkanäle und große L3 Cache Blöcke.
Ja, es ist möglich dass so etwas kommt. Es wäre aber auch nicht überraschend, wenn es nicht kommen würde.

[robbitop]

Naja es gibt sicherlich schon Anwendungsfälle, die Bandbreite brauchen und für die GPUs nicht ideal sind.

[Zossel]

Robbitop und Setsul wollen anscheinend nur darauf hinweisen, das ein weiterer Cache, den man am IF anschließt, von den Latenzen her nicht wirklich schneller sein wird.
Das hilft vor allem bei der Speicherbandbreite. Aber die meisten Programme sind in dem Bereich kaum eingeschränkt. Profitieren würden vor allem leistungsstarke APUs und spezielle Serveranwendungen.

memcpy() & Co. sind nun nicht gerade selten in Serveranwendungen, der ganze Schmodder wird typischerweise zigmal kopiert bevor überhaupt auch nur irgendwas damit gerechnet wird, wenn überhaupt. Und Java beschäftigt sich auch gerne mit dem sammeln von Müll.

Ob ein HBM-Cache da Vorteile oder Nachteile hat, schwer zu sagen .....

[basix]

AI & Raytracing benötigt ebenfalls sehr viel Bandbreite. Hier sind GPUs zwar gut, doch es gibt auch etliche Ausformungen der beiden Themengebiete, wo CPUs im Vorteil sind.

Frontier sieht für mich nach der ultimativen Form von "Heterogenous Computing", welches AMD seit langer Zeit schon als die Zukunft predigt. Nimm GPUs, wo GPUs gut sind. Nimm CPUs, wo CPUs gut sind. Mix & Match, und das dynamisch je nach Arbeitslast. So könnten etwaige Flaschenhälse bei Applikation, welche vorher nur auf einer CPU oder GPU ausgeführt wurden, extrem entschärft werden.

[robbitop]

Was bis dato für solche Workloads wohl problematisch war: Bandbreite und Latenz wischen GPU und CPU. Selbst bei einem gemeinsamen Speicherpool.

[Nightspider]

Gibts keine bezahlbaren, guten Alternativen um einen eDRAM mit kürzeren Latenzenan den IO Chip anzubinden?

Muss das zwangsweise über den IF laufen?

Genauso bei dem HBM? Kann man den nicht vielleicht direkter an die Chiplets oder den IO Chip anbinden?

[Windi]

Selbst wenn du diesen Cache in den IO Chip integrierst, gehen die Daten immer noch über den IF. Schließlich sind die Chiplets mit Hilfe des IF an den IO Chip angebunden. Das ist einfach die Art des Kummunikationsnetzwerkes innerhalb der Zen Prozessoren.

eDRAM in jedes Chiplet zu integrieren macht auch keinen Sinn. Schließlich müssen darauf auch Kerne von anderen Chiplets zugreifen.

Falls man so etwas machen sollte, dann packt man den HBM-Speichercontroller direkt in den IO Chip und setzt den HBM-Speicher direkt daneben. Aber wie schon gesagt erhöht das nur die Bandbreite und senkt nicht die Latenzen. Ja, eDRAM wäre noch etwas schneller, aber was bringt mir das, wenn das einfach nicht bei den Kernen ankommt. Man will ja auch nicht die Herstellungskosten drastisch erhöhen, nur damit man später 5-10% bessere Latenzen hat. Das lohnt sich dann einfach nicht.

[robbitop]

Ggf kann man die IF irgendwann mal noch höher takten. Das würde schon helfen. Ggf wenn man das Interface auf PCIe5 umstellt.

[Windi]

Basiert der IF, der die Chiplets anbinden, auch auf PCIe?

Ich dachte IF wäre bei AMD nur ein Oberbegriff für verschiedene Verbindungsarten, die Cache kohärent sind.

Edit:
Aber ja, wenn man es schaffen würde den IF höher zu takten, wäre das ein großer Vorteil.
Vielleicht hilft es auch weiter, wenn man später einmal auf Interposer aus Silizium wechselt. Oder gar auf einen Aktiven-Interposer.

[Gipsel]

Basiert der IF, der die Chiplets anbinden, auch auf PCIe?Nein. IFOP-Links funktionieren anders (single ended und somit kein LVDS) als die für die GPIO-Lanes für PCIe/SATA/IFIS. Die PHYs sind völlig anders und inkompatibel.

IFOP: Infinity Fabric On Package
IFIS: Infinity Fabric Inter Socket

[amdfanuwe]

Basiert der IF, der die Chiplets anbinden, auch auf PCIe?

Ich dachte IF wäre bei AMD nur ein Oberbegriff für verschiedene Verbindungsarten, die Cache kohärent sind.


Man muß unterscheiden zwischen Verbindungsebene und Protokollebene.
PCIe definiert beides.
Bei Verbindungen zwischen 2 Prozessoren werden die PCIe Leitungen genutzt und das IF Protokoll angewendet.
Bei Verbindungen zwischen Chiplet und I/O hat man andere Bedingungen ( Leitungslängen, Übergangswiderstände, Kapazitäten) und kann die Treibertransistoren entsprechend anders gestalten.

[Windi]

Es ging ja nur darum, ob sich die Verbindung zwischen IO Chip und Chiplet beschleunigt, wenn man von PCIe 4 auf 5 wechselt.
Da der IFOP anscheinend nicht auf PCIe basiert, muss AMD den dann wohl selber weiterentwickeln.

[Karümel]

Soll Zen3 eigentlich auch auf dann älteren Boards laufen?
Gibt es da eigentlich schon Gerüchte zu?

[Setsul]

@Nightspider:
Wenn du ein Interconnect rumliegen hast, dass du billig an AMD lizenzierst, dann ja. Intel wird ihnen nichts verkaufen.

AMD hat exakt ein aktuelles Interconnect. Alles was verbunden werden muss wird entweder über IF verbunden oder gar nicht. Die 2 CCX auf einem Chiplet sind auch mit IF verbunden.

HBM an den Chiplets bringt nichts. Das hätte man auch mit DDR4 machen können aber dann hat man wieder die gleiche NUMA Probleme wie bei Zen1. Außerdem bräuchte man dann neue Chiplets mit HBM-Interface und 8 Stacks, das kann sich keiner leisten.
HBM bringt nichts für die Latenz also reicht das am I/O-Die.
"Direkter" an den I/O-Die als am I/O-Die geht nicht. Und wie kommen die Daten vom I/O-Die zu den Chiplets? Über IF, da führt kein Weg dran vorbei.

@Windi:
Das Interface ist nicht PCIe, aber die benutzen teilweise die gleichen PHYs. XGMI zwischen den Sockeln braucht man nicht wenns nur einen Sockeln gibt, aber von den 128 PCIe Lanes braucht man nur die Hälfte wenn man 2 Sockel hat. 64 PCIe Lanes sind fest und aus den anderen 64 PCIe Lanes werden 4 IFIS Links mit je 16 bit, wenn man mit einem anderen Sockel kommunizieren will der dafür nochmal 64 PCIe Lanes stellt sodass nach außen immernoch 128 Lanes gehen.

Man muss aber sagen dass PCIe 3.0 nur 8 GT/s braucht während IFIS bei 1333 MHz (EPYC1 unterstützt keinen 3200 MHz RAM) schon 10,67 GT/s braucht. Wobei von den PHYs her (12G) 1600 MHz drin wäre. AMD kauft das IP für die PHYs ein und hat bei Zen2 nicht bloß das Minimum für PCIe 4.0, 16 GT/s, sondern gleich 25G Kombi-PHYs genommen und damit sind dann 1600 MHz + doppelter Takt fürs IFIS möglich.
PCIe 5.0 braucht dann 32 GT/s und dafür gibts auch 32G PHYs, aber weil Zen2 ja schon 25G hat, nicht 16G, wäre das nur 25% schneller.

Außerdem ist das alles IFIS, IFOP (on-package) hat sowieso 32 bit weil man sich auf dem Package mehr Drähte leisten kann als zwischen den Sockeln und läuft dafür bei Zen1 maximal mit gemächlichen, aber effizienten, 5,33 GT/s. Mit Zen2 wurde das auch verdoppelt + IF Takt von 1333 auf 1600 MHz max, also 12,8 GT/s. Da ist definitiv Luft nach oben, aber es würde Strom kosten und es ist auch definitiv unabhängig von PCIe.

Aktiver Interposer bringt in diesem Fall nichts. Das ist interessant wenn man noch kleinere Chiplets will, weil dann der Interposer das Routing übernimmt. Also praktisch wie das Skylake-X Mesh, nur dass das Mesh im Interposer sitzt und darauf dann Chiplets mit einem einzelnen Kern + Cache. AMDs momentane MCMs sind 1-zu-1 Verbindungen, da gibt es nichts zu routen und ein aktiver Interposer würde nichts machen.

Ein passiver Interposer wäre an sich interessant aber um 8 Chiplets + I/O und in Zukunft sogar noch mehr unterzubringen wäre das Ding natürlich riesig. Da gibts dann wieder die Probleme mit reticle size limit (im Wesentlichen die Masken sind zu klein). EMIB wäre hochinteressant, aber da hätte Intel mit seinen Patenten wohl etwas dagegen wenn das kopiert wird.

[Windi]

@Karümel
Den Sockel wird man wohl erst wechseln, wenn man auf DDR5 umsteigt.
Und dafür ist es nächstes Jahr noch zu früh.
Also sollte theoretisch alles möglich sein.
Es ist aber nicht garantiert, das alle alten Boards ein neues Bios bekommen. Schon bei Zen2 gab es genügend kleine Problemchen und bei vielen Mainboards ist der Bios-Chip zu klein, um noch mehr CPUs zu unterstützen.

Ich würde Mal raten, das die Mainboards aus dieser zweiten Jahreshälfte mit größerem Bios-Chip höchst wahrscheinlich Zen3 unterstützen werden. Bei dem Rest muss man einfach abwarten was AMD sagt.

[Karümel]

Ich würde Mal raten, das die Mainboards aus dieser zweiten Jahreshälfte mit größerem Bios-Chip höchst wahrscheinlich Zen3 unterstützen werden. Bei dem Rest muss man einfach abwarten was AMD sagt.

Das wären dann nur die mit X570?
Und die die noch folgen mit anderen Chipsätzen?

[Windi]

@Karümel
Es sollten auch neue Boards mit alten Chipsätzen kommen, die einen größeren Bios-Chip haben.
Aber, das habe ich jetzt nicht so genau beobachtet.

@Setsul
Danke für die ausführliche Antwort.

[2B-Maverick]

@Karümel
Es sollten auch neue Boards mit alten Chipsätzen kommen, die einen größeren Bios-Chip haben.
Aber, das habe ich jetzt nicht so genau beobachtet.

@Setsul
Danke für die ausführliche Antwort.

Jop. Die MSI "MAX"-Boards haben die alten Chipsätze und ein 32MB BIOS.
Damit leider auch wieder diese Klicki-Bunti UEFI-Bios Ansicht. Da finde ich das normale, in aktuellen Versionen beschnittene 16MB Bios fast schöner. (habe den Direktvergleich mit zwei 3700X Systemen).

[HPVD]

The Zen 3 core would be based on the 7nm+ process node which would be put up against the 10nm Ice Lake-SP and 14nm++ Cooper Lake Xeon processors. In terms of efficiency, AMD has highlighted that their processors would offer much better performance per watt & just by looking at the slide, we can also note that even EPYC ‘Rome’ processors are designed to compete favorably against Intel’s 2020 Xeon products.

https://wccftech.com/amd-zen-3-epyc-milan-cpus-better-performance-per-watt-intel-10nm-xeon-ice-lake-sp/

[Nightspider]

Also nix Neues.

[HPVD]

Also nix Neues.

es sei denn man geht davon aus, das die dort gezeigte Grafik halbwegs Maßstabsgerecht ist...
-> dann könnte man interpretieren, dass der Vorsprung von Milan (7nm+) zu Icelake (10nm+) fast konstant bleibt zu dem von Rome (7nm) zu Cascade Lake (14nm+++)
=> Das wäre schon recht beachtlich...

[gmb]

https://wccftech.com/amd-zen-3-epyc-milan-cpus-better-performance-per-watt-intel-10nm-xeon-ice-lake-sp/


Klar, die haben bestimmt 1 Jahr vorm launch schon einen fertigen Icelake-SP im Labor, das ist wirklich sehr vertrauenswürdig. Aber ist ja von AMD, dann muss es stimmen.

[Unicous]

Mimimi?

[Lehdro]

Klar, die haben bestimmt 1 Jahr vorm launch schon einen fertigen Icelake-SP im Labor, das ist wirklich sehr vertrauenswürdig. Aber ist ja von AMD, dann muss es stimmen.
Intel ist bekannt dafür bestimmte Serverhardware (oder Daten darüber) bestimmten Herstellern weitaus früher zur Verfügung zu stellen, als sie eigentlich verfügbar sein sollten - was gerade jetzt relevant ist da sind in dem Bereich auf jeden Fall mit allen Mitteln um jeden Kunden kämpfen wollen laut eigener Aussage. Da AMD nun auch wieder dick in dem Markt mitmischt werden sie sicher weniger im Dunklen stochern als wir alle hier - es sind im Grunde dieselben Partner die die Informationen beider Seiten haben, Fragen kostet ja nix.
Achja: Icelake-SP kommt laut der Intel Roadmap schon Q2 2020, also ist es vielleicht nur ein halbes bis dreiviertel Jahr - was durchaus auch mal für Validierungsprozesse und erste frühe ES Phasen genutzt werden kann. Die groben Daten wie Kernzahlen, Sockel und RAM Channel sind ja ebenso bekannt wie die grobe Performance eines nicht unähnlichen Icelake-U Kernes.

[Unicous]

Ich meine, AMD geht davon aus, dass Zen3 unter "7nm+" besser performed als ICL unter 10nm. Das ist die Kernaussage. Ich sehe da jetzt keine große Kontroverse.

Ich meine Intel hat über Jahre solche Folien veröffentlicht:

https://www.extremetech.com/wp-content/uploads/2017/03/Slide6.png

Und wir wissen ja alle was daraus geworden ist.:freak:

gmb ist nur pissed, weil er sonst keine Argumente hat um zu stänkern.:wink:

[Denniss]

Lustig wie einem solche Folien Jahre später piranhamäßig in den Hintern beißen können.

[reaperrr]

Klar, die haben bestimmt 1 Jahr vorm launch schon einen fertigen Icelake-SP im Labor, das ist wirklich sehr vertrauenswürdig. Aber ist ja von AMD, dann muss es stimmen.
Brauchen sie gar nicht.

Man sieht doch schon an den mobilen ICLs, dass 10nm+ aktuell in Sachen Taktbarkeit und Effizienz auf CPU-Seite nicht mal an 14nm++ rankommt.

TSMCs 7nm+ wird dagegen definitiv eine Verbesserung gegenüber 7nm bringen.
Insofern ist AMD mit der Folie sogar noch ziemlich großzügig, weil sie es so darstellen, als ob 10nm bis zum ICL-SP Launch in Sachen Effizienz ggü. 14nm++ merklich zulegen würde, was aktuell mindestens unsicher ist.

Edit: Außerdem bezieht sich das auf Perf/W im Server-Bereich, und der größte ICL-SP soll nach aktuellem Stand nur 38 Kerne haben, somit müsste Intel den schon ziemlich stark auf Effizienz statt Performance trimmen (sprich: niedrige Taktraten, um niedrige Spannungen fahren zu können), um gegen 64 Kerne am Sweetspot eine Chance im Bereich Perf/W zu haben. Was Intel nicht in dem Ausmaß tun kann, weil sie sonst vielleicht nicht bei Perf/W, aber absoluter Perf chancenlos sind (werden sie außerhalb AVX512 wohl schon gegen Rome sein, wenn Milan noch full-rate AVX512 bringt, ist der Ofen in der Hinsicht ganz aus).

[Karümel]

https://www.gamestar.de/artikel/virtuelle-kernvervierfachung-amd-zen-3-durch-smt4-mit-vier-statt-zwei-threads-pro-kern,3349498.html

Einem Gerücht zufolge könnte schon die nächste Ryzen-4000-Generation aus einem Rechenkern ganze vier virtuelle Kerne machen.

[unl34shed]

Das geistert doch schon seit einem Jahr oder so rum, dass es eventuell SMT4 gibt.

[Opprobrium]

War auch schon für Zen2 kurz Thema.

Müssen sie dann aber ganz genau formulieren in ihren Marketingfolien. Nicht, dass da sonst irgendwer klagt weil SMT4 nicht die Leistung verdoppelt oder ähnliche Blutsaugeranwaltereien (siehe Bulldozer...)

[BoMbY]

Halte ich für sehr unwahrscheinlich. Der Vorteil wäre so oder so gering.

Damit das ordentlich funktioniert bräuchte man schon einen sehr schlauen Scheduler welcher die Threads abhängig von den hauptsächlich genutzten Instruktionen verteilt (was natürlich auch jetzt schon nicht schaden würde).

[Zossel]

Halte ich für sehr unwahrscheinlich. Der Vorteil wäre so oder so gering.

Damit das ordentlich funktioniert bräuchte man schon einen sehr schlauen Scheduler welcher die Threads abhängig von den hauptsächlich genutzten Instruktionen verteilt (was natürlich auch jetzt schon nicht schaden würde).

Und da ist sie wieder, die Glaskugel die die Zukunft voraussagt.

Hier gibt es zumindest eine Möglichkeit zur Vergangenheitsbewältigung: https://www.phoronix.com/scan.php?page=news_item&px=Linux-AVX-512-Usage-Tasks

[Tesseract]

allein für den serverbereich wäre SM4 sinvoll und kostet wahrscheinlich auch kaum fläche - ist eigentlich nur eine frage der zeit bis SMT >2 auf x86 kommt.

Müssen sie dann aber ganz genau formulieren in ihren Marketingfolien. Nicht, dass da sonst irgendwer klagt weil SMT4 nicht die Leistung verdoppelt oder ähnliche Blutsaugeranwaltereien (siehe Bulldozer...)

das hatte nix mit der performance zu tun. wenn ein "core" nicht unabhängig fetch-decode-execute-write durchführen kann ist es kein core.

[][immy]

allein für den serverbereich wäre SM4 sinvoll und kostet wahrscheinlich auch kaum fläche - ist eigentlich nur eine frage der zeit bis SMT >2 auf x86 kommt.
Naja, ja und nein. Gibt durchaus Anwendungsfälle wo SM4 sinnvoll sein könnte, aber eher selten. SM4 macht im Spiele Bereich absolut keinen Sinn. Aktuell schafft man es ja nicht mal sinnvoll 12-16 Kerne zu beschäftigen. Und selbst die Synthetischen Benchmarks haben teilweise bei den 32-Kernen + SMT Probleme.

Den IBM CPU hat 4x SMT jetzt auch nicht all zu viel gebracht. Sind halt wirklich nur wenigen % wenn überhaupt die man damit gut machen kann. Die Server sind selten heutzutage so überbucht, das sie Dauerhaft ausgelastet sind. Vorher hat man eigentlich an anderen Stellen das Nadelöhr (z.B. die Speicherbandbreite spielt da immer mehr mit rein). Und 2x SMT bringt schon den größten nutzen, was für Gewöhnlich schon nicht viel ist. Aber hey, wenn man später aus einem 64-Kerner noch 5% rausholen kann im Serverbereich, kann sich das schon lohnen. Bei 64-Kernen ists aber auch schon ein ziemliches Transistor-Budget.

[BoMbY]

Und da ist sie wieder, die Glaskugel die die Zukunft voraussagt.

Hier gibt es zumindest eine Möglichkeit zur Vergangenheitsbewältigung: https://www.phoronix.com/scan.php?page=news_item&px=Linux-AVX-512-Usage-Tasks

Was genau willst Du mir damit jetzt sagen? Soll das belegen dass der Linux Kernel schon basiert auf Instruktionen Threads auf SMT-Threads verteilt?

Das Problem bei SMT ist, dass Threads sich gegenseitig blockieren wenn sie die gleichen Rechneinheiten benötigen. Zen ist bei weitem nicht breit genug dass SMT4 hier ordentlich funktionieren kann. Zu viele Dinge hängen voneinander ab.

Vielleicht würde es eventuell 5% bei einem Apache Webserver oder sowas bringen, aber alles andere würde sich vermutlich blockieren. Abgesehen davon dass man dann noch mehr andere Probleme bekommt. Eine Windows Processor Group ist zum Beispiel auf 64 Kerne beschränkt, wenn Du eine CPU mit 64c/256t hast, hast Du mindestens vier Prozessorgruppen. Dann verteilst Du je einen CPU-Thread pro Kern auf eine Prozessorgruppe, oder was?

[Zossel]

Was genau willst Du mir damit jetzt sagen? Soll das belegen dass der Linux Kernel schon basiert auf Instruktionen Threads auf SMT-Threads verteilt?

Nein, es ist noch dümmer, die Anwendung muß sich selbst drum kümmern:

As using complex AVX-512 operations can lead to lower turbo frequencies for those cores, the Linux kernel will be providing better tracking of AVX-512 usage of tasks that is readable by user-space for programs doing their own task placement.

[ ...... ]

This AVX-512 usage tracking is said to be useful for real-world workloads like TensorFlow and Linpack but no performance details were shared to quantify the impact.


Das Problem bei SMT ist, dass Threads sich gegenseitig blockieren wenn sie die gleichen Rechneinheiten benötigen. Zen ist bei weitem nicht breit genug dass SMT4 hier ordentlich funktionieren kann. Zu viele Dinge hängen voneinander ab.

IMHO ist POWER auch nicht sonderlich breiter. Und die Sparc CPUs mit SMT8 waren eher schmaler. Und ein ein Thread der auf einem SMT-Thread läuft ist besser als in der Run-queue zu liegen und nichts zu tun.
Wenn irgendwelche Spiele damit nicht klarkommen, ist es ein Problem der Spiele. Oder darf es Features nicht geben wenn Spiele nichts davon haben?

Vielleicht würde es eventuell 5% bei einem Apache Webserver oder sowas bringen, aber alles andere würde sich vermutlich blockieren. Abgesehen davon dass man dann noch mehr andere Probleme bekommt. Eine Windows Processor Group ist zum Beispiel auf 64 Kerne beschränkt, wenn Du eine CPU mit 64c/256t hast, hast Du mindestens vier Prozessorgruppen. Dann verteilst Du je einen CPU-Thread pro Kern auf eine Prozessorgruppe, oder was?

Wäre ja nicht das erste Mal das irgentwelche Limits in DOS oder Windows von der Hardware überholt werden. Beispiel: https://en.wikipedia.org/wiki/File_Allocation_Table

[Zossel]

das hatte nix mit der performance zu tun. wenn ein "core" nicht unabhängig fetch-decode-execute-write durchführen kann ist es kein core.

Für Int konnten das die Bulldozer-Cores.
Nach dieser Definition wären auch Cores die sich das RAM teilen auch keine Cores weil fetch und write nicht unabhängig voneinander sind.

[danarcho]

Ich glaube, er meint lediglich register writes. Ist zumindest eine interessante Definition, aber ich kann mir trotzdem bauweisen vorstellen, die keine so klaren Grenzen ermöglichen.
Ich denke, höhere SMT Levels kann man als gesetzt ansehen, wenn die CPUs weiter in die Breite gehen, und das tun sie. Dass der Windows-Scheduler zu dumm ist, ist kein Argument für Hardware-Entwickler.

[BoMbY]

Dass der Windows-Scheduler zu dumm ist, ist kein Argument für Hardware-Entwickler.

Es wäre für alle Hardwarehersteller angeraten Microsoft auf's Dach zu steigen, und die dazu bewegen das besser zu machen.

Ebenso wäre es angeraten wenigstens für Linux selber etwas zu bauen was die Lage verbessert.

Zumindest wenn man solche Dinge wie 4-way SMT auf den Markt bringen will.

Bis jetzt wäre mir jedenfalls nicht bekannt dass Windows oder Linux vernünftig mit so etwas umgehen können. Mit einer entsprechenden Systemunterstützung wäre SMT4 jedenfalls nicht total nutzlos, ansonsten obliegt es jedem Softwarehersteller das selbst irgendwie zu berücksichtigen, und das kann sehr mühsam sein, und findet wohl eher selten statt.

[robbitop]

Ggf kommen die smt4 Gerüchte von der custom Zen CPU für Horizon. Da hat AMD doch explizit betont, dass der Kern custom ist und keine einfache Auskopplubg. Ein deutlich verbreiterter Kern mit SMT4 und 512bit FPU würde sich für die Aussge qualifizieren.

[Nightspider]

Kann man abschätzen wie viel 2 zusätzliche Threads bringen könnten?

Einzusätzlicher Thread bringt ja bis zu 40%. Aber drei werden garantiert nicht weiter skalieren.
Da erwarte ich eher was um die +15-20% beim dritten Thread und nur noch um die 10% beim 4. Thread.

[robbitop]

Das hängt davon ab, wie viel Ressourcen sie sich teilen und wie breit der Kern ist. POWER8/9 ist zB ja extra so ausgelegt, dass SMT besonders gut skaliert. SMT2 ist da fast so schnell wie 2 Kerne. Dafür ist ein Kern ohne SMT ziemlich unterausgelastet und wird in ST dadurch nicht schneller. Auch SMT4 skaliert noch ziemlich gut und selbst SMT8 ist noch OK.
Aber dafür sind die Kerne ziemlich fett. Ob es sich na nicht lohnt für das gleiche Transistor/Powerbudget lieber mehr Kerne zu verbauen?

Wenn soetwas kommt, dann IMO mittelfristig nur für Epyic oder ggf nur in den custom CPUs.
Bei Ryzen wird soetwas nicht besonders sinnvoll sein.

[Tesseract]

Für Int konnten das die Bulldozer-Cores.
definitiv nicht. die int execution units sind unabhängig voneinander aber quasi der ganze rest vom modul ist im tandem.

Nach dieser Definition wären auch Cores die sich das RAM teilen auch keine Cores weil fetch und write nicht unabhängig voneinander sind.
sind sie aber. ein core kann alle stages durchlaufen wärend ein anderer core komplett power gated oder sogar permanent deaktiviert ist.

[robbitop]

Steamroller hatte immerhin die Decoder verdoppelt so dass jeder Kern pro Modul seinen eigenen hatte. War nicht auch der L1 am Ende dediziert pro Kern?


———-
Ggf gräbt man CMT ja nochmal für diesen Custom HPC/Servercore aus. Das würde relativ gut skalieren und ist auch mit SMT kombinierbar. CMT war ja auch so schlecht nicht. Nur der Bulldozercore war es.

[Opprobrium]

Genau das meinte ich, als ich sagte das AMD da sehr genau formulieren muss um keine Hintertüren für Klagewütige Verbraucher"schützer" offen zu lassen ;)

[robbitop]

IMO auch ein wenig lächerlich. Wer sich nicht anständig informiert was er kauft, hat es nicht besser verdient. Die meisten tun das auch. Wahrscheinlich auch die, die geklagt haben.

[Tesseract]

Ggf gräbt man CMT ja nochmal für diesen Custom HPC/Servercore aus. Das würde relativ gut skalieren und ist auch mit SMT kombinierbar. CMT war ja auch so schlecht nicht. Nur der Bulldozercore war es.

CMT ist in der theorie ein guter ansatz wenn man viel throughput auf wenig fläche bekommen will, aber in einer zeit wo man schon ohne CMT cores ohne ende hat machen die größeren abhängigkeiten unterm strich wohl mehr probleme als sie lösen. vielleicht als teil eines heterogenen designs in ferner zukunft irgendwann mal wo es z.B. 2 verschiedene arten von CCX gibt, eines mit 4 starken cores mit haufenweise cache und extremer IPC und ein anderes mit vielen kleinen CMT cores die beim number crunchen alles zerstören.

[Setsul]

IMHO ist POWER auch nicht sonderlich breiter. Und die Sparc CPUs mit SMT8 waren eher schmaler. Und ein ein Thread der auf einem SMT-Thread läuft ist besser als in der Run-queue zu liegen und nichts zu tun.
POWER8 kann 4 Loads oder 2 Loads + 2 Stores, POWER9 jede beliebige Kombination von 4 Loads/Stores, soweit ich weiß.
Das ist alles nicht ganz billig.
IBM geht auf maximale Leistung pro Kern, egal wieviele Threads man dafür braucht, plus den Trick 2 SMT4 Cluster als einen SMT8 Kern zu zählen. Wenn man bei Softwarelizenzen pro Kern bezahlt ist das sinnvoll. Für den durchschnittlichen Linux Server mit FOSS eher weniger.

Es gibt in-order SPARC CPUs mit SMT8, das ist nicht falsch wenn man in einer großen Datenbank rumfischt und alle Threads trotz Dutzenden MB Cache die meiste Zeit darauf warten dass die richtigen 100 Byte aus ein paar TB RAM rausgeholt werden. Alles andere läuft darauf nicht so großartig, weil sich 8 Threads 2 ALUs teilen.


Es gibt schon einen Grund wieso Intel kein SMT4 macht.
Bulldozer hatte eigentlich keine Probleme beim Durchsatz und man kann nicht alles auf den Stromverbrauch schieben. Aber in den meisten Situationen sind doppelt soviele Threads mit 55-60% der Leistung pro Thread einfach keine wirkliche Verbesserung.
Sagen wir mal SMT2 bringt 40%, ist ja so bei manchen Programmen, und nochmal 20% durch SMT4. Dann hat man mit SMT2 doppelt soviele Threads mit je 70% der ST Leistung, was nicht so schlecht ist, und bei SMT4 vier mal soviele Threads mit 40% der ST Leistung. 40% der ST Leistung von Zen2 bekommt man locker mit sowas wie nem P6 für weit weniger als 1/4 der Fläche. Aber das ist einfach nicht erstrebenswert. Jedesmal wenn nicht alles perfekt gleichmäßig auf die Threads verteilt ist, also verdammt oft, wartet man auf den langsamsten Thread und die Latenz geht hoch.


Endergebnis ist dass SMT4 entweder nicht so billig ist wie viele glauben, weil man den Kern stark aufbohren müsste, oder nicht so nützlich ist weil die Leistung pro Thread auf ein unangenehm niedriges Niveau abfällt.

[S940]

Es gibt schon einen Grund wieso Intel kein SMT4 macht. Ja, deren enges Kerndesign. In den letzten Generationen verbreitern sie das aber auch immer weiter. Damit könnten sie auch bald mit SMT4 um die Ecke kommen.
Sagen wir mal SMT2 bringt 40%, ist ja so bei manchen Programmen, und nochmal 20% durch SMT4. Dann hat man mit SMT2 doppelt soviele Threads mit je 70% der ST Leistung, was nicht so schlecht ist, und bei SMT4 vier mal soviele Threads mit 40% der ST Leistung. 40% der ST Leistung von Zen2 bekommt man locker mit sowas wie nem P6 für weit weniger als 1/4 der Fläche.
Aber wenn du soviele P6 haben willst, brauchst Du erstmal nen Interconnect, um die alle zu verbinden. Um den gleichen Stromverbrauch zu erzeugen müsstest Du das Design auch auf 10/7nm portieren und dann fehlen Dir auch noch diverse Befehlssatzerweiterungen und Features, z.B. zur Virtualisierung, Verschlüsselung etc..

Aber das ist einfach nicht erstrebenswert. Jedesmal wenn nicht alles perfekt gleichmäßig auf die Threads verteilt ist, also verdammt oft, wartet man auf den langsamsten Thread und die Latenz geht hoch.Deswegen setzt man SMT4/8/16 v.a. dort ein, wo der Nutzer eine höhere Latenz hat, eben bei Webserver und/oder Datenbanken.
Dort hat ein eigener Thread pro User-Instanz dann sogar Latenzvorteile.
Damit kann man auch Leistungsspitze besser abfangen. Bei Deinem hypotetischen P6-Manycore müsstest Du dafür mehrere Extrakerne vorsehen, die in der Nebenzeit nur Stromkosten verursachen und bei der Herstellung Die-Fläche kosten. SMT bietet hier ein besseres P/L-Verhältnis.


Endergebnis ist dass SMT4 entweder nicht so billig ist wie viele glauben, weil man den Kern stark aufbohren müsste, oder nicht so nützlich ist weil die Leistung pro Thread auf ein unangenehm niedriges Niveau abfällt.
Natürlich bringt SMT4 nicht mehr so viel, aber Zen hat schon seit dem Anfang 4 INT-Pipes, dort kämen sich die 4 Threads nicht großartig ins Gehege. Zen2 war relativ konservativ und platzsparend designt, Hauptziel war die breitere FPU. Der 7nm Prozess war ja auch noch taufrisch. Beim Nachfolgemodell hat man mehr Raum für einen fetteren Kern. Wenn AMD dabei z.B. die L1-Caches (wieder) auf 64kB verdoppeln und die µOp-Loop, Schattenregister etc. pp ebenfalls vergrößern würde, kostet das nicht allzuviel, brächte sogar für single-Thread Anwendungen ein kleines Plus und würde den Leistungseinbruch bei 4 Threads gering halten.


Das ist auch der große Vorteil ggü. CMT: Ein einzelner Therad kann nie die (größeren) Resourcen des 2. Clusters nutzen, bei SMT geht das dagegen. Deshalb rentieren sich damit auch Kernausbauten, die sich - aufgrund des mageren Leistungsplusses mit einem oder 2 Threads - eigentlich nicht rentieren würden.
Damit hält man dann auch die komplette Kundschaft bei Laune. Die Gamer freuen sich über etwas mehr IPC, die Epyc-Kunden über die passable SMT4-Leistung und den hohen Durchsatz.

[Setsul]

Also Skylake und Sunny Cove würde ich nicht gerade als eng bezeichnen.
Zen2 ist nicht wesentlich breiter und schon da haben viele SMT4 erwartet.

P6 zu portieren und zu erweitern wäre garantiert weniger Aufwand als die letzten 20 Jahre an CPU Designs mit höherer ST performance. Es wäre sogar weniger Aufwand als nur Sunny Cove. Interconnect existiert, siehe Xeon Phi (hat auch SMT4 nebenbei).

Der Punkt ist dass es Lasten gibt bei denen man einen Haufen langsamer Threads will, aber das sind nicht die, mit denen Intel und AMD den Großteil ihres Umsatzes machen.
SMT4 ist eben nicht kostenlos und muss mehr bringen um den Ressourcenaufwand zu rechtfertigen als etwas das bei (fast) allen Lasten Vorteile bringt.

Intel hat seit Haswell 4 INT-ALUs, das ist keine große Hürde. POWER8 und 9 haben auch 4. Das heißt nicht dass SMT4 für Haswell, Zen(2) und POWER8/9 gleichermaßen sinnvoll sind. Wie gesagt es gibt SPARC CPUs mit 2 ALUs und SMT8.
POWER9 hat auch nur 32 kB L1. Bloß mit ein bisschen mehr Cache und Registern bringt man SMT4 nicht von 40% ST auf z.B. 60%. Dafür müsste SMT4 doppelt soviel bringen wie SMT2 und das geht schon rein logisch nicht.
ALUs sind nicht das Problem, die sind ja gerade der Teil den man besser auslasten will weil man oft mehr hat als man braucht. Man braucht mehr Loads/Stores um Arbeit für die ALUs zu beschaffen und mehr Load/Store Queues sind teuer. In der Hinsicht hat Zen2 gerade erst zu Intel aufgeschlossen (Zen war nur 1L+1S/2L, Intel 2L+1S) und Sunny Cove zieht wieder weg (2L+2S) während POWER8/9 deutlich voraus sind.
Weder in Workloads noch in L/S-Breite ist Zen2 näher an POWER8/9 als Haswell und deshalb lohnt sich SMT4 für beide nicht. 7nm EUV ist nicht soviel besser als 7nm DUV dass Zen3 in der Hinsicht massiv aufgebohrt werden könnte ohne in anderer Hinsicht oder Core Count (relativ hartes TDP Limit atm) zurückzufallen und die Workloads werden sich kaum ändern. Vor Zen4 denke ich nicht dass sich SMT4 sinnvoll implementieren lässt.


CMT ist nicht völlig abwegig, es muss nur die ST oder pro-Thread Leistung eines Clusters alleine immer ausreichend sein. Kleinere Cluster sind einfacher und billiger zu bauen als ein riesiger Kern. Von den SMT8 SPARCs teilen sich bei manchen 4 Threads einen Cluster und 2 Cluster eine FPU weil Leistung pro Thread nachrangig ist (also wenig Vorteile durch besseres sharing) und die FPU für Datenbanken praktisch nie gebraucht wird. POWER8 hat 2 Cluster aber die teilen sich zum Beispiel die Branch Units. Die Cluster sind einfach alleine groß genug für anständige Performance und 2 halb so große PRFs sind viel billiger als eine riesige.
SMT ist kein Freifahrtschein einen monolithischen Kern bis ins Unendliche zu verbreitern weil die Kosten nicht linear steigen. Umgekehrt wird alles billiger in je mehr und je kleinere Cluster man es unterteilt aber die Cluster müssen groß/schnell genug sein um alleine nützlich zu sein, sonst bekommt man Bulldozer.

[danarcho]

Ihr müsst verstehen, dass SMT praktisch eine Resteverwertung der extremen ST Leistung ist. Will man diese weiter erhöhen, muss man zwangsläufig den Kern aufboren (größeres instruction window, decoder, execution units, blabla). Dabei bleiben aber immer mehr Ressourcen immer häufiger ungenutzt. Durch zusätzliche virtuelle Kerne kann man jetzt mit wenig Aufwand diese Ressourcen (lies Fläche) nutzen, und die MT Leistung überproportional steigern (und zwar deutlich mehr als durch das Hinzufügen weiterer Kerne möglich ist).
Folgende Überlegung ist dabei relevant: Möchtet ihr lieber eine 32/64-Core CPU mit aktueller Leistung oder eine 16/64-Core CPU mit vielleicht +10% ST, dafür aber -20% MT bei gleicher DIE-Size. (Vielleicht geht bei einer Verdopplung der Fläche auch mehr ST, keine Ahnung.)
Was ich aber für eher unwahrscheinlich halten würde, wäre +80% DIE-Size, und weiterhin nur 32 Threads. Und schon merkt ihr selbst, dass SMT im Interesse der Spieler ist, da die Server-Seite sicher nicht bereit sein wird auf die zusätzlichen Threads zu verzichten. Das ganze muss natürlich nicht mit Zen3 passieren, aber irgendwann wird es sicher so kommen.

Ebenso wäre es angeraten wenigstens für Linux selber etwas zu bauen was die Lage verbessert.
Soweit ich weiß, existiert das längst.

[BoMbY]

Soweit ich weiß, existiert das längst.

Es gibt einen Ansatz:

https://lwn.net/Articles/780703/

https://lkml.org/lkml/2019/2/18/1152

Soweit ich das gerade sehe ist das aber noch nicht Mainline.

Edit: Ach das ist eher eine Mitigation für die Intel-Probleme.

Das ist vermutlich der aktuelle Stand:

https://en.wikipedia.org/wiki/Completely_Fair_Scheduler

Das ist vermutlich der letzte große Wurf:

https://lkml.org/lkml/2018/9/7/1521

Nach diesem Paper:

http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf

[MiamiNice]

Folgende Überlegung ist dabei relevant: Möchtet ihr lieber eine 32/64-Core CPU mit aktueller Leistung oder eine 16/64-Core CPU mit vielleicht +10% ST, dafür aber -20% MT bei gleicher DIE-Size. (Vielleicht geht bei einer Verdopplung der Fläche auch mehr ST, keine Ahnung.)


Dato 2019 hätte ich gerne eine 8 Core CPU ohne SMT mit 30% mehr ST Leistung. Das wäre göttlich :D