News AMD Zen 5: GCC-Patch liefert zahlreiche Details zur Architektur der nächsten Ryzen-Generation

PCGH-Redaktion

Kommentar-System
Teammitglied
Jetzt ist Ihre Meinung gefragt zu AMD Zen 5: GCC-Patch liefert zahlreiche Details zur Architektur der nächsten Ryzen-Generation

Durch ein Update für den GCC-Compiler hat AMD mehrere Details zu den neuen Ryzen-9000-Prozessoren verraten. Für die Zen-5-Kerne wird es beispielsweise neue Instruktionen und deutlich mehr Pipelines geben.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: AMD Zen 5: GCC-Patch liefert zahlreiche Details zur Architektur der nächsten Ryzen-Generation
 
Vllt wären dann doch bis zu 30% Leistungssteigerung drin?
Ziemlich sicher nur in Sonderfällen. Oft brauchen Befehle die Ergebnisse von vorhergehenden Befehlen und durch das Pipelining entsteht da dann eine Latenz. Deswegen wirken sich solche Verbreiterungen bei weitem nicht 1:1 aus, sondern werden eher durchgeführt, um möglichst jegliche zusätzliche Verzögerung zu vermeiden, auch wenn es nur relativ selten etwas nutzt. Das ist einer der Hauptgründe, warum man mit kleineren Cores so viel mehr Leistung pro Chipfläche erzielen kann.
 
Ja aber nur wenn ne Software mit so vielen Kernen umgehen kann. Vielleicht gibt es bei solchen die viele Programme gleichzeitig nutzen ja einen Gewinn,wer weis.
Also ich lasse mich dabei überraschen ob die breiten Kernen bei 2 gleich starken Software gleichzeitig etwas bringt.
Ich bin mir allerdings nicht sicher weil intel mit den e kernen durchaus die selbe Leistung ergeben hatte.Von daher ist es nicht so sicher.Und die e kerne sind ja nicht ganz so breit.Darum verstehe ich nicht warum es da keine Leistungskosten gab.Scheinbar liegt es auch an dem Aufbau drum rum oder die Latenzen sind bei Intel geringer.Ich weis es nicht weil im Detail nicht so genau drinnen bin.Auf jedenfall war der i9 14900k mit dem 7950x gleich stark gewesen.
Das sind aber eigentlich 2 sehr unterschiedliche Archetekturen aber beides scheint zu der gleichen Leistung zu kommen.
Man kann sagen,entweder ist meine Software Flexibler als ich gedacht hätte oder aber es hat der Allcore Takt am Ende entschieden.Wobei dann sollten die e kerne mit den 4,6 ghz aber gegen den mit 5,1 ghz verlieren.Es tut es allerdings nicht.
Eines ist jedoch sicher,neben AMDS CPUS kommen heuer ja auch neue Intels CPU ,also wohl eher Ende des Jahres raus.Hier wird sich zeigen,was am Ende zu mehr Leistung führen wird.
Jedoch bin ich mehr für AMDS CPUS weil unter Last kommt man ja häufiger als im Idle,weil man egal was macht immer ne gewisse Last drauf kommt.

Ich las auch was von Optimierung im Idle Stromverbrauch bei Zen 5,na da bin ich ja gespannt.Das war ja der Knackpunkt bei den AMD CPUS gewesen.Da kann man also nur Überrascht werden.
 
Ja aber nur wenn ne Software mit so vielen Kernen umgehen kann.
Ja, das ist die Kehrseite. Wenn eine Lösung für jeden Fall die beste wäre, würde man ja nicht mischen.
Vielleicht gibt es bei solchen die viele Programme gleichzeitig nutzen ja einen Gewinn,wer weis.
Es ist einfach oft so, dass Dinge ziemlich gut oder ziemlich schlecht parallelisierbar sind. Deswegen sind solche Mischkonfigurationen an sich wirklich keine blöde Idee für Systeme, die beides gut können sollen. Bei Spielen hilft es aber leider oft nicht sonderlich viel, weil die eher in die zweite Kategorie gehören. Sie lassen sich zwar parallelisieren, aber viele nur recht begrenzt.
Also ich lasse mich dabei überraschen ob die breiten Kernen bei 2 gleich starken Software gleichzeitig etwas bringt.
Könnte dank SMT sogar prinzipiell sein, weil der zweite Thread die übrig gebliebenen Ressourcen nutzen kann und je mehr da ist, desto mehr bleibt übrig und desto schneller läuft der zweite Thread. Aber dafür müssen alle Kerne ausgelastet werden, sonst wird die zusätzliche Last im besten Fall einfach auf einen anderen Kern gelegt.
 
