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

[Zossel]

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.

Linux läuft ja lange schon auf POWER & Co, wenn X64/X86 mit Features nachzieht die es woanders schon gibt dann ist das in Linux meistens schon implementiert.

~/src $ ls -l linux-4.19.26/arch/
total 124
drwxrwxr-x 9 xxx xxx 4096 Feb 27 2019 alpha
drwxrwxr-x 14 xxx xxx 4096 Feb 27 2019 arc
drwxrwxr-x 101 xxx xxx 4096 Feb 27 2019 arm
drwxrwxr-x 12 xxx xxx 4096 Feb 27 2019 arm64
drwxrwxr-x 9 xxx xxx 4096 Feb 27 2019 c6x
drwxrwxr-x 8 xxx xxx 4096 Feb 27 2019 h8300
drwxrwxr-x 7 xxx xxx 4096 Feb 27 2019 hexagon
drwxrwxr-x 14 xxx xxx 4096 Feb 27 2019 ia64
-rw-rw-r-- 1 xxx xxx 26541 Feb 27 2019 Kconfig
drwxrwxr-x 25 xxx xxx 4096 Feb 27 2019 m68k
drwxrwxr-x 10 xxx xxx 4096 Feb 27 2019 microblaze
drwxrwxr-x 52 xxx xxx 4096 Feb 27 2019 mips
drwxrwxr-x 8 xxx xxx 4096 Feb 27 2019 nds32
drwxrwxr-x 9 xxx xxx 4096 Feb 27 2019 nios2
drwxrwxr-x 8 xxx xxx 4096 Feb 27 2019 openrisc
drwxrwxr-x 10 xxx xxx 4096 Feb 27 2019 parisc
drwxrwxr-x 19 xxx xxx 4096 Feb 27 2019 powerpc
drwxrwxr-x 7 xxx xxx 4096 Feb 27 2019 riscv
drwxrwxr-x 19 xxx xxx 4096 Feb 27 2019 s390
drwxrwxr-x 15 xxx xxx 4096 Feb 27 2019 sh
drwxrwxr-x 15 xxx xxx 4096 Feb 27 2019 sparc
drwxrwxr-x 8 xxx xxx 4096 Feb 27 2019 um
drwxrwxr-x 8 xxx xxx 4096 Feb 27 2019 unicore32
drwxrwxr-x 27 xxx xxx 4096 Feb 27 2019 x86
drwxrwxr-x 11 xxx xxx 4096 Feb 27 2019 xtensa
~/src $

SMT kommt als zusätzliche CPU hoch, im wesentlichen muss der Scheduler die CPU-Topologie möglichst geschickt nutzen. Ohne /dev/glaskugel kann der Scheduler lediglich schätzen und raten welcher der beste Core für den nächsten Kandidaten auf der Runqueue ist. Flow-Control für TCP ist auch so ein Thema wo man nur schätzen und raten kann, man kennt den Zustand der restlichen Welt nicht.

[Zossel]

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

Einfach theoretische Physik studieren und dann so ein Ding bauen.

[Zossel]

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.

Ich könnte mir vorstellen das wir in Zukunft Teile von CMT auch in "herkömmlichen" SMT-CPUs sehen werden. Eigener µ-Op Cache pro SMT-Thread oder so ähnlich.

Gibt es kommerzielle CPUs außerhalb von Bulldozer die CMT implementiert haben?

[Zossel]

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.

Mein Ryzen1x bringt ~133% beim compilieren (make -jx). Compilieren schmeckt SMT ziemlich gut wenn die Makefiles mitspielen.

Hat jemand Zahlen für Intel?

[danarcho]

Ich könnte mir vorstellen das wir in Zukunft Teile von CMT auch in "herkömmlichen" SMT-CPUs sehen werden. Eigener µ-Op Cache pro SMT-Thread oder so ähnlich.

Gibt es kommerzielle CPUs außerhalb von Bulldozer die CMT implementiert haben?
Aus theoretischer Perspektive ist das eh einerlei. Bei SMT geht es darum, dass Instruktionen von zwei Threads im gleichen Taktzyklus auf geteilten Ressourcen ausgeführt werden können. CMT hat nur neben register file, und so drumherum-pipapo noch die integer units aufgeteilt/verdoppelt (mit bescheidenem Erfolg). Da gibt es keinen essentiellen Unterschied, der einen zusätzlichen Begriff rechtfertigen würde, außer man möchte schlechten Implementierungen einen anderen Namen geben.

[Zossel]

Da gibt es keinen essentiellen Unterschied, der einen zusätzlichen Begriff rechtfertigen würde, außer man möchte schlechten Implementierungen einen anderen Namen geben.

Ich bin verwirrt, wo habe ich eine neue Begrifflichkeit genutzt?

[Tesseract]

Ich könnte mir vorstellen das wir in Zukunft Teile von CMT auch in "herkömmlichen" SMT-CPUs sehen werden. Eigener µ-Op Cache pro SMT-Thread oder so ähnlich.

kann ich mir nicht vorstellen. das hauptargument für SMT ist ja gerade, dass es fast keine chipfläche kostet und auf einem extrem auf ST-leistung getrimmten kern fast gratis mitläuft. würde man auf durchsatz optimieren wollen könnte man ganz andere monster bauen, aber das ist halt nicht das primäre optimierungskriterium. wie gesagt: in einer heterogenen CPU möglicherweise, auf den primärkernen eher nein.

[Zossel]

kann ich mir nicht vorstellen. das hauptargument für SMT ist ja gerade, dass es fast keine chipfläche kostet und auf einem extrem auf ST-leistung getrimmten kern fast gratis mitläuft. würde man auf durchsatz optimieren wollen könnte man ganz andere monster bauen, aber das ist halt nicht das primäre optimierungskriterium. wie gesagt: in einer heterogenen CPU möglicherweise, auf den primärkernen eher nein.

Irgendwo wird auch eine SMT-CPU Bottlenecks haben und anstatt zum Beispiel den µ-Op-Cache auf Kosten höherer Latenz zu vergrößern baut man für jeden Thread einen eigenen.

Aber lassen wir uns überraschen.

[HOT]

Man wird 4 fach-SMT vor allem deshalb ausgegraben haben, weil die Kerne immer fetter werden - sie sollen ja auch immer mehr Leistung pro Kern bringen. Hinzu kommt, dass man bei kleineren Prozessen immer mehr die Wärmeableitung im Blick haben muss und man muss auch dieses bei fetteren Caches + Registern mit einkalkulieren. Mehr Cache bedeutet auch mehr Fläche. Das wird auch der Hauptgrund sein, warum Willow Cove 3MB L3 bekommt und Zen2 16MB L3 hat.

Mehr Kerne wird es über 64 bzw. 16 sicherlich nicht mehr geben auf absehbare Zeit. AMD wird selbst bei Zen4 und Zen5 bei dieser Anzahl bleiben mMn und Intel wird sich dem annähern. Wir treten jetzt in eine Zeit ein, in der die Pro-Kern-Leistung absolut entscheidend wird, in der aber eben auch die maximal MT-Leisung gefordert wird. Die neuen Designs werden beidem Rechnung tragen.

Dato 2019 hätte ich gerne eine 8 Core CPU ohne SMT mit 30% mehr ST Leistung. Das wäre göttlich :D
Das macht nur keinen Sinn. Das ist schlicht und ergreifend ein Denkfehler. ST-Leistung gibt es nur mit mehr-von-allem pro Kern. Und wenn du mehr von allem pro Kern bringst, profitierst du nahezu automatisch von mehr SMT in massiv-MT-Anwendungen, ist also dämlich auf SMT zu verzichten, das wäre einfach nicht verhältnismäßig.

[robbitop]

Also ich tippe schon darauf, dass mit jedem größeren Shrink auch mehr Kerne dazu kommen. Ggf aber nicht mehr so rasant wir in den letzten 2 Jahren.

[BoMbY]

Linux läuft ja lange schon auf POWER & Co, wenn X64/X86 mit Features nachzieht die es woanders schon gibt dann ist das in Linux meistens schon implementiert.


Junge, junge, junge ... Nur weil das System darauf läuft heißt das noch lange nicht dass der Scheduler vernünftig damit umgeht.

[Zossel]

Junge, junge, junge ... Nur weil das System darauf läuft heißt das noch lange nicht dass der Scheduler vernünftig damit umgeht.

CPU Topologien, NUMA & Co gibt es unter Linux schon länger. Was allerdings nicht ausschließt das ein anderes OS mit den ein oder anderen Workload besser oder schlechter umgeht.

BTW: Würde unter Linux mehr gezockt würde das sicherlich auch Spuren im Scheduler hinterlassen.

[BoMbY]

Ja, und deswegen sage ich ja müssen die Hardware-Hersteller wie AMD da mal was machen. Bei Zen-CPUs ist es zum Beispiel möglich Instruktionen mit den Performance Monitor Countern zu zählen (https://github.com/iBoMbY/RIM). Dürfte eigentlich nicht so schwer sein damit irgendwas wie Scheduler-Hints auf die Reihe zu bekommen - am besten mit eigenen Registern im MSR dafür.

[Zossel]

Ja, und deswegen sage ich ja müssen die Hardware-Hersteller wie AMD da mal was machen. Bei Zen-CPUs ist es zum Beispiel möglich Instruktionen mit den Performance Monitor Countern zu zählen (https://github.com/iBoMbY/RIM). Dürfte eigentlich nicht so schwer sein damit irgendwas wie Scheduler-Hints auf die Reihe zu bekommen - am besten mit eigenen Registern im MSR dafür.

Wahrscheinlich würde die Bürokratie zur Auswertung mehr Zyklen verbrauchen als es Zyklen bringt.

Welches Modell würdest du dort zur Anwendung bringen wollen?

Wie sollte man z.b. "The number of branch instructions retired, of any type, that were not correctly predicted. This includes those for which prediction is not attempted (far control transfers, exceptions and interrupts)." auswerten und interpretieren und welchen Anteil unter welchen Bedingungen sollte die Interpretation haben um etwas auf einem Core zu schedulen der weiter weg ist als da wo er vorher gelaufen ist. Und welche Art von Workload würde das beschleunigen?

[BoMbY]

Man müsste das idealerweise umbauen, so dass man Threads Stalls, wenigstens pro CPU Thread, besser noch pro OS Thread (die müssten dann vielleicht getagt werden, oder sowas), zählt. Dann braucht der OS Scheduler nur regelmäßig zu schauen wo es viele Blockaden auf Grund von gleichzeitig genutzten Resourcen gibt, und kann versuchen die Threads zu verschieben.

Edit: Ahh, gibt sogar schon was in die Richtung:


PMCx087 [Instruction Pipe Stall] (Core::X86::Pmc::Core::IcFetchStall)


IcStallAny. Read-write. Reset: 0. Instruction Cache pipeline was stalled during this clock cycle for any reason.
IcStallDqEmpty. Read-write. Reset: 0. Instruction Cache pipeline was stalled during this clock cycle due to upstream not providing fetch addresses quickly.
IcStallBackPressure. Read-write. Reset: 0. Instruction Cache pipeline was stalled during this clock cycle due to downstream queues being full.

[Zossel]

Edit: Ahh, gibt sogar schon was in die Richtung:


PMCx087 [Instruction Pipe Stall] (Core::X86::Pmc::Core::IcFetchStall)


Wenn das nicht wegen "any Reason" auftritt ist ziemlich wahrscheinlich kein einzelner Core mehr frei, sonst wäre der Thread mit hoher Wahrscheinlich darauf geworfen worden oder der Core ist topologisch zu weit weg.

Ich tippe allerdings drauf da bei Anwendungen wo so etwas was bringt, die Anwendung besser selbst Affinitäten setzen sollte, in einem typischen mixed Workload kann so was schnell nach hinten losgehen. Das Debugging solcher Geschichten ist nicht trivial.

Für gleichförmige HPC-Workloads wäre evtl. ein Userspacedaemon denkbar der nicht allzu hektisch Affinitäten setzt. In mixed Workloads mit ordentlich IO ist das bestimmt die Hölle.

Schreibt jemand einen Patch?

[BoMbY]

Okay, das alleine scheint noch kein guter Messwert zu sein:

8 Threads:

https://i.imgur.com/QomdLMK.png

16 Threads:

https://i.imgur.com/8Xmo9oJ.png

Das ist jetzt nur IcStallBackPressure. IcStallDqEmpty zählt eigentlich fast nix. Außer ich hab da noch irgendwelche Werte für die Initialisierung falsch.

[SKYNET]

Also ich tippe schon darauf, dass mit jedem größeren Shrink auch mehr Kerne dazu kommen. Ggf aber nicht mehr so rasant wir in den letzten 2 Jahren.

ich behaupte dreist, mit AM5 sehen wir 32 kerne im mainstream. :smile:

[robbitop]

Mal schauen. Aber @5nm schon mehr als 16 denke ich.

[basix]

Schwierig zu sagen. Bis dahin ist 5nm angesagt. Densitysteigerung soll +80% betragen. Doppelte Anzahl Kerne wäre also möglich. Das Problem ist die nur +20-30% steigende Energieeffizienz aufgrund des Prozesses alkein. Da müsste AMD das Design nochmals deutlich auf Effizienz trimmen, falls das mit ähnlichen Taktraten wie heute laufen soll.

[robbitop]

Man muss ja nicht immer eine Verdopplung hinlegen. Ein Teil kann man für mehr Leistung pro Kern investieren und einen Teil für mehr Kerne. +25% oder +50% wäre auch ein Fortschritt.

Zumal in vielen Anwendungen sicherlich auch Amdahls Law signifikant zu greifen beginnen dürfte.

[Locuza]

Ehm..., bisschen lol, aber AMD hat in einem YouTube-Video die High-Level-Specs zu Zen3 offiziell gemacht:
https://www.youtube.com/watch?v=2IqD7U9oNpQ&feature=youtu.be&t=90

https://pbs.twimg.com/media/EGD5UkFX0AYxFsi?format=jpg&name=large
https://pbs.twimg.com/media/EGD5WPfW4AA0RJ6?format=jpg&name=medium

via Dayman at twitter:
https://twitter.com/Dayman58/status/1180212484495626243

Also es bleibt bei 8 CPU-dies + 1 I/O-die.
Die Gerüchte um 15 dies oder was auch immer, sind damit Geschichte, außer AMD hat noch eine extra Variante in der Hinterhand.
Es bleibt bei SMT2, kein SMT4.
Der L3$ ist nicht mehr gesplittet pro Chiplet, statt 2x16MB sind es 1x32MB, somit 8-Core CCX.

Genoa/Zen4 soll auf Socket SP5 erscheinen.

[gmb]

Milan soll ab Q3 2020 in Produktion gehen, da würde ich jetzt nicht vor 2021 mit Produkten rechnen. Klar, ein launch könnte man noch Ende 2020 unterbringen, aber das ist doch dann ein 2021 Produkt bei dem Produktionsstart.

https://abload.de/img/milan1vkzs.png
https://youtu.be/2IqD7U9oNpQ?t=57

Ich vermisse hier PCIe5 und DDR5 Support bei Milan. Auch zeitlich geht das gegen Sapphire Rapids-SP, welcher auch schon Anfang 2021 starten kann, das überschneidet sich:

https://abload.de/img/spc3kuy.png


Ich habe ein ungutes Gefühl für Milan wenn es gegen Sapphire Rapids geht.

[Unicous]

Klar hast du ein ungutes Gefühl wenn es um AMD geht. Das ist deine generelle Einstellung.:wink:

Tu doch bitte nicht so, als wärst du an Wettbewerb interessiert.:rolleyes:

[Locuza]

Mark Papermaster hat schon im letzten Jahr im Novemeber durchscheinen lassen, dass es mit Milan kein DDR5 oder PCIe5-Support geben wird und man auf dem selben Sockel bleibt:
IC: AMD has already committed that Milan, the next generation after Rome, will have the same socket as Rome. Can you make the same commitment with Zen 4 that was shown on the roadmap slides?

MP: We’re certainly committed to that socket continuity through Milan, and we haven’t commented beyond that. Obviously at some point the industry transitions to PCIe 5.0 and DDR5 which will necessitate a socket change.

IC: So one might assume that an intercept might occur with Zen 4?
https://www.anandtech.com/show/13578/naples-rome-milan-zen-4-an-interview-with-amd-cto-mark-papermaster

Das hat diesen Juni Forrest Norrod noch einmal direkt gesagt:
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

Und "vielleicht" kann man die Skepsis pflegen, dass Sapphire Rapids nicht in Q1 2021 erscheint ;)

[gmb]

Klar hast du ein ungutes Gefühl wenn es um AMD geht. Das ist deine generelle Einstellung.:wink:



Diesmal habe ich wirklich ein ungutes Gefühl. Nicht nur auf der Feature Seite wären sie hinten, auch bleibt Milan bei 64C stehen und die Architektur sieht nach einem Tick refresh aus.



Und "vielleicht" kann man die Skepsis pflegen, dass Sapphire Rapids nicht in Q1 2021 erscheint ;)


Ja das ist wohl die einzige Hoffnung, aber selbst wenn Sapphire Rapids 2 Quartale später kommt, überschneidet sich das stark. Und auch Milan muss erstmal wie geplant kommen.

[iuno]

Die Roadmap sollte ja aktuell sein, die Veranstaltung war Mitte September. Er sagt, Milan sei "being sampled". Es sieht ja jetzt auch nicht nach den riesigen Aenderungen aus, von dem 8C CCX mal abgesehen. Ggf. bleibt das I/O Die sogar gleich?
Milan wird ja demnach relativ schnell auf Rome folgen und die 1. Generation CCDs schon abgeloest werden. Ob die 2. dann das I/O Update ueberlebt?

Interessant finde ich, dass jetzt noch explizit nach Anregungen fuer Genoa gefragt wird :uponder:

[Sunrise]

Diesmal habe ich wirklich ein ungutes Gefühl. Nicht nur auf der Feature Seite wären sie hinten, auch bleibt Milan bei 64C stehen und die Architekur sieht nach einem Tick refresh aus.
Ist doch aber praktisch schon alles bekannt gewesen, dass Zen3 sich stark auf Optimierungen konzentriert, wenn der Prozess dies vorgibt. 5nm kommen erst mit Zen4. AMD muss damit genauso umgehen, wie Apple und alle anderen. Und Zen bleibt eben Zen, nur wird da wohl einiges unter der Haube passieren. Man merkt du schaust oder liest dir keine AMD-Roadmaps an bzw. News durch.

Dennoch sollte man sich nichts vormachen, Intel wird nicht Ewigkeiten zusehen, aktuell haben sie nur keine andere Möglichkeit.

Sieht man nur die AMD-Roadmap alleine siehts natürlich sehr unspektakulär aus, aber dann nutzt man die 7nm+ Vorteile auch dort, wo nochmal genug IPC-, Cache- und Takt-Optimierungen ordentliche Sprünge bringen, während Intel weiterhin auf 14nm fest sitzt und gegen die Wand rennt.

Es bleibt erstmal abzuwarten wie weit Intel mit 10nm kommt, bzw. wann 7nm überhaupt einsatzbereit ist. Und hier gehts ja um Massenproduktion und Stückzahlen. Roadmaps sehen immer ganz toll aus, da Intel die Dinger immer ins super positive Licht rückt. Spannend wirds dann eher bei 5nm vs. 7nm.

AMD muss natürlich möglichst schnell erneut mit einem 5nm-Design nachlegen um den Vorsprung so gut als möglich zu halten. Sieht von außen einfach aus, aber da muss einfach alles stimmen. Daher ist die Situation ja auch so spannend, da AMD keine Sekunde auf die Bremse treten darf.

[Piefkee]

Diesmal habe ich wirklich ein ungutes Gefühl. Nicht nur auf der Feature Seite wären sie hinten, auch bleibt Milan bei 64C stehen und die Architektur sieht nach einem Tick refresh aus.





Ja das ist wohl die einzige Hoffnung, aber selbst wenn Sapphire Rapids 2 Quartale später kommt, überschneidet sich das stark. Und auch Milan muss erstmal wie geplant kommen.

Wieviele Kerne hat aktuell Intel *Hust* ohne Kleber und Watercooling? XD

Im Server Segment mache ich mir um AMD Null sorgen.

[Piefkee]

Übrigens bei Milan steht nur „7nm“ ist aber ein typo.
Siehe untere rechte Ecke da steht 7nm+ und ebenfalls wo anders im Video, beziehungsweise auf anderen offiziellen Roadmaps steht 7nm+

[SKYNET]

Ist doch aber praktisch schon alles bekannt gewesen, dass Zen3 sich stark auf Optimierungen konzentriert, wenn der Prozess dies vorgibt. 5nm kommen erst mit Zen4. AMD muss damit genauso umgehen, wie Apple und alle anderen. Und Zen bleibt eben Zen, nur wird da wohl einiges unter der Haube passieren. Man merkt du schaust oder liest dir keine AMD-Roadmaps an bzw. News durch.

Dennoch sollte man sich nichts vormachen, Intel wird nicht Ewigkeiten zusehen, aktuell haben sie nur keine andere Möglichkeit.

Sieht man nur die AMD-Roadmap alleine siehts natürlich sehr unspektakulär aus, aber dann nutzt man die 7nm+ Vorteile auch dort, wo nochmal genug IPC-, Cache- und Takt-Optimierungen ordentliche Sprünge bringen, während Intel weiterhin auf 14nm fest sitzt und gegen die Wand rennt.

Es bleibt erstmal abzuwarten wie weit Intel mit 10nm kommt, bzw. wann 7nm überhaupt einsatzbereit ist. Und hier gehts ja um Massenproduktion und Stückzahlen. Roadmaps sehen immer ganz toll aus, da Intel die Dinger immer ins super positive Licht rückt. Spannend wirds dann eher bei 5nm vs. 7nm.

AMD muss natürlich möglichst schnell erneut mit einem 5nm-Design nachlegen um den Vorsprung so gut als möglich zu halten. Sieht von außen einfach aus, aber da muss einfach alles stimmen. Daher ist die Situation ja auch so spannend, da AMD keine Sekunde auf die Bremse treten darf.


sagte ich schon vor wochen/monaten, das Zen3 nix anderes sein wird wie Zen+ zu Zen1... optimierungen, 5-10% bessere IPC und 300-400MHz mehr takt, thats it.

würd mich auch nicht wundern, wenn die TR3000 abgesehen vom shrink schon sämtliche verbesserungen aufweisen, die mit Zen3 kommen... so wie es schon bei TR1000 war, war ja auch schon nen halber Zen+

[Opprobrium]

Milan soll ab Q3 2020 in Produktion gehen, da würde ich jetzt nicht vor 2021 mit Produkten rechnen
Stimmt. Rome ging Ende Q2 2019 in Produktion. Und jetzt haben wir schon Anfang des 4. Quartals und es sind immer noch keine Produkte verfügbar :rolleyes:

Diesmal habe ich wirklich ein ungutes Gefühl. Nicht nur auf der Feature Seite wären sie hinten, auch bleibt Milan bei 64C stehen und die Architektur sieht nach einem Tick refresh aus.
Wie können sie es wagen nicht jedes Jahr die Kernanzahl zu verdoppeln. Man stelle sich mal vor Intel würde sich so auf ihren Lorbeeren ausruhen. Dann wären die jetzt nämlich noch nicht bei 56 Kernen angekommen!!11!

[Locuza]

Im Gegensatz zu Zen+ ist mit Zen3 schon einmal klar, dass AMD auch architektonisch Hand anlegen wird, denn dort haben alle Kerne Zugriff auf einen gemeinsamen 32MB großen L3$.

AVX512 mag auch noch ein Kandidat sein, welcher von AMD implementiert wird, zwar als Half-Rate, aber das Featureset selber ist schon mehr als die halbe Miete.

[Nightspider]

Wieso steht auf der Folie "32+ MB" und nicht "32MB"? Könnte es am Ende auch mehr werden?

Diesmal habe ich wirklich ein ungutes Gefühl. Nicht nur auf der Feature Seite wären sie hinten, auch bleibt Milan bei 64C stehen und die Architektur sieht nach einem Tick refresh aus.

Erst mal abwarten ob sich Intel mit dem Überspringen von PCIe4 nicht wieder auf die Fresse legt.

Bei 10nm wollte Intel so einen großen Sprung hinlegen das sie es total vergeigt haben. Die aktuellen PCIe4 Boards sind auch schon fett und brauchen gut Leistung. Mal abwarten wer arschteure, stromfressende PCI-Express 5 Boards will, wenn es noch keiner braucht.

Am Ende entscheiden sich viele aus Preis-Leistungs-Sicht für PCIe 4.0.

sagte ich schon vor wochen/monaten, das Zen3 nix anderes sein wird wie Zen+ zu Zen1... optimierungen, 5-10% bessere IPC und 300-400MHz mehr takt, thats it.


Ja wild spekulieren kann hier jeder. Willst du einen Keks dafür? Mal den Ball flach halten. Noch ist kein bisschen zur Architektur bekannt und der Name spricht nach wie vor nicht für die These, die neben dir auch von vielen Anderen schon vor 1-2 Jahren geäußert wurde.

[amdfanuwe]

Die Gerüchte um 15 dies oder was auch immer, sind damit Geschichte, außer AMD hat noch eine extra Variante in der Hinterhand.
Wer weiß, was die austüfteln.
Milan 8 Chiplets und gleicher I/O ist erst mal der sichere Weg.

Wäre es eigentlich möglich, den I/O Die aufzusplitten? Z.B. einen 7nm IF Switch Logik Chip und die PCIe und MMC Treiber auf mehreren 14/12nm Chips?
Könnte den Yield und dadurch die Kosten für den I/O senken.
Mehr Kerne sind wohl erst mit 5nm zu erwarten wegen TDP.

Inwiefern wirkt sich das eigentlich aus, wenn mit Milan nur noch ein L3 Cache mit dem I/O kommuniziert statt der bisherigen 2 Caches eines Chiplets?

[w0mbat]

