AMD waere mir lieber

[hle.ogr]

Wirklich schade, dass die Zeiten von Apple im Profi-Umfeld vorbei sind. Eine Kaesereibe mit der Qualitaet von vor 15 Jahren mit einem Threadripper oder Ryzen 3000, DA koennte ich noch einmal ueberlegen, ob man Apple noch einmal einen Chance gibt. Aber mit ARM ... ja gut fur einfache mobile Laptops ok, aber wieviel Kaffee soll ich denn dann trinken, wenn man mal richtige Arbeitsleistung braucht. Soviel Steroide kann man gar nicht in so einen ARM pumpen. Ich habe den Umstieg weg von Apple nicht bereut und bei solchen Nachrichten bestaetigt sich es einmal mehr.

[gast22]

... dann ist ja alles gut für dich.


Allerdings sehr oberflächlich, den Stand von ARM heute ausschließlich im Blick haben und künftige Entwicklungen bzw. die Potenzen einfach ignorieren. Die letzten Benchmarks vom iPad Pro werden bei dir ebenso negiert, wie die Leistungs-Steigerungen der letzten Zeit. Das sind nicht nur 3 - 5 % von Generation zu Generation wie das bei INTEL derzeit Fall ist. Irgendwann ist der Höhepunkt erreicht, wo mit der x86 kaum mehr geht.

Innovation sieht anders aus!

[hle.ogr]

Welche Benchmarks?

[Anonymer Nutzer]

gast22 schrieb:
--------------------------------------------------------------------------------
> Irgendwann ist der Höhepunkt erreicht, wo mit der x86 kaum mehr geht.
Und ARM lässt sich unbegrenzt steigern? Nein, auch dort gibt es einen "Höhepunkt" wo "kaum mehr geht". Auch ARM kann nicht zaubern.

Man darf die Benchmarks von ARM und x64 nicht vergleichen. Man vergleich ja auch nicht den Spritverbrauch von nem Lupo und nem Gigaliner LKW.

[Bonita.M]

> ... Das sind nicht nur 3 - 5 % von Generation zu Generation wie das bei INTEL
> derzeit Fall ist. Irgendwann ist der Höhepunkt erreicht, wo mit der x86 kaum
> mehr geht.

Die nächste Mikroarchitektur der Intel-CPUs wird massiv breiter: breitere Decoder, mehr Execution-Units, z.B. doppelt ausgelegte Load/Store-Units - das wird nicht nur 3-5% mehr IPC geben, sondern deutlich mehr.

[Slartie]

Agina schrieb:
--------------------------------------------------------------------------------
> gast22 schrieb:
> ---------------------------------------------------------------------------
> -----
> > Irgendwann ist der Höhepunkt erreicht, wo mit der x86 kaum mehr geht.
> Und ARM lässt sich unbegrenzt steigern? Nein, auch dort gibt es einen
> "Höhepunkt" wo "kaum mehr geht". Auch ARM kann nicht zaubern.

Exakt das geht mir in der Diskussion auch permanent auf die Nerven. Es scheint der Irrglaube selbst bei sonst technisch versierten und logisch denkenden Menschen zu bestehen, dass ARM eine Art Wundertechnik wäre, die einfach beliebig lang jedes Jahr 30-80% schnellere CPUs hervorbringen würde, und begründet wird das dann damit, dass es die letzten zehn Jahre ja so war.

Geflissentlich ignoriert wird dabei, dass die x86-CPUs vor einiger Zeit auch mal ein Jahrzehnt sprunghafter Leistungssteigerung hatten. Das ist halt nur schon seit etwa 6-8 Jahren abgeflacht, die niedrig hängenden Früchte sind geerntet, inzwischen lässt sich die Leistung nur noch unter extrem erhöhten Aufwand mit sehr viel geringerem Output steigern.

Bei ARM wurde erst wesentlich später angefangen, ordentlich Geld auf die Entwicklung zu werfen, im Grunde komplett getrieben durch die Smartphone-Revolution. Die niedrig hängenden Früchte wurden also später abgeerntet. Aber macht euch mal keine Illusionen: irgendwann gehen die auch aus. Meiner Meinung nach stehen wir kurz davor.