Ja da hast du völlig recht.Ich könnte genau in diese Richtung hineinfallen.
Ich laste die 16 Kerne zu 92 % wirklich gut aus.Das heißt hier könnte das breitere durchaus ein Vorteil bringen.Bei einen 8 Kerner sind es bei mir sogar 100% Auslastung.Das heißt hier dürfte der Engpass noch deutlicher zu spüren sein.Da könnte sowas wirklich was bringen.Wird sich also noch zeigen ob die breiteren Kerne hier wirklich abhilfe schaffen könnten.
 
Liest sich ja schon mal ganz gut.
Vllt wären dann doch bis zu 30% Leistungssteigerung drin?
Gruß T.
Wie schon @empty antwortete, bis auf einige Nischen recht gesichert auszuschließen und diese Nischen werden für den Consumer-Markt zudem höchstwahrscheinlich nicht relevant sein. Als Consumer fährt man derzeit am besten, wenn man von einer gemittelten Steigerung im Bereich von 10 % bis bestenfalls 20 % ausgeht.

Zudem dürfte AMD mittlerweile entwicklungstechnisch auch einen anderen Fokus als noch zu Zeiten der Zen-Einführung haben. Aktuell blickt man überwiegend auf das professionelle Marktsegment und setzt auch dementsprechend Prioritäten. In diesem Jahr geht es darum gegen Granite Rapids SP gewappnet zu sein. Bereits Emerald Rapids SP, obwohl augenscheinlich nur ein "simpler Refresh", konnte dennoch in vielen Fällen und immer noch auf dem Altprozess unerwartete Leistungszugewinne verzeichnen und auch wenn der aktuelle Genoa als general purpose CPU grundsätrzlich eine gute Figur abgibt, kann Intel dennoch selbst gegen den in diversen Bereichen immer noch erfolgreich konkurrieren. Der in diesem Jahr kommende Granite Rapids SP dürfte dagegen gleich in mehrerer Hinsicht zu einem weitaus größeren Konkurrenten werden, da man nun keinen Fertigungsvorteil mehr haben wird (die Intel-CPU wird in primär in Intel 3 gefertigt und Intels-Interconnect ist min. ebenbürtig, wenn nicht gar leicht im Vorteil ggü. AMDs IF) und Intel verwendet nochmals neuere P-Kerne, die auf einer verbesserten MTL-Variante beruhen.
Die bei AMD hier geteaserte, zunehmende FP-Leistung erscheint durchaus plausibel, denn bspw. hier sind es oftmals Intel's zwei 512-Bit-Einheiten, die AMD dennoch so manches Mal die Show stehlen. Für jedoch bspw. den Consumer-Markt dürfte eine höhere FP-Leistung nur eine untergeordnete Rolle spielen, jedoch wird das grundsätzlich breitere FrontEnd wahrs. mit einigen zusätzlichen Ausführungseinheiten den wesentlichen Anteil an der Zen5-Leistungssteigerung haben. Wenn alles gut für AMD läuft, werden sie auch im NextGen-Schlagabtausch in einer allgemeinen Sichtweise im Datacenter die Oberhand behalten, jedoch sind sie weiterhin deutlich fertigungsbeschränkt und vermutlich wird der Vorsprung gegen Granite Rapids SP zudem signifikant schrumpfen.

*) Darüber hinaus, wenn MLiD Infos korrekt sind und bei einer derartigen Info bleibt nicht viel Spielraum, denn die ist dann entweder schlicht falsch oder kurzum korrekt: Das Zen5-Design wurde angeblich auf den 3nm-Node hin entwickelt und musste dann von AMD auf 4nm backported werden, was natürlich auch die Leistungszugewinne zusammenschrumpfen lässt. Vermutlich fehlten hier AMD schlicht die Ressourcen um in ausreichender Menge 3nm-Kapazitäten bei TSMC zu sichern.

**) THW zu Emerald Rapids SP:
AMD still holds the lead in sheer core count, but as we see in many of our benchmarks, higher core counts aren't the end-all-be-all for every type of workload — particularly in latency-sensitive workloads like AI. Intel also doesn't directly compete with AMD's 96-core flagship. Instead, the Emerald Rapids 8592+ grapples with AMD's 64-core models in a core-for-core battle that finds it winning in more than a few key areas.
(Und wie erklärt, EMR ist ein gepimpter SPR in immer noch Intel 7, weiterhin auf der Eagle Stream Plattform.)
 