Ich vermisse hier PCIe5 und DDR5 Support bei Milan. Auch zeitlich geht das gegen Sapphire Rapids-SP, welcher auch schon Anfang 2021 starten kann, das überschneidet sich:
Wieso sollte eine SP3 CPU mit DDR5/PCIe 5.0 kommen? Das macht doch keinen Sinn! Erstens völlig unnötig und zweitens war es schon lange klar. Deswegen ist AMD ja gerade so am kommen, weil die Plattform langlebig ist.

Und ob Intel Sapphire Rapids überhaupt hinbekommt ist sehr ungewiss. Ich habe da ein sehr schlechtes Gefühl, das wird bestimmt auf >2025 verschoben. Intel hat ja aktuell extreme Probleme. 14nm Lieferschwierigkeiten, 10nm läuft immer noch nicht, veraltertes CPU Design, alte Plattform, etc.

Wirklich sehr schlechtes Gefühl. Und dann kommt Milan früher an und setzt nochmal einen drauf. Wenn Sapphire Rapids dann mal wirklich kommt ists Genoa ja schon um die Ecke, der wieder 1-2 Generationen weiter ist.

Intel muss erstmal ganz viel aufholen. Wirklich kein gutes Gefühl dabei... Armes Intel :(


Zum leak: schön zu sehen, dass Zen3 wieder ein großer Schritt wird. Ganz neuer CCX Aufbau, war klar, dass das eher wie Zen1->Zen2 wird und kein neuer "Zen2+" ist. Bin echt gespannt :D

[amdfanuwe]

Intel muß erst mal ein eigenes Chiplet Design hinlegen. Mit großen monolithischen Chips können sie kostenäßig nicht mithalten.

[gmb]

Wieviele Kerne hat aktuell Intel *Hust* ohne Kleber und Watercooling? XD

Im Server Segment mache ich mir um AMD Null sorgen.


Es geht nicht um aktuell, es geht um 2021. AMD bleibt bei der Kernanzahl und den Features auf dem aktuellen Stand stehen, da muss man sich schon Sorgen machen.

[BoMbY]

Tja, soviel jedenfalls zum Thema 4-way SMT in Zen3. Na, vielleicht ja in Genua - aber ich glaube die haben da wichtigere Dinge zu tun.

[amdfanuwe]

aber ich glaube die haben da wichtigere Dinge zu tun.
Ja, aber was? Das ist ja das Spannende.
Könnte da was mit 3D Stacking kommen? Ein 16Core Chiplet mit 8GB HBM L3 Cache obendrauf? Wie entwickelt sich der I/O Chip, kommt da ein active Interposer?
Was ist der nächste technische Kniff, der mehr Leistung auf kleineren Raum billiger realisiert ohne das alles verglüht?
Rome ist noch ein allzweck Design, viel I/O viel Compute Leistung. Splittet sich das noch auf in Designs für viel I/O und Designs mit Schwerpunkt auf Compute? Dann braucht der I/O nicht mehr so viel PCIe.

[S940]

Tja, soviel jedenfalls zum Thema 4-way SMT in Zen3. Na, vielleicht ja in Genua - aber ich glaube die haben da wichtigere Dinge zu tun.
Wenn das so läuft wie üblich, dann ist Genua nur ein Zen3 Rev.B mit DDR5-Support. Kleinigkeiten wie SMT4 kann man dann ebenfalls freischalten, auch wenn sie schon in Zen3 implementiert sind.


Mit größeren Core-Änderungen muss man rechnen, falls der Name Zen3 nicht nur vom Marketing ersonnen ist. Von daher besserer Core mit mehr IPC, die man dann im Genua-Aufguss auch für SMT4 nutzen könnte.

[Nightspider]

Es geht nicht um aktuell, es geht um 2021. AMD bleibt bei der Kernanzahl und den Features auf dem aktuellen Stand stehen, da muss man sich schon Sorgen machen.

2021 kommt aber schon Zen 4 und über den wissen wir noch gar nichts.

Und 2021 wird AMD mit 5nm garantiert mehr als 64 Kerne bieten.

[Piefkee]

Es geht nicht um aktuell, es geht um 2021. AMD bleibt bei der Kernanzahl und den Features auf dem aktuellen Stand stehen, da muss man sich schon Sorgen machen.

Keine Ahnung welche Folie du gesehen hast aber Milian kommt 2020. Und Genoa (neuer Sockel neue Features kommt 2021). Intel kommt auch 2021 mit ddr5. Aus meiner Sicht ist jetzt da keiner schneller oder langsamer...

Übrigens
Genoa wird wsl 5nm TSMC und Grafit rapids wir 7nm Intel.
TSMC ist seit Q2 in 5nm Risk Production
Intel ist seit 2010 in 10nm Risk Produktion und wo Sind sie bei 7nm?? XD

[Tobalt]

mit mehr kernen wird es auch immer schwieriger da die Kohärenz zu wahren. logischerweise wird dann als nächstes eine untereinheit definiert werden wie die Cluster bei den gpus.

Amd ist da schon deutlich weiter als Intel, einmal durch Erfahrungen mit dem chiplet Design, dem Infinity fabric und auch durch Erfahrungen von dem gpus. im der Vergangenheit hat Intel solche Rückstände wiederholt egalisiert. Mal sehen wie es diesmal läuft.

jenseits der Kerne und Cluster Ära erwarte ich eine Art neuromorphes cpu Modell, das von der Topologie so ausgelegt ist dass da irgendwie fließend hohe Parallelität oder hoher Takt möglich ist, und auch die Präzision on demand tunebar ist. ein Zwischending zwischen asic und fpga möglicherweise.

da ist Intel mit dem zukauf von altera sicher deutlich besser aufgestellt. ich glaube aktuell nicht dass AMD in diesem Markt eine führende Rolle spielen wird. aber das ist auch noch 10-15 Jahre hin

[robbitop]

In Spielen wird es ziemlich hilfreich sein, wenn sich der L3 durch das Vergrößern des CCX verdoppelt. Vorausgesetzt, dass sich die Latenzen im CCX nicht sonderlich verschlechtern.
Dazu wird es sicherlich auch etwas mehr Takt geben. Dank 7nm+ und ggf dank etwas mehr auf Takt optimiertem Layout.

IMO werden sich die Änderungen der uArch im Core selbst in Grenzen halten. Selbst Intel hat zu besten Zeiten das nur alle 2 Jahre geschafft. Optimization-Infliction scheint IMO eine konkludente Strategie. Hinzu kommt, dass uArch Verbesserungen (zur Performancesteigerung) idR auch elektrische Leistung (bei gleichem Takt) kosten (weil mehr Transistoren). Man benötigt für größere Sprünge also Shrinks damit das im großen Stil sinnvoll ist.

[Complicated]

Der schnelle Sprung auf PCIe/DDR5 könnte von Intel in der Hoffnung vorangetrieben werden, dass AMD so über die Speicherpreise das teurere Gesamtpaket wird. So lange Intel über 90% Marktanteil hat in Servern könnten die RAM-Hersteller den Transit schneller vorantreiben und PCI4 und DDR4 so einen kürzeren Lebenszyklus haben und DDR5 schneller günstiger werden. Die immer größer werdende Speichermenge in den Systemen machen ja mittlerweile einen großen Anteil an den Systemkosten aus.

Hier könnte man eine Gesamtstrategie sehen, dass Intel mit DDR5/PCIe5 mit etwas grundlegendem schnell kontern möchte und so schon jetzt einige Käufer überlegen so lange zu warten, wenn kein Kaufdruck da ist. Der Zeitrahmen könnte stimmen um das Fertigungsdesaster in den Griff zu bekommen. 7nm EUV wird vielleicht noch nicht genügend Wafer-Output haben für den Consumermarkt, doch bei den Servern könnte man so schneller den Verlust der Marktanteile eindämmen. Es verhindert auch, dass Intel weiter AMD hinterherhecheln muss in den Augen der Käufer. Ebenso kann Intel schon früher mit schlechteren Yields im Servermarkt Produkte anbieten, und wenn es nur Spitzen-Modelle sind.

[basix]

Es geht nicht um aktuell, es geht um 2021. AMD bleibt bei der Kernanzahl und den Features auf dem aktuellen Stand stehen, da muss man sich schon Sorgen machen.

Wieso sollten sie beim Feature-Set stehen bleiben? AVX512, Bfloat16, neue Custom oder AI Instruktionen, niedrigere Latenzen durch IF v3, Beschleuniger IP für z.B Verschlüsselung usw. gehören alles zu den Features. Muss nichts davon kommen, die Wahrscheinlichkeit für vieles ist aber hoch.

Beim Desktop könnte es zudem ein 7nm I/O Die geben, um endlich mal alle CPUs mit einer kleinen GPU auszustatten (sagen wir mal 512 RDNA CUs)

[robbitop]

Man kann später ja auch die GPU mit dem IO Die koppeln. Für mobile nicht besonders toll aber für Desktop ausreichend. Wer es braucht zahlt halt mehr. Also als optionale SKU.
Idealerweise nimmt man den kleinsten verfügbaren GPU Chip als Salvage um Synergien zu haben (keine Extrawurst braten). Die GPUs müssten allerdings das entsprechende Interface auch nach außen führen (IF).

[basix]

Ich sehe das momentan als grossen Vorteil von Intel, dass es keine dedizierte GPU braucht. Nicht im Enduser Markt aber bei den OEMs. Eine so kleine GPU wäre in 7nm etwa 50mm2 gross und somit verkraftbar. Ausserdem könnte man den selben I/O Die + CCD Chiplet gleich bei Mobile bringen. Dann benötigt man für Mobile keine Extrawurst (R&D Aufwand sinkt). Nicht optimal, aber im Bereich des Möglichen.

Vom IF-Link zwischen den Die auf dem MCM Package redet man von 2pJ/Bit (und das war bei Zen 1). Bei 40GB/s Bandbreite ergibt das 0.7W. Wie gesagt nicht optimal, aber auch kein Beinbruch. Die volle Speicher-Bandbreite wird viel eher von der GPU ausgelastet als von der CPU, deswegen macht es viel mehr Sinn, die GPU auf dem I/O Die und somit möglichst nahe am RAM zu haben.

Zudem bieten sich allgemein für AMD auf Systemebene noch gewisse Synergien mittels GPGPU Computing / HSA an. Dann ist AVX512 Full-Rate evtl. weniger wichtig.

[HOT]

Wenn das so läuft wie üblich, dann ist Genua nur ein Zen3 Rev.B mit DDR5-Support. Kleinigkeiten wie SMT4 kann man dann ebenfalls freischalten, auch wenn sie schon in Zen3 implementiert sind.


Mit größeren Core-Änderungen muss man rechnen, falls der Name Zen3 nicht nur vom Marketing ersonnen ist. Von daher besserer Core mit mehr IPC, die man dann im Genua-Aufguss auch für SMT4 nutzen könnte.
Da hatte ich ja damit gerechnet, dass Milan schon einen neuen I/O-Die bekommt, aber das hat sich damit ja erledigt, denn deine Theorie find ich noch plausibler.
Dann gibts 2021/22 einen Refresh in Server und Desktop mit den gleichen (oder in einer Art N7+ Pro gefertigten) Zen3-Chiplets, beides aber mit neuen I/O-Dies und neuer Plattform. In 2022/23 kann man dann das Chiplet auf N5 Pro bringen, das wäre dann Zen4. Das passt einfach super.
Milan/Vermeer launchen dann im Q4 2020, nach der letztseitigen Folie ist das jedenfalls der Plan, da man ja im Q3 die Massenproduktion hochfahren will.

Zen3 bekommt einen komplett neuen L3$ (nicht nur mehr)? Einen neuen L1? AVX512? Leute begrabt endlich euren "Zen2+" Gedanken, das ist einfach lächerlich. Zen3 ist das erste wirkliche Architekturupgrade seit dem Zen gelauncht wurde. Die Nummerierung von AMD ist eigentlich irreführend. Wenn man das Versionieren müsste, würde das eher wie folgt aussehen:

Zen1 -> Zen 1.0
Zen+ -> Zen 1.01
Zen2 -> Zen 1.1
Zen3 -> Zen 2.0
Zen3+ -> Zen 2.01
Zen4 -> Zen 2.1

[Setsul]

@gmb:
Bei Naples und Rome steht "production" auch ziemlich genau da wo auch der Launch war. Also wenn nichts schiefgeht scheint AMD tatsächlich 2020Q3 launchen zu wollen.

@Nightspider:
Wahrscheinlich wenn man L1/L2 zählt. Da gabs doch bei Zen1/2 auch ein paar Folien bei denen die paar MB auch noch gezählt wurden um z.B. "20+ MB" pro Chiplet schreiben zu können statt "nur" 16 MB.

Die schlechte Nachricht ist, dass AMD anscheinend die Hoffnung aufgegeben hat in Sachen IF Latenz, die gute ist dass 32 MB L3 für praktisch alles ausreichen dürfte. Seit Skylake haben nur die größten Xeons mehr als das und die kleineren deutlich weniger, also könnte AMD dann sogar im Vorteil sein.

Wird interessant wie genau der L3 implementiert wird. Ich glaube immernoch nicht, dass der gleiche Aufbau wie beim CCX nur mit 8 Slices optimal ist.

[HOT]

Das ist das Ende der 4-Kern-CCX. Hab ich ja schon die ganze Zeit prophezeit und wer wollte das partout nicht wahrhaben? ;)

Ich würd mal vermuten, dass AMD jetzt, wie Intel ja auch, den L3 auf die Kerne aufteilt.

[dildo4u]

8 Kern CCX wäre die Bombe für Notebooks,könnte AMD Zen 2 dort überspringen?

[Berniyh]

Ich sehe das momentan als grossen Vorteil von Intel, dass es keine dedizierte GPU braucht. Nicht im Enduser Markt aber bei den OEMs. Eine so kleine GPU wäre in 7nm etwa 50mm2 gross und somit verkraftbar. Ausserdem könnte man den selben I/O Die + CCD Chiplet gleich bei Mobile bringen. Dann benötigt man für Mobile keine Extrawurst (R&D Aufwand sinkt). Nicht optimal, aber im Bereich des Möglichen.
Da würde ich eher darauf tippen, dass irgendwann in Zukunft das Package einer APU so aussieht:
- 1 Chiplet CPU
- 1 Chiplet GPU
- IO Die
- 1 HBM Stack auf dem IO Die

AMD hat ja in den letzten Jahren immer mal wieder Patente zum Stacking eingereicht.
Muss natürlich nicht heißen, dass man das auch implementiert, aber möglich (und meiner Meinung nach sinnvoll) ist es.
Zen2 -> Zen 1.1
Man baut quasi die komplette CPU um und du nennst das Zen "1.1"? wtf?

[w0mbat]

Naja, so extrem viel hat sich auch nicht geändert. Klar, das layout ist neu (chiplets + I/O), aber wir haben weiterhin einen 4C-CCX Aufbau, IF und cache system.

Neu war nur 2x FP und mehr cache. Die Grundarchitektur ist gleich geblieben. Das soll sich bei Zen3 nun augenscheinlich ändern.

[Opprobrium]

Man baut quasi die komplette CPU um und du nennst das Zen "1.1"? wtf?

Ist doch süß. Nach der Logik wäre Intel gerade bei Nehalem 1.9-1.10

Oder vielleicht bei Pentium 2.X ;)

[Sunrise]

Zen1 -> 1.0
Zen+ -> 1.5
Zen2 -> 2.0
Zen3 -> 3.0
Zen4 -> 4.0
Fixed that for you.

Keine Ahnung wo du den Quark mit Zen3+ wieder her hast. Ob man Zen4 jetzt eher 3.5 nennen sollte (mehr Kerne, DDR5 usw.) lass ich mal dahingestellt, noch zuwenig bekannt.

[Linmoum]

Er weiß halt schon mehr als AMD selbst. ;D

[basix]

Wahrscheinlich wenn man L1/L2 zählt. Da gabs doch bei Zen1/2 auch ein paar Folien bei denen die paar MB auch noch gezählt wurden um z.B. "20+ MB" pro Chiplet schreiben zu können statt "nur" 16 MB.

Ist nur eine Folie (deswegen Korrektheit nicht 100% gegeben), aber dort sind L2 und L3 explizit separat eingezeichnet. Ich vermute eher, dass sie den Cache erhöhen, z.B. auf 48 MB, und dann je nach SKU den Cache beschneiden. 32MB L3 Cache machen momentan ca. 50% des CCD Die aus. Mit 48MB wären es dann 60%, also relativ gesehen nicht so extrem viel mehr. Nimmt man noch die 7nm+ Verbesserungen mit rein (Scaling von +17%) dann wird die 8C CCD Die Size gerade mal +7% grösser und somit ca. 80mm2.

Die schlechte Nachricht ist, dass AMD anscheinend die Hoffnung aufgegeben hat in Sachen IF Latenz, die gute ist dass 32 MB L3 für praktisch alles ausreichen dürfte. Seit Skylake haben nur die größten Xeons mehr als das und die kleineren deutlich weniger, also könnte AMD dann sogar im Vorteil sein.

Wird interessant wie genau der L3 implementiert wird. Ich glaube immernoch nicht, dass der gleiche Aufbau wie beim CCX nur mit 8 Slices optimal ist.

Der zusammengelegte Cache hat ausserdem dem Vorteil, dass man weniger IF Traffic hat, was Energie sparen sollte. Für Games und einige Applikationen ist grösserer Cache ebenfalls von Vorteil, vor allem wenn Intel heute max. 38.75 MiB L3 bietet. Es gibt nur eine Handvoll SKUs von Intel mit mehr als 48 MB (alles Broadwell Xeon Chips: E5-2699 v4, E5-4669 v4, E7-8893 v4 usw.), dort hat man dann aber mindestens 2x Ringbusse anstatt 1x Ring oder ein Mesh. Anwendungen welche solche Cache Grössen voraussetzen könnte dann AMD übernehmen. Gehen sie sogar auf 64MB gibt es nichts vergleichbares. 64 MB ist meiner Meinung nach aber Overkill. 32MB ist für 8 Kerne ja schon sehr viel.

Am IF kann man sicher noch was "flexen". Ich meine, mit dem 8C CCX fällt ein IF "Switch" / Node weg, das kann schon mal helfen. Und mit 7nm+ könnte man noch ein paar kritische Pfade entschärfen. So 10-20ns liegt meiner Meinung nach noch drin, danach wird es wohl wirklich mehr oder minder langsam am Limit sein. Mit 20ns wäre man bei der Core to Core Latency knapp über 50ns und nur noch 10-15% über dem was ein 9900K hat (Link (https://www.reddit.com/r/Amd/comments/calue1/intercore_data_latency/)).

[Brillus]

Wer weiß, was die austüfteln.
Milan 8 Chiplets und gleicher I/O ist erst mal der sichere Weg.

Wäre es eigentlich möglich, den I/O Die aufzusplitten? Z.B. einen 7nm IF Switch Logik Chip und die PCIe und MMC Treiber auf mehreren 14/12nm Chips?
Könnte den Yield und dadurch die Kosten für den I/O senken.
Mehr Kerne sind wohl erst mit 5nm zu erwarten wegen TDP.

Inwiefern wirkt sich das eigentlich aus, wenn mit Milan nur noch ein L3 Cache mit dem I/O kommuniziert statt der bisherigen 2 Caches eines Chiplets?

Würde mehr hops bedeuten als höhere Latenz niedriegere Performance, mehr platz für externe interfaces also von der summe größere Chipsfläche und teurere neue Chip Entwicklung für relative kleine Anzahl an Chips wo man schon fertige Alternative hat, machbar sicherlich ja, sinnvoll sicherlich nein.

[reaperrr]

sagte ich schon vor wochen/monaten, das Zen3 nix anderes sein wird wie Zen+ zu Zen1... optimierungen, 5-10% bessere IPC und 300-400MHz mehr takt, thats it.

würd mich auch nicht wundern, wenn die TR3000 abgesehen vom shrink schon sämtliche verbesserungen aufweisen, die mit Zen3 kommen... so wie es schon bei TR1000 war, war ja auch schon nen halber Zen+
Sorry, aber das ist Quatsch.

Zen+ war nix weiter als der 12LP-Port des B2-Steppings des Zeppelin-Dies, intern also (bis auf ein paar Fixes) zu 100% identisch mit Zen1.

Zen3 löst das CCX-Konzept de facto auf, es gibt nur noch CCDs, dafür muss die CCD-interne Kommunikation zwischen den Kernen aufgebohrt werden (evtl. Ringbus?). Zusätzlich gab es schon Hinweise auf AVX512, auch dafür wird's Änderungen an den Kernen selbst gebraucht haben.
Natürlich keine General-Überholung wie Zen2, aber schon deutlich mehr als Zen+. Und das sind nur die Unterschiede, von denen wir jetzt sicher wissen.

Und nein, TR3000 wird garantiert keine Milan-Verbesserungen beinhalten, weil der auf normale Zen2-CCDs setzen wird, das werden Hardware-seitig normale Rome-Packages sein. TR1 konnte nur deshalb ein paar der Zen+ "Verbesserungen" beinhalten, weil man aus Zeitgründen die prinzipiell schon mit Zen1/B1-Stepping möglichen schnelleren Cache-Latenzen für den Ryzen 1000 Launch nicht mehr rechtzeitig validieren konnte.
Sprich, man hat bei TR1 lediglich etwas aktiviert, was Hardware-intern eh schon unterstützt wurde (und im BIOS auf manchen Boards auch für normale Ryzen1k aktiviert werden konnte).

Die Ryzen 3K werden sie aber nicht so unfertig auf den Markt geschmissen haben wie damals Ryzen 1K, da sie finanziell längst nicht mehr so unter Druck stehen wie damals. Mit Ryzen 1k haben AMD im Grunde ne Art Beta-Version des ersten Chips auf den Markt gehauen und sind potentiellen Problemen durch künstlich erhöhte Latenzen aus dem Weg gegangen.
Danach sieht es bei R3K nicht aus.
Dass sie mit den AGESAs der Hardware etwas hinterherhinken ist ne andere Geschichte.

Es geht nicht um aktuell, es geht um 2021. AMD bleibt bei der Kernanzahl und den Features auf dem aktuellen Stand stehen, da muss man sich schon Sorgen machen.
Blödsinn, muss man nicht. Bei den Features stimmt es so nicht, da es chipseitig sicher Unterstützung für neue Instruktionen geben wird. Und was die Anzahl an PCIe-Lanes angeht ist AMDs Vorsprung eh noch gigantisch.
Last but not least, warte mal ab wie enttäuschend die Taktraten/Latenzen von DDR5 zum Marktstart sein werden. Wenn da in der Praxis 20% mehr Takt für 20% höhere Latenzen stehen, wäre das schon gut, bloß ist der Performance-Vorteil dann verschwindend gering...

Und was die Kern-Anzahl angeht: Du glaubst doch nicht ernsthaft, dass Intel schon mit SR AMD einholt, was die Kernzahl außerhalb von lächerlich überteuerten -AP Modellen mit zwei Chips angeht?
Sapphire Rapids ist immer noch 10nm, auch wenn's ein Upgrade auf die ++ Variante gibt. Die Kernzahl und Perf/W werden im Leben nicht stark genug gegenüber Ice Lake steigen, um in den Disziplinen überhaupt an Rome ranzukommen, von Milan ganz zu schweigen.

Man sollte auch nicht unterschätzen, wieviel allein schon die Fusion der beiden CCX zu einem monolithischen CCD in Sachen Effizienz und MT-Performance bringen könnte. Halbierung(!) der IF-Kommunikation, und jeder Kern kann auf bis zu doppelt so viel L3 zugreifen. Neben etwas höherer effektiver MT-IPC spart das etwas Saft, zusammen mit 7nm+ sollte das mehrere hundert MHz mehr erlauben.
Alles zusammen kann schnell 15% mehr Performance bei gleichbleibendem Verbrauch bedeuten, selbst wenn die IPC je Kern als solche sich nicht ändern sollte (was noch lange nicht sicher ist) und man Unterstützung für neue Instrukionen wie AVX512 nicht berücksichtigt.

[Zossel]

Sapphire Rapids ist immer noch 10nm, auch wenn's ein Upgrade auf die ++ Variante gibt.

Gibt es belastbare Quellen zur Verteilung der der EUV-Belichter von ASML?

Last but not least, warte mal ab wie enttäuschend die Taktraten/Latenzen von DDR5 zum Marktstart sein werden. Wenn da in der Praxis 20% mehr Takt für 20% höhere Latenzen stehen, wäre das schon gut, bloß ist der Performance-Vorteil dann verschwindend gering...

AMD könnte bzgl. RAM dank separaten IO-Die etwas flexibler unterwegs sein.

[y33H@]

Erst Diamond Rapids wird 7 nm sein, aber das dauert noch ein paar Jahre ^^

[gmb]

Und was die Kern-Anzahl angeht: Du glaubst doch nicht ernsthaft, dass Intel schon mit SR AMD einholt, was die Kernzahl außerhalb von lächerlich überteuerten -AP Modellen mit zwei Chips angeht?



Na selbstverständlich, das sollte nun wirklich kein Problem sein.



Die Kernzahl und Perf/W werden im Leben nicht stark genug gegenüber Ice Lake steigen, um in den Disziplinen überhaupt an Rome ranzukommen, von Milan ganz zu schweigen.



Da wirst du dich gewaltig täuschen. An deiner Stelle würde ich die Einschätzung pro AMD stark zurückschrauben, sonst wird es ganz bitter. Da muss man sich wirklich kaputtlachen, Sapphire Rapids soll nichtmal an Rome rankommen :freak:

Meinst du Sapphire Rapids kommt wenigstens an Naples ran? ;D

[Zossel]

Da wirst du dich gewaltig täuschen. An deiner Stelle würde ich die Einschätzung pro AMD stark zurückschrauben, sonst wird es ganz bitter. Da muss man sich wirklich kaputtlachen, Sapphire Rapids soll nichtmal an Rome rankommen

Spannend werden die Kosten bei Monolith vs. Chiplets.

[amdfanuwe]

Intel wird auch mal mit Chiplets kommen. Nur wann?
Ob Intel allerdings irgendwann mal wieder einen Fabrikationsvorsprung von 1 - 3 Jahren rausholt, wage ich zu bezweifeln. Sieht so aus, als würde AMD lange im Geschäft bleiben.

[dildo4u]

Jup es wird vor 5nm kein 64 Core Monolith geben vielleicht nicht mal dann.Laut Intel Roadmap ist das 2023,7nm++ ist 2022.

[w0mbat]

Meinst du Sapphire Rapids kommt wenigstens an Naples ran? ;D
Rome ist ca. doppelt so schnell wie Intels aktuelle Angebote. Denkst du, Intel schafft es in so kurzer Zeit ihre CPUs >50% schneller zu machen? ;D

[fondness]

Rome ist ca. doppelt so schnell wie Intels aktuelle Angebote. Denkst du, Intel schafft es in so kurzer Zeit ihre CPUs >50% schneller zu machen? ;D

Doppelt so schnell = 100% schneller. ;)

[Zossel]

Intel wird auch mal mit Chiplets kommen. Nur wann?

Und mit welchen Interconnect? Mesh? Ringbus?

[Zossel]

Doppelt so schnell = 100% schneller. ;)

