Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsZen 4c „Bergamo“: AMDs 16-Kern-CCD benötigt nur 9,6 % mehr Fläche als 8 Kerne
Es ist nun Mal so für die meisten, die hier unterwegs sind, interessieren sich in erster Linie für den Desktop.
Ich sehe es wie Du, der High End Desktop der eine hohe Single Thread Performance will, ist kein Anwendungsgebiet für diese Kerne.
Man bekäme zwar beim zweiten CCD 16 Kerne hinzu, aber diese werden nur sehr niedrige Taktfrequenzen erreichen. Man müsste alle Kerne auslasten damit es in Summe vielleicht ein Plus gibt.
Wenn man nicht alle Kerne auslastet, fällt die CPU hinter einen Ryzen 7950XT zurück.
Beim Desktop hat AMD IMO kein Problem mit den Kernen, sondern mit den CCDs. Mit dem aktuellen Packaging kann AMD von Platz her nur 2 CCDs in den AM5 Sockel unterbringen und die CCDs haben 8 Kerne. Die CCDs mit mehr Kernen auszustatten ist wohl momentan noch nicht möglich. Diesen Schwachpunkt in der Skalierung nutzt Intel momentan aus.
Philste schrieb:
dass die 3.1GHz das vernünftige Maximum von ZEN4c sind.
Das sehe ich ähnlich. Beim Epyc 9754 ist der Turbo 3,2 GHz.
Wahrscheinlich werden wir mehr wissen sobald Siena vorgestellt wird.
Philste schrieb:
Bei Servern oder Laptop CPUs mit niedriger TDP (zusammengefasst CPUs, bei denen die normalen Kerne ihren Takt nicht ausspielen können) sollte das ganze aber eine gute und vor allem kostengünstige Lösung sein.
@Philste kommt in deiner Rechnung auch das SMT für den Bergamo Kern vor? Intels E-Kern bietet ja nunmal kein HT.
Dazu gehst du bei deiner Berechnung von einem linearen leistungsverlust aus beim Takt. Das kann für manch ein Programm passen für andere aber nicht was AVG kein linearer Leistungsverlust darstellen wird.
Sobald man ein Powerlimit hat, wie Notebooks, werden Base-Takte gering und die 'c'- Cores machen Sinn.
Auch beim Server sind 4 P-Cores mit 16 MB L3 plus 8 c-Cores an 16 MB L3, soweit beide Caches verbunden werden, sinnvoller als die 8er Cores mit 32 MB-L3. Die dürften in Zukunft fast alle 3D-Cache haben, bzw. AMD 16+32 bzw. 16+2×32 MB-L3 Cache bauen. Vielleicht auch 12er P-Cores mit dann 24 MB L3 bzw. 24+48 und 24 + 2x48 MB 3-fach gestapelt.
Ab 3nm unterstützt ja TSMC gemischte Transistor-Designs auf dem gleichen DIE bei noch geringeren Takt. Vielleicht verzichtet dann AMD beim Zen6c auf SMT und baut die Rechenunits einfach doppelt ein als Twin = entfernter Verwandter der Bulldozer Idee? Die ISA, die FPU und die Decoder blieben ja gleich, lediglich mehr Durchsatz trotz mässigen Takt ?!
Eigentlich hat das 'c' Konzept mehr Potential als big.little wo man mit reduziert IPC konfrontiert ist.
@RKCPU
Die Annahmen sind alle etwas zu wenig differenziert. Ob irgendwelche Big/Little Konzepte, "normale", "c" Kerne und welche Konfiguration etwaiger Caches sinnvoll ist, kommt immer enorm auf die Anwendung drauf an. Da Pauschal irgendwas Desktop, Notebook oder Servern zuzuschreiben ist kaum sinnvoll möglich.
Das Little Cores eine geringere IPC haben muss dabei nicht mal stören. Auf Ebene des OS/Anwendungen ist es schlussendlich egal, ob die Laufzeitdifferenzen zwischen verschiedenen Kernen aufgrund von Sheduling, I/O-Wait, IPC von Kernen, Takten von Kernen zustandekommen.
@RKCPU
Die Annahmen sind alle etwas zu wenig differenziert. Ob irgendwelche Big/Little Konzepte, "normale", "c" Kerne und welche Konfiguration etwaiger Caches sinnvoll ist, kommt immer enorm auf die Anwendung drauf an. Da Pauschal irgendwas Desktop, Notebook oder Servern zuzuschreiben ist kaum sinnvoll möglich.
Im Prinzip richtig, ABER AMD will zwei weitgehend identische Core vermarkten, die sich lediglich für den Nutzer in der max. Taktrate und in N5 beim Strombedarf unterscheiden.
Im Artikel haben wir den N3E (2025) beschrieben, also 3-2 Fin mit +33% Speed vs. N5, wie knapp 7 GHz Peak (der Transistoren).
Aber auch den kompaktere 2-1 Fin, der -30% Energie vs. N5 aufnimmt bei dann um 4 GHz.
Was nahe legt, dass AMD nur ein Basisdesign Zen4 hat und beim 'c' alle Speedoptimierungen per Baugruppen-Positionierung rausnimmt. Selbst der L2 blieb ja identisch 1MByte zum 'P'.
Bei mittleren Taktraten, wie 2-4 GHz, sind die beiden Cores ähnlich schnell, aber doppelt soviele davon auf dem DIE möglich.
@RKCPU
Das Little Cores eine geringere IPC haben muss dabei nicht mal stören. Auf Ebene des OS/Anwendungen ist es schlussendlich egal, ob die Laufzeitdifferenzen zwischen verschiedenen Kernen aufgrund von Sheduling, I/O-Wait, IPC von Kernen, Takten von Kernen zustandekommen.
So so der Anwendung ist es also egal.Gibt es denn tests wo man sowas wirklich differnzieren kann.Also ich weis das meine Anwendung von mehr CPU Takt profitiert und nun?
Ich finde man kann viel spekulieren und es macht auch richtig Spaß.
Aber man sollte auch schauen was bekannt ist, und das einbeziehen.
Die Zen Kerne skalieren gut. AMD kann damit einen weiten Bereich abdecken. Aber Zen 4 Kerne sind im Vergleich mit Intel, Apple und Arm (High end) relativ schlanke Kerne. AMD hat bereits angekündigt, dass Zen 5 ein "wider issue" bekommt. D. h. die Zen 5 Kerne werden fetter.
E-Kerne opfern Frequenz um damit teute Die-Fläche zu sparen und den Verbrauch zu senken. D. h. diese Kerne erweitern das Performance-Spektrum das Zen 4 abdecken wird nach unten.
Durch das Aufgeben der hohen Frequenzen sind die E-Kerne IMO in der maximalen Performance nach oben scharf begrenzt. Deshalb dürfte die halbierte Speicherbandbreite keine Rolle spielen. Deshalb hat AMD IMO auch den L3-Cache halbiert. 2 GByte L3-Cache je Kern sollte IMO für den Performance-Bereich ausreichen, in dem die E-Kerne operieren. Also bei 128 E-Kernen ein Basistakt von 2 Ghz und Turbo von 3,2 GHz.
Das ist der eigenliche Clou. Denn die Genoa-Server-CPU mit 96 Kernen hat denselben Basistakt. Damit bietet Bergamo bei voller Auslastung ca. 33% mehr Multi Core Performance als die Spitzen-SKUs von Genoa. Für Lasten, die durch die Speicherbandbreite begrenzt sind, verwendet man CPUs mit weniger Kernen.
Einen Aspekt sollte man nicht außer Acht lassen, weil die E-Kerne eine niedrigere maximale Frequenz haben, können sie Leistungsspitzen nicht mit derselben Dynamik abfangen wie P-Kerne. Leistungsspitzen, wie sie z. B. Anwender auslösen.
Bei der maximalen Kernzahl der Server schlägt die Erhöhung der Kernanzahl durch die E-Cores voll auf die Multicore-Performance durch. Bei SKUs mit weniger Kernen und höheren Frequenzen fallen die E-Kerne zurück. Ab welchen Punkt die Multicore-Performance unter die der P-Cores fällt kommt darauf an, wo genau der Sweetspot liegt.
Für Szenarien bei denen die begrenzte Single Thread Performance nicht stört, lassen sich preiswerte und sparsame Server realisieren. Nach allem was bekannt ist, sieht AMD hier bei SP5 kein Potential. Das wird bei SP6 (Siena) wohl anders aussehen.
RKCPU schrieb:
Sobald man ein Powerlimit hat, wie Notebooks, werden Base-Takte gering und die 'c'- Cores machen Sinn.
Das Powerlimit beim Notebook ist variabel. D. h. für kurze Zeit kann man weit mehr abrufen als was die Angabe der TDP suggeriert. Hier werden die E-Kerne nicht so skalieren können wie die P-Kerne.
Ein Notebook auch in der Klasse unter 15 W wird P-Kerne benötigen. Hier bietet sich ein Hybriddesign an, wie es Mark Papermaster angekündigt hat. Es geistern Infos über Phoenix 2 herum der ein Hybriddesign sein soll (2P + 4E).
RKCPU schrieb:
Auch beim Server sind 4 P-Cores mit 16 MB L3 plus 8 c-Cores an 16 MB L3, soweit beide Caches verbunden werden, sinnvoller als die 8er Cores mit 32 MB-L3.
Das ist so pauschal geschrieben falsch. Es wird wahrscheinlich Anwendungen geben bei denen das interessant sein könnte, aber ganz sicher nicht generell.
Hybriddesigns halte ich für eine sehr interessante Option bei den monolithischen Designs. Ist ein Hybrid-CCD wirklich sinnvoll? Falls Hybriddesigns mit CCDs gewünscht sind, kann AMD E- und P-CCDs kombinieren. Das ist viel flexibler und kostet weniger als 3 verschiedene CCDs zu entwickeln.
RKCPU schrieb:
Die dürften in Zukunft fast alle 3D-Cache haben, bzw. AMD 16+32 bzw. 16+2×32 MB-L3 Cache bauen. Vielleicht auch 12er P-Cores mit dann 24 MB L3 bzw. 24+48 und 24 + 2x48 MB 3-fach gestapelt.
Randbemerkung 1: Es gibt die klare Aussage von Mike Clark, dass AMD in absehbarer Zeit keine CPUs macht, die den L3-Cache komplett auf ein anderes Die schiebt. Das ist für den Desktop zu teuer. Und dies wird IMO auch für bei den Servern in preis-sensitiven Bereichen und bei Embedded der Fall sein.
Randbemerkung 2: Das Auflegen eines Rennsattels macht aus einem Ackergaul kein Rennpferd. Die Performance der E-Kerne ist durch die Frequenz begrenzt. Mehr L3-Cache bereitzustellen bringt grob betrachtet nur dann etwas, wenn die E-Kerne wegen fehlendem L3-Cache ihre Frequenz nicht erreichen können. Ist es wirklich sinnvoll bei Szenarien, die von mehr L3-Cache profitieren, E-Kerne einzusetzen?
Für die P-Kerne bringt der L3-Cache eine zusätzliche Option. Die hat für jedes CCD höhere Kosten durch die TSVs und die zusätzliche Cachelogik auf dem Die. Das ist bei den P-Kernen zu verschmerzen. bei den CCDs die ein Cache-Chiplet erhalten, kommen die Kosten für das Chiplet und die Montagekosten dazu. Ganz billig ist der Spaß nicht, den sich AMD da leistet.
Bei den E-Kernen, die ungefähr die halbe Fläche haben, schmerzt der höhere Flächenverbrauch schon deutlich mehr. Es würde mich sehr wundern wenn in den nächsten 1 oder 2 Generationen 3DV-Cache für die E-Kerne kommt.
RKCPU schrieb:
Ab 3nm unterstützt ja TSMC gemischte Transistor-Designs auf dem gleichen DIE bei noch geringeren Takt.
big.little wurde von Arm eingeführt. Intel hat es nur aufgegriffen, um die hohe Anzahl der Cores bei AMD zu kontern. AFAIK hatte Arm auch schon CPUs bei denen derselbe Kern mit unterschiedlichen Frequenzen verwendet wurde.
Dieselbe IPC für E- und P-Kern kann auch nur ein Nebeneffekt sein, der als Feature verkauft wird.
Es ist am schnellsten und billigsten den Kern unverändert zu belassen und nur nochmal neu für einen anderen Frequenzbereich zu designen. Das bindet es praktisch keine Resourcen bei den CPU-Architektur Teams. Hier waren nur die Chipdesigner gefordert.
Dies kann bei Zen 5 und Zen 6, so bleiben muss es aber nicht. Warten wir es ab.
Piktogramm schrieb:
Das Little Cores eine geringere IPC haben muss dabei nicht mal stören. Auf Ebene des OS/Anwendungen ist es schlussendlich egal, ob die Laufzeitdifferenzen zwischen verschiedenen Kernen aufgrund von Sheduling, I/O-Wait, IPC von Kernen, Takten von Kernen zustandekommen.
Das sehe ich genau so. Wichtig ist dass die ISA kompatibel ist.
RKCPU schrieb:
Im Prinzip richtig, ABER AMD will zwei weitgehend identische Core vermarkten, die sich lediglich für den Nutzer in der max. Taktrate und in N5 beim Strombedarf unterscheiden.
Was Zen 4c ist, wissen wir. Ich erwarte keine relevanten Überraschungen.
Ich welchen Frequenzbereichen Zen 4c agiert wissen wir nur für Bergamo.
Wie es bei CPUs mit weniger Kernen aussieht, darüber können wir nur spekulieren.
RKCPU schrieb:
Im Artikel haben wir den N3E (2025) beschrieben, also 3-2 Fin mit +33% Speed vs. N5, wie knapp 7 GHz Peak (der Transistoren).
Die Kurve war nur drin weil Dylan Patel zeigen wollte, dass man dasselbe Design für unterschiedliche Frequenzen entwerfen kann und dabei unterschiedlich viel Fläche benötigt.
Der Witz an FinFlex ist, es gibt den die Designer in den Blöcken mehr Designopionen: Denn sie können in einem Block verschiedene Transistoren mischen.
Der Block wird AFAIK mit 2-2 Transistoren ausgeführt
kritische Pfade werden mit 3-2 Fin Transistoren ausgeführt damit höhere Frequenzen möglich sind
für unkritische bereiche werden 2-1 Transistoren verwendet
Was die Designer daraus machen werden wir sehen.
Was AMD bei Zen 5 im Detail macht ist vollkommen unklar.
Das gilt für die P- und erst recht für die E-Kerne.
RKCPU schrieb:
Aber auch den kompaktere 2-1 Fin, der -30% Energie vs. N5 aufnimmt bei dann um 4 GHz.
Wo siehst Du in dem Diagramm absolute Angaben zur Frequenz?
Ergänzung ()
latiose88 schrieb:
So so der Anwendung ist es also egal.Gibt es denn tests wo man sowas wirklich differnzieren kann.Also ich weis das meine Anwendung von mehr CPU Takt profitiert und nun?
Im Prinzip richtig, ABER AMD will zwei weitgehend identische Core vermarkten, die sich lediglich für den Nutzer in der max. Taktrate und in N5 beim Strombedarf unterscheiden.
Im Artikel haben wir den N3E (2025) beschrieben, also 3-2 Fin mit +33% Speed vs. N5, wie knapp 7 GHz Peak (der Transistoren).
Aber auch den kompaktere 2-1 Fin, der -30% Energie vs. N5 aufnimmt bei dann um 4 GHz.
Was nahe legt, dass AMD nur ein Basisdesign Zen4 hat und beim 'c' alle Speedoptimierungen per Baugruppen-Positionierung rausnimmt. Selbst der L2 blieb ja identisch 1MByte zum 'P'.
Bei mittleren Taktraten, wie 2-4 GHz, sind die beiden Cores ähnlich schnell, aber doppelt soviele davon auf dem DIE möglich.
Naja, halbierter L3 je Cache, und mehr Cores je IF-Link sowie mehr Cores die sich die Speicherbandbreite teilen müssen. Das Gesamtpaket hat schon andere Schwächen/Stärken im Vergleich zu Zen4 ohne c
Und das AMD auf HD-Bibliotheken setzt, anstatt auf Performance steht im Artikel, dass ist keine Überraschung. Und komplett nehmen sie die Optimierungen bestimmt nicht raus, da müssten sie viel deutlicher ran und die Länge der Pipelines anpassen (und damit größere Teile vom u.a FrontEnd).
latiose88 schrieb:
So so der Anwendung ist es also egal.Gibt es denn tests wo man sowas wirklich differnzieren kann.Also ich weis das meine Anwendung von mehr CPU Takt profitiert und nun?
Am Thema vorbei, ich schrieb explizit von Laufzeitdifferenzen zwischen verschiedenen Cores. Was im Zweifelsfall ein Problem beim Sync verschiedener Threads/Workers ist.
Wie dann die absolute Laufzeitverhalten skaliert, ist eine andere Frage. Wenn da wenig von IPC also der Architektur aber enorm vom Takt profitiert wird, löst die Software entweder ein spezielles Problem, oder sollte mal überarbeitet werden.
Am Thema vorbei, ich schrieb explizit von Laufzeitdifferenzen zwischen verschiedenen Cores. Was im Zweifelsfall ein Problem beim Sync verschiedener Threads/Workers ist.
Wie dann die absolute Laufzeitverhalten skaliert, ist eine andere Frage. Wenn da wenig von IPC also der Architektur aber enorm vom Takt profitiert wird, löst die Software entweder ein spezielles Problem, oder sollte mal überarbeitet werden.
Ja gut das war aber nicht immer so gewesen.Zwischen Zen 2 und Zen 3 gab es noch iPC Steigerungen weil ich es mit dem selben CPU Takt gemessen hatte.Das habe ich zwar nicht direkt mit Zen 4 gemacht aber alleine schon wie Zen 4 so reagiert mit weniger Stromverbrauch und dem Einbruch,war das schon eindeutig.Alleine das die bei Zen 4 mit 5 % weniger Leistung 60 Watt eingesparrt und damit 300 mhz weniger Allcore Takt ist wohl eindeutig.
Ich könnte mir aber noch den härte Test mit nur 3,8 - 4 ghz auch noch vorstellen.Dann müsste jedoch dafür in gegenzug der Kern sehr breit werden,sehr viel mehr als es mit Zen 4 der fall gewesen war.Dann dürfte da auch was rüber kommen.Erwarte also nicht sehr viel dabei.Darum ist mir das sehr wohl aufgefallen.Die IPC steigerungen von 13 % zwischen Zen 2 und Zen 3 bei der IPC ist mir nicht entgangen.Und die IPC steigerung zwischen Zen 1 und Zen 2 war sehr ernorm gewesen.Da schlug der Hammer richtig ein.
Wo mir die höchste IPC steigerung aufgefallen war ,ist bei den 8 Kerner.Noch schlägt der neue 8 Kerner gerade so nur den Ryzen 9 3950x bei der Multicore leistung.Gegen den 5950x ist jedoch der 7700X chancenlos.
Ob mir also der neue bergamo mit 32 Kernen aber dafür wenig L3 Cache und so wirklich an Leistung rein haut,das wird es sich zeigen müssen.
Die Threadripper 5965wx war es jedenfalls noch nicht der überflieger bei mir gewesen.
Jedenfalls war der extra L3 Cache kein gewinn,aber zwischen 16 und 32 MB L3 Cache gab es sehr wohl nen Leistungsunterschied.Das sind so um die 10 % an Leistungsverluste.ALso die extra Kerne machen ebenso 10 % mehr Leistung.Also können die extra Kerne nur den Mangel des weniger an L3 Cache bei mir ausgleichen.
Ich bin halt leider nicht die Zielgruppe dafür,aber naja ich warte dann doch lieber auf Zen 5,der soll ja sehr viel breiter werden und die EInheiten größer werden wo auch ich endlich mal wieder Profitiere.Das wird mein heilsbringer sein.CPU Takt ist am Ende,also heißt es wohl auf andere Wege mehr Leistung zu bekommen.
nein ^^ also nicht im eigentlichen sinne SRAM ist Flüchtiger Speicher der um überhaupt zu funktionieren spannung halten muss.
so sieht das aus:
leider ist das sehr platzintensiv weshalb die caches recht überschaubar sind. auch ist die schaltung selbst kaum zu schrinken, weshalb cache erhöhungen nicht selten mit massiven die-größensteigerugnen einhergehen
@Philste Ja deine Betrachtung - sollte sie stimmen wäre natürlich erst mal nicht so toll. Aber entscheidend wäre - was braucht der "E-Kern" an elektrischer Leistung. Ich spinn mal rum und sag der braucht nur 20% vom "P-Core"... Dann wäre das sehr wohl ein ernst zu nehmender E-Core.. Er würde für 80-90% der Zeit für Otto Normalverbraucher mehr als ausreichend sein [Office Browsen YT alte Games] - das würde die gemittelte Leistungsaufnahme extrem nach unten drücken...
Die Angaben zum Taktverlust passen nur für die Single-Core-Beobachtung, und da nutzt man die beiden Kerntypen ja nicht zusammen. Daher:
Bei Intel sind es dann 5,5 GHz zu 4,3 GHz, also -22%
Bei AMD laufen die Kerne im All-Core-Betrieb bei etwa 5,1 GHz. Nimmt man bei AMD die genannten 3,1 GHz, dann sind es -39%.
Ich gehe nicht davon aus, dass die 3,1 GHz das Maximum sind. Es kann sein, dass das der Sweet Spot ist (wegen "vernünftiges Maximum"), aber wenn wir hier ausloten, was möglich ist, dann gehen ja beide Hersteller in ihren Produkten über diesen Punkt der Vernunft beim Desktop hinaus.
Der Leistungsgewinn durch E-Kerne ist auch jetzt schon geringer als man erst einmal meint.
Der Multi-Core-Zuwachs eines 12900K durch die E-Kerne liegt hier bei CB bei +35% im CB R23. Statt der acht E-Cores hätte man auch zwei weitere P-Cores verbauen können, für vermutlich +25%. Demgegenüber liegt der Zuwachs nur noch bei +8%.
Bei Raptor Lake kann das besser aussehen. Verdoppelt man die +35% auf +70%, sind das gegenüber +50% bei vier zusätzlichen P-Cores nun +13%.
Es geht hier auch nur darum, dass man die "+39%" nicht alleine betrachten sollte, sondern jeweils in Relation zur Option mit mehr P-Cores entsprechend der durch die E-Cores belegten Fläche. Der Zugewinn ist dann niedriger.
Der Vergleich der Flächen ergibt für mich nur einen Sinn unter Betrachtung der Gesamtkosten und im Hinblick darauf, ob das finale Produkt passt. Technische Brillanz hin und her, am Ende muss ein Produkt für den Hersteller machbar und wirtschaftlich tragbar sein.
Dann mal eine Betrachtung mit dem 7950X:
Man ersetzt ein CCD durch Zen4c mit -39% Takt, dafür aber doppelt so vielen Kernen bei annähernd gleicher IPC. Das ergibt dann gegenüber dem auf 100% normierten 7950X nun 50% auf dem regulären Die und 50%*2*0,61=61% auf dem anderen. Zusammen hat man dann 111% Performance. Diese +11% liegen ziemlich genau zwischen den Werten für Alder Lake und Raptor Lake.
Das ist natürlich eine etwas simple Rechnung, aber zumindest für Renderbenchmarks kommt man damit oft unbeschadet durch.
Ich gehe davon aus, dass man auch die Zen4c-CCDs etwas oberhalb ihres Sweet Spots betreiben kann. Die 3,1 GHz ergeben sich ja nicht nur aus dem eng gepackten CCD, sondern auch aus der Tatsache, dass man bei 360-400 Watt für den Sockel mit um die 3W pro Kern auskommen muss, wo es bei Genoa 4W sind (wobei man eigentlich vorher jeweils das IOD abziehen müsste, aber der Unterschied bleibt relevant). Beim Desktop sind die Limits deutlich höher. Geht man von den 3,1 GHz auf 3,4 GHz, so wären es schon +17%.
Die Gesamtfläche Silizium steigt für den gesamten Prozessor nur um etwa +2,5%. Solange die Kombi mit dem Zen4c-CCD auf AM5 passt, ergäbe es also auch bei vergleichsweise niedrigem Leistungszuwachs schon einen Sinn.
Und man darf nicht vergessen, dass man bei Zen4c nicht nur SMT, sondern auch die AVX-512-Unterstützung behält. Das ist ja gerade bei Intel derzeit ein unschöner Makel, und sie verhindern die Nutzung der bei den P-Cores eigentlich vorhandenen Einheiten nach Abschaltung der E-Cores inzwischen.
In meiner Betrachtung kommt Zen 4c also etwas besser weg, aber auch ich bin da durchaus kritisch. Es steht und fällt auch bei mir damit, dass man die kompakten CCDs letztendlich mit mehr als 3,1 GHz betreiben kann. Zehn Prozent mehr wären gut, mehr dann großartig.
@Nixdorf die 3.1 sind aber schon höchstwahrscheinlich schon der Single Core Boost. Das jetzt mit dem Allcore Boost von Raphael zu vergleichen ist auch wieder seltsam. Zumal der 7700X hier bei CB sogar im Allcore mit mehr als 5.4GHz takten kann. Ich denke wirklich, dass die ZEN4c Kerne oberhalb dieser 3.1GHz komplett explodieren. Egal wie es ist, wir kommen beide zu einem ähnlichen Ergebnis: Wirklich sinnvoll erscheint die Lösung im Mainstream Desktop nicht.
Wenn die Gerüchte stimmen und Phoenix 2 ein 2+4 Design nutzt, werden wir hoffentlich noch dieses Jahr einen schönen Vergleich sehen können. 7640U mit 6 ZEN4 gegen 7540U mit 2 ZEN4 und 4 ZEN4c wird interessant.
Auch Intels E-Core Server CPU wird interessant, denn auch die werden im Server ja dadurch, dass die P-Cores ihren Takt nicht ausfahren können, stärker.
Die Tabelle hab ich gesehen. Die sagt mir aber nicht, ob das ein technisches Limit oder ein durch Marktsegmentierung bedingtes ist. Daher bin ich da ebenso gespannt, die Implementierung überhaupt erstmal außerhalb eines Servers zu sehen.
In einem Interview mit Techpowerup wurde wurde David McAfee gefragt ob AMD Hybrid Architekturen auf den Desktop bringt.
In typischer AMD Manier hat er nicht ja oder nein gesagt, sondern wie folgt geantwortet:
Handelt es sich um eine Umgebung mit eingeschränktem Stromverbrauch wie bei einem Notebook oder um eine Umgebung ohne Energiebeschränkung wie bei einem Desktop. Ich denke, dass diese Faktoren in erster Linie bestimmen werden, wie wir die verschiedenen Kerntypen in unserer Roadmap in Zukunft einsetzen werden, und ich denke, dass die Vorteile, die Sie beim Cloud-optimierten C-Core sehen, über den wir in der Vergangenheit gesprochen haben, etwas ist, das einen signifikanten Vorteil bei der Leistung pro Watt hat und besser in eine strombeschränkte Umgebung passt. Ob sich das auch auf einen Desktop-Prozessor übertragen lässt, bei dem der Stromverbrauch nicht eingeschränkt ist, ist meines Erachtens schwieriger zu argumentieren.
Auf die Frage ob es für Notebooks kommt hat er geantwortet:
Ich denke, dass Laptops eine weitaus praktischere Anwendung sind, bei der sich dies sehr viel schneller durchsetzen könnte.
Meine Interpretation:
Es ist bekannt, dass AMD Phoenix 2 entwickelt hat der 2 P und 4 E Kerne bringen soll. Natürlich kommt Phoenix 2 zuerst in Notebooks.
