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

Ja, das ist mir soweit schon klar. Nun ist es aber einfacher, Code auf Decoder zu verteilen, wenn man schon im Voraus weiß, wie lang das nächste Wort ist. RISC hat eine feste Wortbreite, also weiß man ohne vorher irgendwas auszuwerten, wo der n+xte Befehl anfängt und kann den schon ungesehen an einen Decoder weiterreichen.
Sicher auch Punkte, aber es ist halt schon allgemein auch ein Unterschied, ob man eine CPU baut, die effizient so schnell wie nötig oder eben so schnell wie möglich ist. und Platzverbrauch und Effizienz kleinere Rollen spielen. Scheint z.B. so, als hätte der im ersten iPhone verbaute Prozessor keine OoO-Execution und keine spekulative Ausführung gehabt. Auch eine Sprungvorhersage mit Sprungzielspeicherung braucht sicher einiges an Platz und auch bei Caches im Allgemeinen sinkt der Nutzen mit steigender Größe zunehmend.
Ja, auf jeden Fall. Mich würde freuen, wenn man irgendwann x86 allgemein zu den Akten legen könnte. Schon wegen der Rechtslage.

Jaein, das Thema mit RISC und CISC war in den 80er und auch Anfang der 90er durchaus ein Thema, ist heute aber weitgehend in den Hintergrund getreten.

Das Hauptproblem bei CISC und RISC ist auch nicht wirklich die variable Wortbreite gewesen, sondern die "Paradigmen" dahinter. CISC ist die ursprüngliche Art der Programmierung einer CPU und ja ein "Retronym". In den Anfangszeiten der Computer hast du diese ja anfangs mit Lochkarten und später auch auch erst mal direkt mit "Assembler" programmiert. Entsprechend hat Intel, aber auch die anderen Entwickler damals auch darauf geachtet, dass es einen gewissen Komfort in der Assembler-Programmierung gibt und damit auch verbunden eben die Komplexenanweisungen, die teilweise mehrere Operationen in einem Befehl vereint haben.

RISC ist dann zu einer Zeit entstanden, als sich Programmiersprachen wie Basic, Pascal, C und Co etablierten und auch die Compiler immer besser wurden. Darauf aufbauend kam ja dann der Gedankengang bei den Prozessoren, dass man die Befehlssätze entschlackt und vereinfacht und sich auf die "atomaren" Operationen beschränkt und der Compiler nun die Programmiersprache in den passenden Maschinencode übersetzt.

Die Notwendigkeit für "gutlesbaren" und "komfortable" Assembler-Code hat draßtisch abgenommen und RISC war damals "deutlich" einfacher zu decodieren als RISC.

Da "Transistoren" ab den 80er und erst recht ab den 90er "schlagartig" billiger wurden, konnte man aber auch da entsprechende Entwicklungen erkennen. Während x86 noch mit 8 Registern entworfen wurden - Transistoren "teuer" - haben die neuen Befehlssetze ab den 80er und 90er immer mehr Register gehabt, man kann das ja mit nehmen. Selbst Intel hat bei IA-64 auf ganze 128 Register gesetzt für die Compiler.
Es gab Ende der 80er und Anfang der 90er sogar eine Zeit, da haben ARM-Prozessoren mit Intel quasi den Boden gewischt von der Leistung her.

Die Platzeffizienz kam durch den einfacheren Decoder, die Energieeffizient zum Teil durch das größere Registerset.

Bei der Energieeffizienz kann das durchaus das Zünglein an der Wage sein. Auch wenn ggf. Daten im L1 oder L2 oder L3-Cache sind, jede Cache-Stufe benötigt entsprechend Energie um die Daten zu übertragen und das summiert sich bis zum RAM.

Am Ende geht es aber auch darum, wie viele Load/Store-Einheiten man benötigt für die ALUs. Die Anzahl der Register wirkt sich halt auch darauf aus, was man drumherum alles benötigt um die CPU gut auszulasten und da kann es dann schon entscheidend sein, ob man nun 6 ALUs mit 4 AGUs hat, oder wie Apple 6 ALUs mit nur 2 AGUs zu versorgen.

Am Ende wird es hoch spannend, was kommt. Ich bin gespannt.