50/100 = 0,5 = 50%
100/100 = 1 = 100%
200/100 = 2 = 200%

[Locuza]

1. Das Video von gestern findet sich übrigens nicht mehr auf dem YT-Kanal, vermutlich sah es AMD nicht vor das es öffentlich wird:
https://www.youtube.com/user/hpcadvisorycouncil/videos

Das erinnert mich an Toronto (Server Carrizo), wo ein AMD-Angestellter auch eine Präsentation auf der Supercomputing Conference 2013 gehalten hat und das Video heruntergenommen wurde und auch Anfragen herausgingen, die Bilder zu entfernen.
https://cdn.wccftech.com/wp-content/uploads/2013/12/AMD-Opteron-APU-Roadmap.jpg

https://www.planet3dnow.de/cms/6845-amd-zeigt-opteron-roadmap-bis-2015-auf-der-sc13/

Anyway...


2. 188号 @momomo_us hat ein Bild hochgeladen mit Genoa:
https://pbs.twimg.com/media/EGII5aJU0AAa3vP?format=jpg&name=240x240
https://twitter.com/momomo_us/status/1180515837792280577

Anfangs dachte ich das er das vllt. selber bearbeitet hat, aber von Fertigungskasten her, den Pixelabständen und Kompressionsartefakten sieht das eher originell aus.

Keine Ahnung wie gut sein Track-Record ist, aber falls es stimmt ergeben sich interessante Details.
Bei Milan steht SMT2, aber hierbei mit einem * dahinter, vielleicht doch optional mit SMT4?
Für Genoa wird auf jeden Fall SMT4 ausgewiesen, dieser wird aber auch mit 7nm+ ausgegeben, außer AMD versteht das "+" als allgemein besser als 7nm und nicht direkt den 7nm+ Node von TSMC, wäre das Stillstand gegenüber Milan.

[Setsul]

@basix:
Bloß weil L2 und L3 getrennt eingezeichnet sind, heißt das nicht, dass sie getrennt gezählt werden. Wenn da steht "32+ MB Cache" und nicht "32+ MB L3 Cache" dann werden es auch nicht mehr als 32 MB L3 Cache sein.
Man kann sich das alles schön rechnen. Sagen wir mal Cache + Kerne sind 90% der Fläche. Jetzt vervierfachen wir das. Sind nur 97,3% der Fläche, also relativ gesehen nicht viel mehr. 32 MB sind schon viel und in dem Video wird auch nie erwähnt dass es mehr geben könnte. Wer wenn nicht HPC-Kunden soll das denn bekommen?

Bloß weil der Traffic nicht übers IF geht, heißt das nicht dass es auf einmal keinen Strom mehr kostet die Daten zu bewegen.
Der Bedarf für 48 oder sogar 64 MB LLC wird sich in Grenzen halten, sonst hätte die Umstellung von Broadwell auf Skylake einige Leute ziemlich gestört. Viel interessanter sind die kleinen Modelle. 8/16 Kerne haben bei Skylake nur noch 11/22 MB LLC, bei Zen3 wären es 1x/2x32MB. Bei 22-24, wo bei Intel die Preise noch nicht völlig abgehoben sind, wäre AMD zum ersten mal seit Langem wieder auf Augenhöhe in Sachen LLC.

[basix]

Halte ich eigentlich für unwahrscheinlich, dass Genoa nicht in 5nm kommt. +80% Density sind halt schon sehr viel. 5nm soll nächstes Jahr schon Full Production sein für Mobile.

An folgenden Dingen könnte es aber scheitern:

5nm HPC Prozess nicht ready (unwahrscheinlich, gibt ja schon Risk Production für Mobile)
Energieffizienz nur marginal besser (kann sein, soll nur +10% effizienter sein als 7nm+)
Zu teuer (kann auch sein)


@basix:
Bloß weil L2 und L3 getrennt eingezeichnet sind, heißt das nicht, dass sie getrennt gezählt werden. Wenn da steht "32+ MB Cache" und nicht "32+ MB L3 Cache" dann werden es auch nicht mehr als 32 MB L3 Cache sein.
Man kann sich das alles schön rechnen. Sagen wir mal Cache + Kerne sind 90% der Fläche. Jetzt vervierfachen wir das. Sind nur 97,3% der Fläche, also relativ gesehen nicht viel mehr. 32 MB sind schon viel und in dem Video wird auch nie erwähnt dass es mehr geben könnte. Wer wenn nicht HPC-Kunden soll das denn bekommen?

Bloß weil der Traffic nicht übers IF geht, heißt das nicht dass es auf einmal keinen Strom mehr kostet die Daten zu bewegen.
Der Bedarf für 48 oder sogar 64 MB LLC wird sich in Grenzen halten, sonst hätte die Umstellung von Broadwell auf Skylake einige Leute ziemlich gestört. Viel interessanter sind die kleinen Modelle. 8/16 Kerne haben bei Skylake nur noch 11/22 MB LLC, bei Zen3 wären es 1x/2x32MB. Bei 22-24, wo bei Intel die Preise noch nicht völlig abgehoben sind, wäre AMD zum ersten mal seit Langem wieder auf Augenhöhe in Sachen LLC.

Bei Zen 2 steht auch 16 MB und nicht 18 MB pro CCX. Deswegen die Annahme, das wirklich nur der L3 gemeint ist ;)

Und schöngerechnet ist da gar nichts. Ich habe ja geschrieben, dass die TOTALE Die Fläche nur knapp +10% grösser wäre. Kannst ja die relative Rechnung ignorieren. 32 MB sind natürlich sehr grosszügig, aber mehr Cache = weniger Off-Die Traffic = effizienter.

Zum IF Traffic: Innerhalb des CCD wird der Datentransfer wohl nicht viel effizienter. Aber es entfällt halt die Logik für den "IF Switch" auf dem CCD deswegen sollte sich die Energieffizienz vor allem bei Kommunikation zum I/O Die hin reduzieren (weniger Logik dazwischen). Genau das ist in Server-lastigen Anwendungen ja Gold wert.

[gmb]

Rome ist ca. doppelt so schnell wie Intels aktuelle Angebote. Denkst du, Intel schafft es in so kurzer Zeit ihre CPUs >50% schneller zu machen? ;D


So wenig nur? Das ist ja echt schwach dann gegen 2015 Kerne, da hätte ich jetzt mehr erwartet. Intel hat die weit besseren Kerne mit Sapphire Rapids, Intel wird da schneller sein, die Frage ist nur wie viel. AMD wird hoffen müssen, dass sie minimum 6 Monate vor Sapphire Rapids in den Markt kommen.

[robbitop]

Pro Kern vermute ich, dass Intel vorbeizieht. Was Corecount und Fabric angeht (und das bedingt sich) hat AMD im Moment mehr Erfahrung. In MT könnte das den Unterschied machen.

[basix]

Pro Kern vermute ich, dass Intel vorbeizieht. Was Corecount und Fabric angeht (und das bedingt sich) hat AMD im Moment mehr Erfahrung. In MT könnte das den Unterschied machen.

Schnellere Kerne, vielleicht. Die Frage ist eher, wie viele davon und mit wie viel Watt.

Edit:
Robbi war schneller :)

[amdfanuwe]

8/16 Kerne haben bei Skylake nur noch 11/22 MB LLC, bei Zen3 wären es 1x/2x32MB.
https://www.amd.com/de/products/specifications/processors/2316,14566
Den 8 Kerner EPYC 7262 gibt es auch mit 128MB L3 Cache. Praktisch 16MB L3/Kern

[robbitop]

L3 außerhalb des CCX bringt dem Kern nichts Oder hat man pro CCX nur 1x aktiven Kern auf allen CCX?

[reaperrr]

So wenig nur? Das ist ja echt schwach dann gegen 2015 Kerne, da hätte ich jetzt mehr erwartet. Intel hat die weit besseren Kerne mit Sapphire Rapids, Intel wird da schneller sein, die Frage ist nur wie viel. AMD wird hoffen müssen, dass sie minimum 6 Monate vor Sapphire Rapids in den Markt kommen.
Nochmal: Sapphire Rapids wird bei Kernzahl, Perf/W und absoluter Performance in den meisten Workloads wahrscheinlich nicht mal an Rome rankommen.
Die besseren Kerne nützen nichts, wenn a) diese dafür mehr Transistoren haben und mehr Saft ziehen, b) der Prozess ineffizienter ist und c) du durch monolithische Designs deutlich schlechtere Yields hast und deshalb nicht so aggressiv binnen kannst wie die Konkurrenz.

Und daran, dass Intel innerhalb von <=250W nichtmal annähernd in die Kernzahl-Regionen von AMD kommt, wird sich auch nicht viel ändern, das Problem wird m.E. erst mit Granite Rapids in 7nm behoben.


Für Genoa wird auf jeden Fall SMT4 ausgewiesen, dieser wird aber auch mit 7nm+ ausgegeben, außer AMD versteht das "+" als allgemein besser als 7nm und nicht direkt den 7nm+ Node von TSMC, wäre das Stillstand gegenüber Milan.
5nm braucht schon wieder Dual-Patterning und treibt die Design-Kosten hoch, für relativ vernachlässigbare Verbesserungen im Bereich Effizienz/Performance, so dass du eh nicht so viel mehr Kerne bzw. CCDs verbauen könntest, ohne die Taktraten merklich senken zu müssen.
Gut möglich, dass AMD hier lieber auf N5P wartet, der aber erst für Ende 2021 veranschlagt ist, was AMD für Genoa zu knapp gewesen sein könnte.

Außerdem steht bei Zen4 wahrscheinlich eine größere Überarbeitung der Kerne im Fokus, und eben der Wechsel auf die neue Plattform. Dazu dann auch noch ein neuer Prozess könnte ihnen zu viel auf einmal gewesen sein.
Aber egal ob's 7nm+ oder doch 5nm(+) wird, AMD wird so oder so gute Gründe für die Entscheidung haben.

Oder hat man pro CCX nur 1x aktiven Kern auf allen CCX?
Jup. Gibt durchaus Workloads, in denen die Menge Cache je Kern/Thread das entscheidende Kriterium und die Zahl der Kerne zweitrangig ist.

[robbitop]

IMO ist eines ganz sicher: Intel wird aufwachen. Früher oder später. Und dieses Mal muss AMD vorbereitet sein. Intel wird regelmäßig executen. (das macht AMD aktuell auch - aber Intel hat massiv mehr Geld/Ressourcen)

[gmb]

Nochmal: Sapphire Rapids wird bei Kernzahl, Perf/W und absoluter Performance in den meisten Workloads wahrscheinlich nicht mal an Rome rankommen.

Könnte es denn für Granite Rapids reichen, wenigstens an Naples vorbeizukommen? Echt lustig mit dir. ;D


Und daran, dass Intel innerhalb von <=250W nichtmal annähernd in die Kernzahl-Regionen von AMD kommt, wird sich auch nicht viel ändern, das Problem wird m.E. erst mit Granite Rapids in 7nm behoben.


Jetzt mal ganz seriös, warum soll sich das nicht ändern??? Intel ist bis jetzt mit 14nm unterwegs und bringt 48 Kerne unter. Zweifel daran, dass sie mit einem dann funktionierendem 10++ und einer komplett neuen Plattform mitsamt neuer CPU Generation nicht die Kernanzahl erhöhen, sollten nicht bestehen. Vor allem zu sagen nichtmal annähernd. Da kann ich dir jetzt schon versichern, dass du mit der Einschätzung daneben liegen wirst.

[amdfanuwe]

Oder hat man pro CCX nur 1x aktiven Kern auf allen CCX?
sieht so aus.

[Linmoum]

Jetzt mal ganz seriös, warum soll sich das nicht ändern??? Intel ist bis jetzt mit 14nm unterwegs und bringt 48 Kerne unter. Zweifel daran, dass sie mit einem dann funktionierendem 10++ und einer komplett neuen Plattform mitsamt neuer CPU Generation nicht die Kernanzahl erhöhen, sollten nicht bestehen. Vor allem zu sagen nichtmal annähernd. Da kann ich dir jetzt schon versichern, dass du mit der Einschätzung daneben liegen wirst.
Mal ganz seriös solltest du genau lesen. Er sprach nicht nur davon, den Core Count zu erhöhen, sondern das bei <=250W zu tun. Kleiner, aber feiner Unterschied. Und durchaus etwas, dass man aktuell bezweifeln darf.

[gmb]

Mal ganz seriös solltest du genau lesen. Er sprach nicht nur davon, den Core Count zu erhöhen, sondern das bei <=250W zu tun. Kleiner, aber feiner Unterschied. Und durchaus etwas, dass man aktuell bezweifeln darf.


Hör doch mit der Wortklauberei auf. Er behauptet von vornherein, dass Sapphire Rapids nichtmal an Rome rankommen kann, weder bei der absoluten Performance noch Perf/W oder Kernanzahl. Über TDP Einstufungen und auch Preise kann man ja nun wirklich nichts sagen derzeit, das hängt ja auch von der Performance ab, wie hoch Intel mit dem Takt überhaupt gehen muss und preislich wie konkurrenzfähig das ist. Es kann wirklich erstmal nur um die Kernanzahl bzw. Performance gehen. Und durch den Stillstand bei AMD in der nächsten Generation, sehe ich für AMD eher schlechte Karten. Das Problem ist vor allem, dass sie gegen die IPC von Willow Cove bzw. Golden Cove nichts haben, wenn Intel schon mit Sunny Cove 15% davongezogen ist.

[w0mbat]

Wer weiß, bei Intels aktuellem Geschick wir SR vielleicht sogar langsamer und kommt erst 2030? Also ich mache mir da wirklich Sorgen :(

[Pirx]

...Und durch den Stillstand bei AMD in der nächsten Generation, ...
Entwicklung ist Stillstand? Wann hörst du endlich mit diesen Kinderspielchen auf?

[gmb]

Entwicklung ist Stillstand? Wann hörst du endlich mit diesen Kinderspielchen auf?


Ja natürlich, AMD bleibt bei der Kernanzahl stehen, das ein Stillstand. reaperrr ging es um die Kernanzahl, laut ihm wird Sapphire Rapids nicht annähernd rankommen. Eben weil AMD eine Generation nicht erhöht, ist das eine gewagte These.

[Voodoo6000]

Und durch den Stillstand bei AMD in der nächsten Generation, sehe ich für AMD eher schlechte Karten. Das Problem ist vor allem, dass sie gegen die IPC von Willow Cove bzw. Golden Cove nichts haben, wenn Intel schon mit Sunny Cove 15% davongezogen ist.
Intel muss aber auch erst mal liefern. Die 15% mehr IPC sind gut aber wenn Intel wie bei Ice Lake nicht mehr die Taktraten der Vorgängergeneration erreicht ist der Performancegewinn doch überschaubar. AMD schläft auch nicht, Zen 3 wir kein gigantischer Sprung aber die Messlatte nochmal höher legen. SR wird interessant aber Milan erscheint schon 2020 und AMD bringt 2021 mit Zen4/Genoa möglicherweise auch DDR5, PCIe 5.0 in 6/5 nm. Selbst wenn SR besser als Milan wird, kommt der AMD Konter nur wenige Monate später.

Auch wenn Intel Mittel bis Langfristig die bessere Architektur als AMD entwickelt muss Intel dringend die Probleme in der Fertigung lösen. Es ist schon fast erschreckend wie sich TSMC mit konstanten Verbesserungen zum Technologieführer gemausert hat.

[w0mbat]

Genau, Intel muss erstmal beim IPC aufholen, dann ne chiplet Architektur bringen und die Kerne skalieren. Und dann sind sie auf dem Niveau von Rome.

[Setsul]

@basix:
Wo steht bei Zen 2 16 MB? Auf Marketing-Folien hab ich schon alles gesehen.

Mehr Cache macht das Ganze nicht unbedingt effizienter. Das ist gerade bei kleinen Caches noch so, aber daraus zu schließen dass das bei beliebiger Größe funktioniert ist falsch.

Dafür muss allen Daten die aus dem IF kommen auf 8 statt 4 L2s verteilt werden. Das geht nicht ohne Logik. Aber nicht jede Maßnahme muss alles verbessern. Gleichmäßige Latenz zu 32 MB statt 16 MB wäre schon bei gleichem Stromverbrauch ein voller Erfolg.

@amdfanuwe:
Ja, wird aber leider ekelhaft wenn geschrieben wird, weil dann alles immernoch zwischen den CCX hin und her durchs IF muss.
Klar gibt es auch solche Workloads die nur einen Haufen Cache wollen (siehe reaperrr) und dafür gibts auch von Intel 4/8-Kerner mit zusätzlichen L3 Slices, aber mir gings um Workloads die einfach 20-30 MB brauchen. Ist bei Zen1/2 schwierig wegen inter-CCX Latenz, bei Skylake braucht man 16-24 Kerne um genug L3 zu kriegen, bei Zen3 ist es kein Problem mehr.

[Locuza]

Bei der Folie, wo Rome und Milan verglichen werden:
https://abload.de/img/zen-39ljxo.jpg

Es wäre etwas komisch bei Zen2 jeweils 16MB L3$ hinzuschreiben und bei Zen3 32MB+, allerdings dort den L3$ + L2$ zusammen zu zählen.

[iuno]

Er hat gesagt, dass die Trennung wegkommt, das war unmissverstaendlich.
Ich nehme mal an, dass 32+ heisst einfach, dass die endgueltige Groesse noch nicht feststeht. Kann ja sein, dass es mehr wird, ohne dass man L2 dazuzaehlen muss.

[Setsul]

Ah, die hab ich wohl übersprungen weil nichts neues. Auf allen anderen stand glaube ich immer nur 32 MB.
AMD hat definitiv bei Zen1 mal L2+L3 zusammengezählt fürs Marketing.
Mal sehen ob und wie die 32+ dann kommen.

[HOT]

lt. Folie hatte Milan sein Tapeout Anfang Q2, also als TSMC den N7+ für die Massenproduktion freigegeben hat. Da ist also nix mehr mit Änderung der L3-Größe.

Jup es wird vor 5nm kein 64 Core Monolith geben vielleicht nicht mal dann.Laut Intel Roadmap ist das 2023,7nm++ ist 2022.

Intel berühmte Prozess"fertigstellung". 14nm wurde auch 2013 "fertiggestellt". Diese "Roadmap" hat einfach keine Aussagekraft. Produkte mit 7nm ohne + sind für 22 zu erwarten, vorher ist das illusorisch.

[Opprobrium]

Es wäre etwas komisch bei Zen2 jeweils 16MB L3$ hinzuschreiben und bei Zen3 32MB+, allerdings dort den L3$ + L2$ zusammen zu zählen.

Zumal der L2 Cache auf der Grafik definitiv getrennt vom L3 Cache dargestellt wird.

[basix]

Mehr Cache macht das Ganze nicht unbedingt effizienter. Das ist gerade bei kleinen Caches noch so, aber daraus zu schließen dass das bei beliebiger Größe funktioniert ist falsch.

Dafür muss allen Daten die aus dem IF kommen auf 8 statt 4 L2s verteilt werden. Das geht nicht ohne Logik. Aber nicht jede Maßnahme muss alles verbessern. Gleichmäßige Latenz zu 32 MB statt 16 MB wäre schon bei gleichem Stromverbrauch ein voller Erfolg.

Da stimme ich dir absolut zu. Raven Ridge hat ja nicht ohne Grund einen halbierten L3.

Beim Chiplet Ansatz scheint sich zusätzlicher Cache aber besonders zu lohnen. Einfach aus dem Grund, dass man weniger oft Off-Die gehen muss. Irgendwo greift sicher auch hier der abnehmende Grenzertrag. Evtl. verkleinern sich die Caches dann wieder bei Interposer / 3D-Stacking Lösungen, da der Off-Chip Penalty deutlich kleiner wird.

[fondness]

AMD hat definitiv bei Zen1 mal L2+L3 zusammengezählt fürs Marketing.


Das hat nichts mit Marketing zu tun, bei einem exklusiven Cache Design kann man beides verwenden. Allerdings ist in den Schaubildern der L2-Cache explizit eingezeichnet, also macht es keinen Sinn diesen dazu zu zählen. Zumal der Block dezidiert als L3 bezeichnet wird.

Und zur Diskussionen vs. Intel sei gesagt: Man muss sich schon bewusst sein, dass die aktuelle Situation eine Anomalie darstellt. Intel hat Minimum die zehnfachen Ressourcen, da zum wiederholten Male so von AMD vorgeführt zu werden ist eigentlich traurig genug und die damalige Führungsriege wurde auch nicht ohne Grund abgesägt. Sobald man allerdings die Fehler korrigiert hat wird Intel zweifellos wieder an AMD vorbei ziehen, sofern man nicht davon ausgeht, dass die Leute dort völlig unfähig sind. Die Frage ist höchstens wie lange es dauert diesen Tank wieder in die Spur zu bringen.

[robbitop]

Ja. Das ist mit Gewissheit so. Diesmal wird AMD, so sieht es in den Roadmaps aus, aber durch konstante Execution näher dranbleiben. Guter zweiter zu sein ist auch OK. AMD hat weniger Ressourcen aber auch weniger Kosten. Entsprechend kann man durch PL überzeugen.

Der L3 hilft vor allem, die mäßige RAM Latenz zu kompensieren. 16 mib haben bei Spielen stark geholfen - laut Epos Vox hilft es auch beim Rendern/Encodieren. 32 MiB sind besser.

Man sah ja beim i7 5775C wie viel der 128 mib Crystallwell L4 brachte. Und der war nur 20 ns schneller als der RAM.

Aber man muss natürlich mit der Chipfläche haushalten. Insbesondere bei sram.

[Opprobrium]

Intel hat Minimum die zehnfachen Ressourcen, da zum wiederholten Male so von AMD vorgeführt zu werden ist eigentlich traurig genug...

Ja und nein. Intel hat zwar deutlich mehr Ressourcen, aber ich würde das nicht so simpel hochrechnen, da Intel diese auch in deutlich mehr Bereiche steckt.

AMD hat eigentlich "nur" noch CPU, GPU, I/O

Intel hat dagegen CPU, arbeitet an einer komplett neuen GPU, betreibt eigene Fabriken und baut nebenher noch SSDs, LAN und WiFi, Modems...

Natürlich haben die im Endeffekt immer noch die Möglichkeit mehr Ressourcen in die CPU Abteilung zu stecken als AMD, aber 10x? Ich weiß nicht. Zumal ja auch die Mitarbeiter eher spezialisiert sein dürften und sich nicht einfach per Slider-Reger von der NIC Abteilung ins CPU Design verschieben lassen dürften.

Vom bürokratischen Overhead in so einem Megakonzern rede ich da noch gar nicht...

[Tesseract]

es spricht imho nichts dagegen on-chip-cache aufzuaddieren, egal wie die strategie ist. direkt adressierbar ist sowieso nichts davon und die lower level caches bingen pro KB sogar mehr performance als die höheren, warum also nicht? war früher mit wenigen cores halt ziemlich sinnlos weil es meist weniger als 1MB ausgemacht hat.

[HOT]

Ja. Das ist mit Gewissheit so. Diesmal wird AMD, so sieht es in den Roadmaps aus, aber durch konstante Execution näher dranbleiben. Guter zweiter zu sein ist auch OK. AMD hat weniger Ressourcen aber auch weniger Kosten. Entsprechend kann man durch PL überzeugen.

Der L3 hilft vor allem, die mäßige RAM Latenz zu kompensieren. 16 mib haben bei Spielen stark geholfen - laut Epos Vox hilft es auch beim Rendern/Encodieren. 32 MiB sind besser.

Man sah ja beim i7 5775C wie viel der 128 mib Crystallwell L4 brachte. Und der war nur 20 ns schneller als der RAM.

Aber man muss natürlich mit der Chipfläche haushalten. Insbesondere bei sram.

Das ist nicht ganz richtig. Man muss ja die Chipfläche ausdehnen, um die Wärmeableitung zu ermöglichen. Dafür braucht man den SRAM. Das wird sogar einer der Hauptgründe für den vergrößerten L3 gewesen sein. Bei N5 Pro wird man die Chipfläche noch mehr mit SRAM ausdehnen. Ich erwarte daher auch nicht mehr Kerne. Die Wärmeableitung zwingt halt zu Kompromissen.

[mboeller]

mal eine Dumpfbacken-Idee zu den angeblichen 15 Chips für Milan von semiaccurate:

vielleicht sind es ja nicht 15 Chips sondern 17?

1 I/O-Chip, 8 Chiplet und 8 HBM3 Chips on Top, und deshalb die 32+MB L3-Cache in der Folie

Bei den ca. 25W pro Chiplet im Servereinsatz könnte es möglich sein da noch ein wenig HBM draufzupacken. Die Größe von Chiplet und HBM-Speicher scheint ja in etwa zu passen, so dass der HBM-Speicher nicht übersteht.

[Der_Korken]

Ich weiß, dass das Thema L4 hier schon oft durchgekaut wurde, aber eine (oder eigentlich zwei) Fragen hätte ich doch noch. Das Hauptargument gegen den L4 war, dass die Latenz viel zu schlecht wäre, weil das alles über den IF muss. Daher mal folgende Überlegung:

Der L3 ist in vier Slices aufgeteilt und an jedem Slice hängt ein Core, er eine Anfrage an den L3 stellt, sobald er intern einen L2 miss hat. Wäre es möglich dieses Prinzip eine Ebene höher nochmal zu bauen? das heißt, man nimmt vier CCX von Zen2 und packe sie auf ein Chiplet. Jedes CCX bekommt ein L4-Slice (z.B. 16MB groß), sodass man einen L4-Cache von insgesamt 64MB für 16 Kerne hat. Der L3 hat eine Latenz von etwa 7ns, wenn man den L2 abzieht. Da der L4 nochmal größer ist, kommt für den vielleicht nochmal das doppelte dazu, also 14ns, was insgesamt dann 24ns für den L4 wären. Wenn es dort auch einen miss gibt, geht die Anfrage auf den IF rüber zum IO-Die. Erste Frage: Wäre so etwas möglich?

Falls ja, zweite Frage: Könnte man den Cut zwischen IO-Die und Chiplet dann nicht auch zwischen dem CCX und dem L4-Slice ansetzen? Der L4 sitzt dann komplett auf dem IO-Die, aber jeder Slice ist direkt mit einem CCX auf dem Chiplet verbunden. Die Kommunikation zwischen CCX und L4-Slice läuft dann nicht über IF, sondern das IF fängt erst zwischen L4 und dem Rest des IO-Dies an. Das ist natürlich nochmal etwas langsamer, aber ein 64MB großer L4 mit 30ns könnte schon viel bringen. Die Speicherlatenz wird natürlich nochmal höher, je nachdem wie es kostet den L4 miss nur zu detektieren.

[Gipsel]

mal eine Dumpfbacken-Idee zu den angeblichen 15 Chips für Milan von semiaccurate:

vielleicht sind es ja nicht 15 Chips sondern 17?

1 I/O-Chip, 8 Chiplet und 8 HBM3 Chips on Top, und deshalb die 32+MB L3-Cache in der Folie

Bei den ca. 25W pro Chiplet im Servereinsatz könnte es möglich sein da noch ein wenig HBM draufzupacken. Die Größe von Chiplet und HBM-Speicher scheint ja in etwa zu passen, so dass der HBM-Speicher nicht übersteht.Der HBM hätte doch praktisch identische Latenz zum DDR4. Was soll das denn bringen außer höheren Kosten?

===============================

Der L3 ist in vier Slices aufgeteilt und an jedem Slice hängt ein Core, er eine Anfrage an den L3 stellt, sobald er intern einen L2 miss hat.Also falls Du vom momentanen Aufbau der CCX redest, dann stimmt das nicht so ganz. Ein Slice hängt nicht an einem Core.
Aber ansonsten kannst Du natürlich Hierarchien aus Gruppen von Kernen und Caches bauen.

[amdfanuwe]

mal eine Dumpfbacken-Idee zu den angeblichen 15 Chips für Milan von semiaccurate:
Bei Milan wohl noch nicht.

Aber andere Dumpfbacken-Idee: Zukünftig setzt man ein Chiplet direkt mit auf ein RAM Dimm. braucht es keine große CPU mehr.

[Der_Korken]

Also falls Du vom momentanen Aufbau der CCX redest, dann stimmt das nicht so ganz. Ein Slice hängt nicht an einem Core.
Aber ansonsten kannst Du natürlich Hierarchien aus Gruppen von Kernen und Caches bauen.

OK, ob ein Core jetzt direkt an einem Slice hängt oder nicht, ist jetzt nicht so entscheidend. Mir ging es eher um die Frage, ob es auch inter-die-Kommunikation ohne IF geben kann, indem "Hyper-CCX" bildet und die über mehrere Dies aufteilt. Bei meiner Beschreibung oben habe ich noch vergessen zu erwähnen, dass sobald der L4 auf den IO ausgelagert wurde, man das 16-Kern-Chiplet wieder aufsplitten kann, weil die 4er CCX nicht miteinander kommunizieren, sondern nur mit dem L4.

[Gipsel]

Mir ging es eher um die Frage, ob es auch inter-die-Kommunikation ohne IF geben kann, indem "Hyper-CCX" bildet und die über mehrere Dies aufteilt.Irgendwie müssen die CCX' ja kommunizieren, um einen "Hyper-CCX" zu bilden. Wie Du das nennst, ist ja beinahe egal, und wenn es IF2.0 ist.
Der Sinn von so gebildeten Hierarchien (oder nenne es Interconnect-Struktur) ist ja einfach, bei vertretbarem Aufwand die mittlere Bandbreite und Latenz zwischen den Kernen akzeptabel zu halten.

[robbitop]

Das ist nicht ganz richtig. Man muss ja die Chipfläche ausdehnen, um die Wärmeableitung zu ermöglichen. Dafür braucht man den SRAM. Das wird sogar einer der Hauptgründe für den vergrößerten L3 gewesen sein. Bei N5 Pro wird man die Chipfläche noch mehr mit SRAM ausdehnen. Ich erwarte daher auch nicht mehr Kerne. Die Wärmeableitung zwingt halt zu Kompromissen.
Ob SRAM da so unbedingt hilft? Silizium ist ein schlechter Wärmeleiter und der Querschnitt ist ziemlich gering. Die Temperatur ist dort hoch, wo die Leistungsdichte am höchsten ist. Dort SRAM einzustreuen reduziert die Energiedichte nicht. Und großartig ableiten aus o.g. Gründen ist auch nicht im großen Stil drin.

[Gipsel]

Ob SRAM da so unbedingt hilft? Silizium ist ein schlechter Wärmeleiter und der Querschnitt ist ziemlich gering. Die Temperatur ist dort hoch, wo die Leistungsdichte am höchsten ist. Dort SRAM einzustreuen reduziert die Energiedichte nicht. Und großartig ableiten aus o.g. Gründen ist auch nicht im großen Stil drin.Silizium ist eigentlich ein relativ guter Wärmeleiter, so im Ganzen betrachtet (liegt zwar unter Aluminium, aber nicht so weit und deutlich über vielen anderen Metallen). Die Idee ist vermutlich, die kleinen Kerne ein wenig weiter voneinander entfernt zu haben, so daß es für den Heatspreader und Kühler einfacher wird, da so die Leistungsdichte sinkt, wenn man es auf einer gröberen Skala betrachtet. Also für den Fall daß mehrere Kerne aktiv sind und nicht nur einer (dann hilft es natürlich nichts).

[S940]

Zen3 bekommt einen komplett neuen L3$ (nicht nur mehr)? Einen neuen L1? AVX512?
Nachdem man bei nem ähnlichen Herstellungsprozess bleibt, muss ein doppelt so großer L3-Cache schlechtere Latenzen haben. Außerdem greifen auf den Cache auch noch doppelt soviel Kerne/Threads zu, das macht es ebenfalls nicht besser.


Der logische Schritt: L1+L2-Cache vergrößern, um die Zugriffswahrscheinlichkeit auf den L3 zu verringern. 2x64kB L1 und 1MB L2 böten sich an. Da verbrät man dann zwar relativ viel Silizium, aber der 7nm+ Prozess wird ne bessere Yield haben, womit man es sich leisten kann. Mit SMT4 rentiert sich der Cache dann ebenfalls.


Ansonsten vielleicht noch Änderungen an den INT-Pipes, FP würde ich ausschließen. Daran wurde gerade erst groß herumgebastelt, das wird man erstmal in Ruhe lassen, bzw. sich aufs Bugfixen beschränken (da gibts sicherlich welche).

[Setsul]

Falls ja, zweite Frage: Könnte man den Cut zwischen IO-Die und Chiplet dann nicht auch zwischen dem CCX und dem L4-Slice ansetzen? Der L4 sitzt dann komplett auf dem IO-Die, aber jeder Slice ist direkt mit einem CCX auf dem Chiplet verbunden. Die Kommunikation zwischen CCX und L4-Slice läuft dann nicht über IF, sondern das IF fängt erst zwischen L4 und dem Rest des IO-Dies an.
Aber wie verbindet man denn CCX direkt mit dem L4?
Die Latenz die entsteht weil man vom Chiplet zum I/O-Die muss, verschwindet ja nicht bloß weil man die Verbindung nicht mehr IF nennt.
Außerdem muss man die Kohärenz wahren und das ist nicht mehr so einfach. Selbst wenn man wieder nach Adressen auf die 4 Slices aufteilt steigt der Aufwand gewaltig. Beim L3 sind nur die Tags für 4,5 MB (1/4 L3+L2) zu prüfen, bei dem L4 wären es dann 34 MB (1/4 L4+L3+L2). Dann müsste man natürlich auch Anfragen von einem CCX über den L4 nach einem Tag Hit an einen L2/L3 in einem anderen CCX weiterleiten können, über diese "direkte" Verbindung. Hätte man nur ein Interconnect für so etwas...

[gravitationsfeld]

Zen3 bekommt einen komplett neuen L3$ (nicht nur mehr)? Einen neuen L1? AVX512? Leute begrabt endlich euren "Zen2+" Gedanken, das ist einfach lächerlich. Zen3 ist das erste wirkliche Architekturupgrade seit dem Zen gelauncht wurde.
15% IPC uplift und komplett andere Organisation mit I/O-Die ist eine kleine Revision? Mach dich nicht laecherlich.

[robbitop]

L1/avx512 sind doch nur Spekulation. Die Reorganisation des CCX und zusammenlegung des L3 sind IMO keine Veränderung an der uArch selbst. Das wäre IMO eher I/O. Am Core selbst ist dafür allein wahrscheinlich nur wenig/nichts notwendig an Änderung.

Zen 2 war schon ein mit Änderungen an der uArch.

[basix]

Für mich ist eine solche Änderung des Cache Subsystems und Core-Organisation schon eine Architektur-Änderung. Nicht die des Cores aber die der CPU. Skylake-X mit Mesh anstatt Ring ist da irgendwie eine Anomalie. Nur veränderte Cache-Grössen sind eher Design-Anpassungen anstatt Architekturänderungen.

Zum 8C CCX und 32+ MB L3 Cache:
Evtl. ist das gleichzeitig eine Vorbereitung / ein Vorspuren für Zen 4 mit 4x SMT. Die zusätzlichen Threads sehen den zusätzlichen Cache sicher gerne. Dazu noch verdoppelter L1/L2 (was in 5nm drin liegen sollte) und ein paar Erweiterungen der kritischen Dinge wie uOp-Cache usw. und die Threads sollten ganz gut skalieren. Vor allem Datenbanken werden stark profitieren, da ist ja heute schon zum Teil >70% Scaling mit 2x SMT zu sehen. Und was ist im Zeitalter von Cloud, Industrie 4.0 und Big Data immer wichtiger? Datenbanken & deren effizientes Handling ;)