ARM-Cores auf dem Leistungsniveau von modernen x86-CPUs unterliegen den gleichen Limitierungen der Physik, die sich durch den aktuellen Stand der Halbleiter-Fertigungstechnik ergeben - denn das ist nun mal dieselbe Technik für beide ISAs. Es liegt also auf der Hand, dass sich die bessere Energieeffizienz der ARM-Cores weitestgehend in Luft auflösen wird, wenn man diese Cores auf Parität zum Leistungsniveau eines schnellen x86-Cores auslegt. Ebenso werden die ARM-Cores an dieselben Leistungsgrenzen stoßen, an denen sich die aktuellen Top-x86-Cores die Zähne ausbeißen. Sie sind einfach nur aktuell noch nicht an diesem Punkt, die Wand liegt noch ein Stück vor uns im Nebel, weshalb sich massenweise Leute weiterhin freudig die Augen zuhalten und auf die ARM-Machtûbernahme hoffen.

[Bonita.M]

> Exakt das geht mir in der Diskussion auch permanent auf die Nerven.
> Es scheint der Irrglaube selbst bei sonst technisch versierten und logisch
> denkenden Menschen zu bestehen, dass ARM eine Art Wundertechnik wäre,
> die einfach beliebig lang jedes Jahr 30-80% schnellere CPUs hervorbringen
> würde, und begründet wird das dann damit, dass es die letzten zehn Jahre
> ja so war.

Also zumindest die ARM-Designs bis auf die ARM-CPU von Apple könnten so einen Sprung einmalig machen, denn die IPC der ARM-CPUs ist wirklich schlecht weil die auf Stromsparen designt wurden.

> Geflissentlich ignoriert wird dabei, dass die x86-CPUs vor einiger Zeit
> auch mal ein Jahrzehnt sprunghafter Leistungssteigerung hatten. Das
> ist halt nur schon seit etwa 6-8 Jahren abgeflacht, die niedrig hängenden
> Früchte sind geerntet, inzwischen lässt sich die Leistung nur noch unter
> extrem erhöhten Aufwand mit sehr viel geringerem Output steigern.

Naja, Intel hat für den nächsten Mikroarchitektur-Schritt einen deutlich breiteren Decoder (und das bei dieser verkorksten ISA!) sowie deutlich mehr Execution-Units - z.B. doppelte Load-/Store-Units - angekündigt; das wird sicher nochmal einen guten Sprung machen.

> ... Es liegt also auf der Hand, dass sich die bessere Energieeffizienz der
> ARM-Cores weitestgehend in Luft auflösen wird, wenn man diese Cores
> auf Parität zum Leistungsniveau eines schnellen x86-Cores auslegt.

Nicht wirklich, denn die x86-ISA sowie das Systemprogrammierungsmodell haben ne Menge Eigenheiten die das Design einer Mirkoarchitektur wirklich kompiziert machen. Diese Pferdefüße haben die "RISC"-CPUs praktisch nicht.

> Ebenso werden die ARM-Cores an dieselben Leistungsgrenzen stoßen, ...

Man könnte die deutlich leistungsfähiger machen als eine x86-CPU. Die haben Eigenschaften wie ein simples Systemprogrammierungsmodell, keine Cache-Kohärenz zwischen Code- und Daten-Cache, Load-Store-Architektur, Drei-Adresss-Modell, simples Instruktions-Layout und was weiß ich noch, was alles mehr Spielraum nach oben ließe.

[Slartie]

> > Geflissentlich ignoriert wird dabei, dass die x86-CPUs vor einiger Zeit
> > auch mal ein Jahrzehnt sprunghafter Leistungssteigerung hatten. Das
> > ist halt nur schon seit etwa 6-8 Jahren abgeflacht, die niedrig
> hängenden
> > Früchte sind geerntet, inzwischen lässt sich die Leistung nur noch unter
> > extrem erhöhten Aufwand mit sehr viel geringerem Output steigern.
>
> Naja, Intel hat für den nächsten Mikroarchitektur-Schritt einen deutlich
> breiteren Decoder (und das bei dieser verkorksten ISA!) sowie deutlich mehr
> Execution-Units - z.B. doppelte Load-/Store-Units - angekündigt; das wird
> sicher nochmal einen guten Sprung machen.

Das ist doch exakt das, was ich meine. Die ganzen zusätzlichen Transistoren bekommt Intel ja nicht umsonst - die nuckeln am Power Budget, sprich der Core mag im Single-Threading schneller sein, aber braucht mehr Strom, ergo leidet die Möglichkeit, viele Cores davon in einen Chip zu packen. "Aufwand" kann sowohl mehr Komplexität als auch mehr Energieeinsatz heißen.

