Diskussion zu: AMDs abgespeckte CPU-Kerne "Zen 4D" für Server-Variante "Bergamo" ...

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/geruechtekueche-amds-abgespeckte-cpu-kerne-zen-4d-fuer-server-variante-bergamo-und-fuer-zen-5

[basix]

Bei Zen 5 könnte man ja auch auf 12 Cores gehen. Da steigt die Chipfläche dann wieder auf 70-80mm2 (ausser die Zen 5 Cores wären wirklich sehr fett verglichen zu Zen 4).

Bei Zen 5 EPYC gibt es ja zudem das Gerücht zu 192/256 Cores. Könnte da auch passen:
- Max. 16 Chiplets --> Neues IOD
- 16*12 Zen 5 = 192 Cores --> Genoa Nachfolger
- 16*16 Zen 4D/5D = 256 Cores --> Bergamo Nachfolger

Alternative:
- Max. 12 Chiplets --> Gleiches IOD
- 16C Zen 5 Chiplets (3D-Stacked 64MB SRAM + IO in 5nm; Zen 5 Cores in 3nm oben drauf)
- 12*16 Zen 5 = 192 Cores
- 4*16 Zen 5 + 8*24 Zen4D/5D = 256 Cores

[Abe_]

Die Zielsetzung bei "Bergamo" sind augenscheinlich Server-Projekte, wo Singlethread-Performance wirklich gar keine Rolle spielt und es nur darum geht, viel Multithread-Performance so energie-effizient wie möglich zu erreichen. Dies dürfte auf nicht einmal einen kleinen Teil des Server-Markts zutreffen, denn Singlethread-Performance interessiert eigentlich nur die Workstation-Benutzer und ist für echte Server-Anwendungen zumeist eher drittrangig.

Stimmt nicht. In Datenbanken, Mainframe-Anwendungen, SAP etc ist Singlethread-Performance nach wie vor King. Bei SAP dann auch noch kombiniert mit maximalem RAM pro Socket.

Es gibt definitiv einen Markt für stark Multicore optimierte Server CPUs. Aber ich würde das eher als Marktnische sehen.

Der Großteil des Server Markts benötigt eine Optimale Balance aus Singlethreaded und Mutlithreaded. Ein Teil des Marktes benötigt brutal Single Threaded. Ein noch kleinerer Teil benötigt rein Multithreaded.

Für den Singlethreaded Marktbereich hat AMD bereits eine eigene Epyc Serie aufgesetzt, die F-Serie. Die besteht aus ganzen 4 Modellen, angefangen beim 8-Kerner Epyc 72F3 für 2500+ EUR. Warum 2500+ EUR für 8 Kerne wenn es das im Desktop schon für 200€ gibt? Weil dieser 8 kerner aus 8 Chiplets besteht, bei denen jeweils 7 Kerne deaktiviert, damit ein einzelner Kern die gesamte Masse des L3 Cache des gesamten Chiplet abbekommt sowie ganze 8 Memory Lanes für diese 8 Kerne. Wozu? Für massive Single Thread Performance in Datenbanken allgemein, SAP etc. Da klatscht man dann mitunter 4TB Ram in ein Dual Socket 16 Kerner System. Der Epyc 72F3 mit 8 Kernen kostet dann auch mehr als der reguläre 32 Kerner Epyc. Ist halt ein wichtiger Marktbereich für Server.

Ich halte also deine Aussage für grob falsch. Der Marktbereich für reine Single Threaded Performance im Server Segment ist größer als der Marktbereich für reine multithreaded Performance. Der größte Teil des Server Marktes wil dagegen die optimale Mischung aus beidem.

[Gast]

Werden die Zen4D Kerne dann auch SMT haben? Oder ist das vielleicht auch eine Stelle, an der man sparen kann? Intel hat das bei den E-Kernen in ADL ja eingespart.

[Platos]

Bei Zen 5 könnte man ja auch auf 12 Cores gehen. Da steigt die Chipfläche dann wieder auf 70-80mm2 (ausser die Zen 5 Cores wären wirklich sehr fett verglichen zu Zen 4).

