AMD - Zen 5 (3/4 nm, 2024) [Archiv] - Seite 7

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - Zen 5 (3/4 nm, 2024)

basix

2024-01-28, 10:17:54

Muss sich für den Zen5D am V-Cache (-Chiplet) etwas unbedingt verbessern?

Nein. Da Zen 5 noch in N4/N5 gefertigt wird, ist das bestehende V-Cache Chiplet genau richtig.

Bei Zen 6 könnte das dann anders aussehen. Aber bei Zen 5 erwarte ich keine wesentlichen Änderungen. Im Idealfall verwenden sie sogar die identischen V-Cache Chiplets wie bei Zen 4.

Zossel

2024-01-28, 10:30:47

Es werden spezielle cache libraries für den 3D V-Cache benutzt, die auf cache cell density optimiert sind.

Ist das offiziell oder nur Internetgelaber?
Und nutzt man nicht sowieso die SRAM-Zellen auch ohne 3D die zum Einsatzszenario passen?

nordic_pegasus

2024-01-28, 10:51:53

wird es eigentlich einen neuen Chipsatz geben (eventuell mit PCIe gen5 Anbindung) oder nur Refresh-Boards mit Promontory21 für Zen5?

basix

2024-01-28, 11:05:16

Erwarten tue ich keinen neuen Chipsatz. Wünschen tue ich es mir aber: PCIe 5.0 Downlink CPU -> Chipsatz und USB 4.0 integriert

Ist das offiziell oder nur Internetgelaber?
Und nutzt man nicht sowieso die SRAM-Zellen auch ohne 3D die zum Einsatzszenario passen?

AMD nutzt einfach die Möglichkeiten von N7 aus, optimiert auf ein SRAM-Array (HD-Cells, Routing, Metal-Stack).
https://www.slideshare.net/AMD/3d-vcache

Bei "normalen" mixed IP Chiplets wie dem CCD geht das nicht. Aber extra optimierte HD SRAM Cells sind das afaik nicht. Das gesamte V-Cache Chiplet ist aber schon entsprechend auf ein fettes SRAM-Array hin optimiert, das ist sicher klar.
Bei Zen 4 hat man noch an den Standard-Cells rumgefummelt und optimiert (N5HPC). Das steht bei den ISSCC 2023 Folien zu Zen 4 so drin.
Bei den V-Cache Folien sehe ich nirgends solche Angaben.

Edit:
Noch eine etwas wilde Theorie meinerseits.
Mike Clark hat das Zen 5 Design mal als "very cool" und "can't wait to buy that thing" bezeichnet.
Mike Clark war einer der Väter der Bulldozer Architektur. Nun die etwas wilde Theorie:
- Zen 5 macht etwas "Bulldozer CMT" mässiges
- CMT: Pro Core werden zwei dedizierte Integer Pipes und eine shared FPU verbaut
- Das erhöht den Durchsatz bei Integer Code deutlich (sagen wir mal >50% verglichen mit 20-30% bei SMT, bei Bulldozer hat man 80% für CMT angegeben)
- Die fette (single cycle?) AVX512 Einheit fällt dadurch weniger stark ins Gewicht (Fläche) -> "normaler Code" läuft deutlich schneller und bei AVX512 ist man eh Power limitiert
- Der auf 48kiB vergrösserte L1D Cache könnte allenfalls in diese Richtung deuten (bei Bulldozer wurden pro Integer Pipe 16kiB L1D verbaut)
- Abwandlung von CMT: L1D ist shared für den ganzen Core und nicht gesplitted wie bei Bulldozer. Das vermeidet Limitationen bei Single Thread.
- Abwandlung von CMT: Das verbreiterte 6-Wide Design ist "dynamisch" CMT fähig. Ein Thread kann alle 6 Pipes nutzen -> Zen 5 CMT ist also ein Mix aus SMT und Bulldozer CMT. Zen 5 hat mehr Blöcke, welche nicht zwischen den zwei Threads shared sind. Wie genau das aussehen kann ist mir noch nicht ganz klar (also welche Einheiten das betreffen würde).

https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2022/12/bulldozer.drawio.png?ssl=1
https://www.pcgameshardware.de/CPU-CPU-154106/Specials/AMD-Zen-CPU-Release-Sockel-1158359/galerie/2625548/?fullsize

https://images.anandtech.com/doci/17585/SoC_07.png

Complicated

2024-01-28, 14:02:13

Mal in Richtung CMT mit Zen5/Zen5c Mix gedacht? Das ganze auf balancing zwischen Performamce (Takt) und Stromsparen (Mulrithreading) optimiert. Ob da Potenzial liegt, das sich lohnt anzuzapfen?

Badesalz

2024-01-28, 14:07:48

Eher nicht. Macht beim Epyc imho keinen Sinn und beim Ryzen ggf. schon, aber das ist viel mehr Aufwand als es mit CMT wäre.

Der_Korken

2024-01-28, 14:33:28

Worin genau soll der Vorteil von CMT liegen? Für mich war eines der Bulldozer-Probleme, dass AMD viel zu stark auf Multithreading gesetzt hat und die ST-Performance der Architektur ziemliche Grütze war, teilweise nichtmal schneller als die Phenoms. Der Benefit war dafür, dass man sich pro Modul das zweite Frontend und die zweite FPU gespart hat. Ersteres hat man mit Steamroller sogar teilweise wieder rückgängig gemacht, weil die Performance sonst zu schlecht war. Die FPU-Einsparung spart natürlich Fläche und somit Kosten ein, aber im Prinzip hat AMD schon ein Werkzeug, was genau diesen Benefit bringt: Die C-Kerne.

Läge die Nachfrage bei mehr MT-Durchsatz pro Fläche (bzw. pro Preis), könnte AMD doch bereits heute überall Modelle mit C-Kernen bringen. Die leisten ca. 40% mehr auf der gleichen Fläche (C-Kern = 50% Fläche, aber ~70% Durchsatz). Offensichtlich will sowas aber kaum jemand haben, außer für große Hyperscaling-Kisten, in denen Bergamo verbaut wird. Kein Desktop-User würde einen 7700X gegen einen 16-Kerner tauschen, der dann aber nur maximal 4 Ghz in der Spitze schafft. ST-Leistung regelt nun mal.

Ich würde daher sagen, dass ein CMT-Design keine Vorteile gegenüber die Kombination aus normalen Kernen und C-Kernen hätte.

basix

2024-01-28, 15:52:08

mboeller

2024-01-28, 16:15:50

Noch eine etwas wilde Theorie meinerseits.

beziehst du dich auf das Twitter-Posting von Kepler und auf diesen Beitrag von gdansk im anandtech-forum?
https://forums.anandtech.com/threads/zen-5-discussion-epyc-turin-and-strix-point-granite-ridge-ryzen-8000.2607350/page-249#post-41144855

basix

2024-01-28, 16:39:09

Ich hatte was im Hinterkopf, dass irgendein Twitterer was mit CMT fallen gelassen hat. Ja. Wann und wo wusste ich aber nicht mehr. gdansk markiert seinen Post aber klar als Joke ;)

Mir geht es gar nicht um das explizite CMT von Bulldozer an sich, sondern um eine verbesserte MT Skalierung. Ob das ein SMT on Steroids oder ein Zwischendings aus SMT und CMT ist, ist mir mal wurscht.

Zossel

2024-01-28, 17:12:54

iamthebear

2024-01-28, 17:13:34

Läge die Nachfrage bei mehr MT-Durchsatz pro Fläche (bzw. pro Preis), könnte AMD doch bereits heute überall Modelle mit C-Kernen bringen. Die leisten ca. 40% mehr auf der gleichen Fläche (C-Kern = 50% Fläche, aber ~70% Durchsatz). Offensichtlich will sowas aber kaum jemand haben, außer für große Hyperscaling-Kisten, in denen Bergamo verbaut wird. Kein Desktop-User würde einen 7700X gegen einen 16-Kerner tauschen, der dann aber nur maximal 4 Ghz in der Spitze schafft. ST-Leistung regelt nun mal.

Ich bin von Zen4c nicht woirklich begeistert:
a) Laut AMD sind es 35% weniger Fläche der Kerne d.h. 54% mehr Kerne pro Fläche.
b) Es gab voir längerer Zeit mal ein Review zu Zen4c. Ergebnis war, dass Zen4 ca. 35% höhere Taktraten bei gleicher Spannung scbafft. Nicht Spitzentaktrate, sondern quer über die gesamte Kurve d.h. Zen4c ist auch nicht effizienter.

Im Endeffekt bedeutet dies:
.) 1.14x höhere MT Performanbce bei gleicher Fläche bei perfekt skalierenden Anwendungen
.) 1.35x niedrigere ST Performance

Noch eine etwas wilde Theorie meinerseits.
Mike Clark hat das Zen 5 Design mal als "very cool" und "can't wait to buy that thing" bezeichnet.
Mike Clark war einer der Väter der Bulldozer Architektur. Nun die etwas wilde Theorie:
- Zen 5 macht etwas "Bulldozer CMT" mässiges
- CMT: Pro Core werden zwei dedizierte Integer Pipes und eine shared FPU verbaut
- Das erhöht den Durchsatz bei Integer Code deutlich (sagen wir mal >50% verglichen mit 20-30% bei SMT, bei Bulldozer hat man 80% für CMT angegeben)
- Die fette (single cycle?) AVX512 Einheit fällt dadurch weniger stark ins Gewicht (Fläche) -> "normaler Code" läuft deutlich schneller und bei AVX512 ist man eh Power limitiert
- Der auf 48kiB vergrösserte L1D Cache könnte allenfalls in diese Richtung deuten (bei Bulldozer wurden pro Integer Pipe 16kiB L1D verbaut)
- Abwandlung von CMT: L1D ist shared für den ganzen Core und nicht gesplitted wie bei Bulldozer. Das vermeidet Limitationen bei Single Thread.
- Abwandlung von CMT: Das verbreiterte 6-Wide Design ist "dynamisch" CMT fähig. Ein Thread kann alle 6 Pipes nutzen -> Zen 5 CMT ist also ein Mix aus SMT und Bulldozer CMT. Zen 5 hat mehr Blöcke, welche nicht zwischen den zwei Threads shared sind. Wie genau das aussehen kann ist mir noch nicht ganz klar (also welche Einheiten das betreffen würde).

Ich denke nicht, dass das sehr viel bringen würde. Seit Bulldozer hat sich einiges geändert. Der Flaschenhals liegt aktuell an der mangelnden Parallelisierbarkeit des Codes. Es lassen sich Sprünge nur bis zu einem gewissen Grad vorhersagen. Da hilft es eher wenig das Backend weiter aufzublasen.

w0mbat

2024-01-28, 17:18:04

Zossel

2024-01-28, 17:21:21

Ich bin von Zen4c nicht woirklich begeistert:
a) Laut AMD sind es 35% weniger Fläche der Kerne d.h. 54% mehr Kerne pro Fläche.
b) Es gab voir längerer Zeit mal ein Review zu Zen4c. Ergebnis war, dass Zen4 ca. 35% höhere Taktraten bei gleicher Spannung scbafft. Nicht Spitzentaktrate, sondern quer über die gesamte Kurve d.h. Zen4c ist auch nicht effizienter.

Im Endeffekt bedeutet dies:
.) 1.14x höhere MT Performanbce bei gleicher Fläche bei perfekt skalierenden Anwendungen
.) 1.35x niedrigere ST Performance

ZenXc sollte mit der Metrik WolkenBumms/Schrank gemessen werden, dafür wurde das entwickelt.

Zossel

2024-01-28, 17:45:34

Zen4c ist ein krasser game changer, in den Taktbereichen die für hyper scaler wichtig sind ist er effizienter und bring deutlich mehr Kerne (=Leistung) auf den Sockel. Bergamo ist so gut, Meta hat überlegt Intel komplett fallen zu lassen.

Und die Entwicklung dürfte vergleichsweise günstig sein, die Shareholder tanzen ja auch auf der Party mit.
Und bei Intel scheint das nur weitere verzettelungen statt klarer Strategien die sich ergänzen hervorzurufen.

robbitop

2024-01-28, 18:11:11

Worin genau soll der Vorteil von CMT liegen? Für mich war eines der Bulldozer-Probleme, dass AMD viel zu stark auf Multithreading gesetzt hat und die ST-Performance der Architektur ziemliche Grütze war, teilweise nichtmal schneller als die Phenoms.
Wobei iirc vishera ein paar Jahre später dann doch (als die Software weiter war) doch schneller war als Phenom. Sogar die Version mit nur 3 Modulen vs 6 Kern Phenom.

Der_Korken

2024-01-28, 18:12:14

Ja, mit den "c" Kernen bekommt man viel Performance/Area. Aber halt auch eine Regression bei ST. Und die "c" Kerne sind sehr gut hinsichtlich Packdichte der Logik-Anteile. Nichtsdestotrotz: Die FPU macht ~1/3 des Kerns aus (ohne L2 gerechnet). Auch bei Zen 4c. Und wenn man das bei Zen 5 nochmals vergrössern sollte (Single Cycle AVX512?), wäre es relativ gesehen noch mehr.

Das leuchtet mir nicht ein. Die FPU zu vergrößern, macht ja nur Sinn, wenn sie in irgendeiner Weise zu langsam ist für den Rest des Kerns und in vielen Fällen die Leistung limitiert. Wenn das aber der Fall ist, dann wäre es doch totaler Quatsch diese ohnehin schon zu langsame FPU auch noch auf zwei Kerne aufzuteilen. Ich müsste die FPU dann so fett machen, dass sie am Ende wieder genauso groß ist, wie zwei kleinere, Kern-exklusive FPUs.

Der einzige theoretische Vorteil wäre für mich, dass man bei stark gemischten Aufgaben pro Kern die Hardware besser auslasten kann, d.h. wenn ein Kern viel INT und einer viel FP rechnet, dann wäre es ein Vorteil, wenn der zweite Kern sich die FPU der ersten mit ausleihen kann.

Wenn ich aber schon so ein Konstrukt habe, wo sich zwei "Kerne" das Frontend, die FPU und womöglich sogar noch den L1$ teilen, warum mache ich daraus nicht einen großen Kern mit SMT? Für mich ist CMT einfach nur ein fetter Kern mit SMT, der aber zusätzlich die Einschränkung hat, dass die INT-Ressourcen immer fix aufgeteilt sind pro Thread. Dadurch hat dieses Design im ST-Betrieb immer Nachteile gegenüber einem fetten Kern, wo alles geshared ist. Für den MT-Betrieb wäre CMT sicherlich leichter zu implementieren, weil die INT-Teile entkoppelt sind und man so etwas mehr MT-Leistung pro Fläche unterbringen kann.

Aber will man das überhaupt? Ich bleibe dabei, dass ST-Leistung regelt und man sich MT heutzutage über big.LITTLE reinholt.

Von einer schlechten initialen Implementierung auf das Prinzip zu schließen ist wenig seriös. Dann dürfte es heute auch kein AVX mehr geben.

Bulldozer hatte natürlich noch ganz andere Probleme, aber ich halte von dem Prinzip an sich trotzdem nichts (siehe meine Ausführung über dem Zitat). Bei Zen 4 sind 70% des Base-Dies mit L2- und L3-Cache belegt. Ich sehe absolut keine Notwendigkeit an Logikfläche zu geizen, wenn dafür substantiell ST-Leistung geopfert werden muss.

Und wenn man es, sagen wir mal, "Rentable Units", nennen würde?

Dann macht es das Konzept nicht besser. Zu den Rentable Units, die nie einer näher definiert hat, habe ich auch in irgendeinem Thread schon mal nach dem Sinn gefragt. Am ehesten würde ich da an Sicherheitsprobleme denken, die sich durch SMT ergeben und dass RUs ein Konzept sein könnten, eine statische Aufteilung der Kern-Ressourcen zu erzwingen und somit zwei Threads vollständig voneinander abzukapseln. CMT im Bulldozer-Sinne passt aber nicht so richtig dazu, da man a) das Frontend ebenfalls modular trennbar gestalten müsste und b) die beiden INT-Teile zusammenarbeiten können müssten. Das entfernt sich imho schon wieder von CMT.

Ich bin von Zen4c nicht woirklich begeistert:
a) Laut AMD sind es 35% weniger Fläche der Kerne d.h. 54% mehr Kerne pro Fläche.

Aber doch nur, wenn man den L2 reinrechnet? Schau dir mal die annotierten Die-Shots in basix's Spoiler oben an: Der L2 macht die Einsparung bei der Logik total kaputt. Das Problem hätte CMT auch, denn da spare ich in gewisser Weise auch nur Logik ein (nämlich die FPU des zweiten Cores eines Moduls)

Seit Bulldozer hat sich einiges geändert. Der Flaschenhals liegt aktuell an der mangelnden Parallelisierbarkeit des Codes. Es lassen sich Sprünge nur bis zu einem gewissen Grad vorhersagen. Da hilft es eher wenig das Backend weiter aufzublasen.

So würde ich das auch sehen. Es gibt immer Bedarf nach mehr ST-Leistung. Wenn man unbedingt auch maximale MT-Leistung pro Fläche haben will. müsste man es eher so wie Intel machen und einen zweiten Core entwickeln für diesen Zweck. Den kann man dann auch maximal dicht packen und mit CMT versehen, denn da spielt die ST-Leistung keine Rolle. Einen one-size-fits-all-Ansatz bekommt man heute nicht mehr mit aller Konsequenz hin.

rentex

2024-01-28, 18:55:23

wird es eigentlich einen neuen Chipsatz geben (eventuell mit PCIe gen5 Anbindung) oder nur Refresh-Boards mit Promontory21 für Zen5?

Soweit ich weiss nen aktualisierten Chipsatz.

mczak

2024-01-29, 03:16:31

b) Es gab voir längerer Zeit mal ein Review zu Zen4c. Ergebnis war, dass Zen4 ca. 35% höhere Taktraten bei gleicher Spannung scbafft. Nicht Spitzentaktrate, sondern quer über die gesamte Kurve d.h. Zen4c ist auch nicht effizienter.

Das ist natürlich mitnichten ein linearer Spannungsoffset zwischen Zen4 und Zen4c. Insbesondere haben beide ungefähr dieselbe Minimalspannung (darunter schalten die Transistoren nicht mehr), die liegt ungefähr bei 0.7V - Zen4c schafft damit um die 1.5Ghz, Zen 4 so etwa 2.3Ghz (beim Diagramm hier https://www.hardwaretimes.com/amds-phoenix-2-hybrid-big-little-cpu-tested/ hat Zen4c etwas tiefere Minimalspannung, ich weiss aber nicht ob das Zufall ist oder immer so ist).
Und da Zen4c eben weniger verbraucht bei gleicher Frequenz und gleicher Spannung gegenüber Zen4 ist der durchaus effizienter bei tiefen Frequenzen - siehe dazu auch die ausführlichen Erläuterungen von Gipsel: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13476380&postcount=6083.

latiose88

2024-01-29, 04:42:24

ah ok sehr interessant,als bei 0.7 v ist schluss.Ich dachte immer das sagte mir wer,je weniger Amper fließt desto mehr wiederstand gibt es und durch das würde der Stromverbrauch nicht wirklich sinken.
Aber scheinbar gibt es auch Ausnahmen.Ich jedenfalls habe bei meinem Zen 3 CPU 0,95 Volt anliegen.Der Stromverbrauch sinkt.Vielleicht verwechsel ich das ja mit der Stromstärke wer weis.
Ich finde es jedenfalls echt blöd das man da so limiert ist beim Stromsparen und gleichzeitig Leistung zu halten.
Wird wohl auch unter Zen 5 sich nix in dieser hinsicht jemals dran ändern.

Zossel

2024-01-29, 06:39:08

Gipsel

2024-01-29, 17:18:11

Eine CPU ist keine ohmsche Last, mit dem ohmschen Gesetz aus der Schule kommst du da nicht weiter.
Im Prinzip richtig, daß es komplizierter ist, aber am Ende verheizt eine CPU schon gemäß P=U*I und verhält sich schon oft recht gut wie ein (variabler) Ohmscher Widerstand .
Latiose's Mißverständnis beruht darauf, daß ein Ansteigen des (effektiven) Widerstands und Sinken des Stroms natürlich mit einem Sinken der Verlustleistung einhergeht (bei einem Ohmschen Widerstand genau wie bei einer CPU).

P=U*I
R=U/I => I=U/R => P=U²/R

Die Frage ist, wo kommt der bei einer bestimmten Spannung fließende Strom her? Paar Leckströme gibt es sicherlich (reduziert man mit Powergating), aber ein Großteil wird durch das Schalten der Transistoren verursacht (und läßt sich mit Clockgating verringern).
Im Prinzip muß bei jedem Schaltvorgang eines Transistors seine Kapazität umgeladen werden. Vereinfacht nehmen wir mal an, daß Alles in einer Voltage Domain läuft, also überall die gleiche Spannung anliegt. Dann läßt sich im Prinzip die pro Takt umzuladende Kapazität als Summe der Kapazitäten aller in dem Takt schaltenden Transistoren beschrieben (wenn weniger schalten, sinkt also der Verbrauch, weswegen Clockgating so effektiv ist). Nennen wir diese aufsummierte Kapazität einfach mal C. Die Ladungsmenge Q, die für dieses Umladen benötigt wird, ist schlicht wie bei jedem Kondensator Q=U*C. Und das macht man mit der Frequenz f, also f mal jede Sekunde. Der (mittlere) Stromfluß I=Q/t ergibt sich damit zu:
I = U*C*f und damit die Verlustleistung P = U*I = U²*C*f
Durch Vergleich mit oben, kann man also sowas wie einen effektiven Widerstand R=1/(C*f) definieren, der vom Betriebszustand abhängt (wie viele/welche Transistoren schalten [C] und wie schnell [f]).
In der Realität ist es dann zwar noch ein wenig komplizierter, das allgemeine Verhalten kann man so aber doch ganz gut beschreiben.

Zossel

2024-01-29, 18:03:18

In der Realität ist es dann zwar noch ein wenig komplizierter, das allgemeine Verhalten kann man so aber doch ganz gut beschreiben.

Wobei das gesamte umgeladene Q/t pro nicht zwingend physikalisch von U abhängt, lediglich das Powermgmt versucht das aktiv zu optimieren :-)

Gipsel

2024-01-29, 18:51:43

