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

[LastManStanding]

Wow toll ich bin echt beeindruckt was ihr alles hier schreibt.. Das Ein oder Andere hab ich schon mal gehört. Ich will nicht behaupten ich verstehe nix... Aber... ich bin raus, Definitiv^^.
Hätte ich mal Studiert mit meinem niemals gelernt 1,7 Abi.. Das hab ich jetzt davon

Für mich heißt breiter, erstmal nur, Breiter! Und ihr schreibt ein Buch...Respekt

 

[ToZo1]

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.

Das sind die Pipeline-Längen. Der P4 hatte überlange Pipelines, was ihn bei Berechnungen ohne Sprünge (z.B. Videobearbeitung) sehr schnell machen konnte. Aber überall wo das Prefetching (die Sprungvorhersagenberechnung) falsch lag, verwandelte sich diese lange Pipeline zum Nachteil, weil dann um so mehr schon Vorherbrechnetes verworfen werden mußte. Am Ende war die P4-Architektur dadurch zu unflexibel, was man mit einem extrem hohen Takt auszugleichen versuchte, was damals wiederum technisch kaum in den Griff zu bekommen war und der Architektur den Beinamen "Heatburst" einbrachte, während die Athlons aufgrund ihres viel besseren Prefetchings, kürzeren Pipelines und größeren Caches mit 2/3 des Taktes oft genug Kreise um die P4 zogen.

 

[soulstyle]

Schauen wir was die Mitbewerber zaubern werden.
Dann imVerhältniss sehen.
So an sich hört es sich ja gut an.

 

[Gast1712437802]

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.

 

[Quake2008]

Wow toll ich bin echt beeindruckt was ihr alles hier schreibt.. Das Ein oder Andere hab ich schon mal gehört. Ich will nicht behaupten ich verstehe nix... Aber... ich bin raus, Definitiv^^.
Hätte ich mal Studiert mit meinem niemals gelernt 1,7 Abi.. Das hab ich jetzt davon

Für mich heißt breiter, erstmal nur, Breiter! Und ihr schreibt ein Buch...Respekt

Ich finde so sollten wir alle Diskussionen um Produkte hier führen. Danke an alle die was beigetragen haben.

 

[Elsathar]

@LastManStanding
Da hätten wir schamlose Eigenwerbung im Angebot, die das zumindest etwas erklärt

In kurz: Eine CPU erledigt Aufgaben. Diese werden in mehrere Teile zerlegt und in einer Pipeline nacheinander abgearbeitet. Wenn eine Pipeline zwei Stufen hat, dann schließt die hintere Stufe also gerade eine Aufgabe ab, während die vordere Stufe schon mit der nächsten beschäftigt ist.

Je länger ("tiefer") die Pipeline, desto kleiner sind damit die Einzelschritte. Und das ermöglicht einen höheren Takt, da kleinere Einzelschritte weniger Zeit brauchen.

Gleichzeitig kann man auch mehrere Pipelines parallel verbauen und damit Aufgaben gleichzeitig abarbeiten. Das wäre die "Breite" des Designs.

Eigentlich ist der Programmcode aber festgelegt, d.h. nicht für solche Späße ausgelegt. Für eine lange wie auch für eine gedoppelte Pipeline braucht man deshalb eine Sprungvorhersage. Die rät, mit welchen zukünftigen Aufgaben die Pipeline(s) gefüttert werden. Wenn das perfekt funktionieren würde, hätte man durch zusätzliche Pipelines 1 zu 1 auch mehr Rechenleistung. In der Realität macht die Vorhersage aber Fehler. Und immer wenn ein solcher passiert, muss der gesamte Arbeitsfortschritt verworfen werden. In der Realität wird der Leistungszuwachs deswegen - potenziell deutlich - niedriger sein.

 

[empy]

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