Bei Zen 5 EPYC gibt es ja zudem das Gerücht zu 192/256 Cores. Könnte da auch passen:
- Max. 16 Chiplets --> Neues IOD
- 16*12 Zen 5 = 192 Cores --> Genoa Nachfolger
- 16*16 Zen 4D/5D = 256 Cores --> Bergamo Nachfolger

Alternative:
- Max. 12 Chiplets --> Gleiches IOD
- 16C Zen 5 Chiplets (3D-Stacked 64MB SRAM + IO in 5nm; Zen 5 Cores in 3nm oben drauf)
- 12*16 Zen 5 = 192 Cores
- 4*16 Zen 5 + 8*24 Zen4D/5D = 256 Cores

Im Desktop glaube ich nicht, dass es 16-Core Chiplets geben wird. Gerade weil die Leistung so grandios sein soll - die Fläche wird steigen, Leistung fliegt nicht vom Himmel. Und das Zen4D 16-Core Chiplets hinlegt, verdeutlicht das eig. nur noch umsomehr. Denn das bedeutet, dass die kleinen Kerne nicht in kleiner Anzahl kommen werden, ergo wird die Wahrscheinlich für mehr grosse Kerner dadurch nur noch kleiner.

Der Trend wird vermutlich immer mehr zu spezialisierten Chiplets gehen, wie man jetzt mit Zen4D sieht. Also gut möglich, dass es für Epic eigene Chiplets gibt (mit was auch immer, Zen5 oder vlt. auch "Zen5D" oder evtl. auch ne Hybridarchitektur mit Zen5 und Zen4D).

[OpenVMSwartoll]

[...]
Der Großteil des Server Markts benötigt eine Optimale Balance aus Singlethreaded und Mutlithreaded. Ein Teil des Marktes benötigt brutal Single Threaded. Ein noch kleinerer Teil benötigt rein Multithreaded.

Für den Singlethreaded Marktbereich hat AMD bereits eine eigene Epyc Serie aufgesetzt, die F-Serie. Die besteht aus ganzen 4 Modellen, angefangen beim 8-Kerner Epyc 72F3 für 2500+ EUR. Warum 2500+ EUR für 8 Kerne wenn es das im Desktop schon für 200€ gibt? Weil dieser 8 kerner aus 8 Chiplets besteht, bei denen jeweils 7 Kerne deaktiviert, damit ein einzelner Kern die gesamte Masse des L3 Cache des gesamten Chiplet abbekommt sowie ganze 8 Memory Lanes für diese 8 Kerne. Wozu? Für massive Single Thread Performance in Datenbanken allgemein, SAP etc. Da klatscht man dann mitunter 4TB Ram in ein Dual Socket 16 Kerner System.

[...]

Ich halte also deine Aussage für grob falsch. Der Marktbereich für reine Single Threaded Performance im Server Segment ist größer als der Marktbereich für reine multithreaded Performance. Der größte Teil des Server Marktes wil dagegen die optimale Mischung aus beidem.

Stimme Dir teilweise zu. Es gibt sie noch, die dedizierten DB-Server. Aber das ist meiner Erfahrung nach nicht die Majorität.

Aber gerade im Bereich SAP spielen Hardwarekosten nicht die alleinige Rolle. Darf's auch ein Pfund mehr sein?

Und gerade wenn es dann um das Replikat der DB geht, möchte man I/O-Performance und dem Kunden nicht sagen: Ja, Failover geht dann in 60 Minuten...

In vielen Projekten hat mir jedoch für die DBs auch ein vServer genügt. Ich denke da verstärkt an Projekte im Bereich Terminal Server mit Tausenden von Usern. Hier ist die Anzahl an Kernen dann spannender als die ST Performance.

[Lehdro]

Bergamo ist doch eindeutig gegen die hochkernigen ARM Server positioniert. Die bieten eh kaum Single Threaded Leistung und sind nur auf multithreading Durchsatz optimiert: Genau wie Zen4D.