Bringt man also mehr Cache, gibt das einen besseren & fliessenden Übergang anstatt plötzlich "zu viel" Cache zu haben. Benötigt man 4x SMT nicht, ist es wohl ein leichtes das auf 2x SMT zu begrenzen.

[gravitationsfeld]

L1/avx512 sind doch nur Spekulation. Die Reorganisation des CCX und zusammenlegung des L3 sind IMO keine Veränderung an der uArch selbst. Das wäre IMO eher I/O. Am Core selbst ist dafür allein wahrscheinlich nur wenig/nichts notwendig an Änderung.
Ihr lest das falsch. Er hat behauptet es gaebe zwischen Zen 1 und 2 keinen Architektur-Unterschied.

[robbitop]

Ich bezog mich auf Zen 3. In Bezug auf Zen 2 sehe ich das genauso wie du.

[HOT]

Ihr lest das falsch. Er hat behauptet es gaebe zwischen Zen 1 und 2 keinen Architektur-Unterschied.

So ein Unsinn. Ich habe behauptet, dass der Sprung von Zen2 zu Zen3 größer ist als von Zen1 zu Zen2.
Das ist auch plausibel, da AMD ja selbst gesagt hat, dass man Zen1 und Zen2 weitestgehend parallel entwickelt hat. Eine Architektur dauert halt 4-5 Jahre von Reißbrett zum Silizium.

Nachdem man bei nem ähnlichen Herstellungsprozess bleibt, muss ein doppelt so großer L3-Cache schlechtere Latenzen haben. Außerdem greifen auf den Cache auch noch doppelt soviel Kerne/Threads zu, das macht es ebenfalls nicht besser.


Der logische Schritt: L1+L2-Cache vergrößern, um die Zugriffswahrscheinlichkeit auf den L3 zu verringern. 2x64kB L1 und 1MB L2 böten sich an. Da verbrät man dann zwar relativ viel Silizium, aber der 7nm+ Prozess wird ne bessere Yield haben, womit man es sich leisten kann. Mit SMT4 rentiert sich der Cache dann ebenfalls.


Ansonsten vielleicht noch Änderungen an den INT-Pipes, FP würde ich ausschließen. Daran wurde gerade erst groß herumgebastelt, das wird man erstmal in Ruhe lassen, bzw. sich aufs Bugfixen beschränken (da gibts sicherlich welche).
Kurz: Man muss das gesamte Frontened komplett umkrempeln, nein, neu denken.

[N0Thing]

So ein Unsinn. Ich habe behauptet, dass der Sprung von Zen2 zu Zen3 größer ist als von Zen1 zu Zen2.
Das ist auch plausibel, da AMD ja selbst gesagt hat, dass man Zen1 und Zen2 weitestgehend parallel entwickelt hat. Eine Architektur dauert halt 4-5 Jahre von Reißbrett zum Silizium.

Wird man dann sehen, AMD hat auch gesagt, dass sie einige Elemente von Zen3 vorgezogen haben und schon in Zen2 implementiert haben.
Der gemeinsame L3 und der 8 Kern CCX sind für mich aber auch massive Änderungen.

[HOT]

Damit wird man die Verkleinerung des L1I und die dazugehörigen Änderungen gemeint haben mMn oder besser gesagt, die Verkleinerung war den Änderungen geschuldet, das wird ein Kompromiss sein.

[SKYNET]

Wird man dann sehen, AMD hat auch gesagt, dass sie einige Elemente von Zen3 vorgezogen haben und schon in Zen2 implementiert haben.
Der gemeinsame L3 und der 8 Kern CCX sind für mich aber auch massive Änderungen.

zumal der 8er CCX deutlich kleinere latenzen aufweisen dürfte, als das 4+4 design... desweiteren wird der L3 sicherlich auf 48MB aufgeblasen werden, AMD ist bei Zen ja am klotzen, nicht am kleckern, und zeigt intel wie man richtige CPUs baut :cool:

[Setsul]

AMD kann nicht jedes Jahr eine neue Architektur bringen und zwischen komplett neuen Architekturen vergehen eher 4 Jahre.

Man kann sich also überlegen was wahrscheinlicher ist: 512 bit FPU, doppelte Caches, SMT4, neue Architektur, was auch immer, bei Zen3 und Zen4 nur als Zen3+ oder Zen3 nur als kleiner Schritt und mit Zen4 mit deutlich mehr Spielraum bei der Leistungsaufnahme dank 5nm kommt dann die neue Architektur mit vielen platz- und stromhungringen Features.

Ich bezweifle einfach mal dass AMD von 14 auf 7nm den L1I verkleinert um bei gleichem Transistorbudget einen größeren µop Cache zu bekommen, dann aber bei 7nm+ mit Transistoren um sich wirft und einfach hofft dass die Leistungsaufnahme pro Kern gleich bleibt.

Realistisch ist eher so etwas wie Ivy Bridge. Bisschen größere PRF und Scheduler, ein paar Optimierungen, was man sich eben so leisten kann durch 7nm+, ein bisschen mehr Takt, anderer L3, vielleicht AVX-512 auf 256 bit FPU (sind ja doch einige Instructions und vor allem Masken die man erstmal debuggen muss) und schon hat man locker +10% ohne die TDP oder die Architektur groß ändern zu müssen.

[gmb]

Das halte ich auch für realistischer, wird eher ein refresh release ähnlich wie der von Zen zu Zen+ mit ein paar Prozent mehr IPC und etwas mehr Taktpotenzial. Darauf lassen die bisherigen Infos schließen. Was größeres erwarte ich erst mit der übernächsten Generation.

[w0mbat]

Das 8C-CCX und der größere L3-cache kommen aber direkt von der AMD Präsi, das würde ich schon also sehr wahrscheinlich ansehen. Und das wäre ein sehr großer Eingriff in den Grundaufbau, also ganz anders als SNB -> IVB.

[Linmoum]

8C-CCX und hier wird von Refresh gesprochen. Halleluja. Und das ist nur das, was man bisher weiß.

[robbitop]

Das betrifft aber bis dato nur I/O. Nicht die uArch der Cores.

[Der_Korken]

zumal der 8er CCX deutlich kleinere latenzen aufweisen dürfte, als das 4+4 design...

Ich glaube im Vergleich zum vorigen Cache sollte die Latenz eher steigen. Es sei denn, du schiebst viele Daten zwischen den 4er CCX hin und her, aber ich hatte nicht den Eindruck, dass das ein großes Problem gewesen wäre. Der größte Vorteil dürfte wohl sein, dass ein Kern mehr Gesamtcache bekommen kann wie bei Intel.

[basix]

Vergrösserte Caches könnten für SMT4 gut was bringen. Beim jetzigen Stand mit SMT2 und angesichts der Performance von Zen 2 sehe ich jetzt nicht unbedingt ein Problem mit zu kleinen Caches oder den Bedarf für noch mehr Cache. Für AVX512 erhöhte L1-Bandbreite ja, grössere Caches keine Ahnung.

Beim L3 ist das aber noch ein wenig anders als bei L1/L2, da man zum Teil "ganze" Applikationen dort reinpresst für maximale Performance. Reduzierte Latenz sehen alle Applikation gerne. RAM-Latenz verstecken L1/L2 natürlich auch aber die Caches sind für viele Anwendungen verhältnismässig klein / zu klein.

Nimmt man an, dass eine Applikation in 1.5 MiB L3 passt (Google hat glaube ich viele Anwendungen auf 1-1.5 MiB optimiert?!), dann kann man bei 6 MiB pro Core 4 davon direkt im L3 halten. Das wäre für SMT4 sicher ein grosser Vorteil. Spiele würden auch davon profitieren.

[Complicated]

Wenn man Robert Hallock glauben darf, dass der Zugriff von CCX zu CCX über den IO läuft bei Zen1, dann wäre es schon gravierend wenn nur noch 1x 8 Core CCX mit gemeinsamen Cache auf einem Die verbaut wird. Hier würden die Zugriffe der 8 cores auf den L3 den Die nicht mehr verlassen.

[Setsul]

8C-CCX und hier wird von Refresh gesprochen. Halleluja. Und das ist nur das, was man bisher weiß.
Aus 2x16MB L3 1x32MB L3 (was wohl die Standard-/Minimalkonfiguration sein wird, wo sich mehr nicht lohnt) zu machen ist in Sachen Fläche, Verbrauch und Aufwand eine ganz andere Hausnummer als die komplette Architektur neu zu machen, L1 und L2 zu verdoppeln, FPU-Breite zu verdoppeln, SMT4 einzuführen und dann zu hoffen dass das mit einem Prozess der bestenfalls 20% bringt alles machbar ist.

Ich bezweifle, dass das ein Refresh wie Kaby Lake oder Zen+ wird, aber was sich manche Leute hier erwarten führt nur zu herben Enttäuschungen.

Wie gesagt AMD wird sicher nicht 2 neue Architekturen in 2 Jahren bringen oder bei 7nm+ mit Gewalt Features reinpressen und bei 5nm dann mit den Schultern zucken und nen Refresh bringen.

Die Verdoppelung der Kerne hat alles was man an Transistor-/Powerbudget durch 7nm gewonnen hat aufgefressen. 7nm+ reicht für keine Verdoppelung von irgendwas.


Nochmal: 8C "CCX" ist vom Aufwand bei der Architektur genauso gewaltig wie Coffee Lake mit 8C auf 10C für Comet Lake zu bringen. Nach der gleichen Logik bedeutet LPDDR4X oder DDR5 auch eine neue Architektur. Ist es aber nicht.
Oder vor Broadwell der Unterschied zwischen Client und Server. 2 MB/Kern vs 2,5 MB/Kern. Mein Gott, völlig anderer Grundaufbau.

AMD hat bis jetzt den CCX einfach nur in jedes Design "reinkopiert" und bei den APUs den L3 halbiert (was auch recht einfach ist). Jetzt können sie es sich leisten das Design zum ersten mal seit Jahren etwas mehr anzupassen (Verdoppelung hat genauso wie Halbierung nichts am Aufbau geändert). Das heißt nicht dass an den Kernen irgendwas geändert wurde.

[LasterCluster]

Es wird keine ZenX+ artigen Generationen mehr geben. Durch die Umstellung auf Chiplets hat AMD einfach zu viele Bereiche, diese seperat angehen können. Dadurch ist es sicherer immer etwas zu bringen als mal viel und mal wenig

[dildo4u]

Es könnte auch mal ein Jahr mit wenig Veränderung geben um deutlich bessere Yields zu ermöglichen,das ständige umbauen geht jetzt da AMD kaum liefern muss.
Das sieht ganz anders aus wenn sie Intel Ernsthafte Marktanteile im Mobile und Server Bereich abnehmen,Intel hat ja selbst mit uralt Tech genug Probleme Stückzahlen zu liefern.

[Locuza]

Damit wird man die Verkleinerung des L1I und die dazugehörigen Änderungen gemeint haben mMn oder besser gesagt, die Verkleinerung war den Änderungen geschuldet, das wird ein Kompromiss sein.
Soweit ich es gelesen habe war der TAGE-Branch-Predictor für den L2$ zu Beginn nur für Zen3 geplant, zeitlich hat es aber gepasst, um den (bzw. eine Form davon) rückwirkend noch für Zen2 einzubauen.

Wenn man Robert Hallock glauben darf, dass der Zugriff von CCX zu CCX über den IO läuft bei Zen1, dann wäre es schon gravierend wenn nur noch 1x 8 Core CCX mit gemeinsamen Cache auf einem Die verbaut wird. Hier würden die Zugriffe der 8 cores auf den L3 den Die nicht mehr verlassen.
Messdaten bestätigen das auch:
https://i.redd.it/mvo9nk2r94931.png

Der 3900X besitzt drei vier CCXs (mit jeweils 3 aktiven Kernen), zwei sind auf einem Chiplet zu finden und ein anderer zwei auf dem zweiten Chiplet.
Es macht aber keinen Unterschied ob CCX1 mit den Kernen von CCX2 auf dem selben Chiplet oder mit den Kernen von CCX3 oder CCX4 auf einem anderem Chiplet kommuniziert, die Latenzen sind gleich.
Wenn es nach der Tabelle liegt die Latenz nur bei ~26ns für die Kommunikation innerhalb eines CCX und die zwischen CCX schießt auf ~68ns hoch.
* Die Zahlen sind etwas zu niedrig, AMD gibt höhere Latenzen für den L3$ an und keine Ahnung wie Intel getestet hat, aber sie haben ~78ns von CCX zu CCX angegeben:
https://www.3dcenter.org/dateien/abbildungen/Intel-Core-i7-9700K-Core-i9-9900K-vs-Ryzen-9-3900X-Bild6.jpg

[Tesseract]

der 3900X hat natürlich 4 CCX, nicht 3. 3*3 config wären nur 9 cores, nicht 12.


Es macht aber keinen Unterschied ob CCX1 mit den Kernen von CCX2 auf dem selben Chiplet oder mit den Kernen von CCX3 auf einem anderem Chiplet kommuniziert, die Latenzen sind gleich.
das war ja auch das designziel bei IF: nicht die bestmögliche latenz innerhalb des cores, aber hohe skalierbarkeit auf 64+ cores mit guter worst-case-latenz.

[gravitationsfeld]

Soweit ich es gelesen habe war der TAGE-Branch-Predictor für den L2$ zu Beginn nur für Zen3 geplant, zeitlich hat es aber gepasst, um den (bzw. eine Form davon) rückwirkend noch für Zen2 einzubauen.
Bitte erklaer mir mal warum ein L2-Cache einen branch predictor braucht? Das ergibt doch ueberhaupt keinen Sinn.

[y33H@]

Der TAGE ist auch nicht für den L2 Cache sondern nur als zweite Stufe hinter den Perceptron gelagert, daher Level 2 - er braucht mehr Cycles, liefert aber auch bessere/genauere Resultate. Das L2 hat hier wohl einige verwirrt ^^

[basix]

CCX zu CCX Latenz ist das eine. Fragt dich, ob das intra CCD auch über den I/O geht oder halt einfach künstlich verzögert wird um gleichmässige Latenzen zu erhalten.

[Zossel]

Das betrifft aber bis dato nur I/O. Nicht die uArch der Cores.

Als wenn bei heutigen Multicore-[CG]PUs der Interconnect kein Teil der Architektur wäre, der Markt und das Umfeld haben sich halt in den letzten Jahren geändert.

Wer jetzt noch große Ressourcen auf einzelne Kerne wirft anstatt auf Interconnects wird in absehbarer Zeit vom Markt verschwinden. und das gilt auch für Hersteller von Spielesoftware.

[Zossel]

CCX zu CCX Latenz ist das eine. Fragt dich, ob das intra CCD auch über den I/O geht oder halt einfach künstlich verzögert wird um gleichmässige Latenzen zu erhalten.

Warum sollte man etwas künstlich aus bremsen? Wenn man gleichmäßige Latenzen haben möchte hätte man niemals Caches und Register einführen dürfen.

[fondness]

Rumor : AMD Zen 3 Delivers 8%+ IPC & 200Mhz Higher Clock vs Zen 2
https://wccftech.com/amd-zen-3-to-deliver-8-ipc-200mhz-higher-clock-vs-zen-2-rumors-indicate/

[pipin]

Rumor : AMD Zen 3 Delivers 8%+ IPC & 200Mhz Higher Clock vs Zen 2
https://wccftech.com/amd-zen-3-to-deliver-8-ipc-200mhz-higher-clock-vs-zen-2-rumors-indicate/