Zuletzt bearbeitet:
Mal schauen was daraus wird. Man könnet mit mehr Piplines auch einen Flaschenhals beseitigen. Mit dem Zusätzlichen Cache könnte das durchaus was werden.

Der Pentium 3 hatte 10 , der Pentium 4 20 und der Athlon hatte 11 Piplines. Viel hat in dem Fall auch nicht geholfen.
 
Mal schauen was daraus wird. Man könnet mit mehr Piplines auch einen Flaschenhals beseitigen. Mit dem Zusätzlichen Cache könnte das durchaus was werden.

Der Pentium 3 hatte 10 , der Pentium 4 20 und der Athlon hatte 11 Piplines. Viel hat in dem Fall auch nicht geholfen.
Meinst du Pipelinestufen? Mehr Stufen erhöhen den möglichen Takt, weil jede Stufe "kürzer" ist, sorgen aber auch für ordentliche Latenzen, wenn Befehle aufeinander warten müssen. Deswegen hat man Sprungvorhersagen eingeführt, damit man zumindest bei Bedingungsabfragen nicht warten muss, sondern einfach weiterrechnen kann. Hat die sich aber geirrt, muss alles wieder zurückgerollt werden, was mit einer längeren Pipeline auch wieder länger dauert. Intel hat das mit den späteren P4 mit ich meine über 30 Stufen auf die Spitze getrieben und der Plan, die Probleme mit einer besseren Sprungvorhersage zu kompensieren ging nicht auf. Aber die Dinger waren überall schnell, wo sie ihre theoretische Leistung auf die Straße bringen konnten, also überall da, wo die Abläufe im Programm fast immer die gleichen waren.
 
Meinst du Pipelinestufen? Mehr Stufen erhöhen den möglichen Takt, weil jede Stufe "kürzer" ist, sorgen aber auch für ordentliche Latenzen, wenn Befehle aufeinander warten müssen. Deswegen hat man Sprungvorhersagen eingeführt, damit man zumindest bei Bedingungsabfragen nicht warten muss, sondern einfach weiterrechnen kann. Hat die sich aber geirrt, muss alles wieder zurückgerollt werden, was mit einer längeren Pipeline auch wieder länger dauert. Intel hat das mit den späteren P4 mit ich meine über 30 Stufen auf die Spitze getrieben und der Plan, die Probleme mit einer besseren Sprungvorhersage zu kompensieren ging nicht auf. Aber die Dinger waren überall schnell, wo sie ihre theoretische Leistung auf die Straße bringen konnten, also überall da, wo die Abläufe im Programm fast immer die gleichen waren.
Ich finde das unglaublich interessant was du schreibst. Ich schätez mal du bist Software Entwickler?

Die RISC CPU´s von Sony CELL und der Power PC IBM in der Xbox 360 hatten den Nachteil, dass Sie In Order Cpu´s waren.

Die CISC sind ja Out Order CPU´s und können ja auf Zwischenwerte warten oder weiterrechnen bis das Ergebnis vorliegt.
 
Zuletzt bearbeitet:
[...] Der Pentium 3 hatte 10 , der Pentium 4 20 und der Athlon hatte 11 Piplines. Viel hat in dem Fall auch nicht geholfen.
Hier wirfst du etwas komplett durcheinander. Was du meinst sind nicht "Pipelines", sondern Stages in der Pipeline, das ist was völlig anderes. Beispielsweise in der Pentium-Entwicklung wurde die Pipeline immer länger, was später konktraproduktiv war, da man mit dem anderen Paradigma eines immer höher werdenden Taktes geplant hatte, was bei einer zu langen Pipeline aber zu neuen Problemen führt und entsprechend wurde die Pipeline wieder verkürzt, indem man beim Pentium 4 die Reißleine zog und mit dem Kerndesign auf ein eigentlich für Mobile-CPUs entwickeltes Design umschwenkte. ;-)
Vielleicht nur eine fehlerhafte Nutzung des Begriffs "Pipeline" bei dir in Verbindung mit der nachfolgenden Zitierung von deren Längen.
Konkret geht dein Gedanke aber in grob die richtige Richtung, sprich breiteres FrontEnd und wahrs. auch ein paar zusätzliche Ausführungseinheiten für mehr Parallelität bei Zen5.