Ich denke übrigens nicht das AMD big.little mit Zen 5 einführen wird. Das widerspricht dem Grundgedanken der da neulich in dem Video so herausgehoben wurde.

[WedgeAntilles]

Zum Glück ist bis Zen5 ja noch etwas hin - da können sich diverse Kandidaten hier noch überlegen wie sie aus ihrer "ich will aber nur richtige große Cores" Ecke wieder wegkommen :biggrin:

[Gast Ritis]

Denke auch, der Kerngedanke ist nicht BigLittle sonder zwei CPU-Core Typen.

CPUs mit Dense-Core Chiplets oder Power-Core Chiplets. Dazu dann I/O Chips für Server, HEDT oder Desktop in Kombination.

Daraus ergeben sich dann vielfältige Angebotsmöglichkeiten.

Das was AMDs Hallock im Interview dazu gesagt hatte wäre absolut stimmig dazu.

[Benutzername]

Bergamo ist doch eindeutig gegen die hochkernigen ARM Server positioniert. Die bieten eh kaum Single Threaded Leistung und sind nur auf multithreading Durchsatz optimiert: Genau wie Zen4D.


Guter Punkt. aber das meiste was Server machen ist ja Datenbank. Webserver ist ja quasi auch nur eine Datenbank, die bunte Webseiten liefert.


Ich denke übrigens nicht das AMD big.little mit Zen 5 einführen wird. Das widerspricht dem Grundgedanken der da neulich in dem Video so herausgehoben wurde.

Ja. Sieht für mich auch so aus, daß AMD auf sehr effiziente Kerne setzt statt big.little. Intel macht das imho eigetnlich auch nicht um Eenrgie zu sparen, sondern Waferfläche. Die P-Cores sind so riesig, da bleibt halt nciht viel Platz für halbwegs vernünftig zugeschnittene dies mit guter Ausbeute. Um trotzdem die vielen threads zu haben stopft intel halt mit den e-cores, die viel kleienr sind.

[Leonidas]

In vielen Projekten hat mir jedoch für die DBs auch ein vServer genügt. Ich denke da verstärkt an Projekte im Bereich Terminal Server mit Tausenden von Usern. Hier ist die Anzahl an Kernen dann spannender als die ST Performance.

So ähnlich habe ich es eingeschätzt. Viele Server werden heuer für Virtualisierung eingesetzt - von Aufgaben und Usern. Und da spielt ST keine Rolle mehr, jeder bekommt sowieso nur einen gewissen Leistungsteil.

Leider kann ich nicht exakt abschätzen, wo da wirklich die Stückzahlen stehen.

[Abe_]

So ähnlich habe ich es eingeschätzt. Viele Server werden heuer für Virtualisierung eingesetzt - von Aufgaben und Usern. Und da spielt ST keine Rolle mehr, jeder bekommt sowieso nur einen gewissen Leistungsteil.

Leider kann ich nicht exakt abschätzen, wo da wirklich die Stückzahlen stehen.

Nochmal: Wenn ST im Server keine Rolle mehr spielen würde, hätte AMD nicht als erste Sonderversion ihrer Epic Sparte die F-Serie aufgesetzt, die 100% auf ST optimiert ist. Die reine MT optimierte Variante setzen sie ja erst jetzt laut Gerüchten iwann in der Zukunft auf. Selbst die 64-core Epycs haben eine gute Mischung aus ST und MT Performance.

Am häufigsten im Serverbereich ist eine Mischung aus ST und MT Performance gefragt. Am zweithäufigsten ist ST Performance gefragt. Reine MT Performance (bei der ST egal ist) rangiert dann erst auf Platz 3.