> > ... Es liegt also auf der Hand, dass sich die bessere Energieeffizienz
> der
> > ARM-Cores weitestgehend in Luft auflösen wird, wenn man diese Cores
> > auf Parität zum Leistungsniveau eines schnellen x86-Cores auslegt.
>
> Nicht wirklich, denn die x86-ISA sowie das Systemprogrammierungsmodell
> haben ne Menge Eigenheiten die das Design einer Mirkoarchitektur wirklich
> kompiziert machen. Diese Pferdefüße haben die "RISC"-CPUs praktisch nicht.

Diese Eigenheiten sind aber größtenteils uralt und werden seit 20 Jahren mitgetragen. Der Einfluss davon auf die Gesamtperformance des letztlichen Chips und auch auf die zukünftige Skalierbarkeit wird meiner Ansicht nach massiv überschätzt.

Ganz abgesehen davon, dass einige dieser Dinge ja einen gewissen Grund haben, so dass ARM das eine oder andere letztlich auch übernommen hat. Ich nehme mal an, du meinst mit "Systemprogrammierungsmodell" das der Privilege-Ringe? Jo, ist hundskompliziert, aber Ringe hat ARM auch, schließlich wollen die am Ende einem OS-Kernel dieselben Isolationsgarantien geben können wie x86-CPUs.

> > Ebenso werden die ARM-Cores an dieselben Leistungsgrenzen stoßen, ...
>
> Man könnte die deutlich leistungsfähiger machen als eine x86-CPU. Die haben
> Eigenschaften wie ein simples Systemprogrammierungsmodell, keine
> Cache-Kohärenz zwischen Code- und Daten-Cache, Load-Store-Architektur,
> Drei-Adresss-Modell, simples Instruktions-Layout und was weiß ich noch, was
> alles mehr Spielraum nach oben ließe.

Das Problem ist, dass alles, was du genannt hast, effektiv Vor- und Nachteile hat.

Nur mal als Beispiel: Load-Store-Architektur ist nice, weswegen x86-CPUs ja auch x86-Instruktionen (nachdem sie ein paar davon per Macro-Op-Fusion zusammengefasst haben) in Micro-Ops decoden und intern eine Art Load-Store-Architektur implementieren. Eigentlich implementieren sie intern eine sehr RISC-artige Architektur. Der Übersetzungsschritt mag ja nun als zusätzlicher Aufwand erscheinen, aber letztlich wird der a) auch für diverse andere laufzeitbasierte Optimierungen genutzt, die bei vorab in RISC-Befehle kompilierte Software schlicht gar nicht machbar sind (außer man führt einen ähnlichen RISC-to-RISC-Decode-Schritt ein, dann ist aber der Vorteil hin, dass man den nicht braucht) und vor allem b) ist der Maschinencode in x86 entsprechend kürzer gegenüber RISC, wo quasi die "Micro-Ops" direkt rauskompiliert werden. Kürzerer Maschinencode heißt weniger Instruktionen -> bessere Cache- und Bandbreiten-Nutzung.

Es gibt im Bereich CPU-Architekturen heutzutage einfach nicht viele Dinge, die klare, reine Vorteile darstellen, ohne irgendeine Form von Nachteil an anderer Stelle nach sich zu ziehen, der dann wieder kompensiert werden muss, was wieder irgendwo anders Vor- und Nachteile hat und so weiter und so weiter. Das heißt, ignoriert man mal den Entwicklungsaufwand, der in eine Arch geflossen ist, und nimmt mal an, der ist bei x86 und Intel irgendwann gleich (extrem hoch), dann wird das Endergebnis letztlich sehr ähnlich performen - mit dem ultimativen Limit, das durch die Fertigungstechnologie gesetzt wird. Die einzigen echten Unterschiede kann man durch unterschiedliche Priorisierung von Zielen hervorrufen - Stromverbrauch vs. Performance etwa. Aber keiner wird den heiligen Gral finden, der beide Ziele gleichzeitig perfekt-möglichst erreicht.

[Bonita.M]

> Das ist doch exakt das, was ich meine. ...