Wobei das gesamte umgeladene Q/t pro nicht zwingend physikalisch von U abhängt, lediglich das Powermgmt versucht das aktiv zu optimieren :-)Nun, physikalisch haben die Transistoren/deren Gates (und Leitungen) schon eine echte Kapazität die auch tatsächlich für einen Schaltvorgang umgeladen werden muß. Man kann natürlich argumentieren, daß die Amplitude/Voltage-Swing zwischen An/Aus vielleicht nicht die komplette Versorgungsspannung ist (aber vermutlich doch halbwegs proportional dazu), aber dann ist das am Ende auch nur ein "fudge factor" mehr.
Wenn weniger Spannung zum Erreichen der Zielfrequenz nötig ist, wird das Powermanagement natürlich versuchen, die Spannung zu reduzieren, weil das eben quadratisch eingeht (weswegen es sogar hilfreich ist, die Spannung mittels Linearreglern wie AMDs LDOs zu reduzieren, die den Spannungsabfall quasi nur per Widerstand erzeugen und insgesamt recht viel Leistung verheizen [aber eben linear zum Spannungsabfall, nicht quadratisch, wie die Verbrauchsersparnis]).

Aber egal, hier soll es um Zen 5 gehen.

dildo4u

2024-01-29, 19:07:34

Angeblich wird Zen 5 Desktop eher ein Herbst Launch.

https://youtu.be/yV1MyhyaOwk?si=Ei83x8I59MqOej97

w0mbat

2024-01-29, 19:32:38

Passt überhaupt nicht mit den Berichten über die Massenfertigung zusammen.

Der_Korken

2024-01-29, 19:40:12

Die Gerüchte sind mal wieder völlig chaotisch. Die einen sagen: Zen 5 kommt im Frühsommer, der X3D erst zur CES 2005, kein neuer Chipsatz, Performace-Bump absolut krass. MLID sagt: Zen 5 kommt eher erst im Herbst, dafür eventuell zusammen mit X3D, Delay angeblich um die neuen Chipsets rauszubekommen, Server braucht neues Stepping wegen Bugs und Performance eher enttäuschend für eine neue Gen.

Unterschiedlicher könnte es nicht sein. Wobei wir bei Zen 4 auch viel Quatsch gehört haben, von wegen 25%+ IPC-Uplift.

Edit: Und 8000Mhz RAM ist - sofern damit nicht einfach ein größerer Teiler zwischen IOD und RAM gemeint ist - eigentlich auch ein Widerspruch dazu, dass der IOD der gleiche sein soll.

HOT

2024-01-29, 20:06:41

dildo4u

2024-01-29, 20:38:34

September macht Sinn wenn sie kein vorher kein 3D Modell haben.
Leute sind jetzt drauf Trainiert den Launch zu überspringen wenn diese Modelle nicht da sind.
Ein Zen 5 8 Core ohne 3D könnte die selbe Gameing Performance haben braucht dafür aber vermutlich mehr Takt/ TDP.

reaperrr

2024-01-29, 21:21:25

MLID scheint bei allen AMD-Gerüchten wirklich meilenweit daneben zu liegen dieses Mal. Er scheint echt schlechte Quellen zu haben. Oder alle anderen liegen falsch ;). Vielleicht streut AMD auch absichtlich Desinformation, das kann bei dem kaputten Informationsumfeld nämlich auch sein.
Jep, den Verdacht habe ich auch.

Gleiches Spiel nämlich bei den RDNA4-Gerüchten:

MLID sagt, N48 schlägt nach seinen Quellen wahrscheinlich 7900 XT, könnte auch an 4080/79XTX nah rankommen.

RGT sagt, N48 landet nur ca. auf/knapp über 7900GRE-Niveau und kommt als 8700er Serie, über N48 gibt's nen N31-Refresh (kein neuer GCD/kein RDNA3+, maximal besseres Binning) als 8800er, was darauf hindeuten würde, dass N48 in Raster dann doch zu langsam ist, um N32 und N31 gleichzeitig zu beerben.

Einer von beiden muss zwangsläufig falsche oder veraltete Infos haben (oder halt beide).

Nightspider

2024-01-29, 21:32:49

MLID ist bisher auch der Einzige, der von einem neuem X870E Chipsatz spricht oder?

HOT

2024-01-29, 22:05:31

Wobei das ausgerechnet Sinn ergibt. Es wird nur keine E-Varianten geben. Wie viele relevante 670-Boards gibt es - 3? Das ergibt keinen Sinn.
X870 -> 2 P21+USB4, alles PCIe5 was geht
B850 -> 1 P21+USB4, alles PCIe5 was geht
B840 -> 1 P19 (als B550-Ersatz) für günstige 100-200€-Boards
A620 -> OEM-Ware

Und der Launch scheint kompliziert zu sein, irgendwas ist da im Busch. Entweder gibts ein 3 und ein 4nm-CCD oder es gibt 4nm CCDs von Samsung und TSMC oder sowas. Das würde i.Ü. auch die Massenproduktion erklären, hat man Samsung mit im Boot muss man viel früher anfangen zu produzieren um Yield-Issues in den Griff zu bekommen.
Das ist aber nur ne wilde Speku meinerseits.
Ich bin aber mittlerweile Toms Meinung, die Dinger werden erst frühestens September launchen, dann aber alle zusammen (auch X3D) mit 800er-Boards.
AM4 wird ab dem Zeitpunkt dann auch begraben, ist mit B840 nicht mehr nötig und sollten sie andere günstigere CCDs dabei haben ist auch N7 nicht mehr nötig.

Der_Korken

2024-01-29, 22:16:55

Wieso überhaupt 800er Chipsätze? Mag AMD die 7 nicht mehr?

HOT

2024-01-29, 22:32:51

Wieso überhaupt 800er Chipsätze? Mag AMD die 7 nicht mehr?
Das kann so viele nicht offensichtliche Gründe haben... beispielsweise hat man 700er bis zum Samplestatus gebracht und dann stimmte was nicht bei den Boardherstellern und die haben das Ding rausgeschmissen oder anderes...

Es sollte ja auch Promontory 21 durch Promontory 22 ersetzt werden was nie passiert ist... AMD scheint sich hier und da doch mal ernstere Problemchen eingehandelt zu haben.

Hinzu kommen noch strategiesche Korrekturen wegen OEMs und AIBs, beispielsweise hatte ja grad erst Kraken Point Tape Out, das ist ein etwas kleinerer Strix Point (damit ist auch geklärt, was little Strix war i.Ü.), der muss in Massen schon in Q3 und Q4 an die OEMs gehen, damit so ein Desaster wie bei Phoenix oder etwas weniger Desaster, aber dennoch Unrund bei Hawk Point (war ja auch minimal zu spät) nicht mehr vorkommt. Ich hab so den Eindruck, dass AMD sich immer mehr auf die angeschlossenen Firmen konzentriert und hier Launchzeiträume an deren Launchzeiträume anpasst. Das heißt, für Notebooks müssen Kraken- und Strix-Point Notebooks dann ab Januar in großen Mengen verfügbar sein, die Produkte müssen also ab September in großen Mengen (1000er, 10000er Stückzahlen) an die OEMs gehen. Da wäre ein Navi-Launch nur im Weg i.Ü., die Desktop-CPU-Launches müssen auch bis dahin durch sein.

Von daher denke ich:

-> Launch Desktop-Grafikkarten ca. Juni
-> Launch Desktop-CPUs so September, erstmals OEM und Retail gleichzeitig
-> danach alles auf Kraken und Strix für die Hersteller, Refreshes ebenfalls (Phoenix, Rembrandt), Januar 25 launch der 9000er-Notebooks
-> Q1 25 Kraken für Desktop (9k-APUs)
-> Q1-2 25 MI400
-> Q2 Fire Range und Strix Halo

ryan

2024-01-30, 00:38:04

Der_Korken

2024-01-30, 00:47:15

Meanwhile im Anandtech-Forum: Nachdem dort auch der Link von MLID gedroppt wurde, legt Bondrewd nach und sagt, dass seine vorher genannten 32% IPC in SpecINT gar nicht stimmen würden, weil der echte Wert sich wie "bs" anhören würde ;D. Wundert mich nur, dass Kepler seine Posts alle liked.

Nightspider

2024-01-30, 02:01:07

Wäre schon nice, wenn das stimmen würde.

Aber lieber die Erwartungshaltung so lange etwas niedriger halten.

amdfanuwe

2024-01-30, 02:30:29

und sagt, dass seine vorher genannten 32% IPC in SpecINT gar nicht stimmen würden, weil der echte Wert sich wie "bs" anhören würde ;D.
Könnten dann sowohl <5% als auch >50% sein; hört sich beides für mich wie "bs" an.
Und selbst wenn SpecINT gut wird, kann es bei anderen Werten enttäuschen.

-----------
Wozu braucht es eigentlich neue Chipsätze? Gibt es neue Schnittstellen, die unterstützt werden müssen? Haben die aktuellen Macken, die behoben werden müssen?

Nightspider

2024-01-30, 02:34:38

Also die Googlesuche hat ergeben das die neuen Chipsätze vielleicht etwas günstiger zu fertigen wären aber die gleichen Features unterstützen würden.

latiose88

2024-01-30, 04:13:52

Super dann macht ja Warten sinn. Wollte ja bis Juli bzw Juli warten. Aber wenn ich was von neue chipsätze lese die preiswert sind und villeicht ja auch sogar sparsamer wer weis, dann wird sich das Warten wohl echt lohnen.

Hoffe das führt zu ner Steigerung und das bis dahin ddr5 ram wieder preiswerter wird bzw viel bessere raus kommen mit noch besseren timing. Damit würde ich dann jede mehrleistung mit nehmen die man so mit nehmen könnte. Zwar gab es in meinem Fall wo andere für mich testeten das programm wo viel Leistung gefordert wird nur von ddr5 4800 MHz auf ddr5 6200 MHz mit timing cl28 auf 6200 MHz nur ganze 2 % Leistungs unterschied. Vielleicht ändert sich ja was wenn die timings sogar noch besser sind ja was. Geil wäre da bei ddr5 cl22 oder cl18. Hätte nix dagegen hier noch mehr heraus zu holen. Villeicht sind dann ja noch weitere 2 % mehrleistung möglich.
Wenn ich allerdings dafür dann 300 oder gar 500 € Aufpreis bezahlen muss, dann lohnt es sich ja kaum für mich. Naja mal sehen was so kommen wird.

Zossel

2024-01-30, 07:54:59

Könnten dann sowohl <5% als auch >50% sein; hört sich beides für mich wie "bs" an.
Und selbst wenn SpecINT gut wird, kann es bei anderen Werten enttäuschen.
War das nicht schon immer so?