Originalquelle:

http://www.redgamingtech.com/zen-3-ipc-gains-are-greater-than-8-percent-exclusive/


Wie schon bei uns geschrieben halte ich das für zu gut um wahr zu sein, vor allem, dass die Engineering Samples schon mehr Takt haben sollen als die Zen 2.

[w0mbat]

Mit nochmal 8% mehr IPC wäre man deutlich über SKL und wahrscheinlich auf dem Niveau von ICL. Mal abwarten...

[Unicous]

Hat der Typ überhaupt einen Track Record? Soweit ich mich erinnern kann, fantasiert der Herr gerne auf seinem YT-Kanal herum und erfindet irgendwelche Quellen, genau wie die anderen YT-"Experten".:rolleyes:

So unrealistisch finde ich das im Übrigen nicht. Gibt noch genug Baustellen bei Zen die man angehen kann, aber die Quelle ist meiner Meinung nach nicht belastbar von daher, meh.

[dildo4u]

200mhz sollten das Minimum sein zur Zeit bringen die X Modelle gar nix,im Prinzip dürfte das grad mal das fixen was jetzt verpufft.

https://www.computerbase.de/2019-07/amd-ryzen-3600x-3800x-test/2/#diagramm-test-performancerating-fuer-spiele-frametimes-fhd

[Der_Korken]

8% mehr IPC und +200Mhz Takt entspricht etwa dem, was Zen+ gegenüber Zen gebracht hat. Der 2700X war im Schnitt etwa 11% schneller als der 1800X. Ist auf jeden Fall nicht zu abgehoben.

[Lehdro]

8% mehr IPC und +200Mhz Takt entspricht etwa dem, was Zen+ gegenüber Zen gebracht hat. Der 2700X war im Schnitt etwa 11% schneller als der 1800X. Ist auf jeden Fall nicht zu abgehoben.
Kleine Korrektur: Zen+ hat wohl eher 3% (von AMD höchstselbst so beziffert) gebracht im Schnitt an IPC und ansonsten noch +200 MHz Takt - das sind dann in Summe etwa 10% in Anwendungen und etwas mehr in Games gewesen.

Dagegen ist Zen 3 deutlich potenter mit angenommenen +8% IPC, + mehr Takt und deutlich breiterer Basis bevor IF zum Einsatz kommen muss (8C vs 4C CCX)

[reaperrr]

Originalquelle:

http://www.redgamingtech.com/zen-3-ipc-gains-are-greater-than-8-percent-exclusive/


Wie schon bei uns geschrieben halte ich das für zu gut um wahr zu sein, vor allem, dass die Engineering Samples schon mehr Takt haben sollen als die Zen 2.
Das mit dem Takt ist angesichts von 7nm+ im Rahmen des Erwartbaren, finde ich.

Zur IPC: Forrest Norrod von AMD hat selbst im Interview mit Anandtech gesagt, dass der Plan von AMD immer war, mit Zen3 "IPC parity (or better) across all workloads" zu erreichen. Und zwar mit Ice Lake, nicht Skylake.
Dafür reichen Zen+-mäßige 3-5% nicht annähernd aus.

[nairune]

Um die 10% mehr Leistung für eine neue Generation halte ich jetzt nicht für so verrückt, Kernzahl wird ja konstant bleiben. Vielleicht noch etwas niedrigere Preise / Kern, wie bei Zen+, und es passt für Ryzen 4000.

[pipin]

Das mit dem Takt ist angesichts von 7nm+ im Rahmen des Erwartbaren, finde ich.

Zur IPC: Forrest Norrod von AMD hat selbst im Interview mit Anandtech gesagt, dass der Plan von AMD immer war, mit Zen3 "IPC parity (or better) across all workloads" zu erreichen. Und zwar mit Ice Lake, nicht Skylake.
Dafür reichen Zen+-mäßige 3-5% nicht annähernd aus.

Für ein Endprodukt vielleicht, aber doch nicht für ein ES.

Zen+ war im Schnitt bei 2-3% mit Ausreißern nach oben in bestimmten Benchmarks.

[gmb]

8% mehr IPC und +200Mhz Takt entspricht etwa dem, was Zen+ gegenüber Zen gebracht hat. Der 2700X war im Schnitt etwa 11% schneller als der 1800X. Ist auf jeden Fall nicht zu abgehoben.


Mit den 8% hat keiner gesagt.

Um das nochmal zu verdeutlichen, Es ist eine email Quelle:


However, a very good source of mine emailed me and provided me insight into the IPC gains of Zen 3, telling me that speculation that the chip had an insignificant improvement over Zen 2 isn’t accurate.


I asked him via email if it was over 5-8 percent (a figure I’d guessed based on what tweaks we’ve seen so far in the public eye) and was told that the gains is more than this


Es sind mehr als 8% laut dieser Quelle. Hört sich stark nach typischen Gehype an, wie man es oft bei AMD sieht (viele Fakes) und damit unglaubwürdig, schon weil das nur eine ominöse email Quelle ist. Die 200 Mhz mehr Takt entstammen wiederum einer anderen Quelle, einem Forums Member.

[reaperrr]

Es sind mehr als 8% laut dieser Quelle. Hört sich stark nach typischen Gehype an, wie man es oft bei AMD sieht (viele Fakes) und damit unglaubwürdig, schon weil das nur eine ominöse email Quelle ist. Die 200 Mhz mehr Takt entstammen wiederum einer anderen Quelle, einem Forums Member.
Welche ebenfalls von "1X%" mehr IPC spricht.

[Lehdro]

Hört sich stark nach typischen Gehype an, wie man es oft bei AMD sieht (viele Fakes) und damit unglaubwürdig, schon weil das nur eine ominöse email Quelle ist.
Das ist die bisher interessanteste Quellenbewertung die ich jemals gelesen habe. Selbst wenn Lisa Su persönlich ne email schreiben würde, wäre das für dich schon aus zwei Gründen unglaubwürdig:
1. email
2. geht um AMD
Geil :freak:Weißt du eigentlich welche Quelle generell am unseriösesten ist? Intels Pressematerial von 2014-2018 über den Stand der 10nm Fertigung. Solch einen Trackrecord hat nicht einmal Adored :freak:

Versuchs doch mal mit gesunden Menschenverstand: Wir kennen die Primärquelle nicht und müssen uns auf die Sekundärquelle verlassen, was die Glaubwürdigkeit angeht. War RGT nicht der einzige von den "YTern" der mit der Radeon VII schon im voraus goldrichtig lag während der Rest schon von Navi geträumt hat? Wo lag er denn bisher so großartig falsch oder auch richtig? Kann man doch alles nachprüfen wenn man mag, ist alles online.

Ansonsten einfach mal abwarten bis sich die Quellen- und Faktenlage verdichtet und nicht jedes Gerüchtchen gleich in eine der beiden Kategorien "Wahr" oder "Falsch" einzuordnen zu versuchen - wir wissen da sicherlich noch mit am wenigsten von den Beteiligten. Es kommen sicherlich noch andere und evtl. sogar aussagekräftigere Gerüchte anhand deren man sich allmählich ein Bild zusammensetzen kann.

[gmb]

Das ist die bisher interessanteste Quellenbewertung die ich jemals gelesen habe. Selbst wenn Lisa Su persönlich ne email schreiben würde, wäre das für dich schon aus zwei Gründen unglaubwürdig:
1. email



Das Problem ist nur, dass Lisa Su niemanden schreiben würde, der es nicht wissen darf und jeder seriöse AMD Mitarbeiter würde das genauso vermeiden. Es hört sich einfach unglaubwürdig an.


Welche ebenfalls von "1X%" mehr IPC spricht.


Sinnvoller wäre es jetzt gewesen, hättest du was zu dem Forums Member geschrieben.

[Unicous]

gmb ist das personifizierte FUD.

Er hat Angst, dass Zen 3 nicht so ein großer Wurf wird. (Fear)
Er ist sich nicht sicher, dass Quellen denen nachgesagt wird, dass sie "gut" seien zu trauen ist. (Uncertainty)
Und diese Annahme befiehlt ja auch die Logik wenn man bedenkt, dass zu Zen 1,+ und 2 IPC-Steigerungen schon Monate vorher geleaked wurden und sich das ziemlich genau bestätigt hat und jetzt auf einmal anscheinend mehrere Quellen von wiederum hohen IPC-Steigerungen ausgehen. Das sollte man in deutlich in Zweifel ziehen (Doubt).

:wink::wink::wink::wink::wink:

[reaperrr]

Sinnvoller wäre es jetzt gewesen, hättest du was zu dem Forums Member geschrieben.
Warum? Steht alles in dem Screenshot des Forum-Posts in der News von redgamingtech.

[Lehdro]

Es hört sich einfach unglaubwürdig an.

"Es kann nicht sein, was nicht sein darf."

Leaks per email sind garantiert weder selten noch ungewöhnlich.

[gmb]

gmb ist das personifizierte FUD.


Unicous geht wieder auf die Beleidigungsschiene wenn ihm eine andere Einschätzung nicht passt, wer hätte schon was anders erwarten können. Ein Musterbeispiel bist du selber nicht gerade, deswegen musst gerade Du dich nicht immer so als große Leuchte aufspielen.


Warum? Steht alles in dem Screenshot des Forum-Posts in der News von redgamingtech.


Den Inhalt kann jeder selber lesen, du solltest was zu dem Forums Member schreiben. Also ob er bekannt ist als Insider etc, das wäre wirklich sinnvoller gewesen. Ich bin doch hier in der AMD "Szene" genau richtig, deswegen frage ich nach.

[HOT]

Wenn es so krasse Änderungen in Topologie und Frontend gibt hat das selbstredend auch Einfluss auf das Leistungsverhalten.

[Unicous]

@gmb

Das ist keine Beleidigung, sondern eine Tatsachenfeststellung. Ich habe nicht deine Person sondern dein Geschriebenes angegriffen, wie das in einer zünftigen Debatte üblich ist.:wink:

Du kannst gerne näher erläutern, was du mit "große Leuchte" meinst. Willst du etwa mit einem schnöden ad hominem meine Intelligenz beleidigen?:eek: Ich bin zutiefst bestürzt.:O

Deine Argumente laufen, wie Lehdro bereits sagte, immer auf das Selbe hinaus:
"Es kann nicht sein, was nicht sein darf."

Vor Kurzem erst hast du dir ganz große Sorgen um Zen 3 gemacht, wie konkurrenzlos AMD doch wäre wenn erst Intel seine 10nm Serverplattform ausrollt. Und die Basis deines Untergangszenarios: Zen 3 wird kein großer Wurf (Beweis durch Behauptung) und hat laut Leaks nur DDR4 und PCIe 4.0. und ist allein deswegen schon dem Untergang geweiht.:wink:

Derweil gibt es keine substantiellen Informationen wie sich Intel schlagen wird, aber hey, das braucht dich ja nicht zu tangieren.:wink:

[Linmoum]

Unicous geht wieder auf die Beleidigungsschiene wenn ihm eine andere Einschätzung nicht passt, wer hätte schon was anders erwarten können.Wahrheiten sind keine Beleidigungen.

"Andere Einschätzung" ist auch geil, wenn man E-Mails automatisch als unglaubwürdig abstempelt. Wie kommt man eigentlich auf den Unsinn?
Und es hat ernsthaft niemand etwas anderes erwartet, als ein auftauchender gmb in einem AMD-Thread, der solche Gerüchte direkt in das Reich der Träume verweisen will. ;)

Bei Zen2 sprachen die ersten Gerüchte zur IPC schon vor 'nem Jahr von +13%. Das passte bekanntlich ziemlich gut.

[gmb]

"Es kann nicht sein, was nicht sein darf."



Ach und du meinst, das gilt für dich etwa nicht? :freak:
Alles positive wird leichtgläubig hingenommen, alles weniger gute nicht, nein das wird aktiv bekämpft. Ist schon immer so gewesen in AMD Threads, egal wie eindeutig die Zeichen gewesen sind. Selbst damals vorm Bulldozer wurde doch jeder im Vorfeld dumm angemacht oder gesperrt, der es wagen konnte, dessen IPC anzuweifeln. Oder die gestiegene TDP bei Zen+, die erst keiner wahrhaben wollte. Den Spruch kannst du für dich anwenden, das passt.

[HOT]

Gestiegene TDP bei Zen+ ist nicht in höherer Verlustleistung geendet, was Igor damals nachgewiesen hat. Sein 2700X hat jedenfalls nicht mehr verbraucht als ein 1700X und weniger als sein 1800X in realen Stresstests IIRC.

[reaperrr]

Den Inhalt kann jeder selber lesen, du solltest was zu dem Forums Member schreiben. Also ob er bekannt ist als Insider etc, das wäre wirklich sinnvoller gewesen. Ich bin doch hier in der AMD "Szene" genau richtig, deswegen frage ich nach.
;D

Warum bzw. wie soll ich etwas zu einem Thema schreiben, das mich a) nicht über das, was aus dem Artikel hervorgeht, hinaus interessiert, und zu dem ich b) deshalb auch nicht mehr weiß als das, was aus dem Artikel hervorgeht?

Was für ein seltsames Schubladendenken has du dir zusammengezimmert, das du überhaupt auf die Idee kommst, so selbstverständlich solche Annahmen zu treffen? :freak:

[w0mbat]

Übrigens beschreibt Intel ihren Vorteil so:
Da weiß man ja, was sie von ihrer hardware denken, wenn ihr "Vorteil" ist, dass sie Ermäßigungen anbieten können ;D
https://i.redd.it/i5zd8ioqg4s31.png

[amdfanuwe]

Lol, das ist also der Stapel Dollar, auf den Intel dieses Jahr verzichten muß um noch halbwegs was zu verkaufen. Sieht man mal, wie man bisher abgezockt wurde.

[Brillus]

Übrigens beschreibt Intel ihren Vorteil so:
Da weiß man ja, was sie von ihrer hardware denken, wenn ihr "Vorteil" ist, dass sie Ermäßigungen anbieten können ;D
https://i.redd.it/i5zd8ioqg4s31.png
Ist das echt?

[Stretcher]

Es sind mehr als 8% laut dieser Quelle. Hört sich stark nach typischen Gehype an, wie man es oft bei AMD sieht.

Ich denke niemand hat mit Zen 2 gleich 15% mehr IPC erwartet, von daher könnten auch nochmal 15% ins Haus stehen.
Spiele könnten durch eine Halbierung der Latenzen durch 8c CCX deutlich profitieren.
Intel kann sich definitiv warm anziehen, denn es könnte auch bedeuten, dass sich die Kernzahl verdoppelt.

[Mortalvision]

@stretcher genau mein Gedanke! Wenn bei Intel@5GHz 40ns drin sind, und AMD rausbekommt, wie das geht, gibt das einen krassen boost ;)

[Windi]

Halbierung der Latenzen?

Wenn nur 4 Kerne mit einander reden wollen, steigen sie eher. Bei 8 Kernen sinken sie natürlich.
Ob die Latenzen zum Speicher sinken kann noch niemand beantworten, das hängt davon ab wie viel AMD noch optimieren kann. Schlechtere Latenzen im 8C CCX + bessere Latenzen Dank eines verbesserten IF = ?????

Es wird noch interessant zu sehen wie die Software auf den verdoppelten L3 und die veränderten Latenzen reagiert. Manche Software wird vermutlich durch die Decke gehen, andere hingegen leicht absacken.

[Lehdro]

Ach und du meinst, das gilt für dich etwa nicht? :freak:
Natürlich gilt das nur für dich. Du bist doch derjenige der ständig Zen 3 als Stillstand bezeichnet. Nun gibt es Indizien dass dem nicht so ist, aber DAS KANN JA NICHT SEIN, NEINNEIN.

Alles positive wird leichtgläubig hingenommen, alles weniger gute nicht, nein das wird aktiv bekämpft. Ist schon immer so gewesen in AMD Threads, egal wie eindeutig die Zeichen gewesen sind.
Wie eindeutig sind denn die Zeichen? :confused:
Achja: Lies am besten noch einmal was ich geschrieben habe: Da steht nicht das ich das glaube, nur das es genauso gut stimmen könnte, oder auch falsch sein könnte. Das nennt man Skepsis - während du nur davon ausgehst das es garantiert nicht stimmt weil, email und so. Das nennt man dann plumpe Ablehnung.

Selbst damals vorm Bulldozer wurde doch jeder im Vorfeld dumm angemacht oder gesperrt, der es wagen konnte, dessen IPC anzuweifeln.
Ich habe zur Bulldozer IPC hier bestimmt nix geschrieben. Von daher hör auf mich mit dem allgemeingeblubber zu bewerfen.

Oder die gestiegene TDP bei Zen+, die erst keiner wahrhaben wollte. Den Spruch kannst du für dich anwenden, das passt.
Komisch, ich habe zu dem Thema nie was gesagt, aber hauptsache erstmal drauf! Wird schon wen treffen.

[w0mbat]

Ist das echt?
Jupp, ss aus ner Intel Präsi.

[basix]

Kann ich fast nicht glauben. Selbst für Intel Verhältnisse sehr abenteuerlich. Ausserdem redet man in der Öffentlichkeit nicht so gerne über Rabatte oder Rabattaktionen. Damit würde man der Konkurrenz ja einige Informationen offenlegen.

[robbitop]

Kann ja auch eine semi-interne Präsentation (für Aktionäre?) gewesen sein?

[M4xw0lf]

Kann ja auch eine semi-interne Präsentation (für Aktionäre?) gewesen sein?
Wäre wohl die einzig logische Zielgruppe für so eine Darstellung.

[basix]

Und wieso sollte das von Investoren begrüsst werden? "Hey, wir schmeissen mittels Rabatten den Kunden Geld hinterher und reduzieren so unsere Marge. Wieso? Weil der Konkurrent die besseren Produkte bietet, der dafür dann weniger verdient.". Kommt sicher sehr gut an ;)

[amdfanuwe]

Wäre wohl die einzig logische Zielgruppe für so eine Darstellung.
Da müssen sie die Aktionäre aber für ganz schön Blöd halten.
Als Aktionär würde ich denken:'WTF, 3Mrd. weniger Gewinn? -> verkaufen'

[Lehdro]

Und wieso sollte das von Investoren begrüsst werden? "Hey, wir schmeissen mittels Rabatten den Kunden Geld hinterher und reduzieren so unsere Marge. Wieso? Weil der Konkurrent die besseren Produkte bietet, der dafür dann weniger verdient.". Kommt sicher sehr gut an ;)
Da müssen sie die Aktionäre aber für ganz schön Blöd halten.
Als Aktionär würde ich denken:'WTF, 3Mrd. weniger Gewinn? -> verkaufen'
Na klar ist das gut. Denk doch mal nach:

Nehmen wir mal an die Aktionäre wissen in was für einer Zwickmühle Intels aktuelles Produktportfolio heutzutage steckt. Was soll Intel denn sonst machen? Gar nix um damit gar nix zu verdienen? Nochmal: Die Rabatte sollen sicherstellen das KEIN AMD gekauft wird, sondern Intel. Der Rest der so oder so Intel kaufen würde und von den Rabatten betroffen ist zählt unter Kollateralschäden. Das sichert großen Langzeitinvestoren (sprich: Niemand der einfach mal so seine Investition wegen sowas rauszieht) doch zu dass Intel an der Lage arbeitet anstatt wie einen Großteil diesen und letzten Jahres einfach nur zuschauen zu müssen.

Intel muss doch laut eigener Aussage nur die paar Jahre überbrücken und dann ist alles wieder wie zuvor, fragt doch mal gmb: Der behauptet doch auch das 2021 AMD wieder nix zu sagen hat.

[M4xw0lf]

Da müssen sie die Aktionäre aber für ganz schön Blöd halten.
Als Aktionär würde ich denken:'WTF, 3Mrd. weniger Gewinn? -> verkaufen'
Eigner größerer Anteile dürften schon langfristiger planen.

[Eldoran]

Das Argument von intel war bestimmt, dass intel sich viel mehr R&D (und Werbung) leisten kann, nicht "wir können uns Preisdumping oder Bestechungen leisten". In der Vergangenheit hat das ja auch funktioniert Pentium4/Rambus. Wobei da auch die illegalen Praktiken hineingespielt haben. Diesmal sieht die Situation allerdings anders aus, die historische Stärke - die beste Fertigung, hat versagt.
Obendrein sind auch keine Durchbrüche zu erwarten. Der Vorteil neuer Verfahren sinkt - auch zeichnet sich bei ein paar Teilbereichen, dass die von intel erwarteten Vorteile nicht einstellen werden - etwa Kobalt hat zwar Vorteile, aber nur statt Wolfram, bei Kupfer sind die neuen Varianten auch auf feinsten Leitungen ebenbürtig, da handelt man sich eigentlich nur Probleme ein. Wenn ich mich recht erinnere wäre da das deutlich teurere Ruthenium die richtige Wahl.
Bei 7nm wird wohl problemloser anlaufen, aber es ist weiterhin offen, ob intel signifikante Vorteile gegenüber TSMC (und der eigenen 14nm Fertigung) herausholen kann. Intel hat gezeigt, dass Icelake die IPC steigern kann, aber wenn dabei der Takt signifikant sinkt, frisst das die Vorteile wieder auf.

[LasterCluster]

Ist kein großes Mysterium. Intel spielt auf seine Marktmacht an. Und es gibt Investoren, für die ist Marktmacht Hauptkriterium.

[Benutzername]

Ist kein großes Mysterium. Intel spielt auf seine Marktmacht an. Und es gibt Investoren, für die ist Marktmacht Hauptkriterium.

Jupp. Oft reicht es ja um Konkurrenz mit geballten Moneten zu plätten. intel kann es sich eben leisten die Preise zu senken und macht immernoch Gewinn, obwohl sie derzeit technisch in einer schlechten Position sind. Mit den 10 nm übernommen und wird ncihts, teure eigene Fabriken, die ausgelastet werden müssen. Da ist es absolut ein sinnvoller Schachzug die Preise zu senken und auch durchaus mit fragwürdigen Mitteln die Marktmacht abzusichern, auch wenn das erst einmal ein paar Jahre weniger Profit bedeutet. hauptsache man bleibt der fast Monopolist. Dann kann man ruhig die Preise wieder hoch setzen und ist den lästigen Wettbewerb los. Diese Strategie versucht intel dort den investoren zu verkaufen, damit diese nicht panisch abspringen. Auch wenn das natürlich ein psätes eingeständnis ist der Situation. Es muss wohl wirklich drücken, wenn sie so ehrlich sind.

[amdfanuwe]

Es muss wohl wirklich drücken, wenn sie so ehrlich sind.
ehrlich wäre es wohl zu sagen: 'wir müssen die Preise senken und verdienen dadurch 3Mrd. weniger'.
Statt dessen stellen sie es so dar, als ob sie 3Mrd. investieren würden.

[Berniyh]

Jupp. Oft reicht es ja um Konkurrenz mit geballten Moneten zu plätten. intel kann es sich eben leisten die Preise zu senken und macht immernoch Gewinn, obwohl sie derzeit technisch in einer schlechten Position sind. Mit den 10 nm übernommen und wird ncihts, teure eigene Fabriken, die ausgelastet werden müssen. Da ist es absolut ein sinnvoller Schachzug die Preise zu senken und auch durchaus mit fragwürdigen Mitteln die Marktmacht abzusichern, auch wenn das erst einmal ein paar Jahre weniger Profit bedeutet. hauptsache man bleibt der fast Monopolist. Dann kann man ruhig die Preise wieder hoch setzen und ist den lästigen Wettbewerb los. Diese Strategie versucht intel dort den investoren zu verkaufen, damit diese nicht panisch abspringen. Auch wenn das natürlich ein psätes eingeständnis ist der Situation. Es muss wohl wirklich drücken, wenn sie so ehrlich sind.
Intel läuft wohl gerade in die größte Krise seit P4 rein und wird vermutlich dennoch mehr Gewinn machen als AMD zu besten Zeiten.
Damit ist wohl alles Notwendige über die Perversität am (x86) Prozessorenmarkt gesagt. ;)
ehrlich wäre es wohl zu sagen: 'wir müssen die Preise senken und verdienen dadurch 3Mrd. weniger'.
Statt dessen stellen sie es so dar, als ob sie 3Mrd. investieren würden.
Das ist doch typisch BWL-Sprech.
Wie war das mit dem "negativen Wachstum"?

[Zossel]

Ist kein großes Mysterium. Intel spielt auf seine Marktmacht an. Und es gibt Investoren, für die ist Marktmacht Hauptkriterium.

Die hohen Fixkosten bei Intel könnten ein Problem werden, in der Vergangenheit mit den Stückzahlen und Marktanteilen war das kein Problem.
Es gibt auch Investoren die eine hohe Fertigungstiefe verabscheuen.

[basix]

Naja, "Korrektur" ist für mich immer noch der Inbegriff von Börsen-Sprech ;)

@amdfanuwe:
Stimmt ja auch beides. Egal was man zusätzlich oder ungeplant investieren muss (könnte auch Infrastruktur sein) schmälert den Gewinn.

[SKYNET]

Ach und du meinst, das gilt für dich etwa nicht? :freak:
Alles positive wird leichtgläubig hingenommen, alles weniger gute nicht, nein das wird aktiv bekämpft. Ist schon immer so gewesen in AMD Threads, egal wie eindeutig die Zeichen gewesen sind. Selbst damals vorm Bulldozer wurde doch jeder im Vorfeld dumm angemacht oder gesperrt, der es wagen konnte, dessen IPC anzuweifeln. Oder die gestiegene TDP bei Zen+, die erst keiner wahrhaben wollte. Den Spruch kannst du für dich anwenden, das passt.

TDP bei zen+ gestiegen, verbauch trotzdem gesenkt... wo ist das problem?

nen 2700X taktet höher als nen 1800X, hat ne bessere IPC und verbaucht trotzdem weniger:

https://www.igorslab.media/wp-content/uploads/2018/05/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS82L00vNzYzNTgyL29yaWdpbmFsLzA3LVBvd2VyLUNv bnN1bXB0aW9uLVRvcnR1cmUucG5n.png