Ne, Du meintest, dass sich die Kurve abgeflacht hat und nur mit extrem hohen Aufwand steigern lässt. Die nächste Mikroarchitektur wird dich aber eines Besseren belehren.

> Diese Eigenheiten sind aber größtenteils uralt und werden seit 20 Jahren
> mitgetragen. Der Einfluss davon auf die Gesamtperformance des letztlichen
> Chips und auch auf die zukünftige Skalierbarkeit wird meiner Ansicht nach
> massiv überschätzt.

Nö, sicher nicht, denn aus einer echten RISC-Architektur ließe sich viel mehr rausholen als aus einer x86-Architektur.,

> Ganz abgesehen davon, dass einige dieser Dinge ja einen gewissen Grund
> haben, so dass ARM das eine oder andere letztlich auch übernommen hat.
> Ich nehme mal an, du meinst mit "Systemprogrammierungsmodell" das der
> Privilege-Ringe? Jo, ist hundskompliziert, aber Ringe hat ARM auch,
> schließlich wollen die am Ende einem OS-Kernel dieselben
> Isolationsgarantien geben können wie x86-CPUs.

Guck dir mal an, wieso die IA-32-/Intel-64-Doku mehr als 6.000 Seiten hat und die der POWER-Architektur nur ein Drittel, und der größte Teil davon bezieht sich in beiden Fällen auf die Systemprogrammierung.

> Nur mal als Beispiel: Load-Store-Architektur ist nice, weswegen x86-CPUs ja
> auch x86-Instruktionen (nachdem sie ein paar davon per Macro-Op-Fusion
> zusammengefasst haben) in Micro-Ops decoden und intern eine Art
> Load-Store-Architektur implementieren.

Irgendwie weißt Du nicht, was Load-/Store-Architektur bedeutet, denn mit Micro-Op-Fusion hat das nichts zu tun.

> Eigentlich implementieren sie intern eine sehr RISC-artige Architektur.

Das wird immer wieder kolportiert, ist aber nicht richtig. Die x86-Instruktionen werden nicht wie in RISC-Instruktionen nach Load-/Store-Manier aufgespalten, sondern durchlaufen mit der ursprünglichen Semantik die Execution-Units. Und nicht nur das: mit der Macro-Op-Fusion wird genau das Gegenteil gemacht wie bei RISC, nämlich einzelne Instruktionen zu komplexeren zusammengefasst. Und dann gibt es noch tausend Eigenheiten die RISC-CPUs haben und die x86er nicht haben, wie z.B. die Kohärenz zwischen Code- und Daten-Cache, oder umgekehrt, dass x86er Eigenheiten haben die RISC nicht kennt, also die Segmente (die es für Windows-Zwecke für ausgewählte Segmentregister sogar im Large Mode gibt). Also, grundsätzlich gibt es einfach einen Haufen Implikationen die eine x86-CPU bei weitem nicht so einfach designbar machen wie eine echte RISC-CPU (wobei sich RISC hier weniger auf die nicht wirklich reduzierte ISA bezieht).

> Der Übersetzungsschritt mag ja nun als zusätzlicher Aufwand erscheinen,
> aber letztlich wird der a) auch für diverse andere laufzeitbasierte Optimierungen
> genutzt, die bei vorab in RISC-Befehle kompilierte Software schlicht gar nicht
> machbar sind (außer man führt einen ähnlichen RISC-to-RISC-Decode-Schritt
> ein, dann ist aber der Vorteil hin, dass man den nicht braucht) und vor allem
> b) ist der Maschinencode in x86 entsprechend kürzer gegenüber RISC, wo quasi
> die "Micro-Ops" direkt rauskompiliert werden. Kürzerer Maschinencode heißt
> weniger Instruktionen -> bessere Cache- und Bandbreiten-Nutzung.

Nochmal: es gibt einen Haufen x86-Implikationen die es zum Märchen machen, dass heutige x86er sich jenseits des Decoders wie eine RISC-CPU verhalten,

> Das heißt, ignoriert man mal den Entwicklungsaufwand, der in eine Arch
> geflossen ist, und nimmt mal an, der ist bei x86 und Intel irgendwann gleich
> (extrem hoch), dann wird das Endergebnis letztlich sehr ähnlich performen -
> ...