Beispielsweise Zen4 kann zwar die meisten AVX-512-Instruktionen prozessieren, kann diese aber nur double-pumped in zwei Durchläufen berechnen, da die internen Datenpfade immer noch auf 256 Bit ausgelegt sind. Dass Zen4 dennoch gut in FP abschneidet liegt an der guten, modernen und effizienten Archtiektur. Die Zugewinne könnten aber weitaus höher sein, denn bspw. Intels Server-Kerne verfügen über zwei 512-Bit-breite Ausführungseinheiten.
Entsprchend darf man vermuten, dass u. a. vielleicht noch einige FP-Ausführungseinheiten hinzukommen und man mit diesen dann auch möglicherweise AVX-512 effizient in einem Durchlauf berechnen können wird. (Dieses Mehr an Einheiten könnte dann auch beim generellen FP für etwas mehr Durchsatz sorgen, nicht nur bei AVX-512.)

*) AMD hat bei Zen4 vermutlich auf eine übermäßige Vergrößerungf des Kerndesigns verzichten wollen, weil es a) schlicht mehr kostet, man b) im Consumer-Segment davon nur wenig hat, aber derzeit quasi nur Ressourcen für ein Kerndesign hat, das man im Server- und Consumer-Segment nutzen muss und c) letzten Endes, weil man ja schließlich auch noch in der NextGen Verbesserungen liefern können muss und für Zen4 den Schritt als ausreichend ansah.
 
Zuletzt bearbeitet:
Hier wirfst du etwas komplett durcheinander. Was du meinst sind nicht "Pipelines", sondern Stages in der Pipeline, das ist was völlig anderes. Beispielsweise in der Pentium-Entwicklung wurde die Pipeline immer länger, was später konktraproduktiv war, da man mit dem anderen Paradigma eines immer höher werdenden Taktes geplant hatte, was bei einer zu langen Pipeline aber zu neuen Problemen führt und entsprechend wurde die Pipeline wieder verkürzt, indem man beim Pentium 4 die Reißleine zog und mit dem Kerndesign auf ein eigentlich für Mobile-CPUs entwickeltes Design umschwenkte. ;-)
Vielleicht nur eine fehlerhafte Nutzung des Begriffs "Pipeline" bei dir in Verbindung mit der nachfolgenden Zitierung von deren Längen.
Konkret geht dein Gedanke aber in grob die richtige Richtung, sprich breiteres FrontEnd und wahrs. auch ein paar zusätzliche Ausführungseinheiten für mehr Parallelität bei Zen5.

Danke für deine Erklärung.

Der Artikel den ich gelesen haben, sprach von (Integer-Pipeline(Stufen)). Finde aber das Theme super interessant, muss mich da wohl wieder ein fuchsen.

 
erste Benchmarks abwarten.
=> Also wie immer. :D Dafür ist doch auch die PCGH da ;)

Aber es hört sich aber gut an.
Also erst einmal abwarten....
 
Ich finde das unglaublich interessant was du schreibst. Ich schätez mal du bist Software Entwickler?
Im Moment bin ich mehr Administrator als Entwickler, aber ich interessiere mich schon lange für das Thema. Ein bisschen was ist aus dem Studium, viel zu dem Thema aber selbst über die Jahre zusammengeklaubt.
Die RISC CPU´s von Sony CELl und der Power PC IBM in der Xbox 360 hatten den Nachteil, dass Sie In Order Cpu´s waren.

Die CISC sind ja Out Order CPU´s und können ja auf Zwischenwerte warten oder weiterrechnen bis das Ergebnis vorliegt.
In- und Out-of-Order hat erst mal nichts mit CISC und RISC zu tun, das ist auch schon in dem Bereich, wo heutige CISC-CPUs sich eher wie RISC-CPUs verhalten. Im Endeffekt werden bei Out-of-Order-Execution die Befehle nach der Dekodierung in einen Verarbeitungstopf geworfen und können von da aus in beliebiger Reihenfolge berechnet werden, solange das das Endergebnis nicht beeinflusst. Dadurch können Befehle vorgezogen werden, während ein anderer Befehl noch auf Operanden wartet, die wiederum das Ergebnis einer noch nicht abgeschlossenen Berechnung sind. Aber genau diese Abhängigkeiten treten recht häufig auf (und verschlimmern sich, wenn die Pipeline sehr lang ist), weshalb man das nur bis zu einem gewissen Grad ausnutzen kann (irgendwann sind keine Befehle mehr da, die nicht vom Ergebnis eines anderen abhängen) und natürlich ist dafür einiges an Logik im Chip nötig. Die ersten Atoms hatten zum Beispiel keine OoO-Execution, dafür aber SMT, was simpler ist, aber ähnlich wirken kann: Wenn der eine Thread nicht weiterrechnen kann, weil er wartet, rechnet einfach der andere Thread weiter. Das skaliert aber natürlich bei einer CPU, die recht schwach auf der Brust ist, deutlich besser als bei einer breiter aufgestellten. Ein bisschen kann man das auch schon während des Kompilierens machen, indem der Compiler den Code analysiert und Befehle vorzieht, wenn das geht.
 