https://www.igorslab.media/wp-content/uploads/2018/05/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS82L0svNzYzNTgwL29yaWdpbmFsLzA2LVBvd2VyLUNv bnN1bXB0aW9uLUdhbWluZy5wbmc.png

https://www.igorslab.media/wp-content/uploads/2018/05/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS82L0wvNzYzNTgxL29yaWdpbmFsLzA1LVBvd2VyLUNv bnN1bXB0aW9uLUxpZ2h0LnBuZw.png

[basix]

Prime95 ist ein eher schlechter Indikator für den Stromverbrauch, da oftmals einfach gedeckelt oder bei Intel through the roof. So etwas wie Blender oder Cinebench wären deutlich aussagekräftiger. CB hat z.B. ganz andere Zahlen als IgorsLab (2700X = 1800X + 20W)

[robbitop]

Wobei er ja noch zwei weitere (IMO weniger synthetische) Lastfälle geliefert hat. Finde ich jetzt nicht so undifferenziert.

[SKYNET]

Prime95 ist ein eher schlechter Indikator für den Stromverbrauch, da oftmals einfach gedeckelt oder bei Intel through the roof. So etwas wie Blender oder Cinebench wären deutlich aussagekräftiger. CB hat z.B. ganz andere Zahlen als IgorsLab (2700X = 1800X + 20W)

igor misst direkt an der CPU... genauer gehts kaum.

[Benutzername]

Wobei er ja noch zwei weitere (IMO weniger synthetische) Lastfälle geliefert hat. Finde ich jetzt nicht so undifferenziert.

Eben. und Igor misst mit 20°C Wassertemperatur um das zu normalisieren an der CPU direkt Wie mein Vorredner (schreiber?) schon fesstellte. Auf Prime95 gebe Ich persönlich sowieso nicht soviel, weil das doch eher wirklichkeitsfern die CPU belastet. Man sehe sich die AthlonFX an und wo die jeweils stehen. Unter Prime95 mehr im Mittelfeld, bei Witcher3 und AutoCAD ganz heiß. Liegt vielleicht and der AVX Implementierung in den FX? Aber welches normale Programm nutzt denn schon so umfangreich AVX Instruktionen? Da fidne Ich die anderen schon brauchbarere Aussagen.



edit: genauer als an der CPU wäre in der CPU, aber kein Hersteller legt den Zugagng zu diesen offen.

[reaperrr]

Hat eigentlich schon jemand erwähnt, dass die 8c-CCX übrigens auch 10c und 14c Modelle ermöglichen sollten?

Bspw. könnte es für Vermeer/Ryzen4K so aussehen:
2 CCD:
4950X - 16c 749$
4900X - 14c 599$ (in so ziemlich allem schneller als 3950X)
4800X - 12c 499$ (in Spielen schneller und anderen Anwendungen nah an 3950X)
4750X - 10c 399$ (u.a. in Spielen schneller als 3900X, überall schneller als 3800X)
1 CCD:
4700X - 8c 329$ (Spiele-Leistung >3800X)
4600X - 6c 229$ (Spiele-Leistung ~3700X)
4600 - 6c 199$

[HOT]

https://www.pcgameshardware.de/AMD-Zen-Architektur-261795/News/3-soll-im-zweiten-Halbjahr-2020-kommen-Zen-4-und-5-in-Arbeit-1335472/

Aha, sieh mal einer an. Klar gibts nen Zen3+, das ist offensichtlich.

[robbitop]

Da steht aber auch, dass es spekulativ ist.
Zumal 2020 für Zen 4 ggf auch durch den 5x Quartalsrythmus kommen kann. Zen kam Ende Q1, Zen+ kam Q2. Zen 2 kam Q3. Zen 3 dann Q4 2020?. Logisch wäre dann, dass Zen 4 dann nicht 2021 kommt, sondern 2022.

Das heißt nicht, dass es keinen Refresh gibt. Das wäre nur all zu gesund. Man kann nicht jedes Jahr eine neue uArch herauspumpen. (oder aber man führt jedes Jahr nur schrittweise begrenzte Änderungen ein, jedoch keine sehr großen)

[amdfanuwe]

Die Wartezeit wäre also länger als zuletzt, was Spekulationen befeuert, dass AMD einen Zwischenstopp 2021 mit einem "Zen 3+" einlegt.
Offensichtlich sinds nur Spekulationen.

[SKYNET]

Da steht aber auch, dass es spekulativ ist.
Zumal 2020 für Zen 4 ggf auch durch den 5x Quartalsrythmus kommen kann. Zen kam Ende Q1, Zen+ kam Q2. Zen 2 kam Q3. Zen 3 dann Q4 2020?. Logisch wäre dann, dass Zen 4 dann nicht 2021 kommt, sondern 2022.

Das heißt nicht, dass es keinen Refresh gibt. Das wäre nur all zu gesund. Man kann nicht jedes Jahr eine neue uArch herauspumpen. (oder aber man führt jedes Jahr nur schrittweise begrenzte Änderungen ein, jedoch keine sehr großen)


"+" wird nicht kommen, frühstens mit zen4 könnte da wieder was passierer, da man dort dann von 5nm(zen4) auf 5nm+ gehen könnte = zen4+.

aber denke eher das AMD derzeit die strategische führungsposition weiter ausbauen will , und das geht nur wenn sie weiter vollgas geben, jedes jahr eine neue uArch um intel so ordentlich einzuheizen. weil intel kommt in desktop in 2 jahren mit nem dicken IPC sprung, das muss AMD bis dahin(jetzt sinds 10% im schnitt die die zen2 schneller sind bei gleichem takt) halten können, das geht nur wenn sie jedes jahr min. 10% drauf legen.

[robbitop]

Naja sollte zwischen Zen 3 und 4 sehr viel Zeit liegen, wäre ein Refresh mit zB 6nm analog Zen+ nicht auszuschließen.

[LasterCluster]

Naja sollte zwischen Zen 3 und 4 sehr viel Zeit liegen, wäre ein Refresh mit zB 6nm analog Zen+ nicht auszuschließen.

Falls bei Zen3 weitgehend der CCD und Zen4 weitgehend der I/O Die überarbeitet wird, bräuchte man aber eigentlich kein Zen 3+. Zen4 hätte dann sozusagen einfach einen 'Zen3+' CCD mit neuem I/O.
Theoretisch könnte dieser CCD aber davor schon mit altem I/O erscheinen.

[HOT]

Zen 4 kommt nicht vor 2.HJ 2022, vor allem liegt das an TSMC, denn N5 Pro soll ja erst 2021 fertig werden. Wir wissen aus den Folien, dass AMD ca. 1 1/2 Jahre benötigt fürs Tapeout bis zum Release. Da muss ne Generation dazwischen sein. Perfekt um einen neuen I/O-Die mit DDR5, PCIe5 für AM5 zu etablieren, alles mit Vermeer-Chiplets. Gibt ja durch effizienteres I/O dann trotzdem mehr Leistung. Ich würd da sogar jede Wette drauf eingehen, dass die den neuen I/O-Chip dann wieder auch als Chipsatz designen um früh mit durchgängig PCIe5 und USB4 am Markt zu sein. Das wird ein spannendes Strück Technik. Also:

Zen2 + PCIe4-I/O AM4-> Q3 2019
Zen3 + PCIe4-I/O AM4-> Q4 2020
Zen3 + PCIe5-I/O AM5-> 2.HJ 2021
Zen4 + PCIe5-I/O AM5-> 2.HJ 2022

Analog dazu würd ich auch die APUs sehen:

Zen+ + Vega 12nm -> Picasso Q2 2019
Zen2 + Vega 7nm (Pro) -> Renoir AM4 Q4 2019
Zen2 + Vega 6nm -> Rembrandt AM4 Q1 2021 (reiner Refresh im kompatiblen Prozess)
Zen3 + RDNA2 ? -> ? AM5 1.HJ 2022 (neuer Chip oder eher Chiplet-Design, neuer Prozess)

[robbitop]

Falls bei Zen3 weitgehend der CCD und Zen4 weitgehend der I/O Die überarbeitet wird, bräuchte man aber eigentlich kein Zen 3+. Zen4 hätte dann sozusagen einfach einen 'Zen3+' CCD mit neuem I/O.
Theoretisch könnte dieser CCD aber davor schon mit altem I/O erscheinen.
Es bleibt leider nur Spekulation. Aber ich vermute, dass Zen 3 weniger Änderungen im Core hat und eher mehr im IO / L3.
Zen 4 klingt wegen dem SMT4 Leak von Genova als wenn es dort größere Änderungen geben würde (ggf mehr decoder, load/store, mehr ALUs, mehr L1). Solche Änderungen zaubert nicht einmal Intel jedes Jahr aus dem Hut.
Zen 3 wird sicher einen gesunden Performancesprung liefern - jedoch wenn Zen4 aufgrund der invasiven Änderungen länger dauert, kann man ggf mit 6nm wieder mit gleichen Masken einen etwas schnelleren Refresh bringen.
Abhängig von der Dauer zwischen Zen3 und Zen4 und von den verfügbaren Prozessoptionen.

AMD wäre es zu raten, jedes Jahr ein neues, inkremental besseres Produkt zu liefern. Intel wird früher oder später zurückschlagen. Wenn man bedenkt, was die an RnD haben (und sicherlich die Mehrheit des seltenen CPU Talents), wird das ziemlich hart werden. Aktuell bremst sie der problematische Prozess. Das Problem wird nicht ewig bleiben. Sunny Cove und Golden Cove werden sicherlich ordentlich nachlegen. Gerüchte besagen, dass Golden Cove ein ähnlicher Sprung wie Sunny Cove wird.

Ergo: dranbleiben. Jahr für Jahr. Das geht nur, wenn es inkrementel ist. Ansonsten hält man Deadlines nicht.

[reaperrr]

Es bleibt leider nur Spekulation. Aber ich vermute, dass Zen 3 weniger Änderungen im Core hat und eher mehr im IO / L3.
Zen 4 klingt wegen dem SMT4 Leak von Genova als wenn es dort größere Änderungen geben würde (ggf mehr decoder, load/store, mehr ALUs, mehr L1). Solche Änderungen zaubert nicht einmal Intel jedes Jahr aus dem Hut.
Zen 3 wird sicher einen gesunden Performancesprung liefern - jedoch wenn Zen4 aufgrund der invasiven Änderungen länger dauert, kann man ggf mit 6nm wieder mit gleichen Masken einen etwas schnelleren Refresh bringen.
Abhängig von der Dauer zwischen Zen3 und Zen4 und von den verfügbaren Prozessoptionen.
Gehe ich auch von aus.
Weiß nicht wo es war, aber irgendwo wurden die internen Bezeichnungen für die Zen1-3 Kern-Architekturen genannt und Zen1 war K17, Zen2 K18.1 und Zen3 K18.2. Zen4 und 5 tauchten dort noch nicht auf.
Würde stark davon ausgehen, dass Zen4 wieder ein Zen2-artiger größerer Sprung wird (K19), jedenfalls was die Kerne selbst angeht (am Aufbau der CCX/CCD wird sich evtl. nicht viel ggü. Zen3 ändern, aber wer weiß).
Und was das Timing angeht, ich rechne mit Zen4 spätestens Ende 2021 im Desktop und Anfang 2022 für Server. N5 geht schon in H1-2020 in Massenproduktion, wüsste nicht warum N5P nicht spätestens H2-2021 ebenfalls reif dafür sein sollte. Und auf den wird AMD mMn setzen, weil der Performance-Vorteil von N5 ggü. N7+ zu gering ist, als dass es sich vom Kosten-/Nutzen-Verhältnis lohnen würde den nicht zu überspringen.

[basix]

N5 bringt schon gut was ggü. N7+: Packdichte

[SKYNET]

Es bleibt leider nur Spekulation. Aber ich vermute, dass Zen 3 weniger Änderungen im Core hat und eher mehr im IO / L3.
Zen 4 klingt wegen dem SMT4 Leak von Genova als wenn es dort größere Änderungen geben würde (ggf mehr decoder, load/store, mehr ALUs, mehr L1). Solche Änderungen zaubert nicht einmal Intel jedes Jahr aus dem Hut.
Zen 3 wird sicher einen gesunden Performancesprung liefern - jedoch wenn Zen4 aufgrund der invasiven Änderungen länger dauert, kann man ggf mit 6nm wieder mit gleichen Masken einen etwas schnelleren Refresh bringen.
Abhängig von der Dauer zwischen Zen3 und Zen4 und von den verfügbaren Prozessoptionen.

AMD wäre es zu raten, jedes Jahr ein neues, inkremental besseres Produkt zu liefern. Intel wird früher oder später zurückschlagen. Wenn man bedenkt, was die an RnD haben (und sicherlich die Mehrheit des seltenen CPU Talents), wird das ziemlich hart werden. Aktuell bremst sie der problematische Prozess. Das Problem wird nicht ewig bleiben. Sunny Cove und Golden Cove werden sicherlich ordentlich nachlegen. Gerüchte besagen, dass Golden Cove ein ähnlicher Sprung wie Sunny Cove wird.

Ergo: dranbleiben. Jahr für Jahr. Das geht nur, wenn es inkrementel ist. Ansonsten hält man Deadlines nicht.

AMD muss nur bis intel 2021 liefern kann, jedes jahr nen durchschnittlichen 10% sprung bei der IPC hinlegen, dann haben sie die sache in der tasche... ausserdem werden sie wohl spätestens bei 5nm aka zen4 auf 32C/64T im mainstream gehen... bis 2021 wird es dann auch endlich spiele haben die von mehr als 16T profitieren... und hoffentlich bis dahin auch endlich mal adobe software... das kackt mich am meisten an, legst nen haufen kohle auf den tisch für software der multithreading sowas von fremd ist, wie ne windows .exe für mac :ulol:

[robbitop]

"nur" 10% pro Jahr. :|
Ente, Rotkohl, Klöße -> fix gemacht.

IPC zu steigern wird von Schritt zu Schritt überproportional aufwändiger. Transistoreinsatz und Energieverbrauch. Man schaue sich Sunny Cove an. Der scheint zwar 18% mehr IPC zu haben als die alten Skylake Cores, scheint aber deutlich mehr Leistungsaufnahme dafür zu verbrauchen. Und das bei nicht gerade hoher Taktfrequenz und das trotz eines Shrinks. Dafür musste Intel sicherlich überproportional Transistoren einsetzen. Das kostet natürlich. AMD hat es nicht einfacher - im Gegenteil - sie haben weniger Ressourcen.

[SKYNET]

"nur" 10% pro Jahr. :|
Ente, Rotkohl, Klöße -> fix gemacht.

IPC zu steigern wird von Schritt zu Schritt überproportional aufwändiger. Transistoreinsatz und Energieverbrauch. Man schaue sich Sunny Cove an. Der scheint zwar 18% mehr IPC zu haben als die alten Skylake Cores, scheint aber deutlich mehr Leistungsaufnahme dafür zu verbrauchen. Und das bei nicht gerade hoher Taktfrequenz und das trotz eines Shrinks. Dafür musste Intel sicherlich überproportional Transistoren einsetzen. Das kostet natürlich. AMD hat es nicht einfacher - im Gegenteil - sie haben weniger Ressourcen.


naja, aber zen ist noch nichtmal halbwegs "fertig" da geht noch einiges was IPC angeht, der nächste dicke sprung kommt mit Zen4 und DDR5... alleine durch den speicher bzw. die massiv gesteigerte bandbreite, dürfte das schon 5-10% schub geben.

und klar hat AMD weniger cash zur verfügung, aber dafür haben sie die besseren chip designer und kreativeren köpfe :)

[robbitop]

Wo bringt Bandbreite denn große Sprünge? Videorendering/Encoding. Aber in vielen Alltagsanwendungen und Spielen eher nicht. In der Regel ist es Latenz, die hilft. Da ist bei Zen aber eher die Fabric der Flaschenhals. DDR5 mit seinen hohen Taktraten kann aber sicherlich erlauben, die Kernzahl pro Speicherkanal zu erhöhen.
Latenz wird aus dem Grund mit inkrementell wachsendem Cache gesteigert. Zen 2 bekam doppelt so viel L3. Zen 3 macht dann aus 2x CCX -> 1x CCX. Das steigert den maximal nutzbaren L3 auf 32 MiB. Wird aber im Gegenzug sicherlich etwas Latenz kosten. Dafür ist die Hitrate besser. Das Endergebnis wird sicher besser. Ist aber streng genommen keine IPC. Aber bringt in Spielen taktnormierte Leistung. Ja.

Ich will damit nur sagen, dass IPC Steigerung ziemlich aufwändig ist und mit jedem Schritt aufwändiger werden wird. Wer am Ende mehr Ressourcen hat, hat sicherlich, je näher man an die Asymptote kommt, bessere Chancen näher an diese zu kommen.

[reaperrr]

DDR5... alleine durch den speicher bzw. die massiv gesteigerte bandbreite, dürfte das schon 5-10% schub geben.
Den Schub bekommt Intel ungefähr zur gleichen Zeit bzw. im Server-Bereich noch früher, ich sehe da keinen Vorteil für AMD.
Zumal ich davon ausgehe, dass die ersten DDR5-Riegel gemessen an den Taktraten teils deutlich schlechtere Timings als die schnellsten DDR4-Riegel haben werden, war beim Umstieg von DDR3 auf DDR4 genauso. 5-10% wird das vielleicht bei APUs bringen und vielleicht in bestimmten HPC-Anwendungen, in denen reine Bandbreite wichtiger ist als Latenz, aber in anderen Fällen einschließlich Spielen wird's sich anfangs im Bereich 0-3% bewegen, bestenfalls.

[Setsul]

Ich zitiere mich mal selbst:
Our 5nm technology entered risk production in March 2019 and target for volume production in 2020.

Meanwhile, TSMC plans to announce N5P technology one year after 5nm technology announcement.
https://www.tsmc.com/english/dedicatedFoundry/technology/5nm.htm

Also TSMC will N5P volume production 2021. Daraus zu schließen dass es vor 2H2022 keine N5P Produkte geben kann ist gewagt.


Nichtsdestotrotz ist da wenig Druck. Neuer Sockel mit PCIe 5.0 und DDR5 geht auch ohne Zen4 (siehe HOT). Ein Refresh wäre auch kein Problem. Zen+ 2018 war auch nichts anderes, gerade bei EPYC war tote Hose. Solange mit Zen3 2020 dank N7P und ein paar kleineren Veränderungen am Kern + anderer L3 >10% rauskommen (und das sollte wirklich machbar sein) kann sich keiner beklagen wenn dann wieder ein Jahr mit einstelligem Prozentbereich kommt.

[S940]

Es bleibt leider nur Spekulation. Aber ich vermute, dass Zen 3 weniger Änderungen im Core hat und eher mehr im IO / L3.
Naja, I/O ist sowieso ausgelagert und der unified L3 ist erstmal langsamer.
Wenns nur dabei bliebe, würde AMD für den langsameren Chip keine Käufer finden, das wäre höchstens nur was für Epycs.

Ergo kann man da mehr erwarten.

Größere Änderungen am Core macht man am besten mit nem ausgereiften Prozess, das würde für größere Änderungen für Zen3 und dem dann eingefahrenen 7nm Prozess sprechen. Die Nachfolgegeneration in 5nm shrinkt man dann nur und bastelt ein neues I/O Die mit DDR5/PCIe5 dazu.

SMT4 kann man sich ebenfalls für Zen4 aufsparen, nachdem man die nötigen Architekturverbreiterungen mit Zen3 eingeführt und alles entbuggt hat.

[amdfanuwe]

An 3D Technologie, also gestapelten Chips, wird ja auch intensiv geforscht.
AMD war des öfteren Vorreiter einer neuen Technologie ( Hypertransport, integrated MMC, Transposer, HBM, Chiplets ...). Ich bin sicher, dass sie auch an 3D Chips arbeiten. Aber was könnte dabei rauskommen?
12nm I/O + getapelten IF Switch und RAM für Kohärenz?
CPU Chiplets + stacked L3 Cache?
APU + stacked HBM?
GPU + stacked CPU + HBM?

Lasst mal hören, wo ihr da Potenzial seht.
Letztendlich geht es immer nur um billiger, effizienter, kleiner, schneller.

[robbitop]

Naja, I/O ist sowieso ausgelagert und der unified L3 ist erstmal langsamer.
Wenns nur dabei bliebe, würde AMD für den langsameren Chip keine Käufer finden, das wäre höchstens nur was für Epycs.

Ergo kann man da mehr erwarten.

Größere Änderungen am Core macht man am besten mit nem ausgereiften Prozess, das würde für größere Änderungen für Zen3 und dem dann eingefahrenen 7nm Prozess sprechen. Die Nachfolgegeneration in 5nm shrinkt man dann nur und bastelt ein neues I/O Die mit DDR5/PCIe5 dazu.

SMT4 kann man sich ebenfalls für Zen4 aufsparen, nachdem man die nötigen Architekturverbreiterungen mit Zen3 eingeführt und alles entbuggt hat.

Ein größerer L3, auch wenn er ein paar Cyles langsamer sein sollte, sollte im Endeffekt schneller sein. Dank Datenlokalität.

Dass ein reifer Prozess besser für neue Designs ist, stimmt. Scheint AMD aber nicht zu interessieren bis dato. Zen neu / 14 nm neu
Zen+ alt / 12 nm = 14 nm+
Zen 2 neu / 7 nm neu

Ich bleibe dabei. MMn wird Zen 3 im Vergleich zu Zen 4 weniger Änderungen im Core haben.

Ggf irre ich mich ja. Werden wir sehen.

[BoMbY]

CPU Chiplets + stacked L3 Cache?


Das wäre doch eine sehr gute Idee - bis zu doppelte Anzahl CPU Cores und doppelter Cache auf der gleichen Fläche. Und dazu könnte man den Cache noch in einem optimierten Prozess dafür fertigen.

[robbitop]

Das kostet bestimmt wider Latenz.

[BoMbY]

Ich denke mit TSVs hätte man da weniger Probleme, aber man müsste vermutlich den L3 Cache weiterhin aufteilen. Also vielleicht 2x CCX mit 8c/16t mit 2x 32 MB Cache auf einem gestapelten CPU Chiplet, oder sowas.

[Complicated]

Da gibt es auch noch aktive Interposer, die durchaus auf der Latenz-Ebene noch etwas bringen könnten. Man stelle sich mal vor ein IO-Die würde aus einem solche aktiven Interposer als Basis hergestellt und die Chiplets für 3D Stacking optimiert um direkt onTop gestapelt zu werden. Möglicherweise HBM dazu, GPUs mit drauf...da sind bestimmt auch langfristig noch einige Möglichkeiten vorhanden um die Signalwege kürzer, stromsparender und latenzarmer zu machen.

Ein solcher NoC auf dem Interposer wurde ja mal in diesem Paper beschrieben:
https://tspace.library.utoronto.ca/bitstream/1807/70378/3/Kannan_Ajaykumar_201511_MAS_thesis.pdf
Die Yields für einen zu 10% aktiven Interposer sind wirtschaftlich tragbar gegenüber dem passiven.

https://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=34746&d=1474814569

Das würde es ermöglichen Teile des Interconnects aus den Chiplets in den Interposer zu verlagern und weitere Chipfläche auf den Chiplets zu sparen:

https://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=34747&d=1474814555

Die Kosten sinken, da weniger Wafer für Chiplet-Fertigung benötigt werden und auch die Chiplets weniger komplex werden.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=68062&stc=1&d=1572095002

Hier könnte noch einiges an Performance brachliegen.

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=68063&stc=1&d=1572095699

Für mich machen die ganzen Zen-Iterationen den Eindruck auf dem Weg dorthin zu sein über die kommenden Generationen

[HOT]

Ein größerer L3, auch wenn er ein paar Cyles langsamer sein sollte, sollte im Endeffekt schneller sein. Dank Datenlokalität.

Dass ein reifer Prozess besser für neue Designs ist, stimmt. Scheint AMD aber nicht zu interessieren bis dato. Zen neu / 14 nm neu
Zen+ alt / 12 nm = 14 nm+
Zen 2 neu / 7 nm neu

Ich bleibe dabei. MMn wird Zen 3 im Vergleich zu Zen 4 weniger Änderungen im Core haben.

Ggf irre ich mich ja. Werden wir sehen.

So wird das nicht laufen. Da wird man alle Register ziehen. Wahrscheinlich kann man das sowieso so gar nicht sehen. Beide Architekturen werden ja sukzessive ausgebaut. Es wird hat sich von Zen1 zu Zen2 viel getan, es wird sich von Zen2 auf Zen3 genauso viel tun, eben so von Zen3 auf Zen4. Nun sind es eben die Gegenbenheiten, die dafür sorgen, ob etwas refresht wird oder nicht. Bei Zen3 bietet sich das einfach an, da die Fertigung recht früh zur Verfügung steht und eben in dessen Zeitraum eine neue Plattform ansteht und somit der I/O-Teil außerhalb der Architekturzeiträume entwickelt werden kann und eben Zen4, genau wie Zen2, auf den großen Fertigungssprung angewiesen ist. Es geht von Zen2 auf Zen3 nur um das Chiplet und von Zen3 auf Zen3+ eben nur um das consumer-I/O-Die - von Zen3 auf Zen4 wieder nur das Chiplet und das Server-I/O-Die für Genoa.

[robbitop]

IMO kommt es drauf an, wie viel Abstand zwischen 2x uArch Änderungen besteht. Wie gesagt: selbst Intel brachte zu besten Zeiten ein Tock nur alle 2 Jahre. Zaubern kann man nicht.

[Setsul]

Das waren immer 2 Teams die jeweils 4 Jahre Zeit hatten. Bei AMD ist die Organisation wohl etwas anders mit mehr gemeinsamer Entwicklung die erst spät auseinandergeht (siehe Zen1/2).