Nö, bei den echten RISC-CPUs ist z.B. der Decoder breiter realisierbar weil das Instruktionslayout wesentlich einfacher ist (von Thumb mal abgesehen, aber das ist ja History). Außerdem macht das Relaxed Memory Ordering, die nicht vorrhandene Kohärenz zwischen Code- und Daten-Cache (man bedenke nur mal, dass vordecodierte Instruktionen im Code-Cache kohärent zum Daten-Cache sein müssen und was das für ein Aufwand ist!) und das Drei-Adress-Modell theoretisch leistungsfähigere CPUs möglich als es bei x86 möglich ist.
Die einzigen Gründe die dagegen sprechen, dass es eben noch keine gleichermaßen schnellen "RISCs" gibt ist (selbst die POWER-CPUs haben keine so hohe IPC wie eine x86er), dass Intel einfach die meiste Kohle für die Entwicklung der CPUs hat und, dass manche CPUs wie die ARMs durchweg auf Stromverbrauch getrimmt sind.

[rldml]

Bonita.M schrieb:
--------------------------------------------------------------------------------
> Nö, sicher nicht, denn aus einer echten RISC-Architektur ließe sich viel
> mehr rausholen als aus einer x86-Architektur.,

Wenn dem so wäre, würde x86 ebenfalls auf RISC basieren und alles andere würde leglich ein Nischendasein fristen. Das ist aber gegenwärtig nicht der Fall.

Vergiss nicht, bei Intel sitzen keine Idioten. Die haben mit Prozessoren mehr Erfahrungen als alle andere Unternehmen auf der Welt.

[Bonita.M]

>> Nö, sicher nicht, denn aus einer echten RISC-Architektur ließe sich viel
>> mehr rausholen als aus einer x86-Architektur.,

> Wenn dem so wäre, würde x86 ebenfalls auf RISC basieren ...

Is aus historischen Gründen aber nicht mehr umzubiegen.

> Vergiss nicht, bei Intel sitzen keine Idioten. Die haben mit Prozessoren
> mehr Erfahrungen als alle andere Unternehmen auf der Welt.

Eben, und deswegen hat selbst die günstigste Intel Core-i-sonstwas-CPU mit SMT eine höhere IPC pro Kern über beide Threads als eine superteure POWER-CPU mit acht Threads pro Kern.
Nichtsdestotrotz ließe sich aus der Architektur mehr rausholen als aus einem x86er. Ist nur die Frage, wieviel Geld man in die Entwicklung steckt. Und da spielt es keine Rolle, ob das eine POWER-, ARM-, SPARC- oder Sonstwie-"RISC"-CPU ist; die haben alle die selben Eigenschaften die das Design deutlich vereinfachen und breiter realisierbar machen.



2 mal bearbeitet, zuletzt am 23.02.19 14:04 durch Bonita.M.

[rldml]

Bonita.M schrieb:
--------------------------------------------------------------------------------
> >> Nö, sicher nicht, denn aus einer echten RISC-Architektur ließe sich
> viel
> >> mehr rausholen als aus einer x86-Architektur.,
>
> > Wenn dem so wäre, würde x86 ebenfalls auf RISC basieren ...
>
> Is aus historischen Gründen aber nicht mehr umzubiegen.

Nein du verstehst nicht - RISC als Konzept so alt wie die x86-Familie und stammt noch aus den 60er-Jahren. Wenn das im Vergleich zu CISC so einen eklatanten Leistungsunterschied gegeben hätte, hätte man bei Intel von Anfang an darauf gesetzt.

>
> > Vergiss nicht, bei Intel sitzen keine Idioten. Die haben mit Prozessoren
> > mehr Erfahrungen als alle andere Unternehmen auf der Welt.
>
> Nichtsdestotrotz ließe sich aus der Architektur mehr rausholen als aus
> einem x86er. Ist nur die Frage, wieviel Geld man in die Entwicklung steckt.
> Und da spielt es keine Rolle, ob das eine POWER-, ARM-, SPARC- oder
> Sonstwie-"RISC"-CPU ist; die haben alle die selben Eigenschaften die das
> Design deutlich vereinfachen und breiter realisierbar machen.

Wenn du mit "breiter" mehr Kerne meinst:

Zum einen kannst du nicht alles nach belieben parallelisieren, zum anderen verlagerst du die Komplexität höchstens. Wenn du eine Funktion nicht festkodiert in der CPU hast, musst die sie entweder mit den vorhandenen Instruktionen nachbauen (a.k.a. emulieren) oder du musst sie in einen separaten Chip auslagern, der dann ebenfalls irgendwo aufs Board muss, Leistung schluckt und im schlimmsten Fall sogar aktiv gekühlt werden muss. Mal von dem Aspekt abgesehen, dass sich die Signallaufzeiten erheblich erhöhen, was wiederum bei Echtzeitanwendungen echt kacke ist.

Auf dem Papier mag ARM gut aussehen und in bestimmten Situationen isses sicher x86 überlegen, aber das würde ich nicht so pauschalieren, wie du es hier tust.

[wonoscho]

Bleibt zu hoffen, dass auch die Energie-Effizienz deutlich besser wird.
Denn deutlech mehr Rechenleistung bei gleichzeitig deutlich mehr Energieverbrauch, das wäre kein wirklicher Fortschritt.

[Bonita.M]

> Bleibt zu hoffen, dass auch die Energie-Effizienz deutlich besser wird.
> Denn deutlech mehr Rechenleistung bei gleichzeitig deutlich mehr
> Energieverbrauch, das wäre kein wirklicher Fortschritt.

Die AMD-/Intel-CPUs sind für ihre Leistungsfähigkeit schon recht effizient.
Und das sind auch keine Smartphone-CPUs, also was soll's?
Ich mein mit Intel-CPUs lassen sich Notebooks mit Laufzeit von 10h+ realisieren; was will man mehr?

[Bonita.M]

>>> Wenn dem so wäre, würde x86 ebenfalls auf RISC basieren ...

>> Is aus historischen Gründen aber nicht mehr umzubiegen.

> Nein du verstehst nicht - RISC als Konzept so alt wie die x86-Familie und
> stammt noch aus den 60er-Jahren. Wenn das im Vergleich zu CISC so einen
> eklatanten Leistungsunterschied gegeben hätte, ...

Ich hab auch nicht gesagt, dass x86 nicht jünger wäre, sondern die historischen Gründe sind eben damalige Design-Entscheidungen.

> Wenn du mit "breiter" mehr Kerne meinst:

Nein, mehr IPC.

> Zum einen kannst du nicht alles nach belieben parallelisieren,
> zum anderen verlagerst du die Komplexität höchstens.

Mehr IPC durch breitere parallele Ausführung mehrerer Instruktionen ist nur durch die CPU möglich; die VLIW-/EPIC-Ansätze wo der Compiler das machen sollte sind ja gescheitert.

> Wenn du eine Funktion nicht festkodiert in der CPU hast, musst die sie entweder
> mit den vorhandenen Instruktionen nachbauen (a.k.a. emulieren) oder du musst
> sie in einen separaten Chip auslagern, ...

Was diskutierst Du da für einen Unsinn?
Es geht um die ISA, und die ist Sache der CPU.

> Leistung schluckt und im schlimmsten Fall sogar aktiv gekühlt werden muss.
> Mal von dem Aspekt abgesehen, dass sich die Signallaufzeiten erheblich
> erhöhen, was wiederum bei Echtzeitanwendungen echt kacke ist.

Du phantasierst echt munter rum. Niemand schreibt Echtzeit-Anwendungen die so Timing-kritisch sind, dass das Timing mit dem Durchsatz der OoO-Ausführung auf der Kippe steht.

> Auf dem Papier mag ARM gut aussehen und in bestimmten Situationen isses
> sicher x86 überlegen, aber das würde ich nicht so pauschalieren, wie du es
> hier tust.

Du diskutierst voll an meinen Aussagen vorbei.
Mit breiterer Ausführung meinte ich mehr IPC, und die ist aus "RISC"-Architekturen leichter und eher rausholbar als aus CISC-Architekturen.

[wurstdings]

rldml schrieb:
--------------------------------------------------------------------------------
> Bonita.M schrieb:
> ---------------------------------------------------------------------------
> -----
> > Nö, sicher nicht, denn aus einer echten RISC-Architektur ließe sich viel
> > mehr rausholen als aus einer x86-Architektur.,
>
> Wenn dem so wäre, würde x86 ebenfalls auf RISC basieren und alles andere
> würde leglich ein Nischendasein fristen. Das ist aber gegenwärtig nicht der
> Fall.
Oh doch seit dem Pentium Pro basiert x86 auf RISC und wird nur von außen mit CISC-Befehlen angesprochen.