Das war auch nur auf die 30% bezogen, die halte ich allgemein betrachtet für sehr hoch gegriffen. Es wird sich schon an vielen Stellen bemerkbar machen, aber eben deutlich subtiler.

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.

Ich habe im Kopf, dass es meistens so vier bis fünf Befehle sind, die parallel ausführbar sind. Aber ich weiß nicht, ob da spekulative Ausführung miteinbezogen war und je nach Code ist natürlich auch mal deutlich mehr drin. Dann weiß ich auch nicht, wie viele Takte die FPUs brauchen und am Ende kommt es natürlich noch darauf an, wie viele FP-Operationen wirklich vorkommen. Die spekulative Ausführung macht eine Abschätzung noch mal schwieriger, weil der Vorteil nur dann greift, wenn die Sprungvorhersage richtig liegt. Weißt du zufällig, ob diese FPUs auch für SIMD benutzt werden oder ob es da zusätzliche Einheiten für gibt?

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.

Sequentielle Performance wird immer wichtig bleiben und es ergibt schon Sinn, (auch) CPU-Kerne zu haben, die dieses Ziel mehr oder weniger kompromisslos verfolgen. Die Frage, ob ein breiteres Frontend wirklich helfen würde, die Verbreiterung im Backend auszunutzen, ist jetzt auch nicht gesichert. Klar muss das zusammenpassen, aber wenn man durch so eine allgemeine Verbreiterung die sequentielle Leistung noch gut skalieren könnte, hätte man das vermutlich schon lange getan. Mein Eindruck in der halbwegs modernen Entwicklung ist, dass man immer den oder die größten Flaschenhälse sucht, auch wenn sie inzwischen ziemlich klein sind, um sich den Maximum anzunähern, das mit dem Fertigungsprozess möglich ist und dass aus der Tatsache heraus, dass das nicht gut skaliert auch die heterogenen Architekturen hervorgehen, wo man eben diese verschwenderischen Kerne und auf Leistung pro Kosten optimierte hat.

 

[Hagal]

Hört sich interessant an, das Problem ist nach wie vor MT. Es gibt Tools die sehr gut viele Kerne auslasten, nach dem letzten Update konnte man bei Unreal Engine v5 gut sehen was möglich ist bzw in die richtige Richtung.
Spiele hinken noch mehr hinterher als Utils. Da kommt es darauf an. On Top noch der Windows-Scheduler.

Schaun wa mal wo hin sich das bewegt

 

[PCGH_Torsten]

Weißt du zufällig, ob diese FPUs auch für SIMD benutzt werden oder ob es da zusätzliche Einheiten für gibt?

Machen auch (respektive überwiegend) SIMD.

 

[Mironicus1337]

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.

Mehr Decoder kosten womöglich zu viel die space und lassen die Leistungsaufnahme explodieren, hemmen unter Umständen die Taktbarkeit.
Von AMD stand auf den Folien etwas von "re-pipelined front end and wide issue".
Naheliegt, es bleibt bei 4 decodern. Integerseitig findet eine Aufbohrung auf auf 6 ALUs, 4 AGUs und 8 wide rename/dispatch statt. Das ganze Design wird auch ohne Änderungen am Frontend deutlich breiter, das bedeutet aber noch lange nicht, dass es deshalb schneller wird.

30% mehr 1c ipc ist sehr hochgegriffen. Ich spekuliere auf 10 bis 15%.
Die Flaschenhälse sind mit konventionellem Code nicht mehr so groß, dass solche IPC Gewinne erzielt werden können.
IPC Gewinne aus den vorliegenden Fakten zu schätzen, ist nicht mehr als Kaffeesatz zu lesen.

 

[Emil_Esel]

hoffentlich werden die nicht wieder zu gut
sonst kommt Intel ja gar nicht mehr aus der Krise
da AMD ja wohl GPUs aufgegeben hat und NieWieder das Feld überlassen hat evtl. der Fokus auf die CPU sparte

 

[LastManStanding]