Vor allem hat AMD nicht die Ressourcen um alle tollen Neuerungen erst auf einem alten, bewährten Prozess zu implementieren und dann die ganze Architektur fürs nächste Jahr auch noch zu portieren. Deshalb hat AMD schon seit Jahren neue Architekturen auf neuen Prozessen gebracht, damit das eine Team das sie haben sich gleich der nächsten Architektur auf dem nächsten Prozess widmen kann während auf dem gleichen Prozess nur noch wenig geändert wird.

[robbitop]

Das ist gut möglich. Jedoch hat man entweder weniger Innovationssprünge pro Zeiteinheit oder mehr Manpower. Letzteres wäre schwer zu glauben.

Mein letzter Stand war, dass AMD zwei Implementierungsteams aber nur ein Designteam für x86 hat. Hat sich das geändert?

[Tesseract]

Vor allem hat AMD nicht die Ressourcen um alle tollen Neuerungen erst auf einem alten, bewährten Prozess zu implementieren und dann die ganze Architektur fürs nächste Jahr auch noch zu portieren.
das macht ohne eigene fabs auch nicht wirklich sinn. in den modernsten intel fabs laufen ausschließlich intel CPUs vom band, d.h. sie wollen von anfang an zumindest ein konservatives design haben das ohne große verzögerungen bzw. kinderkrankheiten läuft damit nichts still steht. AMD kann das vollkommen egal sein, wenn die die fetten chips erst später bestellen produziert TSMC/glofo/samsung/etc. inzwischen einfach was anderes mit weniger risiko bzw. besseren yields.

[S940]

Ein größerer L3, auch wenn er ein paar Cyles langsamer sein sollte, sollte im Endeffekt schneller
Das stimmt bei single-thread, aber beim neuen Design konkurrieren ja noch 2 andere Threads um den L3. Das Anflaschen 2er Kerne an einen L3 wird außerdem mehr als "ein paar" Cycles kosten, das ist nicht trivial.
Außer AMD nähme die Billiglösung mit abwechselnden Zugriffen, dann wären die Latenzen aber noch schlechter. Umso mehr/besser müssten in dem Fall die vorgelagerten Cache-Stufen ausgebaut werden. Hmm.. unterm Strich könnte sich das dann vielleicht doch noch rentieren, z.B. mit 2x64kB L1 und 2MB L2.
Ich erwarte von Zen3 deshalb noch viel, weil das das letzte Design von Jim Keller ist. Allerdings ist auch eines klar - Keller ist schon länger weg und wer weiss, was AMD da mittlerweile getrieben hat.
Möglich, dass AMDs Marketingabteilung in der Zwischenzeit Zen3 in Zen4 umbenannt hat und der jetzige Zen3 nur ne Art Zen2+ ist. Das kann man nicht ausschließen.

[S940]

IMO kommt es drauf an, wie viel Abstand zwischen 2x uArch Änderungen besteht. Wie gesagt: selbst Intel brachte zu besten Zeiten ein Tock nur alle 2 Jahre. Zaubern kann man nicht.
Zaubern nicht, aber durch die automatischen Designtools hat man schon nen nicht zu unterschätzenden Vorteil ggü. Intel. Deren Designs schauen immer noch wie von Hand gemacht aus.

[tm0975]

so ganz genau wissen wir ja nicht, was intel aktuell macht bzw. wie. das, was sie derzeit (als neu) verkaufen ist ja viele jahre alt...

[HOT]

Das ist gut möglich. Jedoch hat man entweder weniger Innovationssprünge pro Zeiteinheit oder mehr Manpower. Letzteres wäre schwer zu glauben.

Mein letzter Stand war, dass AMD zwei Implementierungsteams aber nur ein Designteam für x86 hat. Hat sich das geändert?

So unflexibel ist das bei denen denke ich nicht. Die haben Leute, die die Designs bauen und Leute, die die Architekturen entwickeln. Ich denke da ist die Trennung.
Zudem wird auch Zen sehr modular sein, das sieht man ja an der Sache, die für Zen3 gedacht war aber aufgrund des Wartens auf die Fertigung noch in Zen2 implementiert wurde (gabs ein paar Seiten vorher). Das wird ein stetiger Entwicklungsfluss sein, der dann entsprechend in neue Designs mündet. Es ist im Gegenteil sogar so: Neuer Prozess erfordert neues Design, alter oder kompatilber Prozess erfordert kein neues Design. Die Implementierung in Chips ist der große Zeitfresser, weniger die Architektur mMn.
Mit dem I/O-Die hat man sich jetzt noch ne Refreshmöglichkeit geschaffen, die außerhalb der Architekturentwicklung läuft, also außerhalb der Fertigungsinnovation (eben zwischen N7+ und N5 Pro). Den könnte man die DDR5-Variante in 12LP+ oder N6 bringen.

N7+ ist sowohl von AMD als auch von TSMC bestätigt worden und der Prozess ist inkompatibel zu N7. Also erzwingt das ein neues Design, da wird man dann alles einbauen, was man bis dahin an Innovationen entwickelt hat. Gegenbeispiel ist Zen+ oder Picasso (und mMn auch Renoir, vielmehr dessen Refresh Rembrandt), man erhält einen kompatiblen Prozess und packt daher mehr Leistung, das spart ein neues Design.

[robbitop]

Naja. Da AMD automatsierte Layouttools hat, können sie es auch rekompilieren. Natürlich braucht es dennoch Manpower. Aber weniger als zuvor.
Es wäre super für den Markt, wenn jedes Jahr eine veränderte uArch käme. Es klingt für mich aber ein wenig optimistisch, dass AMD mit 1 Größenordnung weniger RnD als Intel das schaffen soll.

[HOT]

Meine Güte darüber reden wir doch, dass das eben nicht so ist. Man bringt Zen1, dann über 2 Jahre später Zen2 (was primär dem Prozess geschuldet sein dürfte, den man sich ausgesucht hat), 1 Jahr und 1 Q später Zen3 (der Prozess ist halt schon verfügbar) und dann wieder 2 Jahre später Zen4 (der Prozess dauert halt so lange). Trotzdem sind das alles Architektursprünge. Man könnte wahrscheinlich alle 1 1/2 Jahre ein Architekturupdate bringen, das ist halt schwierig mit der Planung für die Prozesse.

[robbitop]

Wie gesagt, das ist eine Variante. Die andere ist, dass es durch die 5Q Schritte automatisch 2022 bei Zen 4 wird. Bisher waren es immer 5 Q.
Bis dato ist alles Spekulation. Da gibt es hier kein falsch und richtig. ;)

Außerdem klingt SMT4 nicht nach einer kleinen Änderung. Das bedarf sicher nach enormen Validierungsaufwand. Und damit es was bringt, sollte vieles breiter werden. Klingt für Zen 4 nicht nach einem kleinen Update.

[HOT]

Klar sind das 5Q. Aber erst ab Q2 oder 3 2021, da man vorher den Prozess nicht soweit hat.

[Setsul]

@Tesseract:
Tick-Tock war auch ein bisschen Salamitaktik. Wenn alle 2 Jahre neue Architektur und neuer Prozess gleichzeitig kommen und dazwischen nur +3% (also immer so wie Haswell Refresh, mit dem Wissen das Skylake kommt) werden sich die Käufe ungleichmäßig verteilen. Schlimmstenfalls sinkt der Umsatz in der Hälfte der Jahre, er steigt dafür in der anderen Hälfte um so stärker, aber das ist trotzdem in den Augen einiger Leute ein fürchterliches Unding.

Das stimmt bei single-thread, aber beim neuen Design konkurrieren ja noch 2 andere Threads um den L3. Das Anflaschen 2er Kerne an einen L3 wird außerdem mehr als "ein paar" Cycles kosten, das ist nicht trivial.
Außer AMD nähme die Billiglösung mit abwechselnden Zugriffen, dann wären die Latenzen aber noch schlechter. Umso mehr/besser müssten in dem Fall die vorgelagerten Cache-Stufen ausgebaut werden. Hmm.. unterm Strich könnte sich das dann vielleicht doch noch rentieren, z.B. mit 2x64kB L1 und 2MB L2.
Es werden 8 Kerne / 16 Threads statt 4/8 pro L3. Die Slices sind nicht unabhängig wie bei Intel sondern es ist wirklich ein einziger L3 pro CCX. Deshalb kann Intel beliebig von 2 bis 12 Kernen pro Ring skalieren und AMD eben nicht.

2 MB L2 sind auch völlig übertrieben. Soll das etwa keine Latenz kosten? Das kostet außerdem viel Fläche und Strom. Es gibt keinen Grund von der gut funktionierenden Cache Hierarchie bei Zen wieder Rückschritte Richtung Bulldozer zu machen.

64 kB L1 sind auch nicht so einfach. L1 ist noch strom- und transistorhungriger pro Kapazität als L2. Den L1I hat AMD erst wieder verkleinert weil die Transistoren beim µop-Cache besser aufgehoben waren. Der L1D müsste entweder 16-way werden und die Latenz und der Stromverbrauch den das erzeugt ist es nicht wert oder man gibt VIPT auf, was noch schlechter ist. PIPT ist noch langsamer, VIVT ist ein Aliasing-Albtraum.

[S940]

Außerdem klingt SMT4 nicht nach einer kleinen Änderung. Das bedarf sicher nach enormen Validierungsaufwand. Und damit es was bringt, sollte vieles breiter werden. Klingt für Zen 4 nicht nach einem kleinen Update.
Das ist eben der Kasus Knacktus. Eben weil der Validierungsaufwand stark ansteigt, würde es durchaus auch Sinn machen den breiteren Kern bei Zen3 zu bringen und ihn bis Zen4 dann zu debuggen und auch schon zu optimieren. Erst mit wirklichem Si sieht man ja, wo es bei welchen Queues hakt, welcher Code mit welchen Daten Stau in den Exec-Units verursacht, etc.
Durch die automatisierten Tools hat AMD halt nen Zeitvorteil. Damit können sie es sich leisten, bei jeder neuen Maske neue Änderungen einzubauen, wenn auch nicht im vollem Umfang.
Sprich, die Frage ist die, wie viel von der Verbreiterung bei SMT4 schon bei Zen3 eingebaut werden wird. Man wird einen Schritt in die Richtung machen, aber wie groß der ausfällt ist offen. Möglich, dass man erstmal nur die Caches vergrößert. Die Änderung des L3 geht in die Richtung, da muss man dann auch irgendwann mal L1/L2 anfassen, wenn man später 4 Threads auf einen Kern haben will.
Spannend wird es halt bei den INT-Units. Man hat gerade ne AGU von 2 auf 3 nachgelegt und für SMT4 wären mind 6 statt 4 INT-Units, besser 8 und 4 AGUs für SMT4 angesagt. Wenn man jetzt ne Scheibchentaktik aufgrund der Autotools vorraussetzt, könnten bei Zen3 dann z.B. 6 INT-Units kommen und SMT4 abgeschaltet implementiert sein (das benötigt nur Arbeit im Front+Back-End, weniger direkt in den Exec-Units, d.h. man kann damit so gut wie alles Debuggen). Bei Zen4 könnte AMD dann SMT4 freischalten. und ggf. die diversen Queues vergrößern, die sich im Test als besonders große Flaschenhälse erwießen haben.


So oder so, der INT-Teil wird in den nächsten Generationen getunt werden, da die Caches-Bandbreite für AVX256bit verdoppelt wurde. Diese Bandbreite liegt im Moment für INT brach. SMT4 bietet sich da zur Nutzung der vorhandenen Resourcen einfach an.






Es werden 8 Kerne / 16 Threads statt 4/8 pro L3. Die Slices sind nicht unabhängig wie bei Intel sondern es ist wirklich ein einziger L3 pro CCX.
Ja im aktuellen Design, aber wieso sollte das beim nächsten so bleiben? Das ist ja noch nicht sicher. Man weiss nur, dass AMD auf einen mind. doppelt so großen L3 umschwenkt. Die Größe sagt aber nichts über die Implementierung aus.

Deshalb kann Intel beliebig von 2 bis 12 Kernen pro Ring skalieren und AMD eben nicht. Stand Zen2 ja, Stand Zen3 weiss man es aber eben noch nicht.

2 MB L2 sind auch völlig übertrieben. Soll das etwa keine Latenz kosten? Mit 5nm nicht mehr. Latenz ist abhängig von der Leiterbahnlänge, die das Signal zurücklegen muss, bei jedem Shrink wird das weniger. Trotz 14-> 12 -> 7nm blieben die Latenzen aber bisher gleich, bei nem weiteren Shrink auf 5nm hat man also genug Polster um sich bei gleicher Latenz nen schönen Nachschlag bei der Cachegröße zu gönnen.


Das kostet außerdem viel Fläche und Strom.
Caches brauchen nicht viel Strom, eher im Gegenteil. Die Heizkörper der Chips sind die Rechenwerke, da gehts ab. Deren Kühlung wird mit immer kleineren Strukturen ein Problem, weshalb es auch immer mehr Sinn macht, die einzelnen Hot-Spots von Mehrkern-Prozessordesigns auf einem Die durch kühlende/isolierende "Cache-Seen" abzugrenzen. Bei AMD jetzt umso mehr, als der ebenfalls kühle I/O-Teil ausgelagert wurde. Also das würde schon alles gut zusammen passen, auch mit dem steigendem Cache-Bedarf durch SMT4.

Es gibt keinen Grund von der gut funktionierenden Cache Hierarchie bei Zen wieder Rückschritte Richtung Bulldozer zu machen.
Bulldozer hatte viele Probleme, ja, der 2 MB L2 war aber ganz sicher nicht das Problem. Das ist ein Äpfel-Birnen-Vergleich. Wenn Du statt 1l Wasser 1l Alkohol trinkst, hast Du auch nen anderen Effekt, obwohl die Menge gleich ist. Also allein von der Cachegröße eines 32nm Designs und dessen Gesamtleistung auf die Leistung eines komplett anderen Designs in 5-7nm schließen zu wollen, ist zusammenhangslos.

Nebenbei: Bei der letzten Bulldozer-Generation hatte man die L1-Caches (endlich) auf 32kB verdoppelt, wodurch sich die Leistung schon ansehnlich verbesserte. Das Designteam schaffte es trotz der Verdoppelung, die ursprüngliche Cachelatenz beizubehalten und den Stromverbrauch sogar zu senken.


64 kB L1 sind auch nicht so einfach.
Keiner hat behauptet, dass Chipdesign trivial sei.
L1 ist noch strom- und transistorhungriger pro Kapazität als L2. Das sind jeweils 8T-Sram-Zellen beim L1+L2, das Transistor-Design ist also gleich, der höhere Stromverbrauch liegt v.a. an der unterschiedlichen Spannung, da der L1 an der vollen Core-Spannung hängt, L2+L3 dagegen nicht. Am Ende ist das nur das triviale Argument, dass ein größerer Core aufgrund der größeren Fläche mehr Leistung verbraten kann, was logisch ist. Ist am Ende halt die Frage, ob sich der Aufwand rechnet, oder nicht. Mit SMT4 werden die Karten hinsichtlich dessen neu gemischt.


Den L1I hat AMD erst wieder verkleinert weil die Transistoren beim µop-Cache besser aufgehoben waren. Klar, wenn das bei SMT4 auch noch so ist, kann man den L1I so lassen und nur den µop-Cache weiter vergrößern. Muss man simulieren. Wenn 2 neuen Threads dazu kommen, die ganz andere Instruktionen nutzen könnten, dürfte ein größerer L1I-Cache aber mehr bringen, als ein größerer µOp-Cache. Denkbar wären auch 2 µOp-Caches für je 2 Threads, aber das wäre dann schon wieder ein größerer Designeingriff. Ein vergrößerter L1I wäre erstmal einfacher zu implementieren.

Der L1D müsste entweder 16-way werden und die Latenz und der Stromverbrauch den das erzeugt ist es nicht wert
In 5nm und mit SMT4 kann das ganz anders aussehen, davon abgesehen gäbe es auch die Möglichkeit bei 8way zu bleiben. Wäre halt etwas mehr Design-Aufwand, bei weniger Leistung, aber auch kein Hexenwerk.

[robbitop]

Das mit dem SMT4 könnte ggf. Sinn ergeben bezüglich folgenden Hintergrundes: Gerüchte sagten ja schon länger, dass Zen 3 SMT4 erhalten soll. Das hielt alle Welt (inkl. mir) für unwahrscheinlich. Die zurückgezogene AMD Präsentation von vor einigen Wochen zeigte, dass Genoa (Zen 4 Epyc) SMT4 haben wird. Da könnte sich der Schluss ergeben (wie von dir dargestellt), dass SMT4 ggf. mal für Zen 3 vorgesehen war, man aber aus Gründen (z.B. nicht schaffbar in der Deadline) den Teil auf Zen 4 verschoben hat.

Bzgl. AVX2 256bit: hatte Zen 2 nicht bereits die Verdopplung der Cachebandbreiten dafür (analog Skylake) bekommen? Mir ist so als wenn das so wäre. Es gab nämlich auch einen vergleichbaren Speedup bei AVX2 Anwendungen wie von Haswell auf Skylake. (z.B x264/265 encoding)

[S940]

Das mit dem SMT4 könnte ggf. Sinn ergeben bezüglich folgenden Hintergrundes: Gerüchte sagten ja schon länger, dass Zen 3 SMT4 erhalten soll. Das hielt alle Welt (inkl. mir) für unwahrscheinlich. Die zurückgezogene AMD Präsentation von vor einigen Wochen zeigte, dass Genoa (Zen 4 Epyc) SMT4 haben wird. Da könnte sich der Schluss ergeben (wie von dir dargestellt), dass SMT4 ggf. mal für Zen 3 vorgesehen war, man aber aus Gründen (z.B. nicht schaffbar in der Deadline) den Teil auf Zen 4 verschoben hat.
Genau. Man hat jetzt 2 Möglichkeiten: Entweder kommen die Architekturverbesserungen (teilweise) - aber erstmal ohne SMT4, oder man hat ersatzhalber nen Zen2+ eingeschoben, der nur wenige der Zen3-Verbesserungen aufweist (wenn überhaupt) und das ehem. Zen3 Design kommt erst als Zen4.

Bzgl. AVX2 256bit: hatte Zen 2 nicht bereits die Verdopplung der Cachebandbreiten dafür (analog Skylake) bekommen? Mir ist so als wenn das so wäre. Es gab nämlich auch einen vergleichbaren Speedup bei AVX2 Anwendungen wie von Haswell auf Skylake. (z.B x264/265 encoding)Ja klar, sorry, falls das missverständlich ausgedrückt war. Die Caches sind jetzt mit 256bit angebunden (2x256b lesen + 1x256b schreiben), aber fürs klassische INT hat das im Moment 0 Vorteile, weil die INT-Einheiten die Bandbreite nicht ausnutzen können, da sie nur max 64bit breit sind. Ersatzhalber böte es sich deshalb an, an einem Cache-Port 4x64bit für 4 INT-Threads pro Takt einzulesen bzw. zu schreiben. Das passt dann gut. Ob das immer optimal klappen wird, ist ne andere Frage, aber besser man versucht es, als es generell überhaupt nicht zu nutzen ;)

[Setsul]

@S940:
Die Hälfte deiner Argumente ergibt leider keinen Sinn.
Ob SMT4 bei Zen3 kommt oder nicht darüber kann man sich sicher streiten, aber SMT4 zu implementieren und dann abzuschalten ist definitiv Schwachsinn.

Ich erwarte auch dass der L3 anders wird, sonst wären 32+ MB nicht so einfach möglich, aber es spricht absolut gar nichts dafür dass AMD 2 Kerne an einen "L3" hängt, egal wie du dir das vorstellst. Es ist immernoch falsch weil bei Zen1/2 definitiv 4 Kerne an einem L3 hängen. Es gibt durchaus sinnvolle Argumente wieso ein größerer L3 höhere Latenz haben sollte, aber die Realität zu ignorieren und zu behaupten dass bei Zen1/2 je ein Kern an einem "L3" hängt und es bei Zen3 definitiv 2 Kerne pro "L3" sein müssen ist keines davon.

Ich habe keine Ahnung wie 5nm es ermöglichen soll den L2 zu vervierfachen bei gleicher Latenz wenn Zen3 immernoch auf 7nm+ ist. Das musst du mir erklären.

Bloß weil der L1/L2 nicht den Hauptteil des Stromverbrauchs stellen heißt das nicht, dass man die einfach beliebig vergößern kann und nichts davon merkt. Den Teil mit der Fläche hast du geschickt ignoriert. Wieder ist Teil deines Argument "das muss kommen weil SMT4".

Doch, die L2 Latenz war bei Bulldozer ein massives Problem. Deshalb hat der doppelte L1 ja so viel gebracht. Der Stromverbrauch ist gesunken weil Bulldozer ursprünglich 6 GHz schaffen sollte. Mit wesentlichen entspannteren Pipeline-Timings wird auch der L1 sparsamer.

"Das ist nicht trivial, aber auch kein Hexenwerk" ist ein denkbar schlechtes Argument wieso AMD jetzt von heute auf morgen ein Problem lösen kann an dem Intel und AMD 20 Jahre lang gescheitert sind. Nein, auch mit 5nm ist VIVT immernoch ein Schuss ins Knie. Du überschätzt auch massiv wieviel neue Prozesse bei der Cache-Latenz bringen. Die 90er sind vorbei. Intel hat seit einer gefühlten Ewigkeit nichts am 32 kB 8-way L1D geändert (seit Banias, 130nm), da sollte sich doch ein "Polster" angesammelt haben dass einem schwindlig wird. Sunny Cove bekommt 50% mehr L1D und die Latenz geht hoch. Warum wohl?
Das Problem ist, dass wire delay mittlerweile richtig scheiße ist. Man merkt nichts davon, dass die gleiche Strecke doppelt so lange dauert wenn sich alle Entfernungen innerhalb von Kern/Cache halbieren, aber sobald man den Cache größer macht oder mit anderen Kernen kommunizieren will ist der Spaß vorbei.

EDIT:
Zen3 ist Zen3, Zen4 ist Zen4.
Zen2 ist letztendlich auch Zen 1.5 und Zen3 ist praktisch Zen 1.7.

Es gibt einfach keinen Sinn exakt ausdrücken zu wollen wie sehr sich die Architekturen unterscheiden. Deshalb sagt Intel ja Sandy und Ivy Bridge. Ähnlich, aber nicht ganz gleich.
Zen+ ist schlicht und ergreifend der selbe Kern mit einem neueren Stepping das den L2 fixt das EPYC schon von Anfang an hatte.
Zen2 ist ein anderer Kern, also geht die Nummer hoch.
Zen3 ist ein anderer Kern, also geht die Nummer hoch.
Zen4 ist ein anderer Kern, also geht die Nummer hoch.
Da ist keine Information drin wie ähnlich die Kerne untereinander sind. Jedes Argument, dass Zen3 nicht "wirklich" Zen3 weil sich zu wenig ändert ist ein "no true scotsman". Es hat sich etwas am Kern geändert, also ist es Zen3 weil 3 nach 2 kommt.

[robbitop]

IMO sehr hilfreiche Erläuterung, Setsul. :up:

[S940]

Ob SMT4 bei Zen3 kommt oder nicht darüber

kann man sich sicher streiten,
Ja.
aber SMT4 zu implementieren und dann abzuschalten ist definitiv Schwachsinn.
Lass mich raten, Du hast 0 Ahnung von CPU-Debugging? Das allein wäre ja noch nicht verwerflich, nicht jeder debuggt nen Chip und kennt auch die undokumentierten Befehle, aber anscheinend hast Du auch noch nichts von Spectre oder Meltdown gehört. Spätestens seitdem diese Sicherheitslöcher in Größe eines Scheuenentores bekannt sind, sollte auch dem größten Dau klar sein, dass das Debuggen von SMT kein Kindergeburstag ist. Aber nö, klar, Schwachsinn :freak:



aber es spricht absolut gar nichts dafür dass AMD 2 Kerne an einen "L3" hängt, egal wie du dir das vorstellst. Es ist immernoch falsch weil bei Zen1/2 definitiv 4 Kerne an einem L3 hängen. Was fängst Du jetzt an Sachen vom vorletzen Post abermals zu diskutieren. Natürlich hast Du recht, das war falsch ausgedrückt, anstatt "2 Kerne", hätte ich "2x soviele Kerne" schreiben sollen. Wenn Du nur halb so klug wärst, wie Du vorgibst, hätte Dir das in den Sinn kommen müssen.

Ich habe keine Ahnung wie 5nm es ermöglichen soll den L2 zu vervierfachen bei gleicher Latenz wenn Zen3 immernoch auf 7nm+ ist. Das musst du mir erklären.Erstmal müsstest Du erklären, was DU jetzt willst, 7 oder 5nm?


Bloß weil der L1/L2 nicht den Hauptteil des Stromverbrauchs stellen heißt das nicht, dass man die einfach beliebig vergößern kann und nichts davon merkt. Das hat keiner behauptet, wer redet von beliebig großen L1+L2? Konkret waren 64kB L1 und 2 MB L2 genannt. Wie bei jeder anderen Designentscheidung schlicht darum, ob sich der Aufwand lohnt.

Den Teil mit der Fläche hast du geschickt ignoriert.
Ja, weils irrelevant ist. Wozu soll bei einer Diskussion über zukünftige Shrinks denn die Fläche wichtig sein? Früher gabs auch L1-Caches mit nur 2kb, seitdem sind wir Generationen weiter und die L1-Größe wuchs in ~20 Jahren immerhin auf 32 kB an. Es gab auch schon 64 kB L1-Caches. Von daher wäre eine solche Größen in 7- oder 5nm alles andere als ne Riesenüberraschung.

Doch, die L2 Latenz war bei Bulldozer ein massives Problem. Deshalb hat der doppelte L1 ja so viel gebracht.
Genau, die 2x16kB L1 waren für 2MB L2 zu klein, da die Hitraten im L1 zu gering waren und der L2 zu oft genutzt werden musste. Das ist aber eben *nicht* der Fehler des L2, sondern der des L1 bzw. der gesamten Architektur (der L2 war ja auch noch durch 2 Cluster gemeinsam genutzt, da ist ein kleiner L1 doppelt sch...lecht).