ah sehr interessant.Das heißt 2 x das selbe Programm werden die Befehle auch auf ein Verarbeitungs Topf geworfen.Aufgrund weil sie das selbe machen,also die selbe Arbeit nur unterschiedliche Quell Dateien,dennoch zusammen gefasst und durch das kostet es auch nicht noch mehr bei den Befehlen.Nur ne kleine Unterscheidung wird es da gewiss noch geben,weil sonst würden die Ergebnisse ja zusammen geworfen.Also sprich Anwendung A hat Videoaufnahme A umzuwandeln also Videoumwandeln und Anwendung B hat Videoaufnahme B umzuwandeln.
Irgendwie wird das bei den Befehlen schon unterschieden,sonst würde Videoaufnahme A infos von Videoaufnahme B haben und umgekehrt und damit unbrauchbare VIdeos.
Ist halt die Frage braucht es in den Sinne die doppelte EInheiten in den Topf oder nicht um ja nicht an Leistung zu Verlieren.
Alles verdoppeln werden sich die EInheiten bei Zen 5 ja nicht.
Bei Intel wird es ja Ähnlich aufgebaut sein wie bei AMD oder nicht?
Und ich habe gelesen das der CPU Takt auch ne Rolle bei der Ausführung der Befehle.Mal sehen wie viel Einfluss das Ganze so haben wird.
 
Ziemlich sicher nur in Sonderfällen. Oft brauchen Befehle die Ergebnisse von vorhergehenden Befehlen und durch das Pipelining entsteht da dann eine Latenz. Deswegen wirken sich solche Verbreiterungen bei weitem nicht 1:1 aus, sondern werden eher durchgeführt, um möglichst jegliche zusätzliche Verzögerung zu vermeiden, auch wenn es nur relativ selten etwas nutzt. Das ist einer der Hauptgründe, warum man mit kleineren Cores so viel mehr Leistung pro Chipfläche erzielen kann.
AMD wird die Pipeline sicherlich nicht nur aufgrund der ST Performance verbreitert haben. Gerade SMT kann hier auch gut von einem breiteren Frontend und Backend profitieren. Also wenn es sich bewahrheitet, was man bisher von Zen 5 so liest, dann denke ich könnten gerade in MT Szenarien bei identischem Takt etwa 30% mehr Performance keine "Sonderfälle" sein. "Sonderfälle" sind für mich dann eher, wenn aufgrund der verdoppelten SIMD/MIMD Kapazitäten eventuell auch mal 50-100% mehr Performance bei identischem Takt rausspringen. Da sind dann weniger die Latenzen das Problem. An denen AMD anscheinend auch weiter schrauben wird. Sowohl was Befehlslatenzen betrifft. Als auch Cache, der mit Zen 5 einige Änderungen mitbringt. Es sind dann vielmehr die thermischen Grenzen ausschlaggebend. Aber da sehe ich eigentlich noch relativ viel Spielraum für AMD. Einen 7950X mit 170W PPT kann man locker auf die Hälfte des PPT runterschrauben ohne allzu viel an Performance zu verlieren.
Ich bin mir allerdings nicht sicher weil intel mit den e kernen durchaus die selbe Leistung ergeben hatte.Von daher ist es nicht so sicher.Und die e kerne sind ja nicht ganz so breit.Darum verstehe ich nicht warum es da keine Leistungskosten gab.Scheinbar liegt es auch an dem Aufbau drum rum oder die Latenzen sind bei Intel geringer.Ich weis es nicht weil im Detail nicht so genau drinnen bin.Auf jedenfall war der i9 14900k mit dem 7950x gleich stark gewesen.
Nicht wirklich, wenn man mal in "normalen" TDP Bereichen wie 65-125W vergleicht. Da sehen 13900K/14900K kein Land gegen den 7950X bei voller Auslastung. Darüber stösst der 7950X mit lediglich 16 Kernen einfach viel früher an thermische Limits, weil sich Taktraten bekanntlich nicht beliebig nach oben schrauben lassen. AMD könnte übrigens auf der gleichen Fläche von 16 Zen 4 Kernen auch 24 Zen 4c Kerne unterbringen. So ein Prozessor würde Sowohl 7950X als auch 13900K/14900K ziemlich alt aussehen lassen bei voller Auslastung.
 