Ich hatte die letzten 3 Jahre deutlich mehr Kunden, die mich nach 8 - 16 Core Server CPUs mit maximalem Takt für gute ST Leistung, als Kunden, die mich nach 32+ Cores mit niedrigerem Takt, fragten. Vorallem, wenn wir raus aus dem Datacenter gehen und uns z.B. MES Systeme in Fabriken anschauen (da steht dann ein einsames Rack neben der Fertigungsstraße mit Servern, Switch, USV alles drin in einem Schrank), kriege ich da oft die Anforderung, so viel Takt bzw ST Leistung wie möglich, Kerne nicht mehr als 16 nötig. Aber auch im Datacenter, wenn es z.B. um Datenbanken geht, ist ST King. Auch im HCI Bereich hab ich selten erlebt, dass man die maximale Kernzahl in einen Node klatscht, sondern eher mehr Nodes nimmt, mit niedrigerer Kernzahl pro CPU aber dafür etwas mehr Takt.

[Abe_]

...

Zu deinem Usernamen: Ich hatte dieses Jahr einen Kunden, der OpenVMS auf alten Itaniums am laufen hat, der hat da ein exotisches MES (naja, für mich exotisch, für Leute in der Nische vll üblich) für seine Maschinen drauf laufen (Name weiß ich gerade nicht). Gerade migriert der OpenVMS von IA64 auf die x86 kompatible neue Version. Bis zu diesem Kunden wusste ich nichtmal, dass es sowas wie OpenVMS gibt :D

[OpenVMSwartoll]

Zu deinem Usernamen: Ich hatte dieses Jahr einen Kunden, der OpenVMS auf alten Itaniums am laufen hat, der hat da ein exotisches MES (naja, für mich exotisch, für Leute in der Nische vll üblich) für seine Maschinen drauf laufen (Name weiß ich gerade nicht). Gerade migriert der OpenVMS von IA64 auf die x86 kompatible neue Version. Bis zu diesem Kunden wusste ich nichtmal, dass es sowas wie OpenVMS gibt :D

Ist auch etwas länger her. Ich hatte das Glück, 33 Alpha Server mitbetreuen zu dürfen, Schwerpunkt war Pathworks on OpenVMS. Ikea hatte es noch sehr lange im Einsatz.

Auf Hacking-Wettbewerben nahm man das OS früh aus dem Spiel, da es OOTB zu sicher war. Passwort 3mal falsch eingegeben und Du warst ein Intruder und es sprach mit Dir nicht mehr, bis der Admin aktiv wurde.

Die gute alte Zeit.

Aber zu Deinen Kunden: Der Gedanke herrscht noch vor. Aber in den beiden RZ, in denen ich aktiv war, waren dedizierte Server eher selten und wenn dann im Bereich SAP. Ansonsten galt es, viele verschiedene virtuelle Systeme bereitzustellen. In dem Umfeld waren die wenigen ST-lastigen Applikationen oftmals von kleinen Programmierschmieden gestrickt, die mit MT nicht umgehen konnten.

Auch die Produktionssysteme wanderten sukzessive in die Rechenzentren, da wir dort andere HA-Szenarien bieten konnten. Hardware gehört nicht in Produktionsumgebungen, sonst wird die sehr schnell sehr schmodderig. Und wenn Du Site 1 produktiv hast und Site 2 Replikas bereitstellt, kann Dir der Himmel auf den Kopf fallen, das Failover sorgt dafür, dass es weitergeht.

P.S.: Eines hatte ich bezüglich des Einsatzes von Servern in Produktionsumgebungen noch vergessen: Gabelstaplerfahrer. Der Kunde hatte einige Ausfälle durch "Fahrfehler". Nen Server zu recovern dauert aber länger, als kurz die Config eines Switches wieder einzuspielen. Die Downtimes konnten wir durch Zentralisierung massiv reduzieren.

[nairune]

Nochmal: Wenn ST im Server keine Rolle mehr spielen würde [...]

Hat er nicht geschrieben, sondern einen bestimmten use-case genannt. Dass der in deiner Blase nicht vorkommt, kann ja sein, aber wo wie viel insgesamt abgesetzt wird, haben wir wohl alle keinen Überblick.
In meinem Berufsumfeld wird virtualisiert so viel wie geht, da es zig Terminalserver, Applikationsserver mit paar Services oder (Intranet-)Websites usw. braucht, die im Prinzip alle nur Schmalspurleistung bekommen.
Daneben steht zusätzlich ein hochperformanter Schrank mit DB-Server und Storage, ja, aber die Masse ist es eben nicht.