@LastManStanding
Da hätten wir schamlose Eigenwerbung im Angebot, die das zumindest etwas erklärt

In kurz: Eine CPU erledigt Aufgaben. Diese werden in mehrere Teile zerlegt und in einer Pipeline nacheinander abgearbeitet. Wenn eine Pipeline zwei Stufen hat, dann schließt die hintere Stufe also gerade eine Aufgabe ab, während die vordere Stufe schon mit der nächsten beschäftigt ist.

Je länger ("tiefer") die Pipeline, desto kleiner sind damit die Einzelschritte. Und das ermöglicht einen höheren Takt, da kleinere Einzelschritte weniger Zeit brauchen.

Gleichzeitig kann man auch mehrere Pipelines parallel verbauen und damit Aufgaben gleichzeitig abarbeiten. Das wäre die "Breite" des Designs.

Eigentlich ist der Programmcode aber festgelegt, d.h. nicht für solche Späße ausgelegt. Für eine lange wie auch für eine gedoppelte Pipeline braucht man deshalb eine Sprungvorhersage. Die rät, mit welchen zukünftigen Aufgaben die Pipeline(s) gefüttert werden. Wenn das perfekt funktionieren würde, hätte man durch zusätzliche Pipelines 1 zu 1 auch mehr Rechenleistung. In der Realität macht die Vorhersage aber Fehler. Und immer wenn ein solcher passiert, muss der gesamte Arbeitsfortschritt verworfen werden. In der Realität wird der Leistungszuwachs deswegen - potenziell deutlich - niedriger sein.

Der Erste Absatz war mir tatsächlich bekannt, jedoch habe ich niemals weiter gedacht was das für Auswirkungen in welche Richtung haben kann. So in etwa hatte ich mir das aber schon etwas zusammen gereimt. Habe mich mit dem Thema tatsächlich auch in 26 Jahren PC nie wirklich Tiefergehend beschäftigt obwohl ich es Interessant finde wie das halt immer so ist

Ich werde mir die Ausgabe aus dem Stapel ziehen und zur Hand bzw nochmal zur Brust nehmen.

Danke auch Dir für die Erklärung und den Hinweis

 

[Quake2008]

hoffentlich werden die nicht wieder zu gut
sonst kommt Intel ja gar nicht mehr aus der Krise
da AMD ja wohl GPUs aufgegeben hat und NieWieder das Feld überlassen hat evtl. der Fokus auf die CPU sparte

Mach dir keine sorgen nach E- CORE´S, kommen F-Cores, kommen G-Cores oder direkt Z-Core´s. ......

 

[latiose88]

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?

 

[Gast1712437802]

Weißt du zufällig, ob diese FPUs auch für SIMD benutzt werden oder ob es da zusätzliche Einheiten für gibt?

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.

Die Frage, ob ein breiteres Frontend wirklich helfen würde, die Verbreiterung im Backend auszunutzen, ist jetzt auch nicht gesichert

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.

Klar muss das zusammenpassen, aber wenn man durch so eine allgemeine Verbreiterung die sequentielle Leistung noch gut skalieren könnte, hätte man das vermutlich schon lange getan.

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.

 

[empy]

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.

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.

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.

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.

Apple fährt ein 6-4 Design mit einem 8-fach Decoder. Das ist Intel und AMD in der IPC immer noch voraus.

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.

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.

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.

 

[Gast1712437802]

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.

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.

Ich weiß noch wie man zu Beginn der Smartphone-Zeit immer die Platz- und Energieeffizienz von ARM bewundert hat.

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.

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?

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.

 

[empy]

Das Hauptproblem bei CISC und RISC ist auch nicht wirklich die variable Wortbreite gewesen, sondern die "Paradigmen" dahinter.

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.

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

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.

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

Ja, auf jeden Fall. Mich würde freuen, wenn man irgendwann x86 allgemein zu den Akten legen könnte. Schon wegen der Rechtslage.