Zuletzt bearbeitet:
Gerade SMT kann hier auch gut von einem breiteren Frontend und Backend profitieren. Also wenn es sich bewahrheitet, was man bisher von Zen 5 so liest, dann denke ich könnten gerade in MT Szenarien bei identischem Takt etwa 30% mehr Performance keine "Sonderfälle" sein.
Ja, kann schon sein. Dafür müsste es aber schon viele FP-Operationen gefragt sein, ohne dass sich SIMD lohnt. Muss man halt abwarten.
 
Nicht wirklich, wenn man mal in "normalen" TDP Bereichen wie 65-125W vergleicht. Da sehen 13900K/14900K kein Land gegen den 7950X bei voller Auslastung. Darüber stösst der 7950X mit lediglich 16 Kernen einfach viel früher an thermische Limits, weil sich Taktraten bekanntlich nicht beliebig nach oben schrauben lassen. AMD könnte übrigens auf der gleichen Fläche von 16 Zen 4 Kernen auch 24 Zen 4c Kerne unterbringen. So ein Prozessor würde Sowohl 7950X als auch 13900K/14900K ziemlich alt aussehen lassen bei voller Auslastung.
Da gebe ich dir recht.Naja Intel hat es darum geschafft weil die da mit verbesserung der e kerne um 300 mhz höher Takten.Dabei frisst selbst wenn der 14900k optimiert worden ist noch immer um die 315 Watt an strom.Vielleicht ändert Intel ja beim Nachfolger etwas.So das die CPU sparsamer wird und leicht mehr Leistung hat.Ich erwarte ohnhin nur 5 % mehrleistung beim Nachfolger ,dafür dann eine um 30-40 % weniger Stromverbrauch.Damit wird Intel noch immer nicht mit AMD mit halten können ist jedoch schon näher dran als es im moment der fall ist.Es würde sogar auch schon ohne die Fertigung Intel dazu in der Lage sein noch sparsamer zu werden.Einfach die P Kerne auf 4,8 ghz anstatt 5,1 ghz zu setzen.Die e Kerne dann auf 4,6 ghz zu erhöhen.Aber dann wären es keine e kerne,sondern vollwertige Kerne,kann man so sagen.
Mit den Vorteil der Fertiung wird es denke ich mal sogar noch mehr möglich sein.Der Allcore Takt wird nicht mehr so hoch steigen bei Intel,das ist vorbei.Takt braucht einfach zu viel Strom.Man merkt also das es bei Intel einen wandel geben wird.Amd hat das Problem aber schon früher erkannt und darum den Allcore Takt nicht zu weit nach oben getrieben.

Wenn nun Pro Takt mehr Befehle möglich ist,wird auch der Takt nicht mehr so viel Auswirkung mehr haben.Für die Anwendung ist es ja unrelevant woher die mehr Befehle her kommen.Wenn nun doppelt so viele Befehle wie zuvor möglich sein wird,werden auch Anwendung die so stark von mehr Cpu Takt profitiert haben,etwas abgemildert werden.
Dann ist ein leichtes senken wohl auch nicht mehr so schädlich.Denke mal ja gut Zen 4 waren von 5,1 ghz auf 4,8 ghz 5 % Leistungsunterschied gewesen.Jedoch wenn doppelt so viele Befehle nun möglich sind,sinkt der Verlust und es sinkt weit weniger.

Denke mal das durch das auch sparsamere CPUS möglich sind.Bei beiden werden wir das wohl merken,wie es weiter gehen wird.
 
wo soll das hingehen AMD ? intel bringt jährlich 5%mehr Leistung. AMD dagegen über 25% mehr Leistung alle 1,5 Jahre. kann mich gut errinnern als Intel Freaks AMD Ryzen 1000er ausgelacht haben(zähle ich mit). wie sich die Zeiten ändern
 
Zurück