Die Hersteller werden schon sehen, wo die Nachfrage da ist.

[Leonidas]

Ich hatte die letzten 3 Jahre deutlich mehr Kunden, die mich nach 8 - 16 Core Server CPUs mit maximalem Takt für gute ST Leistung, als Kunden, die mich nach 32+ Cores mit niedrigerem Takt, fragten. Vorallem, wenn wir raus aus dem Datacenter gehen und uns z.B. MES Systeme in Fabriken anschauen (da steht dann ein einsames Rack neben der Fertigungsstraße mit Servern, Switch, USV alles drin in einem Schrank), kriege ich da oft die Anforderung, so viel Takt bzw ST Leistung wie möglich, Kerne nicht mehr als 16 nötig. Aber auch im Datacenter, wenn es z.B. um Datenbanken geht, ist ST King. Auch im HCI Bereich hab ich selten erlebt, dass man die maximale Kernzahl in einen Node klatscht, sondern eher mehr Nodes nimmt, mit niedrigerer Kernzahl pro CPU aber dafür etwas mehr Takt.

Danke für den Einblick.

[Lehdro]

Denkt noch einen Schritt weiter: Zen4D wird deutlich effizienter sein als Zen4. Wenn ich also einen Supercomputer mit maximaler Leistungsdichte und Effizienz bauen wollen würde, was käme da wohl in Frage?

AMD deckt damit mit vergleichsweise wenig Entwicklungsressourcen zwei komplett unterschiedliche Zielsetzungen ab. Intel hat für Big und Little Cores jeweils komplett eigene Entwicklungsteams, zusätzlich zu den sich abwechselnden Teams, quasi mindestens 4. AMD kann nun mit zum Beispiel 3 Teams dasselbe Abdecken: Zwei sich überspringende Teams für die Hauptarchitektur und eins was die bereits fertiggestellte Architektur danach oder währendessen auf Density optimiert.

Das ist genau das was ich meine mit "Zen Grundgedanken": Maximale Erträge mit möglichst kleinem Einsatz. Das geht weit über Flächeneffizienz, Chiplets, Stacking, MCMs, Fabrics und sonstigen Innovationen hinaus, sondern fängt bei der Entwicklungsstruktur innerhalb AMDs erst einmal an. Wir wissen ja gar nicht was da noch so schlummert - wir kriegen von den Projekten ja erst etwas mit wenn die schon mehr als projektiert sind.

[WedgeAntilles]

Maximale Erträge mit möglichst kleinem Einsatz.
Klugscheiß: Es gibt keinen maximalen Ertrag bei minimalem Einsatz.
Es gibt entweder einen Ertrag X bei minimalem Einsatz.
Oder maximalen Ertrag bei Einsatz X.
Eines muss eine Konstante sein. Zwei Variablen funktionieren nicht. ;)

[Lehdro]

Klugscheiß: Es gibt keinen maximalen Ertrag bei minimalem Einsatz.
Es gibt entweder einen Ertrag X bei minimalem Einsatz.
Oder maximalen Ertrag bei Einsatz X.
Eines muss eine Konstante sein. Zwei Variablen funktionieren nicht. ;)
Lies noch einmal und klatsch dir dann auf die Stirn. Ich habe das Wort minimal nicht benutzt, aus genau diesen Gründen :cool:

AMD hat den möglichst kleinen Einsatz fix definiert: Entwicklungsbudget. Kann man auch undercutten, muss man aber nicht.

[iamthebear]

Woher liest du das mit der Effizienz heraus? Ich interpretiere das nur so, dass der Kern etwas kompakter ist, mit weniger Cache und im Desktop etwas niedrigere Taktraten hat. In Servern sind die Taktraten meistens sowieso schon niedrig.

