Krik schrieb:
Das ist jetzt natürlich übertrieben simplifiziert.
Was du schreibst, ist nicht nur übertrieben simplifiziert, man könnte hier schon schreiben, dass es weitgehend falsch ist, was du schreibst, weil du die klassischen Stereotypen wiedergibst, die aber in der Form NIE gestimmt haben.
RISC und CISC hat nichts damit zu tun, dass CISC ein "Alleskönner" ist und RISC nicht - alleine die Andeutung in diese Richtung ist schon weitgehend Falsch und eine "Binsenweisheit". Es ist dabei auch erstaunlich, wie hartnäckig sich diese Binsenweisheit hält, obwohl sie vollständig auch gegen die Geschichte hinter RISC und CISC steht.
Bulletchief schrieb:
Gibt's irgendwo ne Erklärung for Dummies, wo die konkreten Unterschiede zwischen x86, ARM und Risc-V liegen?
Es kommt darauf an, was du an der Stelle wirklich wissen willst. Da hier aber Kirk bereits die "Binsenweisheit" hinter CISC und RISC heraus gelassen hat, muss ich jetzt ausholen und wir gehen in die Anfänge der "Computer" zurück:
RISC und CISC beschreibt die Art, wie eine ISA aufgebaut wird und ob man sich auf wenige "atomare" Operatoren beschränkt oder komplexe Operatoren nutzt. CISC steht für "Complex Instruction Set Computer" und ist der eigentliche Ursprung.
Gerade in den Anfangstagen der Computer, wurden Mikroprozessoren in der Regel "direkt" programmiert, was später dann den ersten "Umweg" über Assembler hinzu, womit es dann möglich war "lesbare" Befehle zu nutzen. Assembler ist die Lesbareform des Maschinencodes. Mit der Zeit haben Firmen wie Intel - aber auch Zilog z.B. - damit angefangen "Erleichterungen" in ihre ISAs aufzunehmen, womit das Programmieren der CPUs einfacher wurde. Dabei geht es nicht um Multipilkation mit anschließender Addition, sondern darum, dass bestimmte Konstrukte wie "bedingte Sprünge" direkt im Assembler zu implementieren.
if x then go to n. So etwas ist für Entwickler damals eine großé Hilfe gewesen. Entwickler sind "faul", wie mein Prof gerne sagte. Und wenn du Codezeilen sparen kannst, dann macht man das.
Jetzt sind wir allerdings mit 8086 und Co in den ausgehenden 70er und Sprachen wie Basic verbreiten sich, ebenso kommen weitere und komplexere Hochsprachen wie C, C++, Delphi auf den Markt, die sogar noch "komfortabler" sind, als es Assembler je sein könnte. Ein weitere Punkt ist, dass die Compiler immer besser werden.
Bei x86 gab es für Intel damals zwei Wege, wie mit dem Maschinencode umgegangen wurde: Er wird in µOPs zerlegt oder nativ ausgeführt. Entsprechend "aufwendig" war damals bereits das Decodieren für Befehle und kostete auch ggf. Zeit. Wurde der "native" Weg geführt, war das Problem, dass die CPU-Designs immer komplexer wurden.
Und diese beiden Punkte kommen zusammen: Komfortable Hochsprachen mit immer bessere werdenen Compilern sowie die immer komplexeren CPUs, weil Befehle nativ eingebettet werden müssen oder durch den Decodierer "langsam" sind. Acorn hat sich damals dann gedacht, dass es hier einen Weg raus geben muss und hat eine ISA entworfen, die auf komplexe Befehle verzichtet und sich auf atomare Operationen beschränkt, die schneller decodiert und ausgeführt werden können. Das ist dann die Geburtsstunde von RISC (Reduced Instruction Set Computer). Es geht hier bei also nicht darum, dass man "komplexe" Alleskönner und eben "sparsame" kleine CPU-Kerne bekommt. Gerade in den 80er und Anfang der 90er haben so manche Acorn-RISC-Workstations jeden PC mit x86 bei der Leistung geschlagen.
Es gibt in der Informatik einen Grundstock an Befehlen, mit denen du "arbeiten" kannst, alles andere kannst du damit dann abbilden. Und genau das hat sich Acorn dann zu Nutze gemacht: Sie haben einen schlanke ISA umgesetzt, die das nötigste kann. Alles weitere lag ab da an am Compiler, mit der Programmcode für die Plattform erstellt wird. Man könnte an der Stelle schreiben, dass man bei den Prozessoren von "
C++" zu "
Brainfuck" ging. Und das war eben auch Anfangs sehr erfolgreich, weil gerade die ersten RISC-Prozessoren den CISC-Pendants überlegen waren.
Für die "Leistunfsfähigkeit" - so wie sie hier verwendet wird durch Kirk und manche andere - ist es vollkommen egal ob RISC oder CISC. Beides beschreibt primär, wie die ISA aufgebaut wird und welche "sichtbaren" Befehle man hat. Heute abreiten alle CPUs "intern" mit µOPs und entsprechend finden sich CISC-Befehle heute auch in der ARM ISA und umgekert findet man RISC-Befehle in der x86 ISA.
CISC-RISC ist also für die weitere Diskussion über die Leistungsfähigkeit der Prozessoren irrelevant. Es gibt andere Punkte, an denen es Unterschiede gibt, und die sich auch heute noch auswirken: Alter.
x86 entstand zu einer Zeit, als Transistoren "teuer" waren. Entsprechend wurden die ISAs mit "möglichst" wenig Registern umgesetzt. Dazu hatte x86 am Anfang auch viele Register, die feste Aufgaben hatten und Befehle, die nur mit bestimmten Registern gingen. Entsprechend oft hatte man Load- und Store-Anweisungen im Assembler. (UND NEIN, SCHATTENREGISTER UND RENAMING ÄNDERT DARAN NICHTS!.) Ab den 80er wurden Transistoren günstiger und es zeigte sich bereits damals, dass alles, was in den RAM geht, mehr Energie kostet, als wenn es im Kern bleibt. Entsprechend haben damalige neue ISAs auf mehr Register gesetzt, damit man um unnötige Load- und Store-Anweisungen herum kommt. ARM hat heute 31 allgemeine Register, x86 hat 16 - mit der x64-Erweiterung eingeführt. Das hat auch heute noch eine direkte Auswirkung auf die Effizienz von Prozessoren, weil der Compiler wesentlich länger mit den Daten im CPU-Kern bleiben kann und weniger auf Daten aus dem Cache oder schlimmsten Fall eben RAM warten muss.
Es gibt hier bei (mein Ausfall muss ich ja auch erklären) noch zwei weitere Methoden, die dabei helfen, die Effizienz zu erhöhen, gleichzeitig aber auch heute dafür sorgen, dass wir überhaupt effektiv Out-of-Order-Architekturen, Spekulative-Ausführung und Co nutzen können: Register Renaming soll auf der einen Seite unnötige "Kopiervorgänge" verhindern, auf der anderen Seite sollen damit aber auch unnötige Abhängigkleiten gelöst werden. Man hat hier dann nicht "mehr" Register und man verhindert auch keine Load/Store-Anweisungen, aber man verhindert unnötige Kopiervorgänge zwischen den Registern. Das andere sind die Schattenregister, die man heute dafür benötigt, dass man Daten sowohl im Voraus lädt, aber auch sich beim Speichern der Daten "Zeit" lassen und es zu dem Zeitpunkt speichern, wenn entsprechend "Platz" dafür ist. Im "günstigsten" Fall kann er auch das Register auch wieder "benennen"
RISC-V hat ähnlich wie ARM 31 Register. Intel hat mit
APX nun eine Erweiterung, bei der x86 auf 32 Register aufgebohrt wird. Intel will mit APX einige Probleme beseitigen, die mit dem breiten Kerndesign seit Golden Cove und eben nun auch Lion Cove einher gehen und die auch AMD mit Zen 5 hat. Und um die "Profis" zu zitieren: "Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations."
Wir haben damit zwei Punkte abgearbeitet: RISC und CISC sind heute in der Form irrelevant, weil es beschreibt, wie die Befehle der ISA aufgebaut werden. Der zweite Unterschied liegt in den Registern, die die ISA definiert. Hier stehen 8/16 gegen 31 sowie ein festes Register für den Wert 0. Den Punkt geht Intel aber an.
Kommen wir zum letzten Unterschied: Den Erweiterungen. Der Hauptunterschied zwischen ARM, RISC-V und eben x86 ist heute primär in den Erweiterungen zu suchen und genau hier liegt auch das Problem von zweien der drei Architekturen. ARM und x86 teilen sich heute eine Schwäche: Sie sind historisch gewachsen. Beide ISAs haben heute sogar einen ähnlichen Umfang an "Funktionalität". Intel mit MMX und SSE führte die Vektor-Extensions ein, ARM gibt es dafür NEON. Sowohl SSE als auch NEON können mit 128-Bit-Vektoren umgehen. Intel führte dann AVX ein mit 256 Bit und später AVX 512, ARMs Antwort darauf ist die SVE (Scaleable Vector Extension) die bis zu 2048 Bit Vektoren Unterstützt. Beide haben Extensiosn für AES und andere Verschlüsselungen und Co.
Geht man hier also rein nach den Fähigkeiten, nehmen sich x86 und ARM nichts. Man kann dicke fette Kerne mit 512-Bit-SIMD ebenso mit ARM umsetzten, wie mit x86, wenn man denn will. (Plottwist: die meisten wollen nicht bei ARM, weil es kaum vorteile bringt, aber viel Platz kostet).
Und jetzt kommt RISC-V: RISC-V ist eine junge ISA, die entsprechend mit den heutigen Anforderungen desigend wurde. Während du bei x86 heute für "SIMD" MMX, SSE, SSE2, SSE3, AVX, AVX2, AVX512 und all die Unterweiterungen von AVX512 hast, ist die Auswahl bei RISC-V hier relativ "simpel". Ähnliches gilt für ARM mit Neon, SVE1 und SVE2. Bei ARM und x86 muss der Compiler die Entscheidung treffen anhand der Fähigkeiten der CPU, was der beste Weg wäre. Die Komplexität steigt an. Dazu kommt, dass man zwischen den Extensions auf der einen seite "Dopplungen" hat, gleichzeitig aber auch Funktionen wiederum fehlen. So ist SVE zwar für breite Vektoren bis 2048 Bit ausgelegt, aber bestimmte BEfehle gibt es nur in NEON, wodurch SVE nie Neon ersetzten konnte. Ähnliches kann man bei MMX, SSE und AVX Beobachten.
RISC-V schleppt keine Altlasten mit sich und kann so eine "saubere" ISA sein, die das nötigste mit bringt und deren Erweiterungen sauber getrennt sind (noch, mal sehen, was die Zukunft bringt.)
ARM umgeht das Problem mit den Erweiterungen dadurch, dass sie ihre ISA-Level eingeführt haben und fest schreiben, was eine ARMv9.5 Kern "können" muss. Intel wiederum versucht das aktuell auch und die Gründung der Allianz ist auch in diesem Kontext zu verstehen. Bei ARM gibt es genau ein Player, der hier den Ton angibt: ARM. Bei RISC-V ist es das Konsortium. x86 befand sich mit dem Erstarken von AMD Ende der 90er in einer "Sonderstellung", denn Intel und AMD haben auf der einen Seite zusammen gearbeitet, aber auch getrennt. Wenn AMD und Intel jetzt "gemeinsam" an den Erweiterungen arbeiten und beide Anbieter diese auch Zeitnah einsetzten dürfen, ist das sowohl für Intel als auch AMD ein Vorteil.
DerMond schrieb:
Das zeigt eigentlich nur dass Intel wie auch AMD selber wissen dass x86 nicht der richtige Weg in die Zukunft ist.
Das ist deine Interpretation der "Allianz". Für mich und viele andere ist das, was jetzt kommt, der Schritt in die Zukunft von x86, in dem AMD und Intel ENDLICH an einem Strang ziehen und Erweiterungen wie AMX, APX und ebenso AVX10 relativ schnell Verbreitung finden, in dem AMD und Intel sich auf dem gleichen ISA-Level bewegen.
So "interessant" AMX als auch APX ist, in der Regel setzen sich diese Erweiterungen erst durch, wenn sowohl Intel als auch AMD die Fähigkeiten besitzen. Ansonsten bleiben diese Erweiterungen lange im Schatten und werden nur in wenigen speziellen Fällen ausgepackt.
jo89 schrieb:
In Sachen Leistung/ Effizienz gibts es (soweit ich weiß) derzeit nichts vergleichbares.
LunarLake als auch Strix Point zeigen eine sehr hohe Effizienz, auch im "Low-Power"-Bereich. Ja Apple hat 2020/2021 mit dem M1 eine super Architektur hervorgebracht und auch jetzt mit M3 und M4 geht es voran.
Gleichzeitig zeigt sich aber auch bei Apple, dass sie an die "Grenzen" der Physik gebunden sind. Ein Teil der Effizienz geht auf den sehr guten Prozess von TSMC zurück. Natürlich geht auch ein Teil auf die ISA zurück, aber ebenso - und das wird ja angesprochen - von C.J. auf das Zusammenspiel von OS, CPU und dem ganzen Softtwarestack.
DerMond schrieb:
Wären Arm Prozessoren nicht so eine große Konkurrenz, oder eher Bedrohung, in der Zukunft dann gäbe es solch eine Allianz überhaupt nicht.
Richtig, wäre ARM nicht so eine Bedrohung, würde Intel und AMD immer noch so agieren, wie jetzt und bis sinnvolle Erweiterungen wirklich ankommen, vergehen Jahre, weil es sich nicht lohnt.
AVX und AVX2 sind zwei Erweiterungen, die erst jetzt anfangen wirklich Fuß zu fassen und deren Vorteile erst jetzt weitgehend ausgespielt werden, weil sie nun überall vertreten sind. AMX und APX droht quasi das gleiche Schicksal, dass bis auf Spezialanwendungen, die Vorzüge erst in 10 Jahren wirklich ausgespielt werden, was viel zu spät ist.
Wenn Intel und AMD mit den Firmen hier an einem Strang ziehen, dann ist x86 aber sehr überlebensfähig gegen ARM - RISC-V spielt aktuell quasi keine Rolle.
DerMond schrieb:
Dieser offensichtlichen Logik kannst du doch sicher noch folgen.
Nur das in so einem Fall die offensichtlichste Logik nicht unbedingt die richtige Logik ist. Wenn AMD und Intel mit den Firmen es schaffen x86 als ISA weitgehend so zu standardisieren, dass man für AMD und Intel kaum Work-a-Rounds benötigt und beide Zeitnah die gleichen Extensions unterstützen, ist hier viel gewonnen.
C.J. schrieb:
Letztlich unterscheiden sich x86- und ARM-Architekturen größtenteils im Frontend, weil x86 seit vielen Jahren intern mit Micro-Ops arbeitet und somit auch ziemlich RISC-artig ist.
Nein, das stimmt so heute nicht mehr. Wirklich große "Unterschiede" zwischen ARM- und x86-Architekturen gibt es auf Grund von RISC und CISC eigentlich überhaupt nicht mehr. In beiden Fällen wird der eigenliche Maschinencode auch durch den Decoder noch mal in µOPs zerlegt und dann entsprechend behandelt.
ISA-Technisch liegt der größte Unterschied "noch" darin, dass ARM 31 GP-Register hat und ein 0 Register, während x86 noch auf 16 GP-Register zurückgreift. Und das erkennt man auch bedingt im Kern-Design von x86 und ARM-Kernen. Die Loard-Store-Infrastruktur bei vielen ARM-Kernen ist "schmaler" als bei vergleichbaren x86-Kernen. Während man bei x86
C.J. schrieb:
Bei Effizienz werden oft die M-Chips von Apple als Referenz genommen, was auch stimmt. Allerdings ist das quasi eine inhärent auf Mobilgeräte optimierte Architektur, die z.B. nicht für Server herhalten muss.
Das ist an der Stelle ein weitaus komplexers Thema und nicht so einfach zu beantworten, weil hier verschiedene Ebenen eine Rolle spielen. Sieht man sich die M-Chips in Form als APU an, dann hast du natürlich recht, dass hier die Chips auf den mobilen sowie Client-Einsatz hin optimiert wurden und in der Form nicht im Server erhalten müssen. Das ist allerdings nur ein Punkt in der gesamten Betrachtung.
Die eigentliche µ-Arch ist in der Form nicht klassisch auf einen mobilen Einsatz hin optimiert, sondern könnte in der Form sogar sehr gut in eine Server-CPU passen und würde auch dort ihre Stärken ausspielen können, weil hier ganz andere Prämissen gelten.
Man merkt an der Diskussion hier, aber auch allgemein bei ähnlichen Diskussionen, dass oft gewisse Themen teilweise sowohl getrennt als auch zusammengefasst betrachtet werden und daher sich auch das Bild stark verfläscht. Hier in dem Thema haben wir mehrere Ebenen, auf denn wir diskutieren und die teilweise miteinander vermischt werden.
Wir haben einmal die ISA-Ebene mit RISC und CISC, dann haben wir die µ-Arch-Ebene (Kern-Design), sowie eben das finale Produkt (CPU/APU). Das macht es am Ende auch so schwer hier wirklich auf einzelne Kommentare einzugehen, weil hier Bunt die Ebenen gemischt und getrennt werden, dass man nicht mehr weiß, womit man da akkurat ansetzen kann.
Alleine bei deinem Text bewegen wir uns auf drei verschiedene Ebenen, die zum Teil sich bedingen, aber auch eigentlich getrennt betrachtet werden müssen. Du mischt ISA, µ-Arch und APU/CPU zu einem Brei und springst zwischen den drei Bereichen hin und her. (Du bist nicht der einzige!)
C.J. schrieb:
Dass diese Kerne nicht gleichzeitig auch noch Effizienzkönige in Laptops sein können, ist klar.
Aber genau das ist doch aktuell der Fall: Sowohl Lion Cove (µ-Arch) als auch Zen 5 (µ-Arch) zeigen in Lunar Lake (APU) und Strix Point (APU), dass sie sehr effizient sein können und im weiten nicht so ab geschlagen sind zu den M3-Chips (APU) und den dort verwendeten Everest (?)-Kernen (µ-Arch).
Intel pflegt zwei grundlegende µ-Archs zum aktuellen Zeitpunkt: Lion Cove für die P-Kerne und Skymont für die E-Kerne (die Vorgänger lassen wir mal raus, wird sonst zu kompliziert). Mit diesen beiden µ-Archs baut Intel verschiedene Produkte. Darunter Lunar Lake als APU für Notebooks, Arrow Lake für Clients.
AMD deckt - immer besser - mit einer µ-Arch auch alle drei Bereiche ab. Zen 5 skaliert von Ultra-Mobile bis hin zum großen Server. Das liegt daran, dass die eigentliche µ-Arch heute nur noch ein Teil der Rechnung ist, vieles andere aber auch eine Rolle spielt.
C.J. schrieb:
Dazu kommt noch, dass Apple vom Betriebssystem, über die Compiler bis hin zu kleinsten Hardware-Details alles aufeinander abstimmen kann.
Das ist einer der Hauptpunkte, warum Apple hier mit den M-Prozessoren so gut fährt.
Atma schrieb:
Im Mobile Sektor, ja. Muss ARM jedoch richtig aufdrehen und mit Epyc konkurrieren ist es schnell vorbei mit der Sparsamkeit.
Ist es dass? Der große Vorteil der µ-Arch in den M-Prozessoren war, dass es ein sehr breiter Kern war, der dafür relativ langsam takten konnte.
Und selbst von der SIMD-Breite (als ganzes Betrachtet) waren die M-Prozessoren sehr gut aufgestellt, weil sie als ganzes 512 Bit pro Takt verarbeiten konnten und das war nicht weniger als bei Intel oder AMD.
Man muss an der Stelle zwischen ISA, µ-Arch und eben dem finalen Produkt der CPU trennen. Klar, eine APU die auf den Mobilen-Einsatz hin optimiert wurde, wird im Server-Bereich nur bedingt einen Blumentopf gewinnen. Gleichzeitig kann die µ-Arch darunter aber sehr wohl auch entsprechend ausgelegt sein und könnte im richtigen fertigen Produkt auch mit einem Epyc konkurrieren.
ETI1120 schrieb:
Es geht darum eine einheitliche ISA ein definiertes Systemverhalten der X86-CPUs zu haben. Das erleichtert das Entwickeln von Software und Systemen ungemein.
Genau darum geht es und hoffentlich hat der "Wildwuchs" und die "Verzögerung" von Entwicklunen dann auch ein Ende.
Mir macht das Hoffnung, das APX und AVX10 damit deutlich schneller angekommen und verwendet werden.