Wir lernen daraus, dass es für 2 MB L2 einen größeren L1 braucht. 2x32 sind schon mal gut, ich redete aber von ner weiteren Verdopplung auf 2x64kB L1. Die würden dann sehr gut zu einem 2 MB L2 passen, v.a. wenn einem auch kein 2. Cluster in die Quere kommt. Reine Cachegrößen ohne weitere Architekturbetrachtung zu beurteilen, ist - ich passe mich mal Deiner Wortwahl an- wirklich absoluter "Schwachsinn".



Du überschätzt auch massiv wieviel neue Prozesse bei der Cache-Latenz bringen. Die 90er sind vorbei. Intel hat seit einer gefühlten Ewigkeit nichts am 32 kB 8-way L1D geändert (seit Banias, 130nm),
Eben, deshalb ist es jetzt an der Zeit da wieder aktiv zu werden.
da sollte sich doch ein "Polster" angesammelt haben dass einem schwindlig wird. Sunny Cove bekommt 50% mehr L1D und die Latenz geht hoch. Warum wohl?
Gegenfrage: Wieso macht Intel das, obwohl sie die Latenz nicht in den Griff bekommen? Eben weil der L1D-Cache größer werden muss und man sich das endlich leisten kann. Sunny Clove ist davon abgesehen immer noch ein 10nm Design. Man darf erwarten, dass Intel das beim nächsten Shrink wieder auf 4 Takte reduziert. Bei Intel ist aufgrund der abermaligen Prozessverschiebung Chaos angesagt. Über etwas merkwürdige Designentscheidungen würde ich mich deshalb nicht wundern. Man kann annehmen, dass die jetzt SunnyClove genannte Architektur ursprünglich für nen kleineren Prozess entworfen wurde.
Das Problem ist, dass wire delay mittlerweile richtig scheiße ist. Man merkt nichts davon, dass die gleiche Strecke doppelt so lange dauert wenn sich alle Entfernungen innerhalb von Kern/Cache halbieren, aber sobald man den Cache größer macht oder mit anderen Kernen kommunizieren will ist der Spaß vorbei.
Tja und trotzdem nimmt Intel diesen "Spass" in Kauf und vergrößert den L1.


Es hat sich etwas am Kern geändert, also ist es Zen3 weil 3 nach 2 kommt.Doll, Du erklärst Kindergartenmathematik. Nach 1 folgt 2 folgt 3. Ganz duper doll und jetzt kommen die Teletubbies. Darum gehts aber doch überhaupt nicht, die arabischen Zahlen und die dazu passende Grundschularithmetik zieht doch niemand in Zweifel.

Die Frage die sich stellt ist die, ob Zen3 Anno 2019 noch das gleiche ist, wie Zen3 Anno 2015. Zen3 Anno 2015 wurde noch von Keller entworfen, das Design war, seiner eigenen Aussage nach, fertig. Seit seinem Abgang sind bald 5 Jahre vorbei, da kann viel passiert sein, v.a. weil er nicht mehr im Unternehmen ist. Deswegen kann man darüber sehr wohl spekulieren, egal ob das Design nun die Nummer 3,4 oder sonstwas hat.

[BoMbY]

SMT4 ist immer noch sehr unwahrscheinlich:

https://i.imgur.com/ayAyl3Z.png

[Complicated]

Wie gesagt, das ist eine Variante. Die andere ist, dass es durch die 5Q Schritte automatisch 2022 bei Zen 4 wird. Bisher waren es immer 5 Q.
Bis dato ist alles Spekulation. Da gibt es hier kein falsch und richtig. ;)

Da gibt es aber deutliche Ansagen von AMD seit dem 18.09.2019 dazu, im Rahmen des AMD EPYC HORIZON Executive Summit | Rome, Italy (https://www.youtube.com/watch?v=w-4S77RI7LE)
http://ir.amd.com/events/event-details/amd-epyc-horizon-executive-summit-rome-italy
Although AMD will release a few more Zen 2 (https://www.notebookcheck.net/AMD-Ryzen-Threadripper-Zen-2-hits-4-17-GHz-in-Geekbench-obliterating-the-Threadripper-2950X-Ryzen-9-3900X-and-Intel-Core-i9-9900K-in-the-process.433451.0.html)-based chips before moving on, the company's next three architecture are already at least in the design stage. To be more specific, we are talking about Zen 3, Zen 4, and even Zen 5. These are not mere rumors as AMD has confirmed that both Zen 4 and Zen 5 are "in the design phase" during the company's Horizon Executive Summit, an event that took place in Rome, Italy.

Another important bit of information that is now set in stone is the fact that AMD Zen 3 is already in the "design complete" status. This means that all the design work is done, the architecture has been locked down already, and the testing and manufacturing stages should follow. Returning to Zen 5, we should add that the first chips based on this next-next-gen architecture are due to arrive in 2022.




Und was die Anzahl der Entwicklerteams angeht, so müssen das mindestens zwei sein, wenn die sich gegenseitig "leapfroggen" wollen, wie das schon mit Zen 1 bekannt gegeben wurde:
https://www.overclock3d.net/news/cpu_mainboard/amd_confirms_that_zen_5_is_already_in_development/1
AMD's Zen design teams work on a leapfrogging basis. One team works on their next-generation CPU architecture while the other works on next-next-gen hardware. Now that Zen 3's design is finished, AMD's engineers have moved to Zen 5, a CPU architecture that's due to release in 2022.

One thing to note about AMD's design teams is that core architecture improvements can be transferred from one architecture to another in some cases. For example, some changes to Zen 2's branch predictors were due to release with Zen 3. This design feature moved forward into AMD's Zen 2 core, thanks to the fast work fo AMD's Zen 3 team. Similar improvements may also have been moved from Zen 4 to Zen 3, highlighting how closely AMD's design teams can work.

[robbitop]

Hilfreich, danke! :up:

[Setsul]

@S940:
Niemand baut SMT4 mit der Absicht ein beim debuggen zu versagen. Es besteht die Möglichkeit im schlimmstenfall die CPUs auch ohne zu verkaufen aber es gibt keine einzige CPU, weder mit SMT2 noch mit SMT4 noch mit SMT8 bei der man von vornherein gesagt "wir bauen das zwar ein, aber wir wissen das wird eh nix".

Das stimmt bei single-thread, aber beim neuen Design konkurrieren ja noch 2 andere Threads um den L3. Das Anflaschen 2er Kerne an einen L3 wird außerdem mehr als "ein paar" Cycles kosten, das ist nicht trivial.
Das ist vedammt eindeutig, nicht falsch formuliert. Keine Diskussion funktioniert wenn man einfach rät was der andere meint. Wenn beide bei jedem Fehler davon ausgehen dass eigentlich das gemeint ist was sie für richtig halten kommt man nicht weiter.

Deine Begründung ist "2 MB L2 geht locker auf 5nm". Jetzt schauen wir uns mal den Titel an. "Zen 3, 7nm+, 2020 (Vermeer, Genesis & Milan)". Wenn du Zen4 meinst bist du hier falsch, egal wie sehr du dich anstrengst allen klar zu machen dass Zen4 eigentlich Zen3 ist und AMD die "falschen" Namen verwendet.

Ich kann auch konkret 256 kB L1 nennen. Ist nicht beliebig groß. Geht das jetzt automatisch? Nein, und die Kosten sind Platz- und Stromverbrauch. Größere Caches scheitern nicht daran weil keiner Zeit hat sie zu implementieren.

Und in der guten alten Zeit ging das auch ohne überproportional Strom und Fläche zu vebrauchen um die Latenz gleich zu halten. Jetzt nicht mehr. Es ist kein Zufall dass die L1-Größe gleich geblieben ist seit die Taktraten stagnieren. Die Gründe sind die gleichen.

Nein, ein kleinerer, schnellerer L2 wäre sowohl bei gleichem als auch bei größerem L1 besser gewesen. Man merkt es durch den kleinen L1 besonders stark weil bei Bulldozer alles schiefgegangen ist was schiefgehen konnte.
Nein, das ist genau das Gegenteil von dem was man daraus lernen sollte. Ein L2 mit 20 Takten Latenz ist schlecht, egal wie groß er ist. Er ist noch viel schlechter wenn der L1 zu klein ist und man deshalb einen Cache mit niedriger Latenz braucht um das abzufedern, aber die Lösung ist nicht einen zu großen L2 mit einem zu großen L1 auszugleichen sodass beide zu langsam sind. Das ist schon immer so gewesen, wenn sich die Größe die man braucht/will nicht bei sinnvoller Latenz/Stromverbrauch realisieren lässt baut man ein Level mehr und versucht es nicht mit Gewalt.

Nein, nach der Logik sollten wir uns auch wieder um 10 GHz bemühen, weil sich das lange wenig getan hat.
Intel macht das auch nicht auf Teufel komm raus. Wenn die nach vielen Jahren in der Lage sind 50% mehr Cache bei etwas höherer Latenz verbauen dann werden die sehr genau wissen wieso das jetzt sinnvoll ist. Und die Begründung ist nicht "es musste sich mal wieder was tun". Die Hoffnung dass 7nm auf magische Weise die Latenz wieder reduziert ist auch naiv. Wieso haben 10nm, 14nm, 22nm, usw. nicht die Latenz reduziert? Was macht 7nm denn so viel besser als alle Prozesse des letzten Jahrzehnts zusammen?
Intel bezahlt schon für 50% mehr mit höherer Latenz. Aber AMD soll 100% einfach so, ohne neuen Prozess, einfach weil wegen ist so, bei gleicher Latenz schaffen. Nein, wird nicht passieren.


In diesem Thread geht es um das was AMD Zen3 nennt. Egal wie du es gerne nennen möchtest.
Das Namenschema ist, wie du richtig erkannt hast, sehr, sehr einfach gehalten. Es trägt wirklich nicht zur Klarheit bei wenn du das immer vermischst und dich darüber auslässt wie toll "Zen3" doch wird wenn man nie weiß ob du Zen3 oder Zen4 meinst, solange du nicht auch 5nm erwähnst.
Was mich wirklich stört ist das hier:
Genau. Man hat jetzt 2 Möglichkeiten: Entweder kommen die Architekturverbesserungen (teilweise) - aber erstmal ohne SMT4, oder man hat ersatzhalber nen Zen2+ eingeschoben, der nur wenige der Zen3-Verbesserungen aufweist (wenn überhaupt) und das ehem. Zen3 Design kommt erst als Zen4.
Zen3 ist eben nicht Zen2+. Zen+ war nie ein anderer Kern.
Die Numerierung ist so einfach und sinnvoll, wieso ist es so schwer die zu verwenden?
AMD entwickelt kontinuierlich an einem Zen Design und baut immer ein was gerade fertig und auf dem Prozess möglich ist. Es ist müßig zu diskutieren was genau für die Kerne für 2021 (egal welcher Name) geplant war, weil sich das zu oft ändert. Siehe Complicated, Zen2 hat schon Teile der Branch Predictors von Zen3 die eben früher bereit waren als geplant.

Man kann sich bei den Nummer auch eigentlich fast sicher sein. Neuer Prozess, neuer Kern.
N7+ 7nm+ und 12LP 12nm zu nennen ist in dem Zusammenhang natürlich ungünstig weil 12LP eben wirklich 14nm+ ist und erst 12LP+ etwas anderes, aber egal.
14nm, 7nm DUV, 7nm EUV, 5nm. Zen1, Zen2, Zen3, Zen4.
Große Änderungen wie SMT4 landen damit sinnvollerweise schon immer bei Zen4. Bestenfalls kommen Features von Zen4 zu Zen3, aber nicht umgekehrt.
Die ganzen Gerüchte die SMT4 schon Zen3 zuschreiben kommen wahrscheinlich daher dass Zen4 intern wohl als "die neue Architektur" gesehen wird. Da sind auch wieder die 4 Jahre dazwischen, die völlig normal sind.
Es ist also auch wahrscheinlich dass Keller mit Zen3 wirklich Zen3 gemeint hat. Er wird wohl kaum 2015 das Design für 2021/22 fertig haben das dann Jahre rumliegt. Aber dass er den Plan für Zen und dann zweimaliges Aufbohren für Zen2 und Zen3 fertig hat klingt realistisch.

[Piefkee]

Die Frage die sich stellt ist die, ob Zen3 Anno 2019 noch das gleiche ist, wie Zen3 Anno 2015. Zen3 Anno 2015 wurde noch von Keller entworfen, das Design war, seiner eigenen Aussage nach, fertig. Seit seinem Abgang sind bald 5 Jahre vorbei, da kann viel passiert sein, v.a. weil er nicht mehr im Unternehmen ist. Deswegen kann man darüber sehr wohl spekulieren, egal ob das Design nun die Nummer 3,4 oder sonstwas hat.

Das mit Keller stimmt nicht. Wenn dann Quelle. Keller war von August 2012 bis August 2015 bei AMD. Hat primär die Team geleitet und war für K12 zuständig. Für Zen3 oder Zen4 ist so gut wie nix von ihm...

[robbitop]

Dass mit dem iterativen Einbauen von Neuerungen im ~1 Jahresrhytmus klingt IMO verdammt gut. So kommt kontinuierlich eine Verbesserung und man reduziert das Risiko. Word etwas nicht rechtzeitig fertig, verhindert es nicht das Produkt sondern kommt im nächsten. So kann man langfristig dranbleiben. :up:

Wahrscheinlich kommt man irgendwann an einen Punkt an dem man wieder was Neues machen muss weil die Basis ausgedrückt ist. Ggf ein bisschen so wie bei GPUs. Neue uArch und dann immer neue verbesserte Iterationen. Alle habe Jahrzehnte mal eine neue Grundarchitektur.
Klingt das abwegig? Ggf hat man doch mehr von den GPU Jungs übernommen als gedacht (automatisiertes Layout und ggf den grundsätzlichen Entwicklungsverlauf?)

[Nightspider]

Interessant wäre es natürlich schon wie viele Jahre solche Persönlichkeiten wie Keller und Su im vorraus planen und Weichen stellen.
In jedem Falle hat Keller auf viele Jahre hinaus eine Basis geschaffen und eine Richtung vorgegeben und vielleicht schon Ansätze für etliche Generationen später aufgezeigt.

IMO kommt es drauf an, wie viel Abstand zwischen 2x uArch Änderungen besteht. Wie gesagt: selbst Intel brachte zu besten Zeiten ein Tock nur alle 2 Jahre. Zaubern kann man nicht.

Das las man von dir schon öfter. Tatsache ist aber auh das Intel die letzten 10 Jahre Gewinnmaximierung betrieben hat und kompliziertere Innovationen gescheut hat.
Von sowas wie Chiplets und Stacking hat man früher von Intel glaube auch nie was gelesen, bis AMD damit erfolgreich wurde.

Bei der Architektur gab es ein halbes Jahrzehnt lang keine größeren Änderungen und hier im Forum haben schon alle geheult das die IPC schon am maximal Machbaren liegen würde. :ugly:

Es klingt für mich aber ein wenig optimistisch, dass AMD mit 1 Größenordnung weniger RnD als Intel das schaffen soll.

Bei Intel hat aber auch so ein bisschen der Ehrgeiz gefehlt und man hat sich sichtbar auf den Lorbeeren ausgeruht.
Dazu hatte Intel diverse verschiedene Designs gleichzeitig am laufen für mobile, desktop, workstation und hpc.
Alleine für die zig designs ging bestimmt auch immer gut Geld drauf.

[robbitop]

Ja scheint ein anderer Entwicklungsansatz zu sein.

IMO fehlte es Intel aber bei der Einführung nicht an Ehrgeiz. Die ersten paar Tick Tocks kam massiv mehr Leistung.

[Hammer des Thor]

An 3D Technologie, also gestapelten Chips, wird ja auch intensiv geforscht.
AMD war des öfteren Vorreiter einer neuen Technologie ( Hypertransport, integrated MMC, Transposer, HBM, Chiplets ...). Ich bin sicher, dass sie auch an 3D Chips arbeiten. Aber was könnte dabei rauskommen?
12nm I/O + getapelten IF Switch und RAM für Kohärenz?
CPU Chiplets + stacked L3 Cache?
APU + stacked HBM?
GPU + stacked CPU + HBM?

Lasst mal hören, wo ihr da Potenzial seht.
Letztendlich geht es immer nur um billiger, effizienter, kleiner, schneller.


Es würde bei 3D CPUs erst mal reichen Leiterbahnen und Transistoren auf andere Ebenen zu bringen, da wäre ein ganz grosser Durchbruch, der die Chips viel schneller und stromspardener macht, denn dass meiste an Fläche sind die Leiterbahnen die auch das Meiste an Verlustleistung bringen. Man stelle sich mal eine Megastadt mit mehreren 100-Millionen Einwohnern vor in der es weder Brücken noch Tunnel gibt. Da müssen die Verkehrswege extrem ausgeklügelt sein und leider oft auch sehr lang.
Dann gab es dieses Jahr einen grossen Durchbruch bei Carbon-Nanoröhrchen:

https://www.heise.de/newsticker/meldung/Neuer-Nanoroehrchen-Chip-koennte-Moores-Gesetz-retten-4515782.html

Sowas als Nachfolger der 3nm Siliziumtech in der 2. Hälfte der 20er Jahre in diesem Jahrhundert erst mal planar, auch solche Transistoren lassen sich schon mal viel höher takten, dann Ende der 20er Jahre oder 2030 3D mit einer Transistorschicht und Leiterbahnen auf anderen Schichten und im Laufe der 30er Jahre dann immer mehr Schichten auch Transistorschichten! Das wäre doch was!

[Setsul]

Äh wir sind mittlerweile bei über einem Dutzend Metal Layers. Versteh ich da etwas falsch oder schlägst du wirklich etwas vor das es seit dem ersten IC gibt?

[amdfanuwe]

@Hammer des Thor
Nanoröhrchen liegen mir noch etwas zu weit in der Zukunft.
Was ist in naher Zukunft machbar?
Bei Apples aktuellem I-Phone wird ein POP (Pakage over Pakage) verwendet. Über der CPU wird noch ein 4GB RAM verbaut.
Wäre das etwas für AMDs APU?
Könnte als IGP RAM verwendet werden.
Oder mit 8 GB und 4Core APU gäbe das ein schönes single Pakage für den Massenmarkt.
Bei embedded und günstigeren Notebooks spart sich der OEM das externe RAM.

[HOT]

@Setsul, du schreibst dir die Finger wund und liegst dennoch daneben denke ich. Bei deinem steifen festhalten an den CCX lagst du schon daneben, das könnte schon jetzt bei Renoir fallen. Und das wird bei den Caches eben so sein. Sicherlich gibt es Argumente, die du da nennst, die gegen eine Cache-Vergrößerung sprechen, aber das ist ja immer ein Abwägen des Für und Wider. Und dass die Cachegrößen steigen sieht man eben auch bei Intel. Erst der L1D, dann der L3 (Tigerlake). Bei AMD wird das jetzt auch erfolgen, ich denke, dass Opteron da einfach den richtigen Riecher hat. Na ja, der hat ja auch Jahrzehntelange Erfahrung mit Architekturinternas.

[robbitop]

Naja es ist immer ein Balanceakt aus Latenz, Größe und Verbrauch. Insofern ist der Ansatz "the right tool for the right job" schon schlüssig. Von kleiner Größe und sehr guter Latenz über mehrere Stufen zu größer und schlechterer Latenz.
AMD war beim K7 ja mal bei 64+64kiB für L1. Und ist jetzt Jahrzehnte später sogar kleiner geworden, weil man dafür massiv geringere Latenzen fährt. Beim L2 scheint das auch zu gelten.
Ggf. ist beim L3 aber irgendwann die Lücke bezüglich Latenz zum L2 doch so groß, dass man dann doch in Richtung L4 geht. Für besonders große Caches (die aber noch vor dem Interconnect liegen müssen - denn der scheint es ja in Regionen zu bremsen, dass man schnell auf RAM Latenzniveau liegt).
Eines ist Fakt: die nächsten Jahre werden durch den entfachten Wettbewerb interessant. AMD liefert ~jährlich eine neue Iteration der uArch ab und Intel fängt seit einem halben Jahrzehnt auch wieder an, richtig Gas zu geben. Ich finde es super! :)

[HOT]

Das kann ich auch so unterschreiben. Aber man kann das natürlich nicht mit K7-Zeiten vergleichen. Da spielen ja jetzt deutlich mehr Faktoren eine Rolle, beispielsweise die Wärmeableitung, die durch die Cache-Größe ja mitbestimmt wird.
Selbst wenn bei Vermeer der Cache nicht sonderlich größer werden sollte, bei Zen4 in 5nm wird das einfach zur Notwendigkeit.

[Setsul]

@HOT:
Wie lag ich beim CCX daneben? Bei Zen2 haben alle auf 6 oder 8C CCX spekuliert und ich habe gesagt das wird nichts und sieh da es wurde nichts. Surface sollte 6C custom bekommen und siehe da, es ist der selbe alte 4C Picasso geworden. Renoir kommt zu einer Zeit zu der Intel schon 8C Mobile anbietet, aber nein, AMD investiert sicher extra Aufwand um nicht konkurrenzfähig zu sein und baut einen 6C CCX. Wäre sonst ja zu einfach. Also viele Gerüchte waren von Anfang an einfach Schwachsinn.
Ich liege bei Weitem nicht bei allem richtig, aber als Beispiel etwas zu nehmen wo ich jedes Mal den Gerüchten widersprochen habe und jedes Mal Recht behalten habe als Beweis zu nehmen, dass beim dritten Mal doch die Gerüchte mich endlich widerlegen müssen ist schon eine interessante Argumentation.
Nur so zur Information: Der Roman den ich dazu geschrieben habe wieso 6/8C CCX nicht möglich/sinnvoll sind bezieht sich nur auf CCX. "32+ MB" interpretiere ich so dass da wesentlich mehr Konfigurationsmöglichkeiten vorhanden sind als nur halbieren/verdoppeln wie beim CCX. Das wird meiner Meinung nach eben nicht bloß "CCX aber mit mehr Kernen" sondern eventuell ein völlig anderer L3. Bei den offensichtlichen Nachteilen war klar, dass sich da irgendwann etwas ändert.
AMD hat leider keine spezielle Bezeichnung für die Topologie außer "CCX", siehe Definition "A CPU Complex (CCX) is four cores connected to an L3 cache", also kann man das vielleicht fehlinterpretieren als "AMD wird nie mehr als 4 Kerne an einen L3 hängen". Aber es ist eher so gemeint wie "Intel wird nie mehr als 12 Kerne an einen Ring hängen". Haben sie auch nicht, werden sie auch nicht. Stattdessen wird eben etwas anderes gebaut. Die ganzen Gründe wieso diese Organisation mit fixed distance 4 slice low adress interleaving L3 nicht auf 6 oder 8 erweitern kann fallen natürlich weg wenn AMD etwas völlig anderes baut so wie Intel den Ring durch ein Mesh ersetzt hat.
Meine Vorhersage war, dass diese Umstellung mit Zen4 und 5nm kommt, weil potentiell 32 CCX pro Sockel nicht mehr wirklich tragbar sind. Gleichzeitig sind 16 CCD vielleicht auch nicht so toll und mit 16 Kernen / 4 CCX pro CCD würde man eine Umstellung auf einen gemeinsamen L3 deutlich merken, während mehr als 16 Kerne wieder zu viel sind (siehe Intel Mesh SNC Mode) also kann das System dann wieder auf Jahre so bleiben. Da bin ich natürlich positiv überrascht, dass ich falsch lag und die Umstellung schon mit Zen3 kommt.
Auf den HPC Folien stand auch nirgends mehr CCX, soweit ich mir erinnern kann. Der CCX ist tot, es lebe der CCD. Wahrscheinlich wird AMD ab jetzt immer alle Kerne auf einem CCD an einen L3 hängen, egal ob 4, 8 oder später sogar 12/16.

Renoir ist nebenbei immernoch Zen2. Es ist nicht ausgeschlossen, dass weil Renoir so viel später kommt, recht nahe an Zen3, oder eben gerade deswegen so spät ist, der neue L3 schon kommt. Praktisch wäre es sicher, nicht die vollen 32 MB sondern wieder halbiert (wobei eventuell ist das Ding ja konfigurierbar auf 36/40/48 MB oder so, also mehr als 16 MB sind nicht unmöglich), aber 1x16 MB dürfte nützlicher sein als 2x8 MB, vor allem wenn aus TDP Gründen in vielen SKUs nur 4 oder 6 Kerne aktiv sind.
Generell wäre eine Flexibilität bei der Größe wie bei Intels L3 sicher wünschenswert, aber ob das schon mit Renoir kommt ist ungewiss.

Also an Gerüchten festzumachen dass ich ja völlig falsch lag geht mir zu weit. Ich habe AMD unterschätzt, dachte das L3 Redesign kommt erst wenn es sein muss, aber 6/8 Kern CCX mit dem jetzigen Design ist und bleibt nicht sinnvoll bis unmöglich. Die Frage ist wie gut und vor allem flexibel wird der neue L3.

Opteron ist tot.

Zu den Cache-Größen: Intel hat den L1D um 50% vergößert und die Latenz geht hoch. AMD hat den L3 verdoppelt und die Latenz ging hoch. Intel hat den L2 vergößert und die Latenz ging hoch. Intel hat schon lange L3 Slices mit 1,5 bis 2,5 MB gebaut. Tigerlake bekommt eben 3,0 MB. Und die Latenz wird wieder hochgehen. Nebenbei hat AMD 4 MB pro Slice, zwar mit noch höherer Latenz, aber nichts davon ist verrückt.
Wenn jetzt S940 daherkommt und meint AMD kann einfach die Realität ignorieren und nicht nur einen 2 MB L2 mit vernünftiger Latenz bauen sondern sogar mit exakt der gleichen wie für 0,5 MB, dann muss ich dem widersprechen.

[HOT]

Unified L3 von 32MB ist das Ende der CCX, nix anderes. Sollte Renoir wirklich 6 Kerne haben ist da schon Ende der CCX. Es gibt einfach ne neue Topologie und Ende. Du mit deinen starren Ansichten, so funktioniert das nicht.