Wobei "kompakt" hier auch immer relativ ist. Würde man Zen3 auf 5nm shrinken, so würde man auch 16 Kerne mit 32MB L3 auf einen gleich großen Compute Die bringen.

Jetzt mal reine Spekulation wie ich mir das in etwa vorstelle:
.) Zen3 bietet 100% Performance mit 8 Kernen pro Compute Die

Mit Zen4 gibt es dann 2 Alternativen je nachdem ob man mehr ST oder mehr MT Performance braucht:
.) Zen4 bringt 25% mehr IPC und weiterhin 8 Kerne pro Compute Die
.) Zen4D hat ca. dieselbe IPC aber 16 Kerne pro Compute Die

Beide Varianten kosten dann dasselbe.
Optional hat AMD noch die Möglichkeit zusätzlich VCache auf die Compute Dies zu packen bzw. einen 2. Compute Die zu verbauen.

.) Zen5 bringt noch mal 20-40% mehr IPC als Zen4 (60% mehr als Zen3) wieder mit 8 Kernen pro Compute Die
.) Als 2. Compute Die packt AMD dann noch einen Zen4D Compute Die als Little Cores dazu.

Vom Zeitplan her hört sich das besonder ambitioniert an und Intel wird vermutlich nichts liefern können, was von der ST Performance auch nur annähernd in die Nähe von Zen5 kommt. Allerdings sollte man dabei bedenken, dass Zen5 noch in einer relativ frühen Designphase ist und es sich hier um Performanceziele handelt. Ob das dann auch so umsetzbar ist wird man sehen.

Von der Energieeffizienz weiß ich nicht so Recht was ich davon halten soll. Wenn Zen4D dann weiterhin in 5nm gefertigt wird während Zen5 schon auf 3nm ist, so könnten die 16 "Little" Cores unter MT Last ganz schöne Heizkanonen werden.

Auch von der Modellpalette ist hier Intel etwas im Vorteil. Die können jeden Big Core theoretisch einzeln in einen Little Core Cluster umwandeln und so beliebig viele Kombinationen bauen. Bei AMD endet das dann in 1 IO Die und 2x80mm² Compute Dies also 5950X Nachfolger. Aber was macht man mit all den kleineren Modellen in den kleineren Preisklassen?

Nur 8 Zen5 Cores verbauen ist für Gaming in 2-3 Jahren vielleicht schon etwas zu wenig in der 400 Euro Preisklasse selbst wenn sie schnell sind.
Nur 16 Zen4D Cores verbauen (mit ca. 5950X Performance) ist Ende 2023 dann wahrscheinlich bei der ST Performance auch nicht mehr ausreichend
Compute Die mischen mit Zen5 + Zen4D ist auf Grund von 3nm vs. 5nm auch keine Alternative

Und für alles was außerhalb des Desktop+Gaming Bereichs liegt muss man sich wieder etwas neues einfallen lassen.

[Ahnungsloser Passant]

Lies noch einmal und klatsch dir dann auf die Stirn. Ich habe das Wort minimal nicht benutzt, aus genau diesen Gründen :cool:

Das hat er neulich auch mit mir gemacht. Er legt einem Worte in den Mund, die man gar nicht geschrieben hat und regt sich dann darüber auf. Feinste Politikertaktik. :biggrin:

[Gast]

Viele Kerne, hohe I/O, geringere Single Thread Performance, dafuer gibt es viele Anwaendungsfaelle. Z.b. Alles was mit Webservern und Microservices zu tun hat. Da braucht man auch kein AVX und diverse andere spezielle Befehlssaetze. Spezifische Anwendungen die Spezialhardware benoetigen, wie KI etc. die wuerde man eh entsprechend auslagern. Und auch wenn manche Datenbanken immer noch stark von der Singlethread Performance abhaengt, mehere Datenbanken in Containern = mehere Threads und schon waeren wir wieder bei den Cloud Systemen.