Ich habe jetzt mal ein bisschen Diagramme angeguckt, scheint so als gäbe es mehrere FPUs, die jeweils verschiedene Dinge können, aber auch eher am SIMD-Register hängen, was durchaus heißen könnte, dass die auch INT-SIMD übernehmen könnten und einzelne FP-Operationen auch dort ausgeführt werden.
Bei Vergleichen mit ARM muss man aber auch immer gucken, wo die gestartet sind. Ich weiß noch wie man zu Beginn der Smartphone-Zeit immer die Platz- und Energieeffizienz von ARM bewundert hat. Aber es ist nun mal so, dass sequentielle Leistung schon ziemlich lange ziemlich schlecht skalierbar ist. Das ist jetzt aber auch schon eine Weile her und mir ist bewusst, dass ARM-CPUs schon lange nicht mehr nur mit Smartphones und Raspis assoziiert werden sollten.
Ich könnte mir vorstellen, dass der CISC-Code sich schlechter auf die Decoder verteilen lässt, weil die Wortbreite variabel ist. Aber vielleicht gibt es auch eine clevere Lösung dafür.
Es stimmt natürlich, dass die ISA Grenzen setzt, die man aber ja mit Erweiterungen ausweiten kann. Laut einem Heiseartikel will Intel mit der Verdopplung der Register die Anzahl der L/S-Operationen um 10 bis 20 Prozent reduzieren. Das ist sicher nicht schlecht, aber ob das wirklich kriegsentscheidend ist? Immerhin ist ja auch mit 16 Registern nur eine Minderheit der Befehle L/S und ein Speicherzugriff heißt in den meisten Fällen auch nur L1-Zugriff. Aber es ist sicher insgesamt ein entscheidender Nachteil, dass x86 so steinalt ist. Probleme umgehen oder mindern ist in vielen Bereichen einfach schlechter als ein Design, dass diese Probleme gar nicht erst hat. Da kommt über die Jahrzehnte vermutlich schon was zusammen.

Eigentlich gibt es die FPU in der Form ja nicht mehr wirklich. Die FPU ist auf SIMD ausgelegt. Also ja, die Erweiterungen betreffen die SIMD Ausführung. Theoretisch kannst du da auch INT rein setzen.
Gesichert ist nichts. Aber sieh dir mal die Entwicklung der ARM-Kerne von Apple an und wie diese bei der IPC skalierten mit ihrer jeweiligen Verbreiterung und wo aktuell Firestorm noch liegt.

Apple fährt ein 6-4 Design mit einem 8-fach Decoder. Das ist Intel und AMD in der IPC immer noch voraus.
Ja und nein. Man wandelt auch immer in dem Rahmen, was die ISA zulässt.

Ein breites Kerndesign bei x86 hat andere Ansprüche als ein breite Kerndesign bei ARM.

Intel bringt nicht umsonst jetzt APX und will die Register von 16 auf 32 erhöhen. Das reduziert die Load und Store-Anweisungen und entsprechend kann man länger im Compiler bei in den Registern bleiben.

Bedeutet auch, dass man weniger Store/Load-Einheiten benötigt für die ALUs. Die Daten müssen ja irgendwo her kommen und auch gespeichert werden.

Der aktuelle Hauptvorteil, den ARM noch hatte, waren die 31 Register gegenüber den 16 bei x86 in der 64-Bit Variante.

Intel geht diese „Nachteile“ nun an und macht damit auch x86 für breite Kerne fit ohne das man noch größere Infrastruktur für die Daten benötigt.

Wird interessant, wann AMD APX aufnehmen darf. In Intels und AMDs Interesse hoffe ich, das APX zeitnah bei beiden Herstellern kommt.

Am besten macht man für jede Aufgabe neue Cores.Die super kleinen Kerne (skk) sind dann nur für den idle also zum nix tuen gemacht.Können nix,nur die standard sachen.Die könnte man dann einbauen,der rest geht dann schlafen.
Sobald dann wirklich last anliegt,dann werden die anderen geweckt.Wie der rest aussehen könnte,da bin ich mir nicht sicher.Man könnte wenige Kerne noch viel breiter machen als es bei Zen 5 der fall wäre.Wäre merkwürdig wenn man wenige Kerne doppelt so breit machen würde wie es bei Zen 5 kommen wird.

Damit ich davon was hätte ,wären am besten 10 ghz auf 6 Kerne,damit die volle Leistung.Dann gehen auch weniger Kerne.Ob diese hochtaktenden 6 Kerne gegen 16 kerne mit 5 ghz eine chance hätten,kann ich nicht sagen.Und wenn extrem breit auch zu einer sehr starken Leistung führen würde,dann bräuchte ich auch weniger Kerne um die gleiche Leistung oder mehr zu haben.

Ist die frage ob das die Chiplet Nachteile ausgleichen könnte,da bin ich mir nicht sicher.Diese Kerne könnte man ja neben der Onbard GPU platzieren weil sie so klein ist und so.Damit der rest sich abschalten könnte.
Durch das fällt der Nachteil nicht mehr ins gewicht.Es in das Chiplet rein zu stecken würde wohl mehr nachteile als Vorteil bringen.

Naja ist die Frage ob sowas AMD jemals so machen würde.Die super kleinen Kerne Takten auch nicht so weit nach oben.Ab wann wäre der Takt zu klein bei 2 ghz oder erst bei 1 ghz Takt?