Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsLinux-News der Woche: Mesa wird Explizit, Updates für Proton, AMD auf RISC-V
Mit einer Emulationsschicht in Software geht dies. In Hardware bauste dann halt ein Großteil vom Frontend von x86 CPUs und die CPU würde dann als x86 CPU gelten.
Selbst beim Backend müsste man da etwas anpassen. X86 kennt ja nur 16 Register und RISC-V 32 (oder besser 31 +1 ?!). Bei Out of Order Architekturen baut man Sheduling, Reordering etc. wohl schon leicht anders, jenachdem wie viele Register vom Code angesprochen werden. Ganz abgesehen, dass RISC-V per Definition keine Exceptions wirft bei Overflow, Underflow, Nulldivision.
Das kritische ist dass bei X86 nur noch AMD und Intel Kerne entwickeln, währen sehr viele bei RISC-V Kerne entwickeln. Bei Arm sind es eigentlich AFAIK auch nur Apple, Arm und Qualcomm die Kerne entwickeln. Aber alleine Arm hat erheblich mehr Kerne als AMD und Intel zusammengenommen.
Du tust so als würde es keinen Unterschied machen außer irgendwelche Rechtlichen, wieso nutzen dann nicht ab jetzt alle RISC-V klar ein paar brauchen noch x86 wegen Rückwärtskompatibilität mit irgendwelcher Software aber sonst könnte man ja auf RISC wechseln oder wieso benutzen die Leute nicht.
Es sollte doch einen Unterschied machen ob CPUs einen kleineren oder größeren Befehlssatz verstehen, RISC hat wohl "tendenziell" kleinere Befehlssätze als CISC worunter wohl auch x86 fällt, ab dem Pentium Pro hatte Intel dann wohl irgend ne "Funktionseinheit" die komplexe CISC Befehle in simplere RISC ähnliche Befehle umwandelt die der Kern dann verarbeitet.
Soweit ich das jetzt raus lese skaliert RISC besser und ist schneller aber CISC ist komfortabler für Entwickler weil sie für jeden Scheiß nen Spezialbefehl haben.
Eine solche Übersetzung kostet im Zweifel auch Zeit/Latenzen, Strom, Geld etc.
Das würde nahelegen das RISC sehr wohl effizienter ist wenn die Software passt, natürlich kann man auch mit RISC starten und dann irgendwie CISC nach emulieren, es gibt immer ausnahmen und Einwände aber pauschal würde ich sagen wenn ich Wikipedia richtig verstehe RISC sehr wohl mehr Potenzial für Effektivität hat, ob das allerdings 1% oder 50% sind das kann ich nicht beurteilen.
So ähnlich wie GPUs effizienter sind und besser skalieren weil sie primitiver sind (kleinerer Befehlssatz), aber eben schwerer zu programmieren wie ne CPU sollte das hier auch der Fall sein wenn auch zu nem geringeren grad.
für die benutzerseite ist auf dauer dennoch entscheidend welche "kerne" tatsächlich in der herstellung landen und dann in der realen welt nutzbar werden...
Diese News zeigt auf, dass die Software Unterstützung für RISC-V wächst. Eine Vernünftige Unterstützung durch Linux und Treiber für Aktuelle Hardware ist eine Grundvoraussetzung.
Das scheint zu werden. Was ich nicht beurteilen kann ist wie binär kompatibel die einzelnen RISC-V Prozessoren zueinander sind.
Im allgemeinen ist X86 in einer schrumpfenden Nische gefangen. Um dauerhaft das Überleben zu sichern genügt der Client und Server nicht.
die nutzung hat sich doch stark verändert - wer lief früher schon mit einem "taschencomputer" durch die gegend? heute quasi jeder.
auch andere mobile geräte wie tablets oder selbst laptops waren früher wesentlich seltener verbreitet - und mit unterschiedlichen nutzungsszenarien, ändert sich auch die eigesetzte technik sowie verbreitung dieser - ca 20-25 jahre zurück fristeten die arm kerne ein nischendasein im embedded bereich - außerhalb dieser gab es im großen und ganzen nur x86/powerpc.
inzwischen sieht es eben anders aus.
Soweit ich das jetzt raus lese skaliert RISC besser und ist schneller aber CISC ist komfortabler für Entwickler weil sie für jeden Scheiß nen Spezialbefehl haben.
Was einfach nicht stimmt.
RISC und CISC nach strikter Definition hat jeweils Vor- und Nachteile. Die Implementierungen der Architekturen erfolgen im Wissen darum und kompensieren entsprechend im Rahmen des Möglichen mit Dekaden an Erfahrung. Ebenso sind ARM, x86 und bedingt RISC-V als Implementierung der ISA je keine strikten Implementierungen von RISC oder CISC.
Und Entwicklern kann wie Zielarchitektur fast egal sein. Hochsprachen sind weit genug weg und die paar Leute die handgeklöppeltes Assembler schreiben und Compiler entwickeln sind im Regelfall die entspanntesten Gesellen bei der RISC/CISC Diskussion.
Was einfach nicht stimmt.
RISC und CISC nach strikter Definition hat jeweils Vor- und Nachteile. Die Implementierungen der Architekturen erfolgen im Wissen darum und kompensieren entsprechend im Rahmen des Möglichen mit Dekaden an Erfahrung.
Alleine die Einschränkung "im Rahmen der Möglichen" widerspricht deiner Aussage, das es gar keine Unterschiede zwischen den Architekturen gäbe.
Nur weil sie geringer sind wie zu Urzeiten heißt es nicht das es nicht so ist, aber ich habe Belege für meine Vermutungen gebracht, du stellst nur pauschale totale Behauptungen in den Raum, und hast noch nicht geklärt warum man dir mehr wie Wikipedia und Co und gesundem Menschenverstand vertrauen soll.
Du hast beruflich mit irgend einem kommerziell wohl sehr wenig erfolgreichen da extrem langsam nicht sehr relevanten Soc oder sowas zu tun?
Das macht dich jetzt zum allwissenden Experten, alleine der Ton diese Rechthaberei dieser aggressive Ton, diese Verabsolutierung und 2 Sätze später wo du plötzlich doch eingestehen musst und deine Aussage einschränken mit "im Rahmen des Möglichen" also nicht vollständig, zeigt das es solche Unterschiede gibt, wie ich geschrieben habe kann ich nicht einschätzen ob die Unterschiede noch sehr groß oder sehr klein sind, aber es gibt sie wohl sind dann wohl näher an den 1% als den 50%, schön das macht meine Aussage aber nicht falsch.
@latiose88
Irgendwas ist in deinem Post schiefgegangen.
Wenn man von der Anzahl der Register einer ISA spricht, sind das immer nur Aussagen, wie viele "Allzweckregister" (General Purpose Register oder GPR) von der ISA angesprochen werden können. X86_64 kann 16 GPR von den Instruktionen adressiert werden. Bei x86 also der 32bit Variante sind es nur 8GPR. Wobei die 8 32bit GPR bei x86_64 CPUs "einfach" die unteren 8 GPRs des vollen Satzes der 16GPR sind.
Naja und die GPRs sind ja auch unterschiedlich groß. Die 64bit ISA verarbeitet ja 8, 16, 32, 64, 128 und 256bit große Register[1]. Wo man mit Zähneknirschen 8bit Werte im 64bit Register abbilden kann, wird man die >=128bit Register separat implementieren (also aufm Chip).
Was moderne CPUs aber machen ist ja fröhlich Befehle umzusortieren und um das abbilden zu können haben die Implementierungen die Register in mehrfacher Ausführung.
[1] In Ignoranz von AVX512, 80bit "double-extend" Floats und was es nicht noch alles gibt..
Ergänzung ()
blackiwid schrieb:
Alleine die Einschränkung "im Rahmen der Möglichen" widerspricht deiner Aussage, das es gar keine Unterschiede zwischen den Architekturen gäbe.
Die Aussage war, dass Nachteile bekannt sind und kompensiert werden, und nicht, dass eine absolute Parität erreicht wird.
Nur weil sie geringer sind wie zu Urzeiten heißt es nicht das es nicht so ist, aber ich habe Belege für meine Vermutungen gebracht, du stellst nur pauschale totale Behauptungen in den Raum
Du hast nicht einen externen Verweis gebracht, der als Beleg dienen könnte.
Aber da du so nett fragst, Jim Keller zum Thema:
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Wenn die eigene Position als "gesunder Menschenverstand" bezeichnet wird, impliziert das immer, dass man die Position des Gegenübers als irgendwie krankhaft darstellt. Imho ganz schlechter Stil.
Und ich weiß nicht was du in der Wikipedia gelesen hast, aber Imho kann man die deutschen Artikel zur Rechnerarchitekur lesen und kaum zu einem anderem Schluss kommen. https://de.wikipedia.org/wiki/Kategorie:Rechnerarchitektur
Englische Wikipedia wäre jedoch zu empfehlen, die Artikel sind da umfangreicher.
Du hast beruflich mit irgend einem kommerziell wohl sehr wenig erfolgreichen da extrem langsam nicht sehr relevanten Soc oder sowas zu tun?
µController kommen und gehen, meine Abneigung gegen die Architektur der STM Quellcoderepos bleibt (sie sind ISA agnostisch, aber grauenhaft redundant)
Unterschiede noch sehr groß oder sehr klein sind, aber es gibt sie wohl sind dann wohl näher an den 1% als den 50%, schön das macht meine Aussage aber nicht falsch.
Wenn du konkret Differenzen bemessen willst und etwaige Differenzen in Prozentwerten angeben, dann braucht es konkrete Vergleiche zwischen realen Implementierungen. Um dann auszuklamüsern, ob die Differenzen durch Speicheranbindung, Architektur und/oder ISA zustandekommen müssen man aber auch den Code perfekt verstehen und halbwegs wissen wie die betrachteten Prozessoren implementiert sind. Das ist ein tierischer Aufwand.
Es bleibt aber dabei, die RISC/CISC-Diskussionen sind alt, die Diskussionen welche ISA nun irgendwie die Geilste ist auch und dort wo die Leute mit Ahnung sitzen sieht man das Ganze schlicht und ergreifend entspannt, weil es sich im Wesentlichen Nichts nimmt.
Es bleibt aber dabei, die RISC/CISC-Diskussionen sind alt, die Diskussionen welche ISA nun irgendwie die Geilste ist auch und dort wo die Leute mit Ahnung sitzen sieht man das Ganze schlicht und ergreifend entspannt, weil es sich im Wesentlichen Nichts nimmt.
Du bringst Tim Keller, ich halte den nicht für Neutral, hier zu zu geben das RISC deutlich besser als CISC ist würde sein Lebenswerk in Frage stellen.
Du widersprichst mir nicht mal wirklich du sagst nur es ist schwer das in % zu messen, ich will aber auch gar nicht die genaue % Satz die Frage war nur ist diese > 0% oder nicht alles andere ist für meine Frage irrelevant.
"im Wesentlichen" du hast gesagt meine Aussage sei falsch und die war nun mal "es scheint so zu sein das tendenziell RISC leicht effizienter ist und CISC mehr komfortabel für entwickler" du schiebst mir immer unter als hätte ich gesagt das wäre ein riesen Unterschied, das habe ich nirgends gesagt/behauptet.
Du kannst meine "Quellen" kritisieren wie du willst aber ich habe irgendwelche Quellen gebracht du vor dem Post 0, du verschiebst immer den Goal Post so das es dir in die Argumentation passt, wäre nett wenn du konkret darüber argumentieren könntest was ich gesagt habe und nicht das was du mir unterstellst das ich gesagt hätte.
Wenn ich sage es scheint einen Unterschied zu geben und du sagst das stimmt nicht dann kann das nur Stimmen wenn es GAR keinen Unterschied gibt, wenn nicht ist meine Aussage nicht falsch.
Dir ist eben wichtig zu betonen das die Unterschiede sehr klein sind jetzt schön, mich hat aber mit der Lupe interessiert was für Unterschiede es gibt. Intel und AMD haben ja mehr Geld und mehr Erfahrung als jede Firma die im Moment RISC versucht zu designen, daher sind solche Unterschiede schon wichtig, wenn RISC ineffizienter ohne anstrengungen wäre wie CISC und die Firmen die das benutzen wollen weniger Geld für Forschung und anderes haben, wäre klar das die niemals auch nur in die Nähe von Intel oder AMD kommen, weil sie dann alle nachteile hätten, so haben sie immerhin diesen Nachteil nicht sondern wenn dann eher einen kleinen Vorteil.
Neben der rein theoretischen Fragen ob theoretisch x86 ähnlich gut ist oder nicht, wird eben nicht alle Software alle 10 minuten neu kompiliert, so muss z.B. x86 weiterhin 32bit und anderes Zeug unterstützten haben vielleicht auch grössere Biose, das mag nicht ein fixer Bestandteil des Befehlssatzes zu sein, aber fixer bestandteil jeglicher x86 implementierung. Dies hab ich da noch nicht mal erwähnt.
Es ist eben mit nichten so das man ständig alles neu komplieren kann. Sonst hätte sich für Homepcs x86 gar nie als quasi Monopol durch gesetzt.
@latiose88
Irgendwas ist in deinem Post schiefgegangen.
Wenn man von der Anzahl der Register einer ISA spricht, sind das immer nur Aussagen, wie viele "Allzweckregister" (General Purpose Register oder GPR) von der ISA angesprochen werden können. X86_64 kann 16 GPR von den Instruktionen adressiert werden. Bei x86 also der 32bit Variante sind es nur 8GPR. Wobei die 8 32bit GPR bei x86_64 CPUs "einfach" die unteren 8 GPRs des vollen Satzes der 16GPR sind.
Naja und die GPRs sind ja auch unterschiedlich groß. Die 64bit ISA verarbeitet ja 8, 16, 32, 64, 128 und 256bit große Register[1]. Wo man mit Zähneknirschen 8bit Werte im 64bit Register abbilden kann, wird man die >=128bit Register separat implementieren (also aufm Chip).
Was moderne CPUs aber machen ist ja fröhlich Befehle umzusortieren und um das abbilden zu können haben die Implementierungen die Register in mehrfacher Ausführung.
[1] In Ignoranz von AVX512, 80bit "double-extend" Floats und was es nicht noch alles gibt..
ah das erklärt auch warum das Programm avx so schlecht ausnutzen kann. Wobei es keine rolle spielt ob 32 oder 64 bit. avx wird einfach nur maximal zu 5 % ausgelastet. Aber es gibt prozessoren die von der 32 bit ausgebremst wird aber bei 64 bit noch eine Steigerung aber auch nicht viel vielleicht so um die 10 %. woran liegt es das es bei sehr starken CPUs zu eine Leistungs Verschlechterung bei 32 bit Programm führt obwohl es die selbe Version und so ist. Können weniger register etwa die Leistung bremsen und spielt die Anzahl der Kerne da eine Rolle das es bremst oder weiter schneller voran geht, also mit der Steigerung und so?
Du tust so als würde es keinen Unterschied machen außer irgendwelche Rechtlichen, wieso nutzen dann nicht ab jetzt alle RISC-V klar ein paar brauchen noch x86 wegen Rückwärtskompatibilität mit irgendwelcher Software aber sonst könnte man ja auf RISC wechseln oder wieso benutzen die Leute nicht.
Du hast den wichtigsten Grund genannt, warum es RISC-V auch auf Dauer schwer haben wird, AMD64 dort abzuloesen, wo AMD64 derzeit dominiert: Kompatibilitaet mit irgendwelcher Software. Deswegen hat es auch ARM schwer, dort einzudringen.
Und es laeuft auch umgekehrt: Intel hat versucht, in den Android-Markt einzudringen (angefangen mit Tablets) und ist gescheitert.
Bei RISC-V ist ein weiteres Hindernis, dass die aktuell verfuegbaren Kerne noch deutlich schwaecher sind als die Konkurrenz von AMD, Apple, ARM, Intel und Qualcomm: SiFive nennt fuer ihren staerksten Kern P870 ">18 SpecINT2k6/GHz", nennt aber keine GHz (warum wohl?). Fuer aktuelle Prozessoren listet SPEC keine SPECInt 2006 Werte, die juengsten Werte sind von 2018, alle mit irgendwelchen Servern mit teuren Xeons, von denen einige uber 80 SPECInt erreicht haben.
Es sollte doch einen Unterschied machen ob CPUs einen kleineren oder größeren Befehlssatz verstehen, RISC hat wohl "tendenziell" kleinere Befehlssätze als CISC
Nicht unbedingt. Das relevantere ist, wie kompliziert die Befehle sind, insbesondere, ob sie mehrere Speicherzugriffe durchfuehren.
worunter wohl auch x86 fällt, ab dem Pentium Pro hatte Intel dann wohl irgend ne "Funktionseinheit" die komplexe CISC Befehle in simplere RISC ähnliche Befehle umwandelt die der Kern dann verarbeitet.
Das ist heutigen Entwicklern egal, denn die meisten programmieren nicht in Assembler. Und selbst beim Polynom-Befehl der VAX ging es nicht um Komfort fuer die Entwickler.
Bin Laie, aber mit ein paar Schlagworten kann ich doch etwas anfangen:
Sind die Frontends (Decoder für CISC-ISA) in Relation zum "Rest" bezogen auf die Performance heute noch so bedeutend? "Hintenraus" ist doch seit Jahrzehnten eh' "alles granular", also RISC, oder?
ah das erklärt auch warum das Programm avx so schlecht ausnutzen kann. Wobei es keine rolle spielt ob 32 oder 64 bit. avx wird einfach nur maximal zu 5 % ausgelastet. Aber es gibt prozessoren die von der 32 bit ausgebremst wird aber bei 64 bit noch eine Steigerung aber auch nicht viel vielleicht so um die 10 %. woran liegt es das es bei sehr starken CPUs zu eine Leistungs Verschlechterung bei 32 bit Programm führt obwohl es die selbe Version und so ist. Können weniger register etwa die Leistung bremsen und spielt die Anzahl der Kerne da eine Rolle das es bremst oder weiter schneller voran geht, also mit der Steigerung und so?
"das Programm" deutet ein spezifisches Programm an, keine Ahnung welches du da meinst.
Im Allgemeinen sind die definierten Register aber kein Grund, wieso AVX oder andere Vektorerweiterungen nur bedingt nutzbar sind. Vektorisierung ist ein Zusammenspiel aus Algorithmen, den Compilern, selten mal händiges Schreiben von Assembler und natürlich der Motivation sich beim Schreiben von Software darum zu kümmern.
Wieso reine 32bit Anwendungen langsamer laufen ist dann meist wieder ein vielschichtiges Ding. Zum einen gibt es bei x86 dann nur 8 nutzbare Register, da kompensieren CPUs zwar mit Reordering und Registerrenaming, aber ein gewissen Nachteil hat es. Beispiel:
Code:
Pseudoassembler, aus Pseudo CPU mit 8 Registern
Es sollen sechs Werte addiert werden
mov R1 0x11 #Schreibe Hexadeximal 11 in Register R1
mov R2 0x12
mov R3 0x13
mov R4 0x14
mov R5 0x15
mov R6 0x16
add R1 R2 #Addiere R1 und R2, schreibe Ergebnis in R1
add R3 R4
add R5 R6
add R1 R3
add R1 R5
Angenommen die CPU hat 8 Register, und eine unendliche Anzahl an Piplines um die Berechnungen auszuführen. Dann ließe sich feststellen, dass die ersten drei ADD unabhänig voneinander sind, die könnten also auf drei Pipelines parallel ausgeführt werden. Die letzten beiden ADD sind aber abhänig, und können dann nur einzeln ausgeführt werden. Angenommen die CPU ist ideal und führt immer alles in einem Takt aus, dann sind die 5 ADD nach 3 Takten durch. Die 6 MOV wären in einem Takt erledigt. Alles in allem also 4 Takte.
Ein Takt für die ersten vier MOV, ein Takt für die ersten beiden ADD, add R1 R3 und die darauffolgenden MOV zusammen ein Takt, die folgenden ADD je einen => 5 Takte für die selbe Rechnerei.
Und es ist real deutlich komplizierter, aber rate, wer keinen Bock hat einen ganzen Assemblykurs zu schreiben. Vor allem hört es bei mir auch irgendwann auf.
Ergänzung ()
ComputerJunge schrieb:
"Hintenraus" ist doch seit Jahrzehnten eh' "alles granular", also RISC, oder?
Decoder zerlegt bei x86 generell viel in µOps, nutzt aber auch µOp-Fusion um µOps sinnvoll zusammenzufassen. Bei den dicken ARM Implementierungen gibt es auch ne ARM zu µOps Übersetzung. Die ist aber näher am 1:1 (ISA-Befehl zu µOp) als bei Intel. ARM und RISC-V nutzen dafür verstärkt µOp Fusion.
Real hält das den RSIC/CISC Definitionen nicht stand. Man bekommt allenfalls mit gezielten Mikrobenchmarks heraus, wie das Verhältnis ISA zu µOp ist und belastbare Dokumentation gibt es quasi garnicht.
krass das sagt mir nicht ganz das ganze,aber die Hexidizimal sagt mir was.Wird bestimmt bei Videoumwandlung auch so sein,mit egal welche Codec kann man so sagen.Ich kann mir das mit dem format schon etwas vorstellen.Aber wenn es nur rund 4% mehrleistung durch 64 Bit ist nicht viel.Ich denke mal das Programm Nutzt nur etwas vom 64 Bit aus,aber nicht das volle Potenzial.Nun ja irgendwas wird bei viel Kernern dennoch im Argen hängen mit 32 Bit und 64 Bit und so,bei mehr als 24 Kernen und so.Scheinbar macht das durchaus etwas nen Unterschied.
Du tust so als würde es keinen Unterschied machen außer irgendwelche Rechtlichen, wieso nutzen dann nicht ab jetzt alle RISC-V klar ein paar brauchen noch x86 wegen Rückwärtskompatibilität mit irgendwelcher Software aber sonst könnte man ja auf RISC wechseln oder wieso benutzen die Leute nicht.
Du hast gefragt, ob RISC-V besser ist als X86 und die Antwort ist nein.
Das mag Dir nicht gefallen, aber ist nun Mal so. Auch Arm ist nicht besser als X86 und X86 ist nicht besser als Arm oder RISC-V. Die Unterschiede die aus der ISA ergeben sind minimal und fallen bei den gesamten Design Entscheidungen die CPU-Architekten treffen müssen nicht ins Gewicht.
Stand der Forschung ist, dass die Micro-Architektur über die Performance entscheidet und nicht die ISA.
Aber die Marketinggeschichte, dass Arm die bessere Architetur sei ist nun Mal so schön, dass sie immer wieder gerne verbreitet ist.
blackiwid schrieb:
Es sollte doch einen Unterschied machen ob CPUs einen kleineren oder größeren Befehlssatz verstehen, RISC hat wohl "tendenziell" kleinere Befehlssätze als CISC worunter wohl auch x86 fällt, ab dem Pentium Pro hatte Intel dann wohl irgend ne "Funktionseinheit" die komplexe CISC Befehle in simplere RISC ähnliche Befehle umwandelt die der Kern dann verarbeitet.
Dieses RISC vs CISC ist eine olle Kamelle. Du kannst nun weiterhin Blödsinn lesen und weitergeben oder dich kundig machen.
Ein Anfangspunkt ist das Interview von Ian Cutress mit Jim Keller.
blackiwid schrieb:
Soweit ich das jetzt raus lese skaliert RISC besser und ist schneller aber CISC ist komfortabler für Entwickler weil sie für jeden Scheiß nen Spezialbefehl haben.
Eine solche Übersetzung kostet im Zweifel auch Zeit/Latenzen, Strom, Geld etc.
Ich habe Dir Artikel verlinkt, die ganz klar erklären dass auch Arm Befehle decodieren muss. Das gilt auch für RISC V. Es gib eine nette Tirade über das ein paar Fehlentscheidungen Design der RISC-V verhindern, dass RISC-V X86-Code effizient emulieren kann.
blackiwid schrieb:
und hast noch nicht geklärt warum man dir mehr wie Wikipedia und Co und gesundem Menschenverstand vertrauen soll.
Vor eine Weile habe ich ein geniales Statement zu Wikipedia gelesen: "Ich schaue auf Wikipedia nur Artikel zu Fachgebieten an bei denen ich mich nicht auskenne."
Wikipedia ist eine gute Orientierung und gibt immer einen guten Überblick. Aber die Artikel haben eine unterschiedliche Qualität, und deshalb würde ich Detailfragen immer überprüfen.
Und das mit dem gesunden Menschenverstand bei komplizierten Sachgebieten von dem man keine Ahnung hat, ist so eine Sache.
Ich habe Dir mehrere Artikel verlinkt, aber die gefallen Dir nicht weil sie Dein Vorurteil nicht bestätigen.
blackiwid schrieb:
Du bringst Tim Keller, ich halte den nicht für Neutral, hier zu zu geben das RISC deutlich besser als CISC ist würde sein Lebenswerk in Frage stellen.
Schön dass Du mit einem einzigen Satz zeigst, dass Du überhaupt keine Ahnung hast, und hier nur mit Plattitüden um dich wirfst.
Wenn jemand eine Ahnung von RISC vs CISC hat, dann Jim Keller. Denn er hat an vielen CPU-Kernen gearbeitet. Und der erste war ganz sicher nicht X86. Aber vielleicht schaust Du Mal in Deine Quelle Wikipedia, Lebensläufe auf Wikipedia stimmen meist. aber Du kannst ja auch bei Tenstorrent nachschauen was die machen.
Das ist eine weitere Lüge von dir. Ich habe gefragt ob sie effizienter ist, ob ein Befehlssatz oder was auch immer effizienter oder nicht effizienter ist nicht der Maßstab ob sie besser ist oder nicht. Wenn jemand Kompatibilität wichtiger ist dann ist die weniger effizienter Architektur mit mehr Kompatibilität besser.
Ich habe daher das Wort Besser ohne ein spezifischen Kontext zu nennen also pauschal wie du mir es in den Mund legst nicht mal in ner Frage geschweige den Aussage so verwendet.
Und auch deine Antwort das beide zu 100% absolut identisch effizient sind ist eine Lüge.
Bitte hör auf mich hier weiter zu diffamieren, wenn du auf meine Fragen oder sonst was nicht eingehen willst lass es bleiben anstatt zu lügen was ich gesagt oder gefragt hätte nur weil du dich zu ner falschen Aussage hast hinreisen lassen und jetzt nicht zugeben kannst das du dich vergaloppiert hast.
Änderung gehört dazu. Sie hat zur Dominanz von X86 auf dem Client und Servermarkt geführt.
Aber trotz dieser Dominanz ist Intel ist daran gescheitert sich im Smartphonemarkt zu etablieren.
cypeak schrieb:
auch andere mobile geräte wie tablets oder selbst laptops waren früher wesentlich seltener verbreitet - und mit unterschiedlichen nutzungsszenarien, ändert sich auch die eigesetzte technik sowie verbreitung dieser - ca 20-25 jahre zurück fristeten die arm kerne ein nischendasein im embedded bereich - außerhalb dieser gab es im großen und ganzen nur x86/powerpc.
Um 2000 gab es noch eine ganze Reihe anderer RISC-Architekturen, Sparc, HP Precision, ...
Embedded ist keine Nische sondern ein riesiges Anwendungsgebiet. Zu dieser Zeit waren MC68000, X86 und andere Architekturen im Embedded-Bereich noch weit verbreitet.
Aber Arm hat sich dann immer weiter verbreitet. Und Arm konnte den neu entstehenden Markt der Smartphones an sich reißen.
Eine weitere Änderung hat sich im Data Center ergeben. Wo 2014 praktisch nur Kisten mit X86 Prozessoren herumstanden machen ich andere Architekturen breit.
Dank sehr guter Branch Prediction kann man sich heute Decoder leisten, die relativ viele Zyklen brauchen, und einfache Dekodierung bringt nicht mehr so einen grossen Vorteil wie in den 1980ern.
"Hintenraus" ist doch seit Jahrzehnten eh' "alles granular", also RISC, oder?
Nicht wirklich. Mikrooperationen (uops) werden so gebaut, wie es zweckmaessig ist.
Z.B. hatte der Pentium Pro WIMRE uops mit ca. 100 bits Groesse, waehrend ein RISC-Befehl typischerweise 32 bit gross ist. In so einem uop ist offensichtlich einiges mehr drinnen als in einem RISC-Befehl. Irgendwann haben die dann eine ALU-Operation und einen Branch zu einem uop zusammengefasst, machen manche RISC-Implementierungen auch, obwohl das auf der ISA-Ebene zwei Befehle sind.
Auf der AMD-Seite kommen schon im K7 (und soweit ich weiss, noch immer) sogenannte Makro-Ops aus dem Front End in den OoO-Teil, und die umfassen z.B. load-and-op und read-modify-write Macro-Ops (also ganz anders als RISC). An gewissen Stellen werden die dann weiter in Micro-Ops (oder in manchen Beschreibungen auch ROps genannt, eben um diese Behauptung "intern RISC" zu machen) zerlegt; aus den Beschreibungen war nicht so klar, wo Makro-Ops sind und wo Mikro-Ops, aber mein Eindruck ist, dass die Puffer eher Makro-Ops enthalten und die Mikro-Ops nur ganz kurzzeitig existieren.
Ein anderer Aspekt ist natuerlich noch, dass es im OoO Bereich darum geht, einen Strom von Befehlen zu verarbeiten, praktisch ohne Kontrollfluss. Kontrollflussbefehle werden da zwar auch verarbeitet, aber nur zur Ueberpruefung, ob der Branch Predictor richtig geraten hat; wenn nicht, wird das im Front End (vor dem OoO-Teil) und im Reorder Buffer (danach) ausgelebt, die sich beide mit ISA-Befehlen beschaeftigen, und nicht im OoO-Teil. Von daher sind die Operationen, die durch den OoO-Teil fliessen, nicht geeignet, um fuer sich alleine einen Befehlssatz zu bilden; dazu braucht es noch die anderen Teile.
Von daher kann man sagen: Nein, die uops sind keine RISC-Befehle, auch wenn manche Mikroarchitekturen manche Befehle in uops zerlegen, die naeher an RISC sind als die urspruenglichen Befehle.