Mich wundert eh, das hier nicht schon lange was passiert ist. Und es waere auch sinnvoll diese Prozessoren auch fuer AM5 zu releasen. 32/64 C/T CPUs auf einer preiswerten Plattform da finden sich einige Hoster die so etwas dankend annehmen werden.

[WedgeAntilles]

Lies noch einmal und klatsch dir dann auf die Stirn. Ich habe das Wort minimal nicht benutzt, aus genau diesen Gründen :cool:

AMD hat den möglichst kleinen Einsatz fix definiert: Entwicklungsbudget. Kann man auch undercutten, muss man aber nicht.
Du schreibst "möglichst kleiner Einsatz"
Möglichst klein ist ein Synonym für minimal.
Möglichst klein = so klein wie möglich = minimal.

Ich lege keinem etwas in den Mund, ich kann Deutsch. ;) (Gleiches bei unserem Passanten, bei dem der Name offensichtlich Programm ist und sich auf die deutsche Sprache anwenden lässt^^)

War auch nicht bös gemeint Lehdro, ich benutze solche Redewendungen ja teilweise selber - obwohl es eben strenggenommen keinen Sinn macht.
Dennoch weiß jeder was gemeint ist.

Bei AMD ist das Entwicklungsbudget die gegebene Größe - und aus der holen sie dann den maximalen Ertrag raus. (Und das verdammt erfolgreich.)
Damit ist streng semantisch aber das Entwicklungsbudget eben nicht "möglichst klein" (denn "möglichst klein" impliziert eben ein so klein wie möglich - und das wäre ein Budget von 0) sondern eine gegebene Konstante.

Sollte aber wie gesagt gar nicht so weit ausarten, sorry :(

[Lehdro]

Sollte aber wie gesagt gar nicht so weit ausarten, sorry :(
Das ist jetzt echt schon Korinthenkackerei auf dem nächsten Level. :D
Woher liest du das mit der Effizienz heraus? Ich interpretiere das nur so, dass der Kern etwas kompakter ist, mit weniger Cache und im Desktop etwas niedrigere Taktraten hat. In Servern sind die Taktraten meistens sowieso schon niedrig.
Und mit Zen4D halt noch niedriger. Denk da eher an Mobile Taktraten anstatt Server.

Irgendwie musst du die verdoppelte Kernanzahl ja thermisch und leistungsaufnahmetechnisch unter Kontrolle kriegen im selben Node. Das heißt halt nicht 2-3W pro Kern wie es bei den heutigen EPYCs ist, sondern eher die 1-2W, wie sie bei den U Modellen im Mobile üblich sind. Da hilft natürlich auch die Zusammenstutzung des Caches u.ä.. +100% Kerne bei mal angenommenen -33% Taktraten/IPC Abzug: ~1.3x Performance bei denselben Verbrauch. Ist natürlich nur eine Milchmädchenrechnung, aber dieselbe gibt es ja schon so ähnlich beim 5950X vs 5900X bei selber PPT. Setzt halt eine sehr gute Kernskalierung zwingend voraus.

[WedgeAntilles]

Das ist jetzt echt schon Korinthenkackerei auf dem nächsten Level. :D

Ja, keine Frage, das ist es. :D
Wie gesagt, es war definitiv nicht bös gemeint.

Ich habe es in diesem Fall nur geschrieben, da man eben öfter hört (noch mal: auch ich sage / schreibe das manchmal!) - maximaler Ertrag,bei minimalem Einsatz.

Sorry, falls das falsch rüberkam! :)

[Zossel]

Klugscheiß: Es gibt keinen maximalen Ertrag bei minimalem Einsatz.
Es gibt entweder einen Ertrag X bei minimalem Einsatz.
Oder maximalen Ertrag bei Einsatz X.
Eines muss eine Konstante sein. Zwei Variablen funktionieren nicht. ;)

Es gibt mehrere Ertragsarten:

- Einmal Anwendungen die nicht gut über viele Threads skalieren.
- Einmal Anwendungen die gut über viele Threads skalieren.