Vllt wären dann doch bis zu 30% Leistungssteigerung drin?
Wenn die Verbreiterungen so kommen, wie es der GCC-Patch und die Analyse andeutet, dann "können" die 30 % im Mittel durchaus zutreffen. Das Problem ist an dieser Stelle eher, was für weitere Änderungen AMD vornimmt bei Zen 5.
Es deutet sich ja schon an, dass auch die Load/Store-Bereich überarbeitet wird, wodruch die 4 FP-ALUs und die 6 ALUs im "INT"-Kern durchaus besser gefüttert werden können.
Neben der Datenversorgung muss allerdings auch das Frontend entsprechend ausgelegt sein. Hier wird es interessant werden, was AMD macht und liefert. Ohne entsprechenden Befehlsfluss bringt das alles nichts.
Ziemlich sicher nur in Sonderfällen.
Nein, es wird ziemlich sicher nicht nur in Sonderfällen so sein, dass hier die Verbreiterung des Backends wirkung zeigt. Klar, es wird keine 1:1 Umsetzung geben - 50 % mehr ALUs oder 100 % bei FP bedeuten am Ende nicht, dass im Mittel 50 % auch ankommen. Das hängt von vielen Faktoren ab. Das sich entsprechende Verbreiterungen jedoch positiv auf die "IPC" - oder 1T-Leistung auswirken, konnte/kann man bei Apple und deren ARM-Kernen gut nachverfolgen. Wie gut das verbreitere Backend am Ende durchschlägt hängt aber von einigen Faktoren ab.
[...], um möglichst jegliche zusätzliche Verzögerung zu vermeiden, auch wenn es nur relativ selten etwas nutzt.
Out-of-Order sowie die spekulative Ausführung von Befehlen sind hier aktuell zwei der Stichpunkte. Ich weiß, dass du auf OoO eingegangen bist, wollte es nur der Vollständigheit erwähnen.
Auch wenn man auf "Programmebene" durchaus denkt, dass sich da vieles nicht parallelisieren lässt, ist das gerade auf der OP-Code und später auf der µ-Code-Ebene durchaus deutlich eher der Fall. Dazu kommt, dass eben durch die spekulative Ausführung auch bereits Sprünge und deren Befehle sepkulativ ausgeführt werden.
Wir wissen jetzt durch den GCC-Patch, was AMD am Backend im groben macht - 6 statt 4 ALUs, 4 FP-ALUs statt 2, eine weitere AGU. Was wir nicht wissen, ist was AMD am Frontend machen und was an anderen Punkten passiert.
Entscheidend ist jetzt, was AMD mit dem Decoder macht, wie die Infrastruktur der Load-/Store-Einheiten angepasst wird. Wie wird der Re-Order-Buffer ausgebaut, wie die Sprungvorherserge mit Buffern und Co erweitert.
All das entscheidet am Ende darüber ob bei 1T am Ende im Mittel 30 % ankommen oder weniger oder mehr. Natürlich auch abhängig von den Szenarien.
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.
Kommt immer darauf an und um welches Problem es geht. Das ist hier für die Betrachtung aber eigentlich nebensächlich. Bei den Änderungen hier am Zen 5 Kern ist eher entscheidend, welche "Mikro-Parallelisierung" ist auf µ-OP-Ebene möglich und da ist meist viel mehr möglich, als man denkt. Je nach gewählter Größe des Re-Order-Buffer und Co kann man hier relativ viel erreichen.
Sei es, dass Berechnungen aufgesplittet werden bereits durch den Compiler und damit auf µ-OP-Ebene deutlich mehr unabhängige Berechnungen möglich sind. Dass man in einer Schleife ist, die entsprechend durch den Compiler aufgelöst wird und und und.
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.
Wenn AMD hier 2 weitere FP-ALUs und zwei weitere INT-ALUs hinzufügt und sonst nichts macht, dann sind am Ende 10 % im Mittel bei der IPC eher enttäuschend und eine relativ große Transistorverschwendung.
Klar, es wird Szenarien geben, in den das nicht durchschlägt, in anderen aber sehr wohl. Wichtig ist jetzt, was AMD abseits davon noch anpasst. Das ist die Unbekannte. Die Einheiten wollen gefüttert werden. Bekommt das AMD hin, sind im Mittel 30 % bei dem Back-End durchaus drin. Verhungern die Einheiten, dann sind 10 % auch wahrscheinluch, nur dann ist die Frage, warum diesen Transistor-Count. Da würde dann eine ALU auch schon reichen.