Wozu braucht es eigentlich neue Chipsätze? Gibt es neue Schnittstellen, die unterstützt werden müssen? Haben die aktuellen Macken, die behoben werden müssen?
Warum müssen I/O-Chips eigentlich von AMD kommen und was haben die mit einer konkreten CPU zu tun`

dildo4u

2024-01-30, 07:59:59

-----------
Wozu braucht es eigentlich neue Chipsätze? Gibt es neue Schnittstellen, die unterstützt werden müssen? Haben die aktuellen Macken, die behoben werden müssen?
Es wäre für Kunden besser wenn man ein Refrsch bringt der immer USB 4 garantiert.
Es gibt bei der ersten AM5 Generation kein Zwang.

Um USB4 alias Thunderbolt mit einer Geschwindigkeit von 40 Gbps zu realisieren, soll einmal mehr ein Chipsatz von ASMedia zum Einsatz kommen. Die Rede ist von einem Refresh der aktuellen Chipsätze X670E, X670, B650E und B650, aber auch von deren Nachfolgern.

https://www.pcgameshardware.de/CPU-CPU-154106/News/AM5-Plattform-soll-USB-4-mit-40-Gbps-erhalten-1424932/

rentex

2024-01-30, 08:21:15

Was hat DDR5 8000 Support mit dem Chipsatz zu tun? Das muss doch der IMC der CPU stemmen können.

basix

2024-01-30, 12:16:39

Es wäre für Kunden besser wenn man ein Refrsch bringt der immer USB 4 garantiert.
Es gibt bei der ersten AM5 Generation kein Zwang.

https://www.pcgameshardware.de/CPU-CPU-154106/News/AM5-Plattform-soll-USB-4-mit-40-Gbps-erhalten-1424932/

Ja, USB 4 als Standard wäre nice. Mit PCIe 5.0 am Chipsatz wäre das kein Problem, wäre dann aber ein Chipsatz Update.

Zossel

2024-01-30, 12:27:13

Ja, USB 4 als Standard wäre nice. Mit PCIe 5.0 am Chipsatz wäre das kein Problem, wäre dann aber ein Chipsatz Update.

Schafft PCIe5 überhaupt die typischen Strecken zwischen CPU und I/O-Chip auf typischen Mutterbrettern ohne Auffrischer?

The_Invisible

2024-01-30, 12:29:45

Schafft PCIe5 überhaupt die typischen Strecken zwischen CPU und I/O-Chip auf typischen Mutterbrettern ohne Auffrischer?

Sollte schon gehen, mein 2. pcie5-m.2 liegt auch ziemlich weit unten, wird aber sicher teurer, die Frage ob man das schon als Standard kompensieren kann...

HOT

2024-01-30, 12:40:14

PCIe5 wird nur in der CPU bleiben, ich sehe keinen wirklich neuen Chipsatz und auch keinen Grund dafür.

basix

2024-01-30, 15:11:08

PCIe5 wird nur in der CPU bleiben, ich sehe keinen wirklich neuen Chipsatz und auch keinen Grund dafür.

PCIe 5.0 hat den Vorteil, dass man "alles" mit vollem Speed anbinden kann. Ausserdem liessen sich USB 4.0 Extension-Chips mit 2x PCIe 5.0 anbinden, bei PCIe 4.0 brauchst du x4. Wenn die CPU mehr PCIe Lanes hätte, wäre das auf diese Weise realisierbar. Mehr Lanes sind für Zen 5 aber eher unwahrscheinlich. Heute musst du wählen ob USB 4.0 + 1x NVMe vs. 2x NVMe and der CPU. Bei 1x NVMe hast du dann das "Downgrade" auf PCIe 4.0, wenn man eine zweite NVMe verbauen will (hängt dann am Chipsatz). Hast du USB 4.0 und/oder PCIe 5.0 ab Chipsatz, kannst du das deutlich flexibler gestalten.

Unbedingt nötig ist das nicht. Aber würde die Plattform mit relativ wenig Aufwand nochmals attraktiver machen. B750E wäre die dann quasi perfekte Plattform (für mich ;))

Was hat DDR5 8000 Support mit dem Chipsatz zu tun? Das muss doch der IMC der CPU stemmen können.
...und das Board ;)

ryan

2024-01-31, 01:07:45

Es gab im Dezember eine chinesische board Channel News, wonach die next-gen Mainboards von AMD und Intel erst in Q3 2024 erwartet werden. Normalerweise kommen CPUs und neue Mainboards zusammen in den Markt.

https://videocardz.com/newz/amd-700-am5-and-intel-800-lga-1851-motherboard-series-might-be-coming-in-q3-2024

Die lagen dann wohl richtig. Wird bestimmt auf ein ähnliches Zeitfenster rauslaufen wie schon bei Zen 3 und 4 zwischen September und November für Desktop und mobile Dezember oder Januar.

An AMD rep just confirmed that Zen 5 is on track for the consumer market for the second half of this year.
https://twitter.com/PaulyAlcorn/status/1752472072339472806

MSABK

2024-01-31, 07:50:49

Dann liege ich mit Herbst nicht so falsch. Frühjahr 25 dann die X3d.

dildo4u

2024-01-31, 09:30:39

Gibt es wirklich Nachfrage nach neuen Modellen?
Ich hab gerade geguckt ordentliche b650 sind immer noch bei 200€, für mich liegt dort das Problem nicht ob ich paar FPS mehr habe.
Wenn ich AMD wäre würde ich mich komplett auf Notebooks konzentrieren APU sind wesentlich interessanter.

Zossel

2024-01-31, 10:13:29

Wenn ich AMD wäre würde ich mich komplett auf Notebooks konzentrieren APU sind wesentlich interessanter.

Desktop-CPUs sind ein Nebenprodukt der Server-CPUs (€€€€€), schon vergessen?

Und wenn die bekloppten Gamer die neuen CPUs auch zusätzlich mit völlig hirntoten Setups testen ist das sehr praktisch für den Server-Markt.

The_Invisible

2024-01-31, 10:17:00

DrFreaK666

2024-01-31, 10:28:08

Gibt es wirklich Nachfrage nach neuen Modellen?
Ich hab gerade geguckt ordentliche b650 sind immer noch bei 200€...

Da das Mainboard für zukünftige CPUs nutzbar ist, relativiert sich der Preis wieder etwas

w0mbat

2024-01-31, 11:53:30

HOT

2024-01-31, 11:55:38

Das werden sie sicher nicht nochmal machen ;). Bis das soweit ist wird auch PCIe5 das Ganze nicht mehr so extrem verteuern mMn, dann sind diese E-Varianten gar nicht mehr nötig.

Nightspider

2024-01-31, 12:36:47

Dazu sind B650E Mobos oft besser als X670.

Ist das so?

dildo4u

2024-01-31, 12:40:55

Klar es gibt doch 650E Modelle hoffentlich wird das ganze beim Chipsatz Update Simpler.

mczak

2024-01-31, 13:09:56

Ich finde es gibt einfach zu viel Versionen mit X670E, X670, B650E & B650. Dazu sind B650E Mobos oft besser als X670. Ich würde es so machen: X770 = PCIe 5.0, B750 = PCIe 4.0 (bzw. den Herstellern überlassen).

Die B-Mobos sind günstig und mit PCIe 4.0 immer noch für alles ausreichend schnell genug, wer das Maximum und Zukunftssicherheit haben will, kauft halt ein teures X-Mobo.
Das scheint mir nicht ideal. Klar bei den 600-Chipsets gab's zuviele Varianten - insbesondere die 2 Varianten bei den X670 sind doch ein Witz, da hätte es nur eine pcie 5.0 Variante geben dürfen.
Aber pcie nur verpflichtend beim Top-Chipsatz scheint mir etwas mager, der hat ja zusätzliche Kosten wegen des doppelten Chipsatz, der ansonsten für viele Boards nicht viel bringt (man muss auch Platz haben für zusätzliche pcie/nvme slots und noch mehr USB-Ports - na gut bei x670 gehen im Gegensatz zu B650 auch 2 USB 20gb Ports, wohl der grösste Vorteil).
Eine Single-Chipsatz Variante mit verpflichtend pcie 5.0 (sowohl für nvme auch für PEG - es kommen ja dann demnächst wohl auch passende Grafikkarten) scheint mir da durchaus angebracht. Wenn man doch nur eine B-Variante will, könnte man allenfalls pcie 5.0 für PEG optional den Herstellern überlassen, aber ein nvme slot mit pcie 5.0 sollte imho da absolut zwingend sein (das beherrschen auch schon viele B650 (ohne E) aber eben nicht alle).

bbott

2024-01-31, 13:33:37

Ist das so?
Zum Marktstart habe ich das auch so bewertet. Ich denke das es immer noch so ist.

Auch stört mich massiv die schmale Anbindung, um dann nochmals beim 670(X) am Chipsatz statt an der CPU angebunden zu sein. :freak:

Ich hoffe neue Chipsätze kommen, verbessern die Anbindung deutlich, sind günstiger und energiesparender =)

w0mbat

2024-01-31, 15:15:59

Ist das so?
Jetzt mal auf PCIe 5.0 bezogen.

basix

2024-01-31, 18:13:58

Nightspider

2024-01-31, 20:05:44

Eine Quelle von RGT meint wohl das die IPC >30% steigt (in Serveranwendungen?).

Hammer des Thor

2024-01-31, 20:55:14

Ich habe gerne viel IO aber B650E wäre für mich auch attraktiver. X670 ist meh unt X670E viel zu teuer, mehrverbrauch usw.

Wenn B750E = All PCIe 5.0 + USB 4.0 und 50$ günstiger als B650E -> Fortschritt

Wie schon mal geschrieben, dass Asus ROG Strix B650E F-Gaming hat das meiste IO bei dem chipsatz und das beste Layout aller AM5 Bords da beide PCIe 1.0 Slot nutbar bei einer Graka die 3 Slotz bedeckt!
All PCIe 5.0 wohl kaum da das teuer wegen der guten Signalqualität sein muss und engergieintensiv.

HOT

2024-01-31, 22:39:43

Langlay

2024-01-31, 23:01:34

Ich habe gerne viel IO aber B650E wäre für mich auch attraktiver. X670 ist meh unt X670E viel zu teuer, mehrverbrauch usw.

Wenn B750E = All PCIe 5.0 + USB 4.0 und 50$ günstiger als B650E -> Fortschritt

Ich bin ja im ITX Bereich unterwegs da isset ja nochmal etwas spezieller.

Ich hätte schon gerne so 2-4 USB-A Steckplätze mehr, 6x USB-A ist halt schon etwas knapp, aber knapp das doppelte ausgeben für das ASUS X670E-I für 2x USB-A mehr und dann musste dich mit der doofen Zusatzplatine rumärgern hab ich dann auch nicht eingesehen.

Allerdings war ich halt aus USB-A Steckplätze angeht vom Crosshair 8 Hero auch verwöhnt, das hatte 11x USB-A.

Nightspider

2024-02-01, 05:22:36

Zen5 müsste N4X bekommen und Zen5C N3E oder?

Da Zen5c ungefähr gleichzeitig fertig zu sein gehe ich zumindest davon aus.
Oder meint ihr es lohnt sich für AMD die dicken Zen5 Kerne auch noch parallel in N3E zu bringen?

OgrEGT

2024-02-01, 06:47:08

Ich warte auf Zen5X3D...
Bis die rauskommen ist die AM5 Plattform und BIOS ausgereift und wir werden wissen wo der Sweetspot beim RAM und IMC bei Zen5 liegen wird...

Zossel

2024-02-01, 07:37:23

Also bevor ich mir so ein völlig überteuertes B650E-Brett holen würde, würde es dann doch ein X670E, denn die sind ja kaum teurer. Beispielseise meins:
https://geizhals.de/gigabyte-x670e-aorus-pro-x-rev-1-0-a3063666.html?hloc=at&hloc=de

Welche Kriterien hast du angewendet die dich zu diesem Board geführt haben?
Trotzdem plädiere ich dafür das Intel und AMD das I/O-Chips auch für Dritte freigeben wird, das sind ja nur noch PCIe-Devices.
Dann würde es wahrscheinlich mehr Auswahl geben.

reaperrr

2024-02-01, 08:52:17

Zen5 müsste N4X bekommen und Zen5C N3E oder?
Zen5 wird eher N4P sein, evtl. mit einigen von N5HPC übernommenen custom Einstellungen (oder gleich ein AMD-optimierter N4HPC).

N4X ist in Sachen Leakage/Verbrauch zu viel schlechter als N4P, um den wegen ~5% höherer maximaler Taktraten zu nehmen.
Der würde eher für Xilinx-Produkte verwendet werden als für Zen5.

woodsdog

2024-02-01, 10:22:47

Ich bin ja im ITX Bereich unterwegs da isset ja nochmal etwas spezieller.

Ich hätte schon gerne so 2-4 USB-A Steckplätze mehr, 6x USB-A ist halt schon etwas knapp, aber knapp das doppelte ausgeben für das ASUS X670E-I für 2x USB-A mehr und dann musste dich mit der doofen Zusatzplatine rumärgern hab ich dann auch nicht eingesehen.

Allerdings war ich halt aus USB-A Steckplätze angeht vom Crosshair 8 Hero auch verwöhnt, das hatte 11x USB-A.

Naja, wenn du wirklich so viele alte USB Plätze brauchst, kauf dir doch lieber einen qualitativen Hub dazu, irgendwas von Anker oder so. Das ist doch sinnvoller als mit den Boards zu hadern. Du wirst ja sicherlich nicht 10 Bandbreiten-hungrige Geräte gleichzeitig betreiben.

HOT

2024-02-01, 10:29:14

Welche Kriterien hast du angewendet die dich zu diesem Board geführt haben?
Trotzdem plädiere ich dafür das Intel und AMD das I/O-Chips auch für Dritte freigeben wird, das sind ja nur noch PCIe-Devices.
Dann würde es wahrscheinlich mehr Auswahl geben.
Ich wollte alles außer gutem Sound (hat dank AE5 keine Priorität) und Platz zwischen den Slots für die Grafik. Zudem hab ich mit Riser-Card 5 m.2-Slots, davon 2 5.0.

Langlay

2024-02-01, 10:38:39

Naja, wenn du wirklich so viele alte USB Plätze brauchst, kauf dir doch lieber einen qualitativen Hub dazu, irgendwas von Anker oder so. Das ist doch sinnvoller als mit den Boards zu hadern. Du wirst ja sicherlich nicht 10 Bandbreiten-hungrige Geräte gleichzeitig betreiben.

Ja, das ist die Lösung die ich aktuell fahre (Corsair USB100 Hub), ich fänd es nur schöner wenn ich ohne auskommen würde weil mein Rechner öfter mal den Standort wechselt und das ist halt alles Kram der dann mit muss.

Pirx

2024-02-01, 11:31:15

Nutzt du nicht die Front-USB Header? Damit wären doch 10xUSB-A drin, oder?

The_Invisible

2024-02-01, 11:47:58

Also bevor ich mir so ein völlig überteuertes B650E-Brett holen würde, würde es dann doch ein X670E, denn die sind ja kaum teurer. Beispielseise meins:
https://geizhals.de/gigabyte-x670e-aorus-pro-x-rev-1-0-a3063666.html?hloc=at&hloc=de

Kommt drauf an was man will, mein Asus X670e-f ist eins der wenigen die 4x m.2 (2x pcie5) gleichzeitig erlauben ohne das was blockiert wird, man könnte sogar noch eine 5. im untersten x4 Slot per Addin-Karte einbauen (ja klar gehts über den chipset downlink aber besser gehts halt derzeit nicht im mainstream markt). War mir halt wichtig.

USB interessiert mich hingegen überhaupt nicht, ka was ich mit USB4 soll, hab höchstens ein paar USB-Sticks und BD-Laufwerk dran

Zossel

2024-02-01, 11:48:22

Ich wollte alles außer gutem Sound (hat dank AE5 keine Priorität) und Platz zwischen den Slots für die Grafik. Zudem hab ich mit Riser-Card 5 m.2-Slots, davon 2 5.0.

Würde man für guten Sound mit einem externen S/PDIF DAC mit eigener Stromversorgung nicht am besten fahren?

Ja, ich weiß die Dinger sind oft maßlos überteuert wegen Voodoo, aber da gibt des doch bestimmt auch gute Geräte für einen schmalen Taler.

HOT

2024-02-01, 12:10:47

Die AE5 ist da schon gut und günstig gewesen ;).

The_Invisible
Kann ich nur zustimmen, es hängt eben viel an den eigenen Anforderungen. USB ist mir auch ziemlich egal, mit 2x2 und 4 kann ich eh nix anfangen ;).

latiose88

2024-02-01, 12:24:56

Zossel

2024-02-01, 13:06:54

Tya mit den USB Anschlüsse habe ich auch so meine Probleme. Einer von den am4 ist defekt gegangen weil wohl sehr oft USB verwenden. Ein USB-c kann ich leider nicht verwenden weil ich keines damit habe. Der Rest des frontpanels bei usb sind alle 4 Anschlüsse in Verwendung. Den hinteren Teil kann ich weil das Gehäuse zu groß ist leider nicht verwenden. Ich brauche also generell viele USB Anschlüsse. Mal schauen wie es in Zukunft mit dem neuen System und dem Gehäuse dann so aussehen wird.

Es gibt doch doch Hubs zum einbauen in 5,25" oder 3,5" Schächte oder auch als Slotblech.
Und PCIe Karten gibt es auch noch.
Das bietet auch einen gewissen Schutz der Ports vom Mainboard.

Oder ist das zu lösungsorientiert?

iamthebear

2024-02-01, 13:58:55

Das ist natürlich mitnichten ein linearer Spannungsoffset zwischen Zen4 und Zen4c. Insbesondere haben beide ungefähr dieselbe Minimalspannung (darunter schalten die Transistoren nicht mehr), die liegt ungefähr bei 0.7V - Zen4c schafft damit um die 1.5Ghz, Zen 4 so etwa 2.3Ghz (beim Diagramm hier https://www.hardwaretimes.com/amds-phoenix-2-hybrid-big-little-cpu-tested/ hat Zen4c etwas tiefere Minimalspannung, ich weiss aber nicht ob das Zufall ist oder immer so ist).
Und da Zen4c eben weniger verbraucht bei gleicher Frequenz und gleicher Spannung gegenüber Zen4 ist der durchaus effizienter bei tiefen Frequenzen - siehe dazu auch die ausführlichen Erläuterungen von Gipsel: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13476380&postcount=6083.

Ich glaube da hast du mich missverstanden:
Der TAKT ist bei Zen4 ca. 35% höher als bei Zen4c wenn man bei gleicher Spannung vergleicht. Diese 35% sind über die gesamte Kurve relativ gleich mit Ausnahme das ganz unteren Ende bei ca. 700mV.
Das bedeutet im Umkehrschluss, dass Zen4c überall bei gleichem Takt mehr Spannung braucht. Dieser Unterschied ist jedoch unterschiedlich. In der Nähe des Maximaltaktes ist es mehr, im unteren Bereich ist es weniger. Das ergibt sich daraus, dass die Spannungskurve an sich schon nicht linear ist.

Dass Zen4c bei gleichem Takt und Spannung etwas weniger verbraucht kann sein aber groß ust der Effekt nicht.
In dem bei dir verlinkten Review ist Zen4 bei 8W (Maximaltakt des Zen4c) immer noch um ca. 20-25% schneller.

Interessantes Detail am Rande:
Unter MT Workloads (d.h. mit SMT Nutzung) ist das Verhältnis zwischen 1 Raptor Cove (2T) und 2 Gracemont Cores (auch 2 Threads) was Performance, Taktraten, Flächenbedarf und Energieverbrauch angeht sehr ähnlich zu Zen4 vs. Zen4c:
Performance: 1.4x Intel, 1.35x AMD
Flächenbedarf: 1.5x Intel, 1.55x AMD
Taktraten: 1.36x Intel, 1.35x AMD

AMD hat hier jedoch den Vorteil, dass die Zen4c Kerne auch noch einigermaßen brauchbar sind wenn sie nur 1 Thread bearbeiten müssen.

Eine Quelle von RGT meint wohl das die IPC >30% steigt (in Serveranwendungen?).

Laut dem Video von heute galt dies explizit nicht für Server CPUs sondern für Desktop.
Allerdings handelt es sich um Mixed Workloads. Da könnte auf der einen Seite einiges an neuen AVX512 Befehlen liegen und auf der anderen Seite profitieren Spiele stark von der Speicherlatenz/Bandbreite als auch von der L3 Größe und hier wurde nicht viel getan. Falls die bisherigen Infos stimmen würde ich also 30% mehr Performance bei einem bereits jetzt stark speicherlimitierten Zen4 vanilla ausschließen. Bei Zen5 X3D könnte es jedoch deutlich besser aussehen.

HOT

2024-02-01, 14:04:03

Tya mit den USB Anschlüsse habe ich auch so meine Probleme. Einer von den am4 ist defekt gegangen weil wohl sehr oft USB verwenden. Ein USB-c kann ich leider nicht verwenden weil ich keines damit habe. Der Rest des frontpanels bei usb sind alle 4 Anschlüsse in Verwendung. Den hinteren Teil kann ich weil das Gehäuse zu groß ist leider nicht verwenden. Ich brauche also generell viele USB Anschlüsse. Mal schauen wie es in Zukunft mit dem neuen System und dem Gehäuse dann so aussehen wird.
Stell dir nen TypC Hub aufs Gehäuse für 20€, Problem gelöst :freak:. Das ist natürlich ein irres Hindernis ;).

Gipsel

2024-02-01, 14:35:32

Dass Zen4c bei gleichem Takt und Spannung etwas weniger verbraucht kann sein aber groß ust der Effekt nicht.
In dem bei dir verlinkten Review ist Zen4 bei 8W (Maximaltakt des Zen4c) immer noch um ca. 20-25% schneller.Beim Maximaltakt des Zen4c ist der natürlich ineffizienter. Der dortige Test ist auch ein wenig inkonklusiv. Deren "7540U" ist ja eigentlich ein Z1 (ein 7540U hat nur Zen4 Kerne, der mit 2x Zen4 + 4x Zen4c ist der 7545U) und der Vergleich mit dem 7840U zeigt, daß deren (unterschiedliche) Testplattform (mitsamt unterschiedlichem Arbeitsspeicher) massiven Einfluß auf die Ergebnisse hat. Anders ist nicht zu erklären, daß der 7840U weniger Grundverbrauch hat als der Z1. Besser wäre es gewesen, nur den Verbrauch der Kerne aufzutragen (statt Package Power). So bleibt bei gleichem package Power Limit beim Z1 weniger Vebrauch für die Kerne übrig, was den Vergleich natürlich erschwert. Insofern bin ich skeptisch, ob es da nicht auch noch andere Probleme gibt (und sei es komische Firmware bei dem Z1 Handheld, mit dem das gemessen wurde). Und ich bin auch ein wenig skeptisch, ob SPECint für eine Gesamtaussage taugt (idealerweise macht man das mit mehreren Lasten). Das Verhalten mit z.B. Cinebench scheint laut AMDs Angaben ja irgendwie nicht so auszufallen wie dort (Crossover bei ~18W für multithreaded Lasten zwischen 7540U und 7545U auf doch vermutlich identischer Testplattform).
Vielleicht bekommen wir ja mal ausführliche Tests mit dem 8500G. Da der aber wohl für viele nicht so interessant ist (Launch-Tests gab es nur vom 8700G und 8600G), würde ich da nicht drauf wetten wollen.

Interessantes Detail am Rande:
Unter MT Workloads (d.h. mit SMT Nutzung) ist das Verhältnis zwischen 1 Raptor Cove (2T) und 2 Gracemont Cores (auch 2 Threads) was Performance, Taktraten, Flächenbedarf und Energieverbrauch angeht sehr ähnlich zu Zen4 vs. Zen4c:
Performance: 1.4x Intel, 1.35x AMD
Flächenbedarf: 1.5x Intel, 1.55x AMD
Taktraten: 1.36x Intel, 1.35x AMDIrgendwie verstehe ich Deine Verhältnisse nicht so ganz.
Ein RaptorCove Kern ist ausgefahren (insbesondere mit 2 Threads) meist grob äquivalent zu 2 Gracemont-Kernen (in Cinebench erreicht ein RaptorCove z.B. ohne HT >90% von zwei Gracemonts, mit HT ist er dann schneller), während 2 Zen4c Kerne zusammen in MT-Szenarien dagegen immer deutlich schneller als 1 Zen4 Kern sind (weil IPC gleich und Takt von Zen4c im Bereich 65% - 75% [offizieller Maximaltakt in verschiedenen Produkten/im gleichen Produkt]).
1 Gracemont zu 1 Raptor: ~1,3x - 1,4x Takt * 1,3x IPC * 1,2 HT-Faktor = ~2-2,2 (bei TDP-Limitierung sinkt der Taktvorteil von RaptorCove, aber IPC und HT bleiben erhalten)
1 Zen4c zu 1 Zen4: 1,3x - 1,5x Takt * 1x IPC * 1 HT-Faktor = 1,3 - 1,5 (bei harter TDP-Limitierung sinkt der Taktvorteil von Zen4 [oder wird identisch oder gar niedriger [siehe Bergamo])

latiose88

2024-02-01, 17:31:42

Stell dir nen TypC Hub aufs Gehäuse für 20€, Problem gelöst :freak:. Das ist natürlich ein irres Hindernis ;).

Hm wie sieht das denn aus und kann man das auch per Amazon kaufen?

iamthebear

2024-02-02, 18:55:12

1 Gracemont zu 1 Raptor: ~1,3x - 1,4x Takt * 1,3x IPC * 1,2 HT-Faktor = ~2-2,2 (bei TDP-Limitierung sinkt der Taktvorteil von RaptorCove, aber IPC und HT bleiben erhalten)
1 Zen4c zu 1 Zen4: 1,3x - 1,5x Takt * 1x IPC * 1 HT-Faktor = 1,3 - 1,5 (bei harter TDP-Limitierung sinkt der Taktvorteil von Zen4 [oder wird identisch oder gar niedriger [siehe Bergamo])

Also ich bin ausgegangen von:
.) 1.5x IPC (Techpowerup hat in ihrem 12900K Review 1.52x in Applikationen und 1.47x in Gaming ermittelt bei gleichem Takt):
https://www.techpowerup.com/review/intel-core-i9-12900k-e-cores-only-performance/2.html
Ich gehe davon aus, dass sich das bei Raptor Lake nicht großartig verändert hat.

.) 1.35x Takt (6GHz vs. 4.4GHz beim 14900K waren 1.33x, beim 12900K waren es 5,2 vs. 3,9 = 1.33x)

.) ca. 1.35x - 1.4x durch SMT.
Ja das ist das obere Ende aber wir unterstellen ja auch den 2 Gracemont Kernen, dass diese eine Performance von 2x haben was in der Praxis kaum der Fall ist, da so gut wie nichts linear mit der Kernanzahl skaliert.

Gipsel

2024-02-02, 19:09:48

Also ich bin ausgegangen von:
.) 1.5x IPC (Techpowerup hat in ihrem 12900K Review 1.52x in Applikationen und 1.47x in Gaming ermittelt bei gleichem Takt):
https://www.techpowerup.com/review/intel-core-i9-12900k-e-cores-only-performance/2.html
Ich gehe davon aus, dass sich das bei Raptor Lake nicht großartig verändert hat.

.) 1.35x Takt (6GHz vs. 4.4GHz beim 14900K waren 1.33x, beim 12900K waren es 5,2 vs. 3,9 = 1.33x)

.) ca. 1.35x - 1.4x durch SMT.
Ja das ist das obere Ende aber wir unterstellen ja auch den 2 Gracemont Kernen, dass diese eine Performance von 2x haben was in der Praxis kaum der Fall ist, da so gut wie nichts linear mit der Kernanzahl skaliert.Selbst mit diesen Annahmen (wovon ich doch einige in Zweifel ziehe) paßt das nicht. Die Verhältnisse sind invers:
1 RaptorCove : 2 Gracemont = 1.35
1 Zen4 : 2 Zen4c = 1 / 1.4 = ~0.7

latiose88

2024-02-02, 22:39:01

.) 1.35x Takt (6GHz vs. 4.4GHz beim 14900K waren 1.33x, beim 12900K waren es 5,2 vs. 3,9 = 1.33x)

.

Ah ok sehr interessant mit annahme der Kerne und so.
Taktet der 14900k etwa auf 6 ghz auf den P Kernen und 4,4 ghz auf den e Kernen?
Weil als wer für mich mit den 14900k getestet hatte,lag der 14900k bei 5,2 ghz auf den P Kernen und 4,4 ghz auf den E kernen.Liegt es daran das die Software das nicht richtig ausgenutzt hatte also die Software die CPU und so?

HOT

2024-02-02, 23:52:32

Hm wie sieht das denn aus und kann man das auch per Amazon kaufen?
https://www.amazon.de/Anker-Datenhub-Daten%C3%BCbertragung-Erweiterungskabel-Ladeleistung-Black/dp/B0CCDZWH5H/ref=sr_1_11?crid=2MPMGT8QQJL2Z&keywords=usb%2Bc%2Bhub&qid=1706914310&sprefix=usb%2Bc%2B%2Caps%2C85&sr=8-11&th=1

Zossel

2024-02-03, 09:01:01

https://www.amazon.de/Anker-Datenhub-Daten%C3%BCbertragung-Erweiterungskabel-Ladeleistung-Black/dp/B0CCDZWH5H/ref=sr_1_11?crid=2MPMGT8QQJL2Z&keywords=usb%2Bc%2Bhub&qid=1706914310&sprefix=usb%2Bc%2B%2Caps%2C85&sr=8-11&th=1

Muss es unbedingt ein Link auf diesen monopolistischen Ausbeuterladen sein?

HOT

2024-02-03, 10:29:35

Moa sonst noch Schmerzen? :freak:
Genieße das Leben Mann.

ashantus

2024-02-03, 12:06:00

Ich warte auf Zen5X3D...
Bis die rauskommen ist die AM5 Plattform und BIOS ausgereift und wir werden wissen wo der Sweetspot beim RAM und IMC bei Zen5 liegen wird...

Die neuen Zen 5, als auch die neuen Intel Arrow-Lake für den Desktop werden offiziell auf DDR 6400 setzen. Insofern ist für jede Neuanschaffung bereits heute meine Empfehlung gleich 6400 zu nehmen. Die meisten AM5 Boards haben jetzt auch Bios Updates um diesen Speed umzusetzen. Besonders empfehlenswert sind eben Module mit Hynix A-Dies, die single-sided verbaut sind.
p.s.: Mir ist auch aufgefallen, daß es inzwischen Intel Boards gibt, die damit werben auch Ram Module mit Expo zu unterstützen.

HOT

2024-02-03, 12:30:07

basix

2024-02-03, 13:06:20

JEDEC 5600 und EXPO 6400 mit 1:1 Teiler für Zen 5? Wäre vermutlich realistisch, wenn man beim gleichen IOD bleibt.

Samsung plante bereits 2021 mit DDR5 7200 für 2023/2024, mit JEDEC Timings und nur 1.1V: https://www.anandtech.com/show/16900/samsung-teases-512-gb-ddr5-7200-modules

rentex

2024-02-03, 14:15:39

Mit "50-50-50 to 60-60-60" Timings...

mczak

2024-02-03, 14:19:07

Samsung plante bereits 2021 mit DDR5 7200 für 2023/2024, mit JEDEC Timings und nur 1.1V: https://www.anandtech.com/show/16900/samsung-teases-512-gb-ddr5-7200-modules
Dabei gibt's noch nicht mal JEDEC-konformen DDR5-6000 Speicher wirklich zu kaufen, so neu sind jetzt die finalen Spezifikationen für ddr5-6000/6400 auch wieder nicht (und OC-Speicher erreicht ja noch deutlich höhere Frequenzen, wenn auch natürlich overvolted).
Gut, TeamGroup hat JEDEC-konforme ddr5-6000 und ddr5-6400 Module im Angebot (Elite Plus). Keine Ahnung ob die auch erhältlich sind. Ansonsten gibt's von Crucial noch JEDEC-konforme ddr5-6000 Module (nur die mit den 24gbit Chips, also 24GB Module). Das ist dann aber auch schon alles. Klar die Timings sind da jetzt nicht so besonders (deutlich langsamer als jeglicher OC-Speicher, CL 48 für ddr5-6000 und CL 52 für ddr-6400), aber eben dafür ohne Ueberspannung.

ryan

2024-02-03, 16:00:28

Nicht offiziell, offiziell werden beide nur den JEDEC-Standard DDR5 5600 unterstützen (mit Abstufungen für Vollbestückung). 6400 gibts nur mit XMP/EXPO. Deren Nachfolger könnten dann offiziell JEDEC DDR5 6400 supporten.

Arrow Lake-S kommt nativ mit DDR5-6400 Support.

Unterstützung für bis zu DDR5-6400-Speicher (Native JEDEC) (https://www.igorslab.de/intels-naechste-desktop-cpu-plattform-arrow-lake-s-mit-bis-zu-24-kernen-ddr5-6400-und-lga-1851-leak/)

latiose88

2024-02-04, 03:03:38

hm ja wenn dann ddr5 6400 mit 28er Timings.Und beim Preis sind diese doch noch immer um einiges Teuer.Für den geringen Mehrleistung so viel zu berappen ich weis ja nicht.

Nightspider

2024-02-04, 04:10:43

Laut dem Video von heute galt dies explizit nicht für Server CPUs sondern für Desktop.
Allerdings handelt es sich um Mixed Workloads. Da könnte auf der einen Seite einiges an neuen AVX512 Befehlen liegen und auf der anderen Seite profitieren Spiele stark von der Speicherlatenz/Bandbreite als auch von der L3 Größe und hier wurde nicht viel getan. Falls die bisherigen Infos stimmen würde ich also 30% mehr Performance bei einem bereits jetzt stark speicherlimitierten Zen4 vanilla ausschließen. Bei Zen5 X3D könnte es jedoch deutlich besser aussehen.

In Spielen hat ja schon Zen4 von starkem Ram Tuning profitiert. Könnte sein, dass das mit Zen5 noch stärker so sein wird, dass der RAM ausbremst.

Gibt ja auch schon Spiele wo ein 7700X mit starkem RAM Tuning vor einem teureren 7800X3D mit RAM Tuning liegt.

iamthebear

2024-02-04, 08:09:26

Selbst mit diesen Annahmen (wovon ich doch einige in Zweifel ziehe) paßt das nicht. Die Verhältnisse sind invers:
1 RaptorCove : 2 Gracemont = 1.35
1 Zen4 : 2 Zen4c = 1 / 1.4 = ~0.7

Ich glaube du hast das falsch verstanden:
1 Raptor vs. 2 Gracemont (beide 2 Threads)
1 Zen4 vs. 1 Zen4c (beide 2 Threads)

rentex

2024-02-04, 09:45:44

Nightspider

2024-02-04, 10:37:35

HOT

2024-02-04, 11:13:24

In Spielen hat ja schon Zen4 von starkem Ram Tuning profitiert. Könnte sein, dass das mit Zen5 noch stärker so sein wird, dass der RAM ausbremst.

Gibt ja auch schon Spiele wo ein 7700X mit starkem RAM Tuning vor einem teureren 7800X3D mit RAM Tuning liegt.

Da gibts noch ein paar Unbekannte. Mal sehen, wie die CCD zueinander stehen und ob Zen5 nicht sogar Latenzen besser verstecken kann als Zen4. Und für das Zweite hätt ich auch gern ne Quelle, das klingt doch sehr weit hergeholt.

Arrow Lake-S kommt nativ mit DDR5-6400 Support.

Unterstützung für bis zu DDR5-6400-Speicher (Native JEDEC) (https://www.igorslab.de/intels-naechste-desktop-cpu-plattform-arrow-lake-s-mit-bis-zu-24-kernen-ddr5-6400-und-lga-1851-leak/)

Das kann schon sein, wird bei Granite Rapids auch offiziell unterstützt. Würd mich aber auch nicht überraschen, wenn man das bis zum Launch wieder herunterstuft aus Kostengründen.

robbitop

2024-02-04, 13:03:53

Wäre interessant ob das noch mehr Spiele betrifft, wenn man nur auf die wichtigen 1%low fps schaut.

https://youtu.be/HzPrGv22R7g?t=206

Der hat schon dutzende Tests gemacht über Monate hinweg und es mehrfach getestet.

Naja wenn das Instructionset bei 32 mb L3 eine gute hitrate hat, bringt mehr L3 kaum noch was. Sind ja nicht alle Spiele die davon profitieren. Und dann zählt halt höherer CPU Takt. Und die x3d haben ja weniger Kerntakt.
Dennoch ist es über die Breite der Spiele sicherlich besser mit mehr L3. Die Performance ist konsistenter weil weniger auf externe Speicherzugriffe gewartet werden muss.
Ich will jedenfalls nie wieder eine CPU im Gaming PC ohne großen, schnellen LLC.
Völlig banane ob in Einzeltiteln dann mal die 10% Mehrtakt ohne x3d mal einen kleinen Sieg holen. Die 10% merkt man kaum. Aber dort wo der LLC greift - das merkt man dann schon doch oft ordentlich.

latiose88

2024-02-04, 13:20:19

@robbitop
Also wenn von l1 zu l2 eine gute hitrate ist, könnte auch l1 hitrate alleine ausprobieren. Kann man ja auch extra pro Anwendung laufen lassen. Aber es dauert dann viel länger weil das Programm alles mit loggt.
Wenn die hitrate super gut und die missrate in einer schon fast unbedeutend. Ab wann ist es das denn bei 0,050 auch schon oder ab wann ist das eine perfekte hitrate. Gibt es denn eine 100 % hitrate überhaupt bei einem Programm?

Also cache ist in dem Sinn also dann nicht mehr abhängig. Aber eine 0 Abhängigkeit bei ram gibt es bei keinen Programm. Und dann zählt also nur noch der CPU takt dann am Ende? Was denn sonst noch so?

fondness

2024-02-04, 13:31:02

basix

2024-02-04, 13:35:26

Dazu braucht es kein 3D-Stacking. Intel macht das seit Sandy Bridge, wo der Uncore langsamer läuft als die Cores ;)

Da Zen 5 eine "neue" Architektur ist, hoffe ich auch auf einen L3$, welcher auf einer anderen Takt-Domain läuft. Damit hat man zusätzlich noch einen Hebel, um Performance und/oder Energieeffizienz zu optimieren.

fondness

2024-02-04, 13:38:29

Er soll aber nicht langsamer laufen, das kostet schließlich Performance. Und klar braucht es dafür 3D-Stacking, alleine schon die Signallaufzeiten wären sonst viel zu lang. Nur dank 3D-Stacking schafft es AMD den L3-Cache zu verdreifachen ohne die Latenz zu erhöhen. Und nur deshalb bringt das Ding ja auch so extrem viel Performance trotz deutlich weniger Takt.

basix

2024-02-04, 13:49:54

Es geht mir um gleichbleibende 32 MByte pro CCX. Natürlich kannst du da noch V-Cache draufpacken, das ist aber für mich nicht das Thema. Es geht darum, dass der L3$ einfach nicht mehr mit der Core-Clock Domain laufen muss und man deswegen reduzierte Spannungen auf dem L3$ anlegen kann. Dann kann der L3$ auf einem optimalen Takt laufen und nicht immer auf dem Takt des schnellsten Cores. Wirklich Performance kostet das nicht, insbesondere wenn man die Anzahl Cycles reduziert. Die Cycles kann man reduzieren, weil die Taktraten tiefer sind und allenfalls Anpassungen am Design vornimmt. Nicht alles muss auf synchronem und maximalem Takt laufen, um sehr gute Performance zu kriegen. Und auch wenn die Cache 3D-Stackest und unter die Cores packst ist es nicht garantiert, dass der dann mit 6 GHz laufen kann. Nein, das Problem verschärft sich sogar, da der Cache unter den Cores sitzt und das in einer schlechteren Wärmeabfuhr resultiert. Hier den Cache tiefer takten zu können (niedrigere Spannung -> geringerer Stromverbrauch -> geringere Temperaturen) ist nochmals wertvoller als bei einem monolithischen CCD. Und sollte man durch die L3$ Taktregression 1-3% Performance verlieren, holt man die durch die +10% Core Takt locker wieder rein.

V-Cache ist ein ganz anderes Thema. Der geht immer. Nur eben optimaler, wenn die L3$ tiefer takten oder weniger Spannung für den Betrieb benötigen. Die Cores dürfen dann immer noch ans Maximum takten. Das geht auch auf einem monolithischen CCD. Ich sehe einen entkoppelten L3$ Takt eher noch als einer der Voraussetzungen, dass "echte" 3D CCDs überhaupt realistisch umsetzbar sind. Wenn man während dem Testen der Chips irgendwelche Temperaturprobleme bemerkt, kann man Takt & Spannung des L3$ Chiplets noch senken und wieder in den grünen Bereich bringen. Ist der Takt "zwingend" auf Core Takt Niveau kannst du nichts anderes mehr machen, als den Core Takt auch zu senken. Ergo verliert man Performance.

latiose88

2024-02-04, 14:42:55

ja da bin ich auch dafür.Besonders wenn man so Programme wie ich verwendet wo mehr Cache nichts mehr bringt und wenn durch sowas mehr CPU Takt hervor bringt,warum auch nicht.Ich weis zwar nicht wie viel mir das dann an Leistung kosten würde,wenn es dann beim L3 in diese Richtung gehen würde.Aber denke mal das da nicht so viel verloren geht.Noch dazu sind es ja beim 16 Kerner 2x32 kann man so sagen.Alleine zwischen 16 MB und 32 MB L3 Cache war nun der Verlust zwar da gewesen aber nicht so groß das es sehr weh tut.Und sowas wie du ja vorgeschlagen hast,wird weit weniger zu spüren sein als zwischen 16 und 32 MB als Vergleich.
Und wenn das dann was bringt warum auch nicht.

Nightspider

2024-02-04, 16:03:03

Naja wenn das Instructionset bei 32 mb L3 eine gute hitrate hat, bringt mehr L3 kaum noch was. Sind ja nicht alle Spiele die davon profitieren. Und dann zählt halt höherer CPU Takt. Und die x3d haben ja weniger Kerntakt.
Dennoch ist es über die Breite der Spiele sicherlich besser mit mehr L3. Die Performance ist konsistenter weil weniger auf externe Speicherzugriffe gewartet werden muss.
Ich will jedenfalls nie wieder eine CPU im Gaming PC ohne großen, schnellen LLC.
Völlig banane ob in Einzeltiteln dann mal die 10% Mehrtakt ohne x3d mal einen kleinen Sieg holen. Die 10% merkt man kaum. Aber dort wo der LLC greift - das merkt man dann schon doch oft ordentlich.

Der Tester hatte ja die Vermutung, dass die Datenpakete in Star Citizen teilweise einfach zu groß sind für den 32MB L3 Cache und dieser daher nicht immer so effektiv Speicher-und Ladevorgänge vor dem RAM abfangen kann und für die 1%lows die 10% mehr Takt der Recheneinheiten mehr bringen. Immerhin kann Star Citizen teils auch mal über 20GB RAM belegen, ich kann mir daher vorstellen, das seine Theorie stimmt und die 32MB zu klein sind für das Spiel in allen Situationen.

Er hat die Latenz des L3 immerhin von Plug&Play 82,3ns über Expo mit 68,1ns selbst per Hand 55,2ns tunen können können. (den 3XD auf 58ns)
28% mehr fps in den 1%lows hat er mit dem Tuning aus dem 7700X geholt.

Der V-Cache ist ja auch nicht nutzlos laut seinem Test und liegt bei den 5% avg_fps sogar leicht vor dem 7700X @ max Tuning.

Interessant wären solche Tests halt auch mit anderen Spielen wenn man nur noch auf die 1%lows schauen würde.

rentex

2024-02-05, 10:48:59

https://www.techpowerup.com/318719/amd-readies-x870e-chipset-to-launch-alongside-first-ryzen-9000-granite-ridge-cpus

Zossel

2024-02-05, 11:40:25

Der Tester hatte ja die Vermutung, dass die Datenpakete in Star Citizen teilweise einfach zu groß sind für den 32MB L3 Cache und dieser daher nicht immer so effektiv Speicher-und Ladevorgänge vor dem RAM abfangen kann und für die 1%lows die 10% mehr Takt der Recheneinheiten mehr bringen.

Schlecht programmiert ist auch immer eine Möglichkeit.

Nightspider

2024-02-06, 15:59:53

Schlecht programmiert ist auch immer eine Möglichkeit.

Gibt genug Spiele wo der V-Cache Cache nicht immer mit 30-40% reinknallt oder nicht genau dann, wenn man ihn braucht.

Scheint sogar recht oft vorzukommen, dass der V-Cache in den Momenten, wo man eh schon zu viele fps hat, mehr bringt als bei den 1%lows, weil die niedrige Latenz bei hohen fps eventuell noch wichtiger wird.

HOT

2024-02-06, 16:12:49

Schlecht programmiert ist auch immer eine Möglichkeit.
Das ist auch ein Mythos der sich hartnäckig hält. Schelcht programmiert gibts halt sowohl als auch.

woodsdog

2024-02-06, 19:51:16

sagen wir's mal so... wenn ein Produkt in einer >12 Jahre alten Engine auf moderner Hardware wie ein Sack Nüsse lüppt... ist vermutlich nicht die Hardware schuld...

Wir hatten DDR3 RAM, Ivy Bridge und AMD FX CPUs zu dem Zeitpunkt wo der Mief aktuell war. v0v

Nightspider

2024-02-06, 20:27:11

Du meinst die Engine, die gerade erst von vorne bis hinten auf Low Level API und DX12 für Multithreading umgestellt wurde, 16 Threads gleichmäßig auslasten kann und gerade noch auf Vulkan optimiert wird?

Richtig altmodisch die Engine. ^^

ist vermutlich nicht die Hardware schuld...

Schuld? Was willst du damit eigentlich sagen? Der X3D läuft ein gutes Stück schneller als der 7700X ohne Tuning.

Jede Software verhält sich etwas unterschiedlich.

Von "Schuld" zu sprechen ist doch etwas albern.

latiose88

2024-02-07, 08:20:40

Mal schauen ob die CPU alleine noch was bewegen kann wenn CPU Cache und RAM nicht mehr limiteren und darum auch der extra cache an l3 auch nix mehr bewegen kann. Dann wird wohl die CPU also der Kern der CPU wohl zu schwach sein. Warum die Erkenntnis weil wenn sonst nix limitiert dann sollte die CPU rennen wie ein leopard, tut es aber nicht. Ich merke schon die software ist das Problem.

Aber selbst ich habe trotz der schlechten Software noch immer Steigerungen. Also unmöglich ist also garnix wenn man die Software mit cpu leistung erschlägt. Dann kommt am Ende doch noch Leistung dann raus.

Zossel

2024-02-07, 08:25:35

Mal schauen ob die CPU alleine noch was bewegen kann wenn CPU Cache und RAM nicht mehr limiteren

Bei den Latenzen von DRAM tut sich schon seit Jahrzehnten nichts signifikantes.

latiose88

2024-02-07, 08:37:46

Naja cl28 ist ja nun nicht langsam wenn man bedenkt wie hoch der RAM so taktet oder meinst du damit was anderes damit?
Villeicht rettet mir ja ddr6 wieder etwas. Aber es wird immer weniger. Ich rechne mit 1 % mehr leistung durch mehr RAM takt und so.

Wie ich drauf komme ist ganz klar von ddr3 auf ddr4 gab es ursprünglich 10 % mehr leistung, dank dem RAM. Dann kam Zen 3 und der RAM mehrleistung reduziere sich auf 4 %. Ich denke mal das am mainbaord sich was verändert hatte. Bei am5 waren es 2 % mehr leistung dank den RAM.
Beim Cache was mehr leistung bei mir geführt hatte weiß ich nicht. Aber auf jedenfall nicht viel wie es aussieht.
Ich habe aber auch Programm da bewegt sich noch was. Wie winrar oder 7zip. Aber dann war es das auch schon wieder was ram angeht.
Ich würde mir mehr leistung durch mehr RAM durchaus wünschen. Dann lohnt sich auch mehr für den RAM auszugeben. Aber so macht das halt nicht so viel sinn.
Ich versuche alles mögliche um mehr leistung raus zu bekommen. Nur leider macht es das eben leider nicht mit.

woodsdog

2024-02-07, 08:45:06

Du meinst die Engine, die gerade erst von vorne bis hinten auf Low Level API und DX12 für Multithreading umgestellt wurde, 16 Threads gleichmäßig auslasten kann und gerade noch auf Vulkan optimiert wird?

Richtig altmodisch die Engine. ^^

Schuld? Was willst du damit eigentlich sagen? Der X3D läuft ein gutes Stück schneller als der 7700X ohne Tuning.

Ändert halt einfach mal gar gar nix an meiner Aussage.

Nur weil die 5 Jahre lang gebraucht haben (Das Ticket im Progress Tracker war allein 138 Wochen alt...) Dx12 in ihre Alte CryEngine 3 rein zu hacken, macht es das nicht "modern". Der Schmutz läuft wie absolute Grütze, egal was du an Hardware druff wirfst. Aber das ist ein anderes Thema was unter anderem mit dir eh keinen Sinn ergibt zu besprechen.

Das es auf x3D Chips überhaupt so riesen Unterschiede macht stimmt eher bedenklich bei dem Alter. Das sollte dick 3-stellig rennen bei der angestaubten Optik.

Nightspider

2024-02-07, 16:03:28

Dein Star Citizen Hate ignoriere ich mal, der gehört in den dafür vorgesehen Hate-Thread.

Hier gehts um Prozessoren.

Leider gibts kaum Tests zu finden wo aufs äußerste getunte 8C Zen CPUs gegen ihre X3D Pendants+Tuning antreten.
Da gibts bestimmt auch noch andere Spiele, wo die X3D Varianten bei den 1%lows hinten liegen.

Das es auf x3D Chips überhaupt so riesen Unterschiede macht stimmt eher bedenklich bei dem Alter.

Also deine Meinung lautet: Je älter die Software ist, desto geringer sollte der Vorteil des zusätzlichen L3 Caches sein?

Gibt es denn deiner Meinung nach viele alte Spiele mit Low Level API, die 16 CPU Threads gleichmäßig auslasten können? :freak:

egal was du an Hardware druff wirfst.

Wieso kommen dann unterschiedliche fps heraus, je nachdem welche Hardware verbaut ist? =)

Haters gonna hate.

iamthebear

2024-02-08, 23:23:16

Wie der L3 performt hängt von der Datenmenge ab die pro Frame benötigt wird. Diese sollte in den L3 passen.

Klar ist es ab einem gewissen Punkt so, dass diese Datenmenge so groß ist, dass selbst die 96MB VCache fast keinen Unterschied mehr machen aber das sind wirklich Ausnahmen.

In der Regel ist es so, dass Spiele mit größeren Datenmengen stärker vom VCache profitieren also der Nutzen mit der Zeit steigt.
Das hat man auch gut bei den Computerbase Reviews des 5800X3D gesehen. Beim Launch Review und veraltetem Parkour waren es noch 15%, mit neuerem Parkour schon um die 30%.

robbitop

2024-02-09, 08:36:25

So ist es. Wenn der X3D kaum was bringt ist es eher ein Zeichen dafür (in typischen Spielen) dass die Hitrate auch ohne X3D schon sehr hoch war und nicht mehr der dominierende Flaschenhals ist.

Zossel

2024-02-09, 10:36:57

So ist es. Wenn der X3D kaum was bringt ist es eher ein Zeichen dafür (in typischen Spielen) dass die Hitrate auch ohne X3D schon sehr hoch war und nicht mehr der dominierende Flaschenhals ist.

Gute Hitraten von Caches können auch durch die Art der Programmierung unterstützt werden. Das ist nicht zwingend alles vom großen Wumba-Tumbo so vorgegeben.

https://www.google.com/search?q=cache+friendly+code

latiose88

2024-02-09, 14:35:16

Ja ich habe eine gute Bitrate sogar bei meinen Zen 3 war sie gut gewesen. Daran liegt es nicht. Was kann man dann noch erwarten wenn die hitrate sehr gut ist und sagen wir mal zu 99,99% liegt und der Rest bei 0,01% eine missrate ist. Wie kann man sonst noch die Leistung beschleunigen also so das das Programm noch beschleunigt wird. Oder gibt es da dann so ne Grenze dann? Also die hitrate ist sogar bei l1 Cache auf l2 Cache gewsen. Ich müsste mal sehen ob l1 Cache eine perfekte hitrate hat. Denn da kann man dann wenn diese da nicht perfekt ist, ja noch eine steigerung erwarten.

Zossel

2024-02-09, 14:56:00

latiose88

2024-02-09, 15:42:11

Ja dann wird es wohl der Chip selbst sein. Weil bei RAM Steigerung ist auch nicht mehr so hoch wie damals. Also ist die volle boost an Cache also keine Bandbreiten Limitierung. Nur der Chip ist zu langsam um diese voll auszuschöpfen. Na da kann ja durchaus Zen 5 etwas bewegen. Vileleicht kann dieser ja die volle Bandbreite ja dann ausschöpfen, wer weiß.

mboeller

2024-02-10, 20:14:27

im anandtech-forum diskutieren sie über die GCC-Patches für Zen5:

https://forums.anandtech.com/threads/zen-5-discussion-epyc-turin-and-strix-point-granite-ridge-ryzen-8000.2607350/page-278#posts

link:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240210/b2991675/attachment-0001.obj

edit: https://www.phoronix.com/news/AMD-Zen-5-Znver-5-GCC

robbitop

2024-02-10, 21:22:09

Nur 4 wide decode? Es hieß doch Zen 5 würde erstmalig breiter werden und man ging von 6 wide aus. Aber die Leute aus dem oh Forum lesen 4x decode heraus.

Gipsel

2024-02-11, 01:22:39

Nur 4 wide decide? Es hieß doch Zen 5 würde erstmalig breiter werden und man ging von 6 wide aus. Aber die Leute aus dem oh Forum lesen 4x decode heraus.Offiziell von AMD hieß es bisher zu Zen5 "Re-pipelined front end and wide issue".
Prinzipiell kann das bedeuten, daß das Frontend tatsächlich bei 4 Decodern bleibt, während der Kern (auf Integerseite) auf 6 ALUs, 4 AGUs und 8 wide rename/dispatch aufgebohrt wird (wie aus Leaks [und auch aus den gcc-Patches abzulesen ist]).
Man sollte nicht vergessen, daß die Anzahl der Decoder bei Code der aus dem µOp-Cache kommt, nicht limitiert (der µOp-Cache kann schon bei älteren Zens 8µOps pro Takt liefern (bei Zen4 9µOps/Takt, der faßt bei Zen4 etwa 7k µOps), auch wenn dispatch auf 6µOps/Takt limitiert ist). Zudem können AMDs Decoder traditionell ab und zu auch mal mehr als 1 µOp pro Takt ausspucken (FastPath Doubles). Was sich genau ändert, wird man sehen müssen. "Re-pipelined front end" auf der offiziellen AMD-Folie kann auch bedeuten, daß es weniger Strom zieht und/oder man höheren Takt fahren kann. Aber vielleicht hat man auch eine ganze Menge umgekrempelt.

Leonidas

2024-02-11, 07:41:38

Denkbarerweise 4x512b FP bei Zen5:
https://twitter.com/InstLatX64/status/1756450975496183820

mehr:
https://www.mersenneforum.org/showthread.php?t=29290

fondness

2024-02-11, 08:57:11

Offiziell von AMD hieß es bisher zu Zen5 "Re-pipelined front end and wide issue".
Prinzipiell kann das bedeuten, daß das Frontend tatsächlich bei 4 Decodern bleibt, während der Kern (auf Integerseite) auf 6 ALUs, 4 AGUs und 8 wide rename/dispatch aufgebohrt wird (wie aus Leaks [und auch aus den gcc-Patches abzulesen ist]).
Man sollte nicht vergessen, daß die Anzahl der Decoder bei Code der aus dem µOp-Cache kommt, nicht limitiert (der µOp-Cache kann schon bei älteren Zens 8µOps pro Takt liefern (der faßt bei Zen4 etwa 7k µOps), auch wenn dispatch auf 6µOps/Takt limitiert ist). Zudem können AMDs Decoder traditionell ab und zu auch mal mehr als 1 µOp pro Takt ausspucken (FastPath Doubles). Was sich genau ändert, wird man sehen müssen. "Re-pipelined front end" auf der offiziellen AMD-Folie kann auch bedeuten, daß es weniger Strom zieht und/oder man höheren Takt fahren kann. Aber vielleicht hat man auch eine ganze Menge umgekrempelt.

Ich würde es mal so formulieren: Nichts ist einfacher, als mehr Decoder zu verbauen. Wenn die in irgendeiner Situation limitieren würden, würde man sicherlich mehr verbauen.

][immy

2024-02-11, 10:14:49

Gute Hitraten von Caches können auch durch die Art der Programmierung unterstützt werden. Das ist nicht zwingend alles vom großen Wumba-Tumbo so vorgegeben.

https://www.google.com/search?q=cache+friendly+code
Ja und nein. Es kommt halt auch darauf an, wie viel du parallel ablaufen lässt. Bei Nutzung nur eines Threads lässt sich das ja noch gut überblicken. Bei Nutzung von vielen Threads wird es aber schnell unübersichtlich und hier kommt es dann auch eher mal zu Situationen wo der cache einfach nicht für alle Parallelen Aufgaben aus reicht.

Aber ja, wenn du allgemein schon cache freundlich schreibst, sollte es auch da weniger problematisch werden.
Angefangen wird es aber meist dadurch, das man trotzdem nur einen thread hat, der die Hauptlast am ende trägt.
Fragt sich halt auch, ob es sich nicht mal lohnen würde auch die anderen Caches zu vergrößern. L3 bietet sich ja eher dadurch an, das er allen Kernen gleichzeitig zur Verfügung steht.

Zossel

2024-02-11, 10:30:50

[immy;13489002']Ja und nein.

Den Konjunktiv in meinem Post hast du gefunden?

CrazyIvan

2024-02-11, 11:38:19

Den Konjunktiv in meinem Post hast du gefunden?
Ich will nicht klugscheißen, aber der Konjunktiv von "können" lautet ebenfalls "können" oder gebräuchlicher "könnten" - war also mindestens schwer erkennbar :wink:

Nightspider

2024-02-11, 14:06:29

[immy;13489002'].
Fragt sich halt auch, ob es sich nicht mal lohnen würde auch die anderen Caches zu vergrößern.

Zumindest die Verdoppelung des L2 bei Zen4 hat kaum etwas gebracht.

vinacis_vivids

2024-02-11, 15:07:31

Zumindest die Verdoppelung des L2 bei Zen4 hat kaum etwas gebracht.

Nachweis ?

latiose88

2024-02-11, 15:07:50

jap kann ich bestätigen.Ob L1 Cache vergrößerung was bringt,ist so ne Frage an sich.

Und fakt ist durch die breiteren Kerne,kann nun mehr Befehle auf Einmal abgearbeitet werden.Das heißt mehr Aufgaben.Wenn nun 2x die selben Programme gleichzeitig starten und aufgrund nicht so breiter kerne,gebremst worden waren,müsste es nun wahnsinnig beschleunigt ablaufen.Ob das wirklich so ist,wird sich zeigen.Die e Kerne von Intel sind ja etwas schmaler,aber der Software scheint es egal zu sein und so liefert so ein 14900k die selbe Leistung in meinem Fall ab wie ein ryzen 9 7950x obwohl dieser eigentlich klar überlegen ist.
Scheinbar spielt noch ein faktor eine Rolle.Ich kann nur nicht sagen was,aber man sieht schon klar ,das es nicht ganz so einfach ist.Einfach breiter zu machen,ist nicht alles für mehr Leistung.
Villeicht bringt es ja bei weniger Kerner etwas,wer weis.Das wäre schon interessant bei welchen Kernen ein breiter ein Vorteil wäre.
Das wäre als wenn man fragen würde wo es mehr leistung dabei raus kommt.Bei 8 kleinen Kernen oder bei 8 breiteren Kernen.Das wird dann sobald neben AMD auch Intel raus gebracht hat,auch zeigen was wirklich mehr bringt.Ich lasse mich da einfach überraschen.

PS:meine Software ist cache Freundlich,also hat immer ne gute Hitrate.Darum kann ich genau sagen ,das die Leistung gut durch kam.ALso ich da bei wem fast den selben Takt wie bei meinem Zen 3 habe laufen lassen,gab es selbst dann noch eine Leistungssteigerung.Die war aber dennoch sehr gering gewesen.Meinen Ryzen 9 5950x habe ich mit 3,8 ghz am Laufen.Den Ryzen 9 7950x mit 3,9 ghz.Es waren also am Ende nur sehr wenige % mehrleistung gewesen.Zieht man die Vorteile durch den Ram ab,sind es gewiss so 3% Leistungsunterschied noch gewesen.Darum kann ich sagen,der L2 Cache beeinflusste die Leistung nicht wirklich.

vinacis_vivids

2024-02-11, 15:28:39

Wo sind die Messwerte ?

latiose88

2024-02-11, 15:33:54

Meinst du mich damit? ALso es ist ja schwer den Cache zu reduzieren.Den Test habe ich ohne Video gemacht gehabt.Ich habe zwar Bilder davon,aber das alleine Nützt ja nix.ALso wie soll man aufzeigen das es ohne dem Cache die Steigerung gab?

woodsdog

2024-02-11, 16:02:49

ich hatte bei "Wenn nun 2x die selben Programme gleichzeitig starten und aufgrund nicht so breiter kerne,gebremst worden waren,müsste es nun wahnsinnig beschleunigt ablaufen." aufgehört zu lesen. :wink:

latiose88

2024-02-11, 16:23:37

Ja was soll ich sagen.Habe halt alle Ergebnisse eines Programms da vorliegen.Aber gut ein Programm alleine sagt für die breite masse eben nicht so viel aus.
Aber solche wie ich wollen halt alles aus einer CPU heraus holen.Da kann die Leistung nicht gut genug sein.Und ja ich mache das wirklich mit 2 x die selbe Software gleichzeitig starten.Das ist mein Workflow.Mit nur einem Programm gleichzeitig gebe ich mich nicht zufrieden.Es muss ordentlich durgezogen werden.Es müssen ordentlich beschleunigt werden.Damit da noch schneller berechnet wird.Und da könnte Zen 5 durchaus in die richtung gehen.
Ich habe es darum so fomoliert weil auch die Intels CPUS mit ziehen können.Wobei so klein die e Kerne auch nicht sind,wie ja so einige geschrieben hatten.
Das können also nur die nachfolgenden CPUS zeigen.Ich bin jedenfalls bereit für noch mehr CPU Leistung.
Ich bin voll auf die CPU Leistung angewiesen. Cache Freundlich ist meine Anwendung,das heißt die skaliert mit den L Cache schon Perfekt.Ram ebenso,weil nicht mehr so steigerbar wie ich mir erhofft hatte.Ich habe wohl zu viel von ddr4 auf ddr5 erhofft gehabt.
Da nun also der Chip alleine Limiert,wird es mir wohl am meisten was bringen.
Warum das,na von der Software kommt nicht mehr viel,bei Optimierung raus.

Hier kann also nur noch CPU Leistung was bringen.Damit das geht,heißt es immer mehr CPU Leistung.Besser mehr als weniger.Ob das immer breiter werden der Kerne wirklich was hilft,bin ich mir da nicht so sicher.Aber ich lasse mich ja eines besseren belehren.
Solange also mehr CPU Leistung dabei rum kommt,ist es mir eigentlich egal wie es entstanden ist,hauptsache ich sehe mehr Leistung dabei rum kommen.

basix

2024-02-11, 16:25:43

Denkbarerweise 4x512b FP bei Zen5:
https://twitter.com/InstLatX64/status/1756450975496183820

mehr:
https://www.mersenneforum.org/showthread.php?t=29290

Wäre das dann auch 8x 256b AVX2? Je nach Programm wäre das ein grosser Boost, auch ohne AVX512.

robbitop

2024-02-11, 16:31:09

Wo sind die Messwerte ?

Dazu gibt es direkt von AMD was:
https://pics.computerbase.de/1/0/4/8/0/3-7c1cab386ec69bad/2-1080.21f3721f.png

Ein Fitzelchen der +13% IPC kommen vom doppelten L2. Grob ~1/10 dieses Balkens. Also grob +1…1,5% IPC.

latiose88

2024-02-11, 16:39:48

ALso aufgut deutsch fast in messtolleranz.1-1,5 % sind halt nicht viel durch den L2 Cache.Dann könnte auch der L1 cache auch nicht mehr so viel mehr rein hauen.
Was interessant wäre,wenn nun der L3 cache halbiert wird wie bei 5700g und so,wie viel wohl dann der doppelte L2 Cache dann abfangen könnte.Weil ich merkte da schon einen Unterschied ob es 16 MB oder 32 MB an L3 Cache wären.Naja das lässt sich wohl schlecht testen.
Da sehe ich dann auch den meisten Gewinn dann.Nun ja wird sich ja bei den C CPUS wie doppelte Kerne mit weniger L3 Cache ja durchaus dann auch zeigen.

Gipsel

2024-02-11, 16:43:06

Denkbarerweise 4x512b FP bei Zen5:
https://twitter.com/InstLatX64/status/1756450975496183820

mehr:
https://www.mersenneforum.org/showthread.php?t=29290

Laut den Patches sind es 2x ADD + 2x MUL wie bei Zen4.
Aber die Änderung bei gcc bezüglich der Dekodierung von AVX512-Befehlen von FastPath-Doubles zu FastPath-Singles ("direct", wie gcc das nennt), sagt nicht unbedingt das aus, was da bei Twitter von InstLatX64 gepostet wurde. Zum einen steht da explizit dran, daß das noch nicht final ist und noch mit den Informationen zu FastPath Doubles geupdatet werden muß (";; Fix me: Need to revisit this later to simulate fast path double behavior.") und zum anderen ist die Kodierung in einzelne µOps (statt einem Paar) nicht unbedingt an die Breite der Ausführungseinheiten gekoppelt. Auch single µOps für 512bit Operationen könnten auf 256bit-Einheiten geloopt werden (dafür benötigt man nicht unbedingt die Enkodierung als Doubles). Insbesondere, falls es eine Stromsparversion von Zen5(c) mit 256bit-Einheiten geben sollte, vermute ich stark, daß die Encoder gleich bleiben und das nur in den FPU-Einheiten doppelt so lange dauert.
Lustigerweise macht sogar Zen4 das schon. Also wenn man AMDs Zen4 Optimierungs-Manual glaubt, werden die üblichen AVX512-Befehle (unabhängig von der Vektorbreite, komplexere Befehle sind auch mit 128 oder 256Bit doubles) von den Decodern tatsächlich bereits bei Zen4 als Fast-Path-Singles übersetzt (und nicht in Doubles, wie gcc meint), was Platz im µOp-Cache spart und auch das Scheduling effizienter macht (nur die halbe Anzahl an Instruktionen zu verwalten). Dies führt (bei gleicher Auslastung) zu einem etwas geringeren Stromverbrauch (bzw. höherem Takt) mit AVX512 statt AVX256. Sagt das Optimierungsmanual und haben Chips 'n Cheese auch so nachgemessen. GCC hat das für Zen4 also wohl einfach nur falsch drin (könnte zu minimal ineffizienterem Code führen).

Kurz: Es ist konsistent mit Hinweisen aus anderer Quelle, daß Zen5 512bit Datenpfade in der FPU besitzt bzw. besitzen kann (trotzdem sind 256bit FPUs in einer Zen5c-Variante denkbar, ohne den Decoder zu ändern).

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

Ich würde es mal so formulieren: Nichts ist einfacher, als mehr Decoder zu verbauen. Wenn die in irgendeiner Situation limitieren würden, würde man sicherlich mehr verbauen.Ich vermute mal, da würden Dir die CPU-Designer bei intel und AMD sanft widersprechen. Das ist bei x86er-CPUs notorisch schwer durch die doch sehr komplexe ISA (die aber anderswo Vorteile hat).

Gipsel

2024-02-11, 16:59:12

Wäre das dann auch 8x 256b AVX2?Nein. Es bleibt bei 4 FP-Pipes (für die wesentlichen Berechnungen), 2x MUL/FMA + 2x ADD.

basix

2024-02-11, 17:13:28

Hatte ich mir schon gedacht. Wäre extrem viel Vektor-Throughput für einen CPU Core.

Leonidas

2024-02-11, 17:40:54

Schade. Aber Deine Rede ergibt Sinn. Danke für die Klarstellung.

Gipsel

2024-02-11, 17:58:26

Schade. Aber Deine Rede ergibt Sinn. Danke für die Klarstellung.Es ist schon wahrscheinlich, daß die FPU-Pipelines schlicht verdoppelt werden (nur die Hälfte der Pipelines zu verdoppeln wäre schräg, wenn auch theoretisch möglich). Man kann es aber aus dem gcc-Patch nicht ablesen.

Zossel

2024-02-11, 20:02:42

Kurz: Es ist konsistent mit Hinweisen aus anderer Quelle, daß Zen5 512bit Datenpfade in der FPU besitzt bzw. besitzen kann (trotzdem sind 256bit FPUs in einer Zen5c-Variante denkbar, ohne den Decoder zu ändern).

Es kann auch nur sein das jetzt 512 Bits/cycle statt 256Bit/cycle geschrieben werden kann.
Breite Vektorunits kosten Takt bzw. saufen wie ein Loch.

Gipsel

2024-02-11, 21:05:44

Es kann auch nur sein das jetzt 512 Bits/cycle statt 256Bit/cycle geschrieben werden kann.Das scheint sicher so zu sein. Aber ich denke, daß zusätzlich auch tatsächlich die Vektoreinheiten verbreitert wurden.
Breite Vektorunits kosten Takt bzw. saufen wie ein Loch.In Anbetracht der Zeiträume, in der diese Entscheidungen getroffen werden, erwarte ich eine Anpassung oder gar eine Umkehr in Frage des Stromverbrauchs der Kerne bei AMD und intel (wobei intel ja anscheinend auch ordentlich an ihren neuen Kernen schraubt, also mal sehen). AMD hat ja pro Kern nur die Hälfte verbraucht, selbst wenn AMD ziemlich hart gepusht hat. Es ist also denkbar, daß AMDs Pläne vorsahen, den Spielraum zu nutzen, um 512bit-Vektoreinheiten zu verbauen (Zen4 war ja auch schon auf höheren Takt ausgelegt, und hatte mehr Takt- und Verbrauchs-Spielraum nach oben). Daß intel im Consumermarkt die 512bit-Einheiten in den P-Kernen zuerst deaktiviert hat (statt AVX512-Support in die E-Cores einzubauen [per Ausführung auf schmaleren Einheiten]) und in näherer Zukunft gar einzusparen scheint (mittelfristig wird es aber wohl wiederkommen), ist ja quasi ein Witz und außer mit einer Überreaktion kaum rational zu erklären.

latiose88

2024-02-11, 21:07:13

ja das erklärt auch warum die Taktraten sinken wenn man AVX 512 nutzt.Ich selbst habe das noch nie erlebt gehabt weil ich auch keine AVX 512 Software nutze.Warum das weil ich keine Ps3 Emulation verwende.Bei AVX 256 kann dann die CPU die Volle Taktraten fahren also die volle Leistung.FInde es spannend ob AMD hier mehr AVX 256 die 512 aufteilen kann.Ob das für mehr Leistung führt,bin ich mir da nicht so sicher.
Diese Aufteilung wäre ja wenn man nur entweder oder verwenden kann,wie bei Intel dann.

Gipsel

2024-02-11, 21:23:06

ja das erklärt auch warum die Taktraten sinken wenn man AVX 512 nutzt.Auf AMDs Zen4 bisher eher nicht der Fall (Takt meist sogar leicht höher bei gleichem Auslastungsgrad der Vektor-ALUs).
FInde es spannend ob AMD hier mehr AVX 256 die 512 aufteilen kann.Wie schon gesagt, ändert sich die Anzahl der FP-Pipelines nicht, der Peak-Durchsatz mit 256bit Instruktionen wird mit Zen5 also geringer ausfallen als mit 512bit (bei Zen4 ist er identisch zwischen 256 und 512bit, 512bit spart aber etwas Verbrauch, weil weniger Overhead weil weniger Instruktionen).
Ein "Aufteilen" von 512bit Pipelines gibt es nicht.
Diese Aufteilung wäre ja wenn man nur entweder oder verwenden kann,wie bei Intel dann.Auch bei intel nicht.

latiose88

2024-02-11, 22:00:51

aha ok,dann wohl missverstanden.DAs heißt je weniger AVX verwendet wird,desto mehr Strom braucht die CPU.Also sprich wenn nur ein wenig AVX2 verwendet wird,dann braucht die CPU also am meisten Strom.Und kann dann weniger Befehle ausführen.Oder missverstehe ich das.Werden intern noch mehr Befehle außer MMX,AVX und so ausgeführt oder sieht man das alles was so stattfindet?Ich weis das das ja alles Befehle sind.ALso je weniger davon verwendet wird,desto weniger Instruktionen werden von der CPU angefordert.

Ich habe mir mal die Intel CPUS so angeschaut und hat auch deutlich mehr Durchsatz bei den Befehlen.Soweit ich gesehen habe 512 davon.AMD hat bisher ja nur 320 EInträge.Scheinbar sagt das alles nix aus um mehr Leistung zu liefern.Ich scheine mich wohl zu viel erwartet zu haben.
Auch hat Intel mehr L1 Cache als AMD.Dies scheint wohl bei meiner Anwendung auch kein wirkung zu haben.Wenn der L1 Cache eine Rolle spielen würde,würde die Leistung richtig Explodieren.

Nun aber scheint aber jede CPU anderst mit den Registern usw zu Arbeiten.AMD scheint damit deutlicher die Leistung umzusetzen.

Denn senkt man Intels CPU auf dem Level von Takt auf ein normales Level,dann sinkt die Leistung richtig abwärts.Es stimmt also das ein zu breite CPU nix bringt.
Der Cache mag eine Wunderwaffe zu sein,aber halt nicht für jede Anwendung.
Nun wie es weiter gehen wird,das sehe ich dann schon,bei den nachfolgenden kommenden CPUS.

Gipsel

2024-02-11, 23:04:26

Ja, Du mißverstehst so Einiges.
Z.B. hat die Größe des ROB (320 bei Zen4) nur mittelbar was mit dem Thema zu tun (oder mit dem "Durchsatz bei den Befehlen" in diesem Zusammenhang). Ich würde Dir empfehlen, erst mal ein paar Grundlagen nachzulesen.

latiose88

2024-02-11, 23:25:17

naja viel mehr habe ich nicht gefunden bei Intel,weder wie groß das Frontenend noch die FP durchsatz wäre.Da schweigt Intel mehr.AMD ist da halt offener.Wollte halt einen direkten Vergleich daraus ziehen und wissen,wie sich so unterschiedliche Archetekturen zu einem ähnlichen Ergebnis oder fast gleich führen kann.Aber Intel macht es einen nicht leicht ,wenn man die ganze Archetektur genau wissen will.

Der_Korken

2024-02-11, 23:38:02

Dazu gibt es direkt von AMD was:
https://pics.computerbase.de/1/0/4/8/0/3-7c1cab386ec69bad/2-1080.21f3721f.png

Ein Fitzelchen der +13% IPC kommen vom doppelten L2. Grob ~1/10 dieses Balkens. Also grob +1…1,5% IPC.

Ich denke, dass es schwierig ist, den Einfluss des L2 genau zu beziffern. Selbst wenn es in ST-Anwendungen nicht viel bringt, könnte bei MT der Druck auf den L3 gesunken sein, was Energie spart oder Bandbreitenprobleme löst, wenn alle Kerne gleichzeitig aus dem L3 lesen wollen. Für 1,5% mehr Performance wird AMD jedenfalls nicht 5% Fläche (blind geschätzt) investieren.

Es kann auch nur sein das jetzt 512 Bits/cycle statt 256Bit/cycle geschrieben werden kann.
Breite Vektorunits kosten Takt bzw. saufen wie ein Loch.

Das habe ich mich auch gefragt. Bei der Zen-4-Vorstellung wurde afaik sogar auf der Bühne gesagt, dass man keine 512-bit-breiten Pfade verwendet hat, weil die Taktraten sonst nicht möglich gewesen wären. Ich kann mir nicht vorstellen, dass man das ganze Restdesign ausbremst, nur damit so eine Nischenanwendung wie Full-AVX512 schneller läuft. Man hat in den Phoronix-Tests gesehen, dass Zen 4 bereits in seiner "Billig"-Implementierung massiv von der Befehlssatzerweiterung profitiert (afaik sogar mehr als Intel!), d.h. die läuft alles andere als langsam. Wenn der Rechendurchsatz ein großer Bottleneck wäre, hätte AMD auch ein drittes ALU-Paar einbauen können, denn davon würden alle anderen FP-Befehle auch profitieren. Zumal ja auch die Datenleitungen der Caches verdoppelt werden müssten, um die ganzen Single-Cycle-Load/Stores überhaupt bedienen zu können.

-------

Apropos Cache: Für Zen 5 eher unwahrscheinlich, weil vieles auf einen 48kB L1D hindeutet, aber wäre es prinzipiell sinnvoll den L1D auf INT und FP aufzuteilen? Alle Loads in INT-Register werden aus dem INT-L1D bedient und analog die FP-Register aus dem FP-L1D. Der Vorteil wäre, dass man den INT-Cache schlanker machen und dabei mehr auf Latenz optimieren könnte, während der FP-Cache weniger Ports aber dafür breitere Leitungen bräuchte. Die einzelnen Caches wären auch sehr viel weniger komplex und könnten selbst bei den bisherigen 32kB die Hitrate erhöhen, sofern der ausgeführte Code nicht ausschließlich INT oder FP beinhaltet (und somit nur ein L1D effektiv genutzt wird). Der neue 12-way 48kB L1D mit 4 Leseports muss in jedem Cycle ja mal eben 48 parallele Tag-Vergleiche schaffen, während der alte 8-way 32kB L1D nur 3*8 = 24 Vergleiche schaffen musste.

latiose88

2024-02-12, 00:21:04

Das sind doch bisher 2x32 kb Cache,aufgrund 2 Chiplet.Mit dem neuen wären es also dann 2x48 kb L1 Cache.Damit würde AMD so viel Anbieten wie es bei Intel der fall ist.

Ok FP ist also die AVX Einheiten.Zählt es auch wenn FP dann bei 256 bit nur 5% nutzt und sonst nut Int Register bedient schon als alle beide oder heißt mit Auschließlich nur eines von beiden und den anderen Quasie bei 0%?

Der_Korken

2024-02-12, 00:35:19

Das sind doch bisher 2x32 kb Cache,aufgrund 2 Chiplet.Mit dem neuen wären es also dann 2x48 kb L1 Cache.Damit würde AMD so viel Anbieten wie es bei Intel der fall ist.

:uconf:

Jeder Kern hat seinen eigenen L1D. Mit Betonung auf "D", es gibt ja noch den L1I (für instructions).

Ok FP ist also die AVX Einheiten.Zählt es auch wenn FP dann bei 256 bit nur 5% nutzt und sonst nut Int Register bedient schon als alle beide oder heißt mit Auschließlich nur eines von beiden und den anderen Quasie bei 0%?

Wenn du es genau wissen willst: Wenn der Programmcode so viel INT beinhaltet, dass mehr als 2/3 des L1D (also mehr als 32kB von 48kB) mit Inhalten für INT-Register belegt sind, dann hätte ein zentraler L1D mit 48kB Größe Vorteile gegenüber zwei getrennten INT/FP 32kB-Caches.

Allerdings könnte das getrennte Layout selbst in diesem Fall schneller sein, weil der spezialisierte INT-Cache bessere Latenzen und/oder geringeren Verbrauch gegenüber dem Alleskönner-Cache hätte. Ich weiß nur nicht, ob es technische Gründe gibt, warum man den L1D nicht sinnvoll trennen kann oder ob es sich nicht lohnt, weil zu viele Daten am Ende in beiden Caches liegen (weil sie sowohl für INT als auch FP gebraucht werden).

latiose88

2024-02-12, 01:04:20

Gipsel

2024-02-12, 01:06:32

Apropos Cache: Für Zen 5 eher unwahrscheinlich, weil vieles auf einen 48kB L1D hindeutet, aber wäre es prinzipiell sinnvoll den L1D auf INT und FP aufzuteilen? Alle Loads in INT-Register werden aus dem INT-L1D bedient und analog die FP-Register aus dem FP-L1D. Der Vorteil wäre, dass man den INT-Cache schlanker machen und dabei mehr auf Latenz optimieren könnte, während der FP-Cache weniger Ports aber dafür breitere Leitungen bräuchte. Die einzelnen Caches wären auch sehr viel weniger komplex und könnten selbst bei den bisherigen 32kB die Hitrate erhöhen, sofern der ausgeführte Code nicht ausschließlich INT oder FP beinhaltet (und somit nur ein L1D effektiv genutzt wird).Zweifelhaft. Es gibt doch recht viel Code, wo sowohl die FPU/Vektoreinheiten und die Integereinheiten auf die gleichen (bzw. innerhalb einer Cacheline) Daten zugreifen. Deshalb müßte man dann bei jedem Schreibvorgang die Tags in beiden L1-D-Caches prüfen (und gegebenenfalls auch in beide schreiben) oder anderweitig (teuer) die Kohärenz zwischen beiden sicherstellen (durch die gleichen L/S-Queues muß man das sowieso schleusen, da kann man also auch nichts sparen). Ich denke nicht, daß sich das lohnt.

@latiose88:
Nein.

latiose88

2024-02-12, 01:10:34

auf was hast du denn mit nein geantwortet.Hättest es ja ruhig zietieren können.

Gipsel

2024-02-12, 01:12:41

auf was hast du denn mit nein geantwortet.Hättest es ja ruhig zietieren können.
Alles.

latiose88

2024-02-12, 01:21:00

Ja stimmt du hast recht,bei Intel sind es 80 kb L1 Cache(P Kerne) und 96 kb L1 cache(e Kerne).
Das ist dennoch mehr als es bei AMD so ist,weil die haben ja im moment 64 KB Pro Kern.
Aber auch bei L2 Cache hat Intel ja mehr.
Nun weis ich ja das es als gemeinsamer Cache dagestellt wird.Aber intern doch auf zwei ebene Augeteilt wird.Intel hat also noch immer mehr L1 Cache als AND.Kann ich ja gerne zeigen,wenn das nicht reicht.
Nun weis ich das die Instrukion Cache auch ne Rolle spielt.Das könnte in der Tat für mehr Leistung führen und die Abhängigkeit von L3 weiter minimieren.

dargo

2024-02-12, 07:53:04

Angeblich wurden die ersten Schätzungen bei der höheren IPC von Zen5 vs. Zen4 unterschätzt. Nun heißt es bis zu +30% in einigen Workloads.

XV2ZGmBzKO4

Schauen wir mal was am Ende bei rumkommt. Wobei ich Zen5 ohne X3D eh uninteressant finde. Aber anhand vom Zen5 kann man dann durchaus einschätzen wo ein späterer Zen5 X3D rauskommen wird.

Andi_90

2024-02-12, 08:19:40

Was am Ende rauskommt werden wir sehen.

Ich denke aber das wir wieder einen ordentlichen boost bekommen. Aus folgenden Gründen.

Zen1 = New Core, Zen 3 = New Core und Zen5 = new Core

Und der wahrscheinlich wichtigste Punkt ist, dass AMD jetzt zwei Core-Piplinies hat für verschiedene Einsatzzwecke. Vor Zen4 musste man einen sehr Blanced Design bauen, damit man Perf, Density und efficiency in einen Core-Design untergebracht hat. Da man jetzt aber Big-Core und die C-Core hat denke ich wird man den Designern freien lauf gegeben haben um den beste möglichen "Big" Core zu bauen. Alles was Desnity und efficiency braucht kann man mit Zen5C bedienen.

Daher erwarte ich schon einen erheblichen Perf zuwachs.

Der_Korken

2024-02-12, 10:32:22

Ok verstehe,dann hat also Intel von haus aus mehr L1 Cache weil diese 2x96 L1 Cache pro Kern zur Verfügung hat.ALso hier hat AMD noch viel Luft kann man so sagen.Ich denke mal AMD ist darum da schneller weil die Latenzen deutlich schneller sind als bei Intel es der Fall ist.Das erklärt auch warum sich Intel hier nicht wirklich absetzen kann.

Intel hat pro Kern 48kB L1D und 32kB L1I. Und du interpretierst in solche Architekturdetails viel zu viel rein in Bezug auf reale Benchmarks. Ja, AMDs L1D hat eine niedrigere Latenz als der von Intel, aber du kannst von außen nicht beurteilen, welcher Benchmark davon wie stark profitiert bzw. von Intels größerem Cache proftieren würde. Außerdem spielen hier so viele andere Faktoren rein, über die wir teilweise gar nichts wissen, dass es quasi unmöglich ist Vorhersagen für bestimmte Benchmarks zu machen. Allein schon, dass Intels ALUs andere Latenzen bzw. Bearbeitungszeiten haben als die von AMD oder dass Intel größere Queues für Loads und Stores hat, verschiebt das Optimum für eine optimale Cache-Konfiguration. Es würde mich nicht überraschen, wenn Zen 4 und Raptor Lake beide langsamer werden würden, wenn man ihre L1Ds vertauscht, weil die auf ihre eigene Umgebung zugeschnitten sind und mit anderen Parametern schlechter performen.

Zweifelhaft. Es gibt doch recht viel Code, wo sowohl die FPU/Vektoreinheiten und die Integereinheiten auf die gleichen (bzw. innerhalb einer Cacheline) Daten zugreifen. Deshalb müßte man dann bei jedem Schreibvorgang die Tags in beiden L1-D-Caches prüfen (und gegebenenfalls auch in beide schreiben) oder anderweitig (teuer) die Kohärenz zwischen beiden sicherstellen (durch die gleichen L/S-Queues muß man das sowieso schleusen, da kann man also auch nichts sparen). Ich denke nicht, daß sich das lohnt.

Daran dass da immer ganze Cache-Lines gelagert werden, habe ich nicht so richtig gedacht. Mein Gedankengang war eher, dass eine Speicheradresse mit einem INT-Wert wohl in den allerseltensten Fällen auch mal als FP interpretiert werden muss und man so einen guten Split des Adressraums bekommt, sodass man getrennt cachen kann (was imho immer besser ist als ein one-size-fits-all Cache).

Gipsel

2024-02-12, 11:12:00

Daran dass da immer ganze Cache-Lines gelagert werden, habe ich nicht so richtig gedacht. Mein Gedankengang war eher, dass eine Speicheradresse mit einem INT-Wert wohl in den allerseltensten Fällen auch mal als FP interpretiert werden muss und man so einen guten Split des Adressraums bekommt, sodass man getrennt cachen kann (was imho immer besser ist als ein one-size-fits-all Cache).Das macht man wie gesagt je nach Code sogar relativ häufig. Jedes Mal, wenn ein Stückchen Speicher irgendwo hinkopiert/initialisiert wird, machen das moderne Betriebssysteme und Compiler (ab einer bestimmten Größe) mit den Vektoreinheiten, auch wenn das Integerdaten sind (intel hatte damit mal [Performance-]Probleme, als schon ein paar Vektor-Instruktionen per Offset den Takt gesenkt haben). Und dann können die Vektoreinheiten ja Integer und FP, die Trennung wäre also vermutlich eher skalar<=>Vektor. Dazwischen umzuschalten bzw. Daten dazwischen zu transferieren gibt jetzt schon ein gewisses Penalty (wahrscheinlich aus Takt-/Latenz- bzw. Verbrauchsgründen und die Result-Forwarding-Netzwerke nicht völlig ausufern zu lassen). Wenn man dann jedes Mal noch einen der beiden L1-D-Caches (oder im worst Case beide) flushen oder zumindest die betroffenen Cachelines invalidieren müßte, wäre das schon blöd und würde sich negativ auf die Performance auswirken.

Ich glaube irgendwer hat mal versucht, die FPU direkt aus dem L2 zu füttern (ähnlich wie es beim P4 keinen klassischen L1-I mehr gab, sondern der Decoder direkt aus dem L2 gelesen hat). Aber das erfordert dann quasi einen Write-Through L1-D (oder zumindest selektives write-through, also ähnliche Checks wie bei zwei L1-D) und ist offenbar nicht konkurrenzfähig.
GPUs kommen damit weg (GCN und RDNA haben getrennte L1-vD$ und L1-sD$ [aus den L1-D$ ist irgendwann mal L0-D$ geworden, weil noch ein L1 eingeschoben wurde, aber egal]), weil dort andere [sehr laxe] Anforderungen an die Kohärenz gestellt werden.

Der_Korken

2024-02-12, 11:31:07

Das macht man wie gesagt je nach Code sogar relativ häufig. Jedes Mal, wenn ein Stückchen Speicher irgendwo hinkopiert/initialisiert wird, machen das moderne Betriebssysteme und Compiler (ab einer bestimmten Größe) mit den Vektoreinheiten, auch wenn das Integerdaten sind (intel hatte damit mal [Performance-]Probleme, als schon ein paar Vektor-Instruktionen per Offset den Takt gesenkt haben). Und dann können die Vektoreinheiten ja Integer und FP, die Trennung wäre also vermutlich eher skalar<=>Vektor. Dazwischen umzuschalten bzw. Daten dazwischen zu transferieren gibt jetzt schon ein gewisses Penalty (wahrscheinlich aus Takt-/Latenz- bzw. Verbrauchsgründen und die Result-Forwarding-Netzwerke nicht völlig ausufern zu lassen). Wenn man dann jedes Mal noch einen der beiden L1-D-Caches (oder im worst Case beide) flushen oder zumindest die betroffenen Cachelines invalidieren müßte, wäre das schon blöd und würde sich negativ auf die Performance auswirken.

Ja, INT/FP ist vielleicht der falschen Trennbegriff, weil es mir nicht um den logischen Datentyp geht, sondern darum, dass CPU-Kerne getrennte INT- und FP-Registerfiles haben. Hier könnte man ja theoretisch den L1D mitsamt Load/Store-Queues duplizieren für beide Registersätze. Aber wie du schon sagst: Wenn sich die beiden Caches ständig ihre Lines invalidieren, weil sie innerhalb der selben Cacheline unterschiedliche Stellen beschreiben, ist der Ansatz Quatsch. Und selbst wenn sie nur lesen, würden zu viele Cache-Lines dupliziert und somit der Größengewinn (teilweise) wieder aufgefressen.

Zossel

2024-02-12, 11:41:22

Mein Gedankengang war eher, dass eine Speicheradresse mit einem INT-Wert wohl in den allerseltensten Fällen auch mal als FP interpretiert werden muss und man so einen guten Split des Adressraums bekommt, sodass man getrennt cachen kann (was imho immer besser ist als ein one-size-fits-all Cache).

memcpy()

fondness

2024-02-12, 12:06:15

Und der wahrscheinlich wichtigste Punkt ist, dass AMD jetzt zwei Core-Piplinies hat für verschiedene Einsatzzwecke. Vor Zen4 musste man einen sehr Blanced Design bauen, damit man Perf, Density und efficiency in einen Core-Design untergebracht hat. Da man jetzt aber Big-Core und die C-Core hat denke ich wird man den Designern freien lauf gegeben haben um den beste möglichen "Big" Core zu bauen. Alles was Desnity und efficiency braucht kann man mit Zen5C bedienen.

Daher erwarte ich schon einen erheblichen Perf zuwachs.

Hm naja, das Argument habe ich jetzt schon ein paar mal gelesen, kann ich aber nur teilweise nachvollziehen. Immerhin verwenden die c-Cores das exakt selbe RTL-Design. Ergo jedes aufblähen von Zen 5 wirkt sich auch genauso auf Zen5c aus. Und bereits Zen4c ist für einen little Core durch seine dicke FPU die auch AVX-512 abdeckt nicht gerade winzig.

robbitop

2024-02-12, 12:14:39

basix

2024-02-12, 13:09:36

Vielleicht überlegt man sich ja zukünftig, die C cores doch etwas abzuwandeln. 512 bit single cycle und die 1 MiB L2 müssen ja nicht unbedingt sein.
Andererseits erkauft man sich damit das Umgehen der ganzen Schedulerkniffe, wo selbst Intel Probleme mit ihren E und P Cores hat.

Zumindest bleibt gegen aussen der Core deutlich ähnlicher und die Befehlssätze sind ganz identisch.

Ich denke aber nicht, dass man bei Zen 5c dort abspeckt. Mit dem deutlich dichteren packen werden die Vector-Units deutlich kleiner und mit N3E steigt die Logikdichte noch zusätzlich. Auch der L2$ wird mit N3E noch etwas "shrinken", weil der einen relativ hohen Logikanteil aufweist (vgl. mit dem L3$). Dito wird der L3$ kleiner werden, weil es auch dort Logik drin hat. Aber grundsätzlich stimme ich dir zu, dass nach dem L3$ der L2$ der nächste mögliche Abspeck-Kandidat wäre.

Wenn ich jetzt grob schätzen müsste:
- Zen 5 CCD in N4P wird ca. 75mm2 gross (Zen 4 = 66mm2) -> +1mm2 pro Core oder +40% (!), wenn man alles bis und mit L1$ anschaut
- Zen 5c CCD in N3E wird ca. 70mm2 gross (Zen 4c = 73mm2)

Und hier unterscheiden sich Zen 5 und Zen 5c nicht hinsichtlich FPU und L2$. Eine Halbierung des L2$ bei Zen 5c würde 6-7mm2 bringen (0.94mm bei Zen 4c für den ganzen L2-Block (https://www.semianalysis.com/p/zen-4c-amds-response-to-hyperscale)). OK, sind 10% Die Size. Doch man hat auch Nachteile, umso mehr weil auch der L3$ halbiert ist. Reduzierte Wärmeabfuhr könnte man auch nennen.

Gipsel

2024-02-12, 13:17:59

Und bereits Zen4c ist für einen little Core durch seine dicke FPU die auch AVX-512 abdeckt nicht gerade winzig.Ist Zen4c flächentechnisch nicht in etwa auf Gracemont-Level? Die Zen4 Kerne sind halt deutlich kleiner als intels P-Cores, so daß der relative Unterschied zwischen Zen4 und Zen4c kleiner ist als bei intel zwischen P- und E-Cores, aber absolut gesehen ist Zen4c schon sehr kompakt.

basix

2024-02-12, 13:20:26

ryan

2024-02-12, 13:30:55

Andi_90

2024-02-12, 14:29:30

Platos

2024-02-12, 15:18:59

Gipsel

2024-02-12, 15:34:11

Und was macht denn Gracemont zum little-core, Zen4c aber nicht ?Gracemont ist schmaler und hat weniger IPC als intels P-Cores. Zen4c ist identisch, taktet nur niedriger im Vergleich zu Zen4.

Am Ende ist es (beinahe bedeutungslose) Semantik. Was wichtiger ist, ist der unterschiedlichen ISA-Support und das merklich unterschiedliche Leistungsprofil zwischen intels P- und E-Cores, was den Support deutlich komplizierter macht als bei AMD, wo die Kerne bis auf den Takt quasi identisch sind.

Platos

2024-02-12, 16:21:53

Ach so, ja für mich sind das sinngemäss trotzdem "little cores", denn dadurch, dass sie weniger hoch takten (müssen), sind sie ja auch kleiner.

Aber bezüglich des Support: Intel hat doch inzwischen nicht mal mehr bei den grossen Kernen AVX512 support, von daher müssten sie m.M.n zuerst einmal überhaupt wieder welchen zurück bringen. Vlt. sollten sie das mal so machen, wie AMD es macht ("emulieren"), dann wäre der Support über alle Kerne doch sicher auch leichter.

Aber Intel bräuchte auch mal kleinere Big-Cores, dann könnten sie ihre Little-Cores so wie AMD einfach niedriger takten lassen. Ist auch wegen der IPC besser, würde ich sagen.

latiose88

2024-02-12, 16:54:36

Ja so schlecht sind die E kerne von Intel nicht.Zumindest bei meinen tests mit anderen brachten sie auch Leistung auf dem Tisch.Das ist zumindest ein guter Ansatz.Und das sie obwohl sie so etwas schmaler sind,könnten sie dennoch bis 4,6 -4,8 ghz durchaus noch hoch gehen beim Allcore Takt.Da sehe ich kein Problem.Ich habe immer noch den Verdacht das meine CPU vom Allcore Takt Profitiert.Knapp 10 % mehrleistung nur durch den Allcore Takt von 1 ghz ist schon mal was.
Und selbst die E kerne steig die Leistung dank der e Kerne um ca 5 % dank von 4 ghz auf 4,3 ghz an.Und fingen sogar das Reduzieren vom Takt der P Kerne ab,die ja von 5,7 ghz auf 5,1 ghz herunter gingen.
Vielleicht weil die e Kerne breiter gestaltet sind,weil mehr Cache und so es abfängt.Oder halt was anderes.Ich kann es nur nicht genau erklären.
So gesehen,ist die Entwicklung sehr interesant.Ich hoffe sowas passiert auch bei AMD.Niedriger Takt,sparsamer aber dennoch mehr Leistung.Dann müsste ich die CPU nicht mehr drosseln um auf 142 Watt zu kommen und hätte dennoch noch mehr Allcore Leistung.

AMD hat es also in der Hand.Und ob sowas Intel noch mal schafft,wer weis.
Denn die 14 Gen brachte gegenüber der 13 Gen verbesserung.Weniger Stromverbrauch also 35 Watt weniger unter Last,aber gleichzeitig 5 % mehr MUlticore Leistung.Die SIngle core ist mir eigentlich nicht ganz so wichtig,weil meine ANwendung eher wohl Multicore Lästig ist.

basix

2024-02-12, 17:34:41

Und was macht denn Gracemont zum little-core, Zen4c aber nicht ?
Gipsel hat es schon beantwortet: Zen 4c = Zen 4, einfach dichter gepackt. Gracemont unterscheidet sich deutlich von Golden Cove / Raptor Cove.

Hast du einen Link von dem Cinebench R23 ?

Hier E-Cores Single beim 12900K. Den Rest kann man sich zusammensuchen und ausrechnen (13900K hat 4.3GHz, 12900K 3.9 GHz, Zen 4 Benches im CB23 gibt es viele):
https://www.techpowerup.com/review/intel-core-i9-12900k-e-cores-only-performance/2.html

mczak

2024-02-12, 18:00:18

Aber bezüglich des Support: Intel hat doch inzwischen nicht mal mehr bei den grossen Kernen AVX512 support, von daher müssten sie m.M.n zuerst einmal überhaupt wieder welchen zurück bringen.
Die Big Cores haben nach wie vor alle AVX512 Support in Hardware (jedenfalls sicher bis Raptor Lake, und meines Wissens auch Meteor Lake), aber halt deaktiviert. Keine Ahnung wie das bei Arrow Lake aussieht.

iamthebear

2024-02-12, 23:01:05

Zen 4c ist kein "Little Core", er ist nur sehr kompakt ;)

Flächen:
- Zen 4c + L2$ = 2.48mm2 (https://www.semianalysis.com/p/zen-4c-amds-response-to-hyperscale) --> 4x Cores = 9.92mm2
- Gracemont 4C-Modul + L2$ = 8.78mm2 (https://twitter.com/Locuza_/status/1453524285260247046)

Edit:
Ich habe noch kurz quergecheckt. Gracemont auf einem 13900K (4.3GHz) hat in etwa die selbe ST Performance wie Zen 4c bei 3.7 GHz (Cinebench R23). ST Performance pro Fläche ist also absolut gleichwertig und bei MT und FP (AVX512) zieht Zen 4c davon.

Cinebench liegt den E Cores auch besonders gut.
Techpowerup hat beim 12900K bei P vs. E Cores noch ca. 1.5x IPC gemessen gemessen:
https://www.techpowerup.com/review/intel-core-i9-12900k-e-cores-only-performance/2.html
Zen4c vs. Gracemont wird ähnlich aussehen. Was den Takt angeht ist Zen4 ca. auf 1.35x Zen4c d.h. wenn die Zen4c Kerne ähnlich hart getrieben werden wie beim 13900K sollte der Takt ähnlich sein.

Bleiben um die 1.5x ST Performance bei nur 1.13x Fläche. Bei MT Last sieht es für Gracemont noch trauriger aus mangels SMT.

Grundsätzlich halte ich das Big/Little Konzept von Intel für sinnvoll nur die E Cores sind eine Enttäuschung. Gracemont wurde für Performance/mm² und Performance/W entwickelt und in beiden ist er nicht besonders gut.

fondness

2024-02-13, 10:12:19

Zen 4c ist kein "Little Core", er ist nur sehr kompakt ;)

Flächen:
- Zen 4c + L2$ = 2.48mm2 (https://www.semianalysis.com/p/zen-4c-amds-response-to-hyperscale) --> 4x Cores = 9.92mm2
- Gracemont 4C-Modul + L2$ = 8.78mm2 (https://twitter.com/Locuza_/status/1453524285260247046)

Edit:
Ich habe noch kurz quergecheckt. Gracemont auf einem 13900K (4.3GHz) hat in etwa die selbe ST Performance wie Zen 4c bei 3.7 GHz (Cinebench R23). ST Performance pro Fläche ist also absolut gleichwertig und bei MT und FP (AVX512) zieht Zen 4c davon.

Naja, zu einem ehrlichen Vergleich gehört halt auch dazu, dass AMD den L2 nicht geshared hat und man deshalb auch immer noch einen L3 benötigt. Intels e-Cores haben ja AFAIK keinen L3? Aber ja stimmt, die Kerne selbst scheinen sehr klein zu sein. Sinnvoll wäre wohl zumindest ein halbierter L2 für die c-Cores, wenn man schon nichts am Design ändern will.

TSMC N4/N5 vs Intel 7 nicht vergessen.

Ja stimmt das dürfte auch ein bisschen was ausmachen.

Gipsel

2024-02-13, 11:39:47

Naja, zu einem ehrlichen Vergleich gehört halt auch dazu, dass AMD den L2 nicht geshared hat und man deshalb auch immer noch einen L3 benötigt. Intels e-Cores haben ja AFAIK keinen L3? Aber ja stimmt, die Kerne selbst scheinen sehr klein zu sein.Das mit dem L3 ist bei intel im Prinzip ganz genau so.
Benötigen sie einen L3? Nicht unbedingt. Aber die Integration von Zen4c-Kernen in einem CCX mit normalen Zen4-Kernen mit shared L3 ist ziemlich gut vom Standpunkt, daß das OS Threads einfach zwischen Zen4- und Zen4c-Kernen hin- und herschieben kann (Phoenix2). Reine Zen4c-CPUs (Bergamo) haben natürlich einen L3, genau wie intels reine E-Core-Server-Chips (Sierra Forest) das auch haben werden (108MB L3 bei der 144-Kern-Variante).
Im Consumer-Bereich packt intel ihre E-Cores auch mit in den L3-Ring (jeder Cluster mit 4 E-Cores hat auch so ein 3MB L3-Segment wie jeder P-Core, was zum Gesamt-L3 beiträgt [Beispiel 14900K: 8 P-Cores * 3MB +4 E-Core-Cluster * 3MB = 36MB]). Nur die 2 zusätzlichen extra E-Kerne im SoC-Tile von Meteor-Lake haben wohl keinen L3 (?).
Man findet auch die Info, daß die LP-E-Kerne im SoC-Tile wohl doch ihren eigenen (von den anderen kernen getrennten) 4MB L3 haben.

davidzo

2024-02-13, 14:04:33

Edit:
Ich habe noch kurz quergecheckt. Gracemont auf einem 13900K (4.3GHz) hat in etwa die selbe ST Performance wie Zen 4c bei 3.7 GHz (Cinebench R23). ST Performance pro Fläche ist also absolut gleichwertig und bei MT und FP (AVX512) zieht Zen 4c davon.

Reine ST Vergleiche sind ein Trugschluss und lassen die E-Cores zu gut aussehen. In Multicore Workloads fehlt nicht nur SMT, sondern der shared L2 Cache limitiert in Hitrate und Geschwindigkeit wie auch die mickrige Anbindung an den Ringbus. Gepaart mit den Taktregressionen kann man froh sein wenn man auf einen MT Faktor von 6x kommt wenn man von 1x auf 8x Kerne geht.

Zudem ist das sehr anwendungsabhängig ob die E-Cores überhaupt effizient sind oder man besser die P-Cores nimmt. Ich erinnere mich da noch an die Tests von Cheese and Chips mit Gracemont(Alderlake) vs Skylake (6600K), wo letzterer in floatingpoint lastigeren Anwendungen wie x264 trotz jahrealter Fertigung eine vergleichbarer Energieeffizienz ablieferte. Die E-Cores sind nur effizienter wenn Intel sie niedriger taktet, was bei den Consumer Desktop SKUs durch die Bank nicht der Fall ist.

Im CB ST ist ein Intel (Atom) N300 (3,8Ghz Turbo, 3Ghz allcore Turbo) gleich schnell wie mein alter 2667V2 (4Ghz Turbo, 3,3Ghz base 25mb Cache, Ivybridge-E), Im Multicore schafft er dagegen nur die Hälfte.
Der Skalierungsfaktor des N300 beträgt lediglich 4.4x bei 8 Kernen. Der 2667v2 liegt bei 9.3x. Ein beinahe 50% Leistungsdefizit in MT, das ist nicht nur das fehlende SMT.
In der Praxis wird der N300 auch Takt-limitiert durch die TDP sein, okay. Aber das bedeutet dann 2.6Ghz statt 3.0? Der Taktnachteil ist jedenfalls nicht hoch, denn auch der 2667v2 fällt auf baseclock zurück.
EDIT: Gracemont-Kerne kommen im CB R20 Test von Anandtech auf 6.2x, haben aber eben auch den großen L3 und SI für sich dienormalerweise von den P-Kernen frequentiert werden und den ein N300 gar nicht erst hat. Also 6x ist schon bestcase aber eben immer noch weit unter den Möglichkeiten.

Da ist noch mehr im Argen als nur fehlendes SMT. L2 cache-misses, fehlende Bandbreite, schwache FPU...

Alte P-Core Architekturen wie Ivybridge, Haswell, Skylake aber auch AMD Zen1 und Zen2 sind zudem in floatingpoint anwendungen haushoch überlegen. Dasselbe gilt im Prinzip auch für Spiele die sehr vom Cachesystem abhängig sind.

Bloß weil Cinebench im ST also gut abschneidet heißt dass noch nicht dass die E-Kerne bei der PPA generell sehr gut abschneiden.

latiose88

2024-02-13, 20:03:33

Ja die Floingpoint Leistung wird mit Zen 5 sehr stark steigen.Genau das ist es was ich drauf gewartet hatte.Zen 6 wird deutlich weniger liefern als die kommende CPU Serie.Hier könnte ich durchaus sehr hohe % an mehrleistung haben,so gehe ich davon aus.Darum warte ich auch immer mehr auf gute CPU.CPUs wo die FLoingpoint sehr stark steigt wird wohl davon mehr Poftieren als von mehr Kernen.Aber es wird auch noch spannend wenn beides zusammen trifft.Floing Point Leistung mit mehr Kernen.Das wird der Hammer werden.Wie weit das noch gehen wird,wird sich zeigen.

iamthebear

2024-02-15, 17:51:25

bbott

2024-02-15, 18:03:08

Die Frage ist ob eine Erhöhung der Execution units (egal ob FP oder INT) noch viel bringen wird. Der limitierende Faktor sind aktuell die Vorhersage von Sprüngen, nicht vorhersagbare Abhängigkeiten im Code und je nach Zugriffsmuster auch die Cache/Speicherstruktur.

Einmal hat Apple eine viel bessere IPC eine besseres Performance/Watt Verhältnis, weil Apple breitere Kerne hat und niedriger Taktet. Dann baut AMD breiter Kerne und Taktet diese hoch und breite Kerne bringen auf einmal nichts. Wenn man dann noch den Taktsenkt steigt auch das Performance/Watt Verhältnis.

Wenn man das bei Intel sagen würde wäre es noch logisch, weil die P Cores schon breit sind.

Gibt es eigentlich eine gute Übersicht, welche welche Die Size je Kern inkl. L" (L3) zwischen Zen 3, Zen 4(c), Intel P und E Cores sowie Apple M2/3(Max) vergleicht?

Auch wenn ich den Vergleich eigentlich unfair empfinge, weil Apple die CPUs in Geräten verbaut werden, welche bei ~2000€ und mehr kosten. Bei AMD und Intel geht es bei ~500€ los. Die Designziele und Preistargets sind einfach total unterschiedlich.

davidzo

2024-02-15, 19:17:04

Gibt es eigentlich eine gute Übersicht, welche welche Die Size je Kern inkl. L" (L3) zwischen Zen 3, Zen 4(c), Intel P und E Cores sowie Apple M2/3(Max) vergleicht?

Die Apple Cores sind zwar "breit", aber vom Transistorcount und Flächenbedarf erstaunlich klein. Aktuelle AMD/Intel Designs sind zumindest flächenmäßig größer. Raptor Cove und Redwood Cove sind deutlich fettere Kerne als Apples M2.

Was die Apple-SOCs so fett macht sind eher die GPU-Kerne, Hardwarecodecs, i/o und das breite SI.

https://www.semianalysis.com/p/apple-m2-die-shot-and-architecture

M1 P-Core: 2.28mm2 (TSMC N5, Firestorm)
M2 P-Core: 2.76mm2 (TSMC N5, Avalanche+)
M1 P-Core: 0,59mm2 (TSMC N5, Icestorm)
M2 E-Core: 0,73mm2 (TSMC N5, Blizzard+)

Der M3 wird da wahrscheinlich ähnlich um die 2-2.5mm2 liegen, da er zwar mehr Transistoren benötigt aber auch vom Nodesprung auf N3 profitiert.

Die Werte sind ohne L2 weil der bei Apple geshared ist. 12MB beim M1 sind ca. 3.5mm2 groß und die 16MB beim M2 4.7mm2, muss man also jeweils teilen durch die vier P-Kerne, das sind also 0,0-1,1 mm2 L2 pro Kern.
Vom Speichervolumen her liegt der L2 bei Apple mit 12 und 16Mb (M2) auch eher zwischen L2 und L3 bei Intel/AMD, daher ist das nur fair den nicht ganz mit zu zählen. Denn der L1 ist mit 384kb bereits so groß dass die Hitrate viel abdeckt was bei Intel/AMD im L2 landen würde.

Vergleichswerte x86:
- Golden Cove: 7mm2 (Intel7, mit 1280kb L2)
- Golden Cove: 5.5mm2 (Intel7, ohne L2)
- Zen4: 3.84mm2 (TSMC N5, mit L2)
- Zen4C: 2.54mm2 (TSMC N5, mit L2)
- Gracemont: 2.01mm2 (Intel7 mit 512kb L2 (2mb shared))
- Gracemont: 1.59mm2 (Intel7 ohne L2)
- Redwood Cove: 5.33 (Intel4, mit 2MB L2)

Wenn wir ARL CPU-Tiles in TSMC-N3 haben wird das ein interessanter Vergleich zu den M3 Kernen.

Auch wenn ich den Vergleich eigentlich unfair empfinde, weil Apple die CPUs in Geräten verbaut werden, welche bei ~2000€ und mehr kosten. Bei AMD und Intel geht es bei ~500€ los. Die Designziele und Preistargets sind einfach total unterschiedlich.

Ab 699€ meinst du :wink:
Neben dem Mac Mini kriegst du auch im Imac, Ipad pro und Macbook Air eine M-CPU. Die liegen alle unter 2K€.

robbitop

2024-02-15, 22:47:53

Der_Korken

2024-02-16, 02:00:32

Wobei Taktbarkeit auch Fläche kostet. Massetransistoren, längere Pipelines und auch ein relaxtetes Layout. Und da die Applekerne deutlich niedriger takten ist da einiges nicht mehr 100%ig vergleichbar.
Ich würde vermuten, dass wenn deren Kerne auf 5+ GHz kommen wölkten wären die auch deutlich geößer und durstiger.
Es sind (breit und low clock vs schmaler und high clock) eben zwei verschiedene Ansätze (die beide zum Ziel führen).

Eine 5Ghz+ Version von Apples Kernen würde aber auch Kreise um Zen 4 und Raptor Lake ziehen. Der Vergleich mit Zen 4 passt schon ganz gut, da beide in N5 auf eine ähnliche Größe kommen (ohne L2) und ähnlich viel ST-Leistung bieten. Wobei Apple sich taktmäßig nach wie vor zurückhält angesichts der nach wie vor unerreichten Perf/W bei ST.

fondness

2024-02-16, 09:25:19

Wobei Apple sich taktmäßig nach wie vor zurückhält angesichts der nach wie vor unerreichten Perf/W bei ST.

Das halte ich für ein Gerücht, wäre mehr Takt möglich würde man auch höher takten. Im übrigen bedarf es dazu Designänderungen die IPC kosten, wie zB höheren Cache-Latenzen.

robbitop

2024-02-16, 09:35:00

Ich denke auch dass sich das viele zu einfach vorstellen. Schön breit -> muss man nur noch höher takten ist ja kein Problem. Dass sich dabei extrem viele Randbedingungen ändern können die fundamentale Auswirkung haben können haben viele nicht auf dem Schirm. Ich würde vermuten node normiert ist es wahrscheinlich eher in richtung „entweder oder“.
Apple wählte den IMO etwas energieeffizienteren Weg - und das können sie machen weil es nur ihren Chip in ihrem Ökosystem gibt. Da gibt es keinen der dann die TDP hochdreht um Benchmarks zu gewinnen. Das Clientel ist auch eher so gepolt, dass die letzten 10-15% performance nicht so wichtig sind wie Dinge wie Akkualufzeit oder Bauraum.
Entsprechend konnte Apple sich voll und ganz auf Energieeffizienz konzentrieren und das ging echt auf. Zugegeben in Kombination mit ihrem OS. Aber die Laufzeiten deren Notebooks sind wirklich krass. Ich hab ein ganz neues Thinkpad T14 G4 als Dienstlaptop bekommen (mit Intel 13Gen 15W) und komme gerade mal auf 5-6 h.
Laut reviews sollen es 11 h (was immer noch weniger ist als die macbooks) aber da kommt man in der Praxis nicht mal annähernd hin. Bei den neuen Macbooks mit M Chip hat man auch in der Praxis echt hohe Laufzeiten.
Das liegt zT an den SoCs aber auch zT am OS.

fondness

2024-02-16, 09:43:43

Nichts was du mit einer AMD-APU im selben Prozess nicht auch erreichst. Intel sollte natürlich nach einer gefühlten Ewigkeit mal ihren hohen Verbrauch in den Griff bekommen.

robbitop

2024-02-16, 14:38:23

Die Akkulaufzeit vom selben Gerät mit Phoenix ist zwar höher aber nicht kriegsentscheidend.

fondness

2024-02-16, 15:47:57

Die Akkulaufzeit vom selben Gerät mit Phoenix ist zwar höher aber nicht kriegsentscheidend.

Wenn dann nur weil die TDP viel zu hoch konfiguriert ist. Würde keinen Phoenix mit über 25 Watt betreiben. Wenn man die iGPU nicht verwendet noch viel weniger.

robbitop

2024-02-16, 15:53:18

Die Werte sind niedrigste Teillast bis idle. Nach meinem Verständnis spielt die TDP Einstellung da keine Rolle. Und da es das gleiche Notebook ist (wie für den 15W Intel) schätze ich nicht, dass dort die TDP besonders hoch eingestellt wurde...

fondness

2024-02-17, 09:05:08

Wenn die TDP nur bei 15W liegt und du trotzdem keine höheren Laufzeiten schaffst, dann muss es am Notebook liegen. Entweder ist der Akku sehr klein oder irgendwas anderes zieht ungewöhnlich viel. Mit einem 15W SoC sollte man locker über den Tag kommen.

basix

2024-02-17, 09:41:29

Es geht um die Laufzeiten in den Tests. Dort wird die TDP garantiert nicht ausgenutzt. Auch mit 15W nicht.

Hinsichtlich Alltagsgebrauch würde ich sagen, es kann einen Unterschied machen. Aber bei "normalem" Office & Browsing dürfte der Unterschied nicht sehr gross sein.

Nightspider

2024-02-18, 18:41:59

latiose88

2024-02-18, 18:48:58

heißt das die 800€ nur für die CPU sind dann sicher oder kann man mit noch höheren Preisen für ne CPU dann in dem fall dann sogar rechnen?

Neurosphere

2024-02-18, 20:24:01

Das ganze Overhyping ist langsam echt nervig.

Linmoum

2024-02-18, 20:45:34

Das Screenshot-Gefake hat gefühlt zuletzt vor allem extrem zugenommen. Ist ja auch keine große Kunst mehr, das unauffällig und authentisch aussehen zu lassen.

Tarkin

2024-02-18, 21:04:56

https://youtu.be/vRKKkQ2Q-YM?t=181

Irgendwo ist ein Screenshot aufgetaucht mit einem 40% höheren SingleThread Benchmark Ergebnis von CB R23 1T.

Klingt alles zu schön um wahr zu sein aber wenn es stimmt wird es ein Day1 Kauf, auch wenn sich AMD diese Leistung ordentlich bezahlen lassen wird.

von hier: https://forums.anandtech.com/threads/zen-5-discussion-epyc-turin-and-strix-point-granite-ridge-ryzen-8000.2607350/page-288#post-41159090

lustig auf der Kommentar von Kepler ;D

Man stelle sich mal vor, dass seit ein paar Wochen in Massenproduktion befindliche B0 Stepping legt nochmal 5% oder so oben drauf und man erreicht knapp 3.000 Punkte

Wenn Zen 5 wirklich so stark wird, dann muss Intel froh sein, mit Panther Lake (Ende 2025) in die Nähe zu kommen. Krass. Ziemlich sicher scheint jefenfalls, ARL ist DOA.

Exxtreme

2024-02-18, 21:10:31

Die 40% werden wohl eher ein "bis zu"-Angabe sein. Andererseits untertreibt AMD eher denn übertreibt. Und 40% mehr wären echt heftig. Das ist schon deutlich über einer Wahrnehmungsschwelle.

iamthebear

2024-02-18, 22:50:03

Ob nun echt oder nicht. Cinebench ist eben nur eine Anwendung unter vielen und nicht unbedingt repräsentativ für alle Anwendungen besonders was Gaming angeht.

reaperrr

2024-02-18, 23:40:03

Ob nun echt oder nicht. Cinebench ist eben nur eine Anwendung unter vielen und nicht unbedingt repräsentativ für alle Anwendungen besonders was Gaming angeht.
Du hast insofern recht, dass CB23 quasi nicht auf X3D anspricht (5800X3D hinter den normalen X und sogar 5700G).

Aber wenn ich mir die Werte aus dem 7700X/7950X Review auf computerbase so ansehe, spricht CB23 auf IPC und Takt an sich schon recht gut an und ist da auch nicht weit von dem weg, was man so im Durchschnitt außerhalb von Spielen zu sehen bekommt.

...Wenn das auch auf Zen5 zutrifft und der CB23-Wert kein Fake ist, wird's später dieses Jahr echt lustig :freak:

Nightspider

2024-02-19, 05:19:55

Es hieß ja früher auf mal das Zen5 in N4 und N3 kommen würde.
N4 für Consumer und N3 für Data Center.

Was, wenn die N4 CCDs gestrichen wurden oder N4 schon immer nur für die IODs geplant war und AMD dank kleiner Chiplets und 2nd Stepping das Maximum aus TSMCs derzeit bestem N3 Prozess herauskeult?

Würde auch für den verzögerten Start sprechen, wenn man jetzt voll auf den neuesten N3 Prozess setzt.
Bei Apple sind die Verkaufszahlen auch zurückgegangen in den letzten 1-2 Jahren. Vielleicht hatte sich AMD letztes Jahr noch ein zusätzliches Stück vom N3 Kuchen geschnappt.

Neue, fette Architektur mit neustem Prozess würden zumindest die mutmaßlichen 40% etwas realistischer erscheinen lassen.

Man erinnere sich an Zen2 zurück, wo AMD eine der ersten Firmen mit N7 Produkten auf dem Markt war.

Zossel

2024-02-19, 07:10:23

Ob nun echt oder nicht. Cinebench ist eben nur eine Anwendung unter vielen und nicht unbedingt repräsentativ für alle Anwendungen besonders was Gaming angeht.

Wenn Intel dort irgendwann wieder führen sollte wird das wieder der wichtige Benchmark werden.

Ansonsten sind Benchmarks dessen Source nicht verfügbar sind sowieso für den Popo.

reaperrr

2024-02-19, 07:53:51

Was, wenn die N4 CCDs gestrichen wurden oder N4 schon immer nur für die IODs geplant war und AMD dank kleiner Chiplets und 2nd Stepping das Maximum aus TSMCs derzeit bestem N3 Prozess herauskeult?
Zen5 verwendet weiter den Zen4-IOD, maximal in neuem Stepping mit kleineren Verbesserungen (RAM-Takt).
Shrink auf N4 würde beim IOD kaum was bringen, weil der voller Interfaces und anderer analoger Transistoren ist, die durch einen Shrink kaum kleiner würden, der wird in N6 bleiben.

Was den CCD angeht, die offiziellen Angaben von TSMC sind

für N4P vs. N5: +11% Perf (Takt) bei gleichem Verbrauch oder -22% Energie bei gleichem Takt, wenn der Rest gleichbleibt

für N3E vs. N5: +15% Perf bei gleichem Verbrauch oder -30% Energie bei gleichem Takt, wenn der Rest gleichbleibt

Außer bei Logik-Packdichte ist N3E also nur unwesentlich besser.
Da wird AMD nicht wild hin- und herswitchen, das kostet nämlich jedes Mal hunderte Millionen für R&D, Masken usw., und nicht zuletzt auch Zeit, sowas macht man nicht in 3-6 Monaten.
Das wird einfach nur ein Respin in N4P sein und fertig.

In N3E wird nur der 16C-Zen5c-CCD für die Servermodelle gefertigt werden.

Jedenfalls, wenn in N3E 40% möglich sind, sind auch in N4P 35-40% möglich.
Übrigens meinte Kepler_L2 außerdem, dass das Ergebnis mit dem A0-Stepping erzielt wurde, welches noch niedriger getaktet hat.

basix

2024-02-19, 09:27:20

N4 bei IOD wird mMn schon kommen, aber erst bei Zen 6. Auch beim IOD hat es noch viel Logik drin und wenn man die GPU / NPU aufbohren will, lohnt sich N4 schon. Vielleicht ist es dann auch eine Samsung Abwandlung von N4, who knows. Die haben immerhin auch schon die RDNA-IP in ihren Prozessen realisiert.

Nightspider

2024-02-19, 18:29:40

Zen5 verwendet weiter den Zen4-IOD, maximal in neuem Stepping mit kleineren Verbesserungen (RAM-Takt).
Shrink auf N4 würde beim IOD kaum was bringen, weil der voller Interfaces und anderer analoger Transistoren ist, die durch einen Shrink kaum kleiner würden, der wird in N6 bleiben.

Was den CCD angeht, die offiziellen Angaben von TSMC sind

für N4P vs. N5: +11% Perf (Takt) bei gleichem Verbrauch oder -22% Energie bei gleichem Takt, wenn der Rest gleichbleibt

für N3E vs. N5: +15% Perf bei gleichem Verbrauch oder -30% Energie bei gleichem Takt, wenn der Rest gleichbleibt

Zum IOD: Stimmt, da war ja was. Das hatten wir ja schon geklärt.

In der Tat ist N3E nicht viel besser.

Wie stehen die Chancen das AMD die N3E CCDs nur für die besten und teuersten Varianten auch im Desktopbereich bringt?

So was wie eine XTX Variante. ^^

w0mbat

2024-02-19, 18:46:12

Da Zen 5c nicht so hoch takten sollte wie der "große" Zen 5 Kern, denke ich nicht, dass man die im Dekstop teuer verkaufen kann. Vielleicht mit mehr Kernen, aber auch dann eben weniger ST-Leistung.

HOT

2024-02-19, 19:49:42

Zum IOD: Stimmt, da war ja was. Das hatten wir ja schon geklärt.

In der Tat ist N3E nicht viel besser.

Wie stehen die Chancen das AMD die N3E CCDs nur für die besten und teuersten Varianten auch im Desktopbereich bringt?

So was wie eine XTX Variante. ^^
Man könnte evtl. einen Refresh in N3P bringen 25. Allerdings glaube ich nicht, dass das irgendwelche wahnsinnigen Vorteile hätte. Der Takt wird denke ich nicht viel besser mit irgendeinem N3-Derivat ggü. N4P.
Für die 16c CCDs ist N3 deshalb interessant, weil man das bisschen bessere Energieeffizienz mitnehmen kann, was bei den Desktop-CCD keine große Rolle spielen wird, im Server aber durchaus.

Alles in allem scheint Zen5 vor allem eine bessere FPU-Leistung zu bieten, die +50% geistern ja schon ne sehr lange Zeit herum, seit Zen3. Zen5 scheint das bei solchen Workloads ja jetzt zu realisieren.
Allerdings gibt es für andere Workloads ja Limits, die erst Zen6 lösen wird, für Spiele dürfte das I/O und Caches sein, was sich bei Zen5 ja kaum verändert. Man sollte also hier seine Erwartungen nicht zu hoch schrauben.

ashantus

2024-02-20, 13:17:17

Techpowerup bezieht sich auf eine Quelle der Chinesischen UDN (k.a. was das ist).

https://www.techpowerup.com/319241/amd-zen-5c-ccds-made-on-more-advanced-3-nm-node-than-zen-5

Demnach wird Zen5 in 4 nm EUV kommen, die kompake Form Zen 5c für Server soll später in 3 nm EUV
erscheinen. Welcher Fertigungsprozess bei den I/O benutzt wird bleibt offen.

was deine Vermutung somit bestätigt. Es hieß ja früher auf mal das Zen5 in N4 und N3 kommen würde.
N4 für Consumer und N3 für Data Center.

Was in dem Bericht ebenfalls steht ist, daß die Produktion erst im Quartal 2 anlaufen soll. Dies wäre eine Abweichung von wccftech, welche geschrieben hatten, daß die Produktion bereits im Januar aufgenommen wurde.

Im Kontext ergibt sich somit folgendes Bild:
Die Produktion von Zen 5 war für Januar geplant, aber wegen Produktionsproblemen beginnt man nun erst im zweiten Quartal. Damit erklären sich die Aussagen diverser AMD--Influencer aus 2023. Wo es letztes Jahr noch hieß, Zen 5 könne im April oder Mai kommen. Anfang des Jahres kam dann die Korrektur seitens AMD, daß Zen 5 erst im zweiten HJ 2024erscheint. Wenn die Verschiebung des Produktionsbeginns von Januar auf April oder Mai notwendig ist, dann wird Zen 5 wohl tatsächlich erst Richtung Oktober zu erwarten sein. Und dann würde Zen 5 gerade mal 6-8 Wochen vor dem Release von Arrow Lake erscheinen. Eine ungünstige Markteinführung, denn der normale Käufer wird dann vollends abwarten, bis die offiziellen Benchmarks von Zen 5 zu Arrowlake auf dem Tisch liegen.

HOT

2024-02-20, 13:21:31

Also N4P für non-c und N3E für c, IOD ist N6, das ist ja jetzt schon klar, wird ja nicht geändert.

Complicated

2024-02-20, 14:24:53

Hat auch den Vorteil, dass sich Kapazitäten in der Fertigung nicht gegenseitig kannibalisieren und Engpässe bei den großen Modellen entstehen, weil c-Modelle an Nachfrage zunehmen. Wenn es dann nicht am Packaging wieder hängt. Bin gespannt wie Samsung da skalieren kann und ob das funktionieren wird.

HOT

2024-02-20, 14:50:06

Mehr N3-Produkte als MI400 und das 16c CCD sind ja erstmal nicht geplant, vielleicht gibts noch in 25 dann die High-End-GPUs in N3, mal sehen.
Alles weitere bleibt ja N4, auch Kraken Point, der Nachfolger von Phoenix/Hawk Point. Außerdem sollen ja Produkte in 4LPP auch noch in der Pipeline sein, mal sehen, wo wir das sehen werden.

TheAntitheist

2024-02-22, 02:40:15

Die 40% werden wohl eher ein "bis zu"-Angabe sein. Andererseits untertreibt AMD eher denn übertreibt. Und 40% mehr wären echt heftig. Das ist schon deutlich über einer Wahrnehmungsschwelle.
das kann man nicht sagen, AMD hat oft genug bei den Leistungszuwächsen mehr versprochen als es am Ende sein sollte. Vor allem bei den GPUs.

Natürlich ist das Cherrypicking aber dennoch wird die CPU sehr gut sein. Daran habe ich keine Zweifel.

HOT

2024-02-22, 08:45:12

a.) hat AMD gar nichts versprochen zu Zen5 und b.) hat AMD bei CPUs eigentlich immer tiefgestapelt. Davon stimmt also nix :freak:

Nightspider

2024-02-22, 11:57:04

Bei CPUs hat AMD tief gestapelt, ja. Aber bei GPUs oft total übertrieben.

amdfanuwe

2024-02-23, 09:43:48

basix

2024-02-23, 09:51:31

Bei CPUs hat AMD tief gestapelt, ja. Aber bei GPUs oft total übertrieben.

Was heisst oft?

Ich wüsste nicht, wo sie im vornherein viel mehr Leistung versprochen haben. Polaris war ein bisschen Wacky mit ihrer Crossfire Vorstellung, OK. Bei Vega kommt mir gerade nichts in den Sinn (ausser dass man gestänkert hat und es dann gegen Pascal abgestinkt hat, klare Leistungswerte gab es von AMD im vornherein aber nicht), RDNA1/2 waren eine Punktlandung und bei RDNA3 scheint was schief gelaufen zu sein, weswegen man das Ziel nicht getroffen hat (und den Fehler gemacht hat, zu hohe Werte auf die Präsentationsfolien zu schreiben).

Ich sehe da jetzt kein "total übertrieben" Schema. Da kommen mir eher Nvidias Ampere & Lovelace Präsentationen in den Sinn, wo man die Grafiken "lustig interpretiert" hat und man auf 2.5x Leistungszuwachs kommt oder alles inkl. FG vergleicht.

Exxtreme

2024-02-23, 09:56:40

Was heisst oft?

Ich wüsste nicht, wo sie im vornherein viel mehr Leistung versprochen haben.

Mehr Leistung nicht. Aber bei RDNA3 haben sie bis zu 54% mehr Energieffzienz versprochen. Und dieses Versprechen können sie bei weitem nicht halten.

https://i.ibb.co/dWGZMz0/Screenshot-2024-02-23-095512.png (https://ibb.co/znGdx0h)

HOT

2024-02-23, 12:24:02

Lisa gibt auf der Computex am 3.Juni 2024 eine Keynote.
Ich denke, da wird Strix Point vorgestellt.
Strix Point: ZEN5 4+8c, 16CU, XDNA2, 24 MB unified L3 Cache laut Gerüchten.
Könnte sich gut im Desktop als 8900G und 8800G machen.
Ansonsten Teaser auf Granite Ridge und RDNA4?

Was denkt ihr?

AMD hat einen Launch-Zeitplan für 2024/25. Im Sommer (bis spätestens Ende September) müssen Zen5, RDNA4, der X3D und die 8xx-Boards an den Mann gebracht werden, damit man im danach den Launchzeitraum für die Mobil und OEM-Ware frei hat, also Strix Point, Sarlak, Fire Range und Kraken Point. Auch Turin und MI300 v2 wird in diesem Zeitraum mMn launchen, das ist aber ne gänzlich andere Baustelle, daher geht das. Den Turin Dense und MI400 dürften wir dann im Frühjahr 25 erwarten können. Wichtig ist eben:

Sommer bis Herbst -> alle Retail-Produkte
Herbst bis Jahreswechsel 25 -> alle OEM-Produkte für 25, Server-Produkte
Frühjahr 25 -> 3nm Server-Generation (MI400 und Turin Dense)

basix

2024-02-23, 13:27:07

Mehr Leistung nicht. Aber bei RDNA3 haben sie bis zu 54% mehr Energieffzienz versprochen. Und dieses Versprechen können sie bei weitem nicht halten.

Ja, bei RDNA3 scheint etwas schiefgelaufen zu sein. Es fehlen die wohl ca. +20% Takt, die RDNA3 hätte liefern müssen. Dann würde es wieder passen, auch bei der Energieeffizienz. RDNA3 scheint auf die ca. 3.0 GHz "engineered" worden zu sein. Real laufen die Karten eher bei ca. 2.5 GHz.

Aber 1x Fall als "oft" zu betiteln, ist wohl nicht ganz richtig ;)

reaperrr

2024-02-23, 15:44:32

Mehr Leistung nicht. Aber bei RDNA3 haben sie bis zu 54% mehr Energieffzienz versprochen. Und dieses Versprechen können sie bei weitem nicht halten.

https://i.ibb.co/dWGZMz0/Screenshot-2024-02-23-095512.png (https://ibb.co/znGdx0h)
Naja, sie sagen "bis zu" 54% mehr Perf/W, also nicht in jedem Spiel und jeder Einstellung, und die 79XT/XTX sind stärker über den SweetSpot hinaus getaktet als es die 6900er waren, die Perf/W-Tests wurden glaube ich mit ner 79XTX @ 330 oder 300W gemacht.

Die 54% sind natürlich arges CherryPicking, aber in manchen Raytracing-Titeln in 4K kommen sie da schon knapp ran.
Dass die XTX in RT@4K dabei selbst gegen ne 3090Ti verliert steht auf nem anderen Blatt :freak:

Gipsel

2024-02-23, 16:25:47

Die 40% werden wohl eher ein "bis zu"-Angabe sein. Andererseits untertreibt AMD eher denn übertreibt. Und 40% mehr wären echt heftig. Das ist schon deutlich über einer Wahrnehmungsschwelle.Mit 512bit Vektoreinheiten in der FPU wird es womöglich eher bis zu +100% werden ;). Außerhalb synthetischer Tests oder Matrixmultiplikationen kommt davon natürlich üblicherweise in der Praxis weniger an.
Es wird interessant sein, wie sich die IPC-Steigerungen auf verschiedenen Gebieten verteilen. Neben AVX512 sollten auch normale FPU-lastige Szenarien (oder welche, die nur bis zu 256bit Vektorlänge nutzen) profitieren können (allein durch die größere Bandbreite zu den Caches und der erhöhten Zahl an möglichen L/S). Wieviel auf Integerseite rumkommt, wird auch stark von den Änderungen am Frontend abhängen, über die wir noch nicht so viel wissen. Die Backend-Änderungen (mehr ALUs und AGUs, "more unified" Scheduler, zusammen mit doch vermutlich weiter vergrößertem ROB) dürften zumindest eine bessere Scheduling-Effizienz ermöglichen, so daß außerhalb von latenzlimitierten Szenarien es weniger Stalls dort gibt. Aber wieviel das ausmacht, kann extrem vom Einzelfall abhängen, so daß es dort einen breiten Querschnitt an Anwendungen benötigt, um das vernünftig einordnen zu können.
Alles über +15% im breiten Schnitt (ohne AVX512) wäre in meinen Augen bereits ganz gut, geht es deutlich über +20% wäre es sehr beeindruckend. Allgemein ist es schon interessant, wieviel Performance AMD aus dem Zen4-Design im Vergleich zu Raptor Cove oder Redwood Cove (MeteorLake) rausquetscht. Die liegen IPC-technisch nicht wirklich weit hinten trotz einfacher aufgebautem Backend mit deutlich weniger Scheduler-Ressourcen (AMD hat dafür ein paar Vorteile im Frontend z.B. der Branch-Prediction). Es wird interessant sein zu sehen, ob man intel mit dann breiterem Backend in Zen5 eventuell deutlich überholen kann.

iamthebear

2024-02-23, 20:28:53

Bei CPUs hat AMD tief gestapelt, ja. Aber bei GPUs oft total übertrieben.

Das hängt halt alles davon ab wie toll das Produkt ist, das man gerade vorstellt. Bei einem guten Produkt kann man leicht bescheiden sein.

Naja, sie sagen "bis zu" 54% mehr Perf/W, also nicht in jedem Spiel und jeder Einstellung, und die 79XT/XTX sind stärker über den SweetSpot hinaus getaktet als es die 6900er waren, die Perf/W-Tests wurden glaube ich mit ner 79XTX @ 330 oder 300W gemacht.

Es ist genau umgekehrt. Die 6900 XT wurde relativ hoch getrieben während die 7900 XTX im Grunde eine 500W Karte ist, die künstlich runtergedreht wurde als man gemerkt hat, dass es nicht für Highend reicht.
Im Techpowerup Review musste die 7900 XTX in CP2077 mit RT die Spannung bis auf 826mV zurückfahren.
Zum Vergleich: Meine 6800 XT läuft bei 900mV und 2GHz in den meisten Spielen schon unter 200W (Standardkurve, kein UV)

Allerdings muss man zur Verteidigung von AMD sagen:
Hier ging es um RDNA3 als Architektur. Navi33 ohne den ganzen Chipletmurks läuft wunderbar. Vielleicht keine 54% aber zumindest besser als RDNA2. Für die ganzen monolithischen 4nm APUs die noch kommen dürften die 54% gut hinkommen.

Die 40% werden wohl eher ein "bis zu"-Angabe sein. Andererseits untertreibt AMD eher denn übertreibt. Und 40% mehr wären echt heftig. Das ist schon deutlich über einer Wahrnehmungsschwelle.

Die 40% sind kein "bis zu". Angeblich ist es Cinebench.
Wobei Intel hier aktuell bei ST ca. 15% vorne ist. 40% vor Zen4 bedeutet 22% vor Intel.

Was die "bis zu" Angaben angeht: Die interessieren glaube ich niemanden. Das kann auch so etwas sein wie die 7x AES Performance von Sandy Bridge.

lilgefo~

2024-02-23, 20:51:00

Wär auf jeden Fall gut, wenn AMD es dann endlich auch im ST schafft. Mit Ryzen 5000 warens ja nah dran, wenn AL nicht gekommen wäre. 22% Vorsprung wär dann aber auch wieder nix was arrow lake nicht erreichen könnte (!). Bin gespannt.

OgrEGT

2024-02-23, 21:12:08

AMD hat einen Launch-Zeitplan für 2024/25. Im Sommer (bis spätestens Ende September) müssen Zen5, RDNA4, der X3D und die 8xx-Boards an den Mann gebracht werden, damit man im danach den Launchzeitraum für die Mobil und OEM-Ware frei hat, also Strix Point, Sarlak, Fire Range und Kraken Point. Auch Turin und MI300 v2 wird in diesem Zeitraum mMn launchen, das ist aber ne gänzlich andere Baustelle, daher geht das. Den Turin Dense und MI400 dürften wir dann im Frühjahr 25 erwarten können. Wichtig ist eben:

Sommer bis Herbst -> alle Retail-Produkte
Herbst bis Jahreswechsel 25 -> alle OEM-Produkte für 25, Server-Produkte
Frühjahr 25 -> 3nm Server-Generation (MI400 und Turin Dense)

9800X3D und/oder 8900XT/X zu Weihnachten wär nicht schlecht :cool:

latiose88

2024-02-23, 21:16:14

Die Backend-Änderungen (mehr ALUs und AGUs, "more unified" Scheduler, zusammen mit doch vermutlich weiter vergrößertem ROB) dürften zumindest eine bessere Scheduling-Effizienz ermöglichen, so daß außerhalb von latenzlimitierten Szenarien es weniger Stalls dort gibt.

Hm was heißt Stalls,anläufe oder Probleme auf gut Deutsch?

Exxtreme

2024-02-23, 22:08:56

Hm was heißt Stalls,anläufe oder Probleme auf gut Deutsch?

Ein Stall ist in der Luftfahrt ein Strömungsabriss wenn z.B. das Flugzeug zu langsam fliegt. Und in der Computertechnik bedeutet das, dass ein Rechenwerk leerläuft und Däumchen dreht weil von vorne nicht schnell genug Daten reinkommen, die das Rechenwerk bearbeiten könnte. Und das kann einige Gründe haben, wie zu kleine Caches, ein langsamer Scheduler oder der Code ist nicht optimal etc.

latiose88

2024-02-23, 22:48:04

ein code nicht optimal also das Programm ist schlecht optimiert bzw Programiert worden ist.

Leonidas

2024-02-24, 07:21:42

Ich denke, da wird Strix Point vorgestellt.

Unwahrscheinlich, dass man die Mobile-APU vor dem Desktop-Modell vorstellt.

amdfanuwe

2024-02-24, 08:52:04

Unwahrscheinlich, dass man die Mobile-APU vor dem Desktop-Modell vorstellt.
Ja, gab es bisher noch nicht.
Mir geht halt diese MLiD Gerücht nicht aus dem Kopf:
https://cdn.videocardz.com/1/2023/11/AMD-RYZEN-ZEN4-ZEN5-ROADMAP-1200x675.jpg
Daher bisher auch die Hoffnung, dass ZEN5 Chiplets noch in Q2/24 erscheinen würde, was sich den Gerüchten nach aber wohl erledigt hat.
Dazu noch die ganzen AI und Windows Geschichten, da würde sich Strix Point für Desktop anbieten.
Könnte mir auch vorstellen, dass Granite Ridge sich nur noch auf 8 Core X3D und 16 Core Varianten beschränkt, 4-12 Core also mit Strix Point und Hawk Point abgedeckt werden.
Und dann frage ich mich noch, wie bei Granite Ridge AI bedient wird? IOD soll ja das gleiche bleiben, XDNA auf dem CCD Chiplet wäre für viele Server Anwendungen Platzverschwendung. Bliebe noch XDNA als eigenes Chiplet oder gestacked. Eventuell sogar Cache und XDNA wie in diesem Patent: https://www.freepatentsonline.com/20210374607.pdf

Lassen wir uns überraschen, da ist AMD jedenfalls stark.

KarlKastor

2024-02-25, 05:23:33

Hawk Point kam zudem als komplette 8000er Serie und nicht nur als Ergänzung untenrum wie Barcelo etc. Da erwarte ich so schnell keine neue Serie. Im Desktop kam auch gerade erst ne neue APU.

bbott

2024-03-15, 15:24:37

Werden die CPUs eigentlich auch AI HW erhalten? Auch Zen 5?

Exxtreme

2024-03-15, 15:26:07

Werden die CPUs eigentlich auch AI HW erhalten? Auch Zen 5?

"AI-Hardware" haben alle CPUs bereits. ;)

Zossel

2024-03-15, 17:07:48

"AI-Hardware" haben alle CPUs bereits. ;)

In den 90'ern hat ein Kumpel von mir bereits neuronale Netze auf den damaligen CPUs trainiert und darüber Sachen laufen lassen, ganz ohne "AI-Hardware".
Und die Konzepte dazu gibt es bereits seit den 60'ern.

Diese ganze Propaganda von den KI- und AI-Butzen scheint bei einigen hier Wirkung zu zeigen.

robbitop

2024-03-15, 17:19:34

memory_stick

2024-03-15, 17:26:51

Nvm wrong thread

CrazyIvan

2024-03-15, 18:10:12

Werden die CPUs eigentlich auch AI HW erhalten? Auch Zen 5?
Was man so hört, soll auf den CCDs zumindest keine dedizierte Hardware wie NPU o.ä. verbaut werden. Wäre ja im Serverbereich totes Silizium und ist es für AMD wohl nicht wert.

Platos

2024-03-15, 18:39:06

Naja aber dank moderner HW (Matrixcores), höherer Rechenleistung und deutlich modernerer Softwarearchitektur (Transformers) sind da schon Galaxien zwischen den 90ern und Heute dazwischen.
In den 90ern waren die NNs sehr klein und langsam und entsprechend waren die Anwendungen doch sehr unbeeindruckend.
Konzepte und echte Anwendungen - das macht IMO schon einen großen Unterschied. Und das liegt nicht an der "Propaganda". ;)

Ich denke die "Propaganda" (falsches Wort eigentlich) ist vor allem eher, dass heute alles "AI" bzw. "KI" ist.

Die Leute verstehen darunter hald was anderes und das wissen Firmen und werben damit. Heute ist einfach alles "AI". Man muss es "AI" nennen, weil das wie "thee next level" und "Sci-Fi" rüber kommt usw. Mit Künstlicher Intelleigenz hat das meiste aber nichts zu tun.

Slipknot79

2024-03-15, 18:49:04

Mir fehlt noch die Bio-AI-Schokolade. (y)

Zossel

2024-03-15, 18:49:35

In den 90ern waren die NNs sehr klein und langsam und entsprechend waren die Anwendungen doch sehr unbeeindruckend.

Bis auf Übersetzer natürlicher Sprachen (Dieser blanke und unverhohlene Faschismus russischer Originalquellen haut mich immer wieder um, früher wäre mir das verschlossen geblieben) haben mich bisher keine KI-Anwendungen beeindruckt.

Oder habe ich was übersehen?

Exxtreme

2024-03-15, 19:13:16

Naja aber dank moderner HW (Matrixcores), höherer Rechenleistung und deutlich modernerer Softwarearchitektur (Transformers) sind da schon Galaxien zwischen den 90ern und Heute dazwischen.
In den 90ern waren die NNs sehr klein und langsam und entsprechend waren die Anwendungen doch sehr unbeeindruckend.
Konzepte und echte Anwendungen - das macht IMO schon einen großen Unterschied. Und das liegt nicht an der "Propaganda". ;)

Mag ja sein, dass heutige "KI" nutzbarer ist als früher. Trotzdem gibt es keine "KI-Hardware" in dem Sinne. Das sind alles stinknormale integer- und floating point-Register, die man auf 4 - 8 Bit reduziert hat damit man von denen viel mehr auf's Silizium bekommt - zulasten der Präzision natürlich. Und diese Register braucht man nicht einmal, da man diese Berechnungen ebenfalls auf den 32-/64-Bit-Registern machen kann.

Ich könnte mir sogar gut vorstellen, dass man das irgendwannmal offiziell in die x86-64-Architektur aufnimmt. Und dann wird wahrscheinlich niemand mehr von "KI-Hardware" reden. ;)

Zossel

2024-03-15, 19:23:48

Ich könnte mir sogar gut vorstellen, dass man das irgendwannmal offiziell in die x86-64-Architektur aufnimmt. Und dann wird wahrscheinlich niemand mehr von "KI-Hardware" reden. ;)

Gibt es bereits:
The AVX512 VNNI x86 extension extends AVX-512 Foundation by introducing four new instructions for accelerating inner convolutional neural network loops.

VPDPBUSD - Multiplies the individual bytes (8-bit) of the first source operand by the corresponding bytes (8-bit) of the second source operand, producing intermediate word (16-bit) results which are summed and accumulated in the double word (32-bit) of the destination operand.
VPDPBUSDS - Same as above except on intermediate sum overflow which saturates to 0x7FFF_FFFF/0x8000_0000 for positive/negative numbers.
VPDPWSSD - Multiplies the individual words (16-bit) of the first source operand by the corresponding word (16-bit) of the second source operand, producing intermediate word results which are summed and accumulated in the double word (32-bit) of the destination operand.
VPDPWSSDS - Same as above except on intermediate sum overflow which saturates to 0x7FFF_FFFF/0x8000_0000 for positive/negative numbers.

https://en.wikichip.org/wiki/x86/avx512_vnni