x86 Advisory Group

[Badesalz]

Hat AMD die Blauen diesjahr endgültig vom Ross geholt? :freak: Ok ich hab schon vor und nach Linus mehrfach über das Chaos was Intel immer wieder verursacht abgekotzt. Wirkt das langsam? :wink:

Es scheint sie sind gegenüber AMD nun schwach genug geworden, daß die "Customer" aufgestanden sind und sagten, daß sie (Intel) jetzt entweder mitmachen oder raus sind (?)

https://www.intc.com/news-events/press-releases/detail/1715/intel-and-amd-form-x86-ecosystem-advisory-group-to

https://www.amd.com/en/newsroom/press-releases/2024-10-15-intel-and-amd-form-x86-ecosystem-advisory-group-to-accelerate.html

PS:
Ich weiß noch als Carly Fiorina zu Amtszeit mal ausrutschte, daß Intel HP plattmachen kann, wenn sie wollen würden.

[Der_Korken]

Was sind die Beweggründe, dass so eine Kollaboration entsteht und ausgerechnet jetzt? Ist das einfach nur ein "Kartell", um ARM-CPUs aus Consumer-Geräten rauszuhalten? Sehen Intel und AMD gravierende Limitierungen in ihrer ISA, die es in Zukunft nicht möglich machen technisch mit ARM-Designs mitzuhalten? Oder geht es darum Altlasten mittelfristig aus der ISA zu schmeißen, was im Alleingang aber nicht möglich wäre (vor allem ohne Software-Support)?

[Badesalz]

Tja... Es werden wahrscheinlich so einigen Analysen dessen folgen.

Limitierungen in der ISA sind es eher nicht. Instructions gibt es mittlerweile mehr als genug. Eher wäre es u.a, deren Vereinheitlichung. Wenn wir bei ISA sind.
Das Thema "Altlasten" hatten wir die Tage auch schon im Forum. Da ist nach der Entsorgung des A20-Gates real kaum was zu holen.

"Ausgerechnet jetzt" liegt wohl daran, daß Intels Überheblichkeit der Alleinherrscher und Hegemon über x86 sein zu können wohl mittlerweile komplett abgebaut wurde... Allgemein denke ich bleibt es dabei sich zwar in den besetzten Segmenten weiter zu bekriegen, aber zusammen andere Architekturen fernzuhalten. Das war zwar schon immer sinnig, aber ich vermute Intel hat das vom Olymp aus einfach nicht interessiert. Jetzt wo sie da vertrieben wurden scheint das für deren Überleben endlich relevant.

Der kleine hat das schonmal aufgegriffen
https://www.youtube.com/watch?v=gYakV3IVHAM

[MSABK]

Die Allianz könnte gegen ARM gerichtet sein, oder aber auch NVIDIA.

[Badesalz]

Die beiden jedenfalls vermeiden das Wort "Allianz" auffällig. Ich glaub kaum, daß die Gruppe etwas gegen Nvidia machen möchte. Man sollte sich die Mitglieder schon anschauen. Das sind nicht nur AMD und Intel. Für mich scheint das eher so als wenn die Restlichen Intel nun mit AMDs Macht im Rücken dazu gezwungen haben bei sowas endlich mitzumachen ;)

Die Gründe für das Advisory wie vermutet:
- Enhancing customer choice and compatibility across hardware and software, while accelerating their ability to benefit from new, cutting-edge features.

- Simplifying architectural guidelines to enhance software consistency and interfaces across x86 product offerings from Intel and AMD.

- Enabling greater and more efficient integration of new capabilities into operating systems, frameworks, and applications.

Ich kann grad nur nicht meinen Post von vor paar Tagen finden wo ich über das steigende Chaos in der ISA gelästert habe, den meist Intel verursacht. GENAU SOWAS meinte ich da nämlich ;) Ich find die beiden "Luminaries" der Group übrigens sehr spannend :tongue:

[MSABK]

Vor allem ist ja auch Microsoft dabei. Bedeutet wohl sie beerben langsam Windows on ARM.

[Leonidas]

https://x.com/PGelsinger/status/1846249205385625805
https://i.imgur.com/E3e7jN1.jpeg

[Shink]

Vor allem ist ja auch Microsoft dabei. Bedeutet wohl sie beerben langsam Windows on ARM.
Vielleicht sieht Microsoft ja ein, dass es ohne die x86-nativen Anwendungen weniger Gründe gibt, Windows zu verwenden.
Man kann natürlich x86 auf ARM emulieren aber das ist aufwändiger als Windows zu emulieren.

€: Warte mal, was macht denn Linus Torvalds dort?

[DrFreaK666]

Die Allianz könnte gegen ARM gerichtet sein, oder aber auch NVIDIA.

Man sollte Apple und ihr Öko-System nicht vergessen

[Badesalz]

Kann man. Getrost. Da wo die Kohle für x86 am allermeisten rüberschwappt gibts kein Apple und wird es auch nicht geben.

[robbitop]

Man sollte Apple und ihr Öko-System nicht vergessen
Nicht wirklich. Weil es für Apple Geräte keine konkurrierenden SoCs gibt. Apple ist irgendwie auf einer separierten Insel. Und wahrscheinlich ist Apple die ISA egal. Wenn RISC-V oder eine andere ISA deutliche Vorteile ggü ARM in der Zukunft bieten sollte, dann wird eben dahin gewechselt. Im ISA Wechseln hat Apple wahrlich Erfahrung. ^^

Es geht wohl eher darum x86 (außerhalb Apple) relevant zu halten jetzt wo ARM in immer mehr Umgebungen Einzug hält und das potenziell auch mit anderen ISAs wie RISC-V geschehen kann.

Ich persönlich vermute aber der Zug ist quasi schon abgefahren. (auch wenn gerade erst die ersten echten Erfolge im Windows Laptop Markt vorhanden sind)
Die beiden täten gut daran andere ISAs im Auge zu behalten und wenn sinnvoll eben auch zu wechseln.

[MSABK]

Arm ist für Consumer wahrscheinlich nicht so wichtig. Aber im corporate Bereich könnte das anders sein. Ich hatte da mal auf reddit gelesen, dass eine Firma massig Dell Snapdragons ausgerollt hat und die Geräte kühler und vom Akku besser sind als die anderen.

Gerade im corporate ist die Software oft ja entweder auf office oder viel remote desktop beschränkt, da wird dann das Thema Kompatibilität anders angegangen. Nur mein take warum man evtl Gefahr von ARM sehen könnte.

Natürlich kommt da jetzt Microsoft ins Spiel was die erreichen wollen mit dieser Mitgliedschaft.

[Badesalz]

XPS13 mit LunarLake 26h gegenüber XPS13 mit Snapdragon 27-28h. Das sind jetzt nicht unbedingt Welten.

[MSABK]

XPS13 mit LunarLake 26h gegenüber XPS13 mit Snapdragon 27-28h. Das sind jetzt nicht unbedingt Welten.

Klar. Mir ging es aber eher darum, dass Snapdragon/ARM wohl ein Thema in Unternehmen werden kann mit potenziell weitreichenden Folgen für die Hersteller.

[Gast_samm]

Ian Cutress rechnet mit 2.5 - 3 Jahren bis praktische Auswirkungen in Form von vereinheitlichten ISA-Erweiterungen verfügbar werden. Weist auch darauf hin, dass es explizit nicht "Konsortium" o.ä. genannt wird, also eigentlich keine Standardisierungs-Möglichkeit, Zertifizierungen oder so bietet

gYakV3IVHAM

[Shink]

XPS13 mit LunarLake 26h gegenüber XPS13 mit Snapdragon 27-28h. Das sind jetzt nicht unbedingt Welten.
Eventuell ist es für den Masseneinsatz ganz dienlich, wenn Legacy-Einfallvektoren wegfallen.

[Badesalz]

@Shink
Wie das? Läuft da OpenBSD drauf?

[ChaosTM]

Hat AMD die Blauen diesjahr endgültig vom Ross geholt? :freak: Ok ich hab schon vor und nach Linus mehrfach über das Chaos was Intel immer wieder verursacht abgekotzt. Wirkt das langsam? :wink:

Es scheint sie sind gegenüber AMD nun schwach genug geworden, daß die "Customer" aufgestanden sind und sagten, daß sie (Intel) jetzt entweder mitmachen oder raus sind (?)

https://www.intc.com/news-events/press-releases/detail/1715/intel-and-amd-form-x86-ecosystem-advisory-group-to

https://www.amd.com/en/newsroom/press-releases/2024-10-15-intel-and-amd-form-x86-ecosystem-advisory-group-to-accelerate.html

PS:
Ich weiß noch als Carly Fiorina zu Amtszeit mal ausrutschte, daß Intel HP plattmachen kann, wenn sie wollen würden.

NV hätte ATI/AMD mehrfach platt machen können und Apple existiert heute nur, weil Microsoft Angst hatte zerschlagen zu werden.

x64 geht mittel bis langfristen den Dino Weg

[Shink]

@Shink
Wie das? Läuft da OpenBSD drauf?
Ich spreche von etwas wie 32 Bit ActiveX Komponenten oder... der eine oder andere böse Virenscanner. Wenn nicht alles 100% läuft auf Windows on ARM, ist das ein Vorteil für Unternehmen.

[Badesalz]

NV hätte ATI/AMD mehrfach platt machen könnenJa? Wie denn?? Sie haben für den x86 nichtmal bugunauffällige Chipsätze hinbekommen.

x64 geht mittel bis langfristen den Dino WegDu betrachtest die Sache irgendwie weiterhin immer nur durch die blaue Brille. Entspann dich :up:

@Shink
Man muss kein Active_xy auf seinen Systemen nutzen. Windows ist Windows. Das wird nicht besser, weil es eine ARM-Version ist. Und wenn es das wäre, wäre so eine Version auch für x86 lockerst möglich.

Die HW-Plattform hat damit nichts zu tun.

[ChaosTM]

Ja? Wie denn?? Sie haben für den x86 nichtmal bugunauffällige Chipsätze hinbekommen.

Du betrachtest die Sache irgendwie weiterhin immer nur durch die blaue Brille. Entspann dich :up:



die Farbe der Brille/Pille ist irrelevant, solange sie wissenschaftlich nachvollziehbar ist.

Und ich bin extrem tiefenentspannt.. OOhmmm

[Badesalz]

Ich muss mich an solche Bilder erstmal gewöhnen :|

https://www.youtube.com/watch?v=7y32wpDhIGM

[Shink]

@Shink
Man muss kein Active_xy auf seinen Systemen nutzen. Windows ist Windows. Das wird nicht besser, weil es eine ARM-Version ist.
Wenn ich ein Unternehmen mit tausenden Mitarbeitern bin, kann ich mir sicher sein, dass irgend jemand ein Excel-Sheet mit ActiveX-Steuerelementen und einem Makro mit Zugriff auf ein 32 Bit-DLL auf seinem Firmenlaptop nutzen will, während er vom Laster gefallene China-USB-Sticks ausprobiert. Ich denke, im Moment wär man da mit Windows on ARM besser dran, so wie damals(C) mit der Windows XP 64 Bit Edition. Nein, da kann x86 nichts dafür aber es dürfte gerade wirklich so sein.

[rentex]

Ich muss mich an solche Bilder erstmal gewöhnen :|

https://www.youtube.com/watch?v=7y32wpDhIGM

Der Kalte Krieg ist vorbei und das Ende der Geschichte realität...ah, wait, anderer Film ;-D
AMD übernimmt Intel? ;-D

[Zossel]

Limitierungen in der ISA sind es eher nicht. Instructions gibt es mittlerweile mehr als genug. Eher wäre es u.a, deren Vereinheitlichung. Wenn wir bei ISA sind.
Das Thema "Altlasten" hatten wir die Tage auch schon im Forum. Da ist nach der Entsorgung des A20-Gates real kaum was zu holen.

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

Bei letzteren ist der Treppenwitz das AMD zu mindestens für die FPU schon mit einer 3-Operanden Maschine vorgelegt hatte.

[Zossel]

Ich muss mich an solche Bilder erstmal gewöhnen :|

https://www.youtube.com/watch?v=7y32wpDhIGM

Die Realität ist eben nicht GZSZ.

[Zossel]

NV hätte ATI/AMD mehrfach platt machen können und Apple existiert heute nur, weil Microsoft Angst hatte zerschlagen zu werden.

x64 geht mittel bis langfristen den Dino Weg

Und wenn ARM mit seinen Monopolallüren alle genug genervt hat wird ARM den Dino Weg gehen. Besser wäre es ARM gleich zu überspringen.

[Sunrise]

https://x.com/PGelsinger/status/1846249205385625805
https://i.imgur.com/E3e7jN1.jpeg
Oh nein! Warum muss ich mir das anschauen... :eek:

[Badesalz]

Die Realität ist eben nicht GZSZ.Umgekehrt. Grad das ist GSZS pur :tongue:

Intels feuchtes Träumchen das Chaos in der ISA ala Alleinstellunbgsmerkmale zu verstärken ist übrigens mit der x86 advisory group beendet. ENDLICH.

PS:
Leute die über Dinos schwafeln haben anscheinend nicht auf dem Schirm, daß ARMv1 von 1985 ist. Ist also exakt genau so alt wie 80386.

[Shink]

Und wenn ARM mit seinen Monopolallüren alle genug genervt hat wird ARM den Dino Weg gehen. Besser wäre es ARM gleich zu überspringen.
Das stimmt schon. Der Befehlssatz ist ja ohnehin abstrahiert, also ist das halb so relevant. Wenn man schon von x86 weg möchte, dann kann man gleich etwas mit offenem Standard nehmen; gäb ja noch ein paar zur Auswahl. Und nach der 3. Befehlssatz-Umstellung kann man sich zumindest sicher sein, dass alle Betriebssysteme Multi-Arch auf die Reihe bekommen.

[Gast]

XPS13 mit LunarLake 26h gegenüber XPS13 mit Snapdragon 27-28h. Das sind jetzt nicht unbedingt Welten.

Es geht nicht um Marketingwerte in irgendwelchen künstlich herbeigeführten Situationen, sondern um reale Akkulaufzeit.

[Badesalz]

Es geht nicht um Marketingwerte in irgendwelchen künstlich herbeigeführten Situationen, sondern um reale Akkulaufzeit.Das Verhältnis bleibt :rolleyes:

[Gast]

Das Verhältnis bleibt :rolleyes:

Bleibt es eben nicht.

ARM hat große Vorteile in typischen Alltagsszenarien mit kurzen Bursts und dazwischen geringen Lasten.

[Leonidas]

https://www.jonpeddie.com/news/amd-and-intel-defend-the-castle/
https://www.jonpeddie.com/wp-content/uploads/2024/10/x86_Intel_AMD_001-1024x1024.png

[Gast]

https://www.jonpeddie.com/news/amd-and-intel-defend-the-castle/
https://www.jonpeddie.com/wp-content/uploads/2024/10/x86_Intel_AMD_001-1024x1024.png

Nicht ganz passend, auch wenn es aus der PC-Bubble so erscheinen mag.

Tatsächlich ist es aber so, dass ARM mittlerweile alles übernommen, bis auf eben jene PC-Bubble.

Sinnbildlich würde eher sowas wie Asterix passen, ARM ist das römische Reich und x86 das kleine gallische Dorf dass sich immer noch wehrt.

Intel ist Obelix, und ARM Miraculix, die mit ihren Zaubertränken den trägen Obelix trotz dessen gewaltiger Stärke immer wieder in die Schranken weißt 🤣

[Shink]

Ihr habt noch OpenPower und MIPS (China!) vergessen. Und RISC dürfte das neue ARM werden.

Geben tut's das alles schon ewig und ich wüsste nicht, warum man den Befehlssätzen so viele Eigenschaften zugeschrieben werden.

[Gast]

Und RISC dürfte das neue ARM werden.




ARM ist RISC, genauso wie so ziemlich alles andere was danach gekommen ist.
Was du meinst ist wahrscheinlich RISC-V

[MORPHiNE]

Es geht Intel und AMD ziemlich offensichtlich darum, nicht neben ARM und längerfristig auch Implementatoren von RISC-V in der Bedeutungslosigkeit zu verschwinden.

Ihr habt noch OpenPower und MIPS (China!) vergessen. Und RISC dürfte das neue ARM werden.

Geben tut's das alles schon ewig und ich wüsste nicht, warum man den Befehlssätzen so viele Eigenschaften zugeschrieben werden.

OpenPower steckt in der HPC-Nische fest. Das ist nicht einmal der gleiche Markt. Die dort vertretenen Hersteller werden kaum ein Interesse haben, das Race to the Bottom im Consumer-Markt mitzumachen.
MIPS ist als Architektur tot, die Firma MIPS baut jetzt auf RISC-V (China!).

[HOT]

Das hat wenig mit ARM zu tun sondern eher mit dem Schutz des PC Ökosystems vor China. Die gesamten IPs bleiben nämlich in den USA. Daher ist die Karikatur nicht falsch, aber ARM ist viel zu kurz gesprungen. Die Großen bestimmen jetzt die Richtung, in die der gesamte PC und Servermarkt geht, eben auch für die mittleren und kleinen, da sie sich dem nicht entziehen können. Intels Schwäche hat zu der Allianz geführt, aber nicht wegen Ds Ausstieg, sondern weit Intel die dominante Rolle nicht mehr ausfüllen kann.

[Shink]

ARM ist RISC, genauso wie so ziemlich alles andere was danach gekommen ist.
Was du meinst ist wahrscheinlich RISC-V
Ja, natürlich meinte ich RISC V

MIPS ist als Architektur tot, die Firma MIPS baut jetzt auf RISC-V (China!).
https://www.heise.de/news/Prozessor-Architektur-MIPS-wird-Open-Source-4255114.html

Ich hatte den chinesischen, MIPS-kompatiblen Loongson im Kopf.

Ob wir alle wirklich so viele unterschiedliche Architekturen brauchen, weiß ich nicht aber im Endeffekt sollte es ja fast egal sein.
Und wenn es egal ist, dann ist klar, dass AMD und Intel mit ihrem Duopol auf dem hier genannten "Dinoweg" sind, während ARM am Dodoweg hinterherwatschelt - die Alternativen sind nicht lizenzpflichtig wenn ich das richtig sehe.

[Exxtreme]

Wenn wir bei ISA sind.
Das Thema "Altlasten" hatten wir die Tage auch schon im Forum. Da ist nach der Entsorgung des A20-Gates real kaum was zu holen.


Naja, die Altlasten loszuwerden wird wohl nicht so einfach sein. Sie sind drin weil sie gebraucht werden weil irgendwannmal jemand nach diesen Instruktionen gefragt hat und auch sehr gute Gründe hatte danach zu fragen.

Das A20-Gate gehört da eher nicht dazu. Denn das war ein Workaround weil Micros~1 auf die Idee kam unspezifiziertes Verhalten auszunutzen.

[Gast]

Naja, die Altlasten loszuwerden wird wohl nicht so einfach sein. Sie sind drin weil sie gebraucht werden weil irgendwannmal jemand nach diesen Instruktionen gefragt hat und auch sehr gute Gründe hatte danach zu fragen.



Selbst diese loszuwerden würde nichts bringen, x86 wäre immer noch ein ISA mit variabler Befehlslänge, was es aufwändiger und vor allem ineffizienter macht die Dekoder in die breite zu skalieren, und ohne ausreichend breite Dekoder verhungert irgendwann das Backend.

Da kann man noch so viele Zwischenpuffer einbauen um das Problem zu lindern, eine ISA die das Problem von haus aus nicht hat wird immer effizienter sein.

Fun fact Intel wollte schon in den 90ern x86 loswerden, und hat es eigentlich nur aufgrund von Verzögerungen noch weiterentwickelt, bis man erkannt hat dass deren Rückwärtskompatibilität eigentlich der big selling point ihrer CPUs ist.

[MORPHiNE]

https://www.heise.de/news/Prozessor-Architektur-MIPS-wird-Open-Source-4255114.html


Zu dieser Zeit war RISC-V längst im Markt. Das war der Versuch, MIPS nicht komplett in der Bedeutungslosigkeit verschwinden zu lassen. :smile:


Ich hatte den chinesischen, MIPS-kompatiblen Loongson im Kopf.


Der letzte MIPS-kompatible Loongson kam 2019 raus. Seitdem bauen sie ihre eigene Architektur ("LoongArch"). Noch eine!

Fun fact Intel wollte schon in den 90ern x86 loswerden, und hat es eigentlich nur aufgrund von Verzögerungen noch weiterentwickelt, bis man erkannt hat dass deren Rückwärtskompatibilität eigentlich der big selling point ihrer CPUs ist.

Bei "Rückwärtskompatibilität" kannst du m.E. "Rückwärts" streichen :rolleyes:

[Exxtreme]

Selbst diese loszuwerden würde nichts bringen, x86 wäre immer noch ein ISA mit variabler Befehlslänge, was es aufwändiger und vor allem ineffizienter macht die Dekoder in die breite zu skalieren, und ohne ausreichend breite Dekoder verhungert irgendwann das Backend.

Da kann man noch so viele Zwischenpuffer einbauen um das Problem zu lindern, eine ISA die das Problem von haus aus nicht hat wird immer effizienter sein.

Fun fact Intel wollte schon in den 90ern x86 loswerden, und hat es eigentlich nur aufgrund von Verzögerungen noch weiterentwickelt, bis man erkannt hat dass deren Rückwärtskompatibilität eigentlich der big selling point ihrer CPUs ist.

Irgendein CPU-Entwickler von AMD meinte mal, dass die variable Länge nicht so das Problem sei. Sprich, eine Lösung dafür gibt es wohl. Und die variable Länge hat auch Vorteile: der Code wird kompakter, es passen mehr Anweisungen in die Caches etc.

[Gast]

Irgendein CPU-Entwickler von AMD meinte mal, dass die variable Länge nicht so das Problem sei.


Irgendein AMD-Entwickler meinte mal, ich kann mich nicht mehr genau erinnern bei Zen2 oder Zen3, dass es breiter einfach nicht mehr geht weil der Verbrauch durch die Decke schießen würde.
Nun ja Raptor Lake wurde breiter und der Verbrauch ist durch die Decke gegangen, Zen 5 ebenfalls, aber der Verbrauch ist weitestgehend stagniert, also hatte er recht und irgendwie doch nicht.



Sprich, eine Lösung dafür gibt es wohl. Und die variable Länge hat auch Vorteile: der Code wird kompakter, es passen mehr Anweisungen in die Caches etc.

Genau dafür hatte man CISC erfunden, in einer Zeit in der Speicher und Cache noch sauteuer, bzw. letzteres kaum existent war.
Der Vorteil ist durch gestiegene Speicher- und Cachegrößen mittlerweile obsolet, und beim Cache war es nicht mal wirklich ein Vorteil, da dieser wiederum komplexer wird, da es kein Alignment von Instructions und Cachelines gibt.

[Shink]

Zu dieser Zeit war RISC-V längst im Markt. Das war der Versuch, MIPS nicht komplett in der Bedeutungslosigkeit verschwinden zu lassen.
Ja stimmt, die Firma "MIPS" setzt jetzt auf RISC-V. Naja klingt zumindest reflektiv.:freak:

x86 wäre immer noch ein ISA mit variabler Befehlslänge, was es aufwändiger und vor allem ineffizienter macht die Dekoder in die breite zu skalieren, und ohne ausreichend breite Dekoder verhungert irgendwann das Backend.

Da kann man noch so viele Zwischenpuffer einbauen um das Problem zu lindern, eine ISA die das Problem von haus aus nicht hat wird immer effizienter sein.

Fun fact Intel wollte schon in den 90ern x86 loswerden
War dieses Problem mit IA-64 nicht noch schlimmer?

[robbitop]

Also iirc hatte Chipsandcheese Zen 4 mal vermessen und die Decoder waren kein Bottleneck. Zen 5 und Lion Cove haben da deutlich zugelegt ohne groß etwas zu bringen.

[Der_Korken]

Kann man die Anfangsbytes der Befehle im L1I nicht einfach mit einem Flag markieren? Quasi als Pre-Decode sobald neue Cachelines in den L1I reinkommen. Dann hätte man den vollen Decode-Aufwand nur noch bei L1I-misses.

[Gast]

War dieses Problem mit IA-64 nicht noch schlimmer?

Die Idee hinter IA-64 war genau das Gegenteil, die Komplexität der Hardware zu verringern und in Richtung Compiler zu verlagern.
Die Hardware war da nur mehr ein "dummer" für damalige Verhältnisse hoch paralleler Rechenknecht. Die Idee war, warum aufwändig bei jeder Ausführung des Codes diesen in Hardware zu optimieren, wenn es der Compiler nur 1x machen muss, und dabei auch noch quasi beliebig viel Zeit hatte, während der Hardware dafür nur begrenzte Ressourcen zur Verfügung stehen.

Deshalb hätte es auch niemals x86 mit guter Performance emulieren können.

Am Ende wurde IA-64 von der schnellen Hardwareentwicklung überholt bevor es wirklich Fuß fassen konnte. OOE in Hardware wurde zu gut, da konnte der Compiler nicht mehr mithalten, am Ende kann man statisch nicht alle Abhängigkeiten perfekt für jeden Programmfluss auflösen.

[Gast]

Kann man die Anfangsbytes der Befehle im L1I nicht einfach mit einem Flag markieren? Quasi als Pre-Decode sobald neue Cachelines in den L1I reinkommen. Dann hätte man den vollen Decode-Aufwand nur noch bei L1I-misses.

Die Idee hatte man schon, so in etwa war die Funktionalität vom Trace-Cache in Netburst.

Allerdings braucht man für die gleiche Menge an gecachten Befehlen damit viel mehr DIE-Space.

Mittlerweile ist man einen Schritt weiter. Heutige CPUs haben einen Micro-Op-Cache, der quasi noch vor dem L1-I liegt und decodierte Befehle cached. Die können dann bei einem Treffer, den Decoder komplett umgehen.

[Gast]

Also iirc hatte Chipsandcheese Zen 4 mal vermessen und die Decoder waren kein Bottleneck.


Weil man die Hardware logischerweise so designt, dass keine einzelne Komponente ein massives Bottleneck darstellt, und der Rest dann einfach verhungert.

Man baut die Kerne ja nicht unnötigerweise so breit, dass sie dann vom Decoder limitiert werden.

Will man mehr ILP ausnutzen und damit mehr IPC generieren, braucht es beides, breitere Decoder und ein breiteres Backend.

Siehe Apples M-Serie, die haben ein viel breiteres Backend, was von einem viel breiteren Decoder befüllt wird, und am Ende massiv mehr IPC als x86.

[Gast]

Kann man die Anfangsbytes der Befehle im L1I nicht einfach mit einem Flag markieren?


Das ist ja gerade das Problem an einer variablen Befehlslänge, man weiß nicht wo der Anfang ist.

[Tobalt]

Glaubt ihr dass man in der x86 Group zu der Erkenntnis gelangt, dass die großen Hersteller perspektivisch einen RISC Produktpfad brauchen? Also glaubt ihr, dass speziell Intel/AMD der Meinung sind, dass sie in den nächsten "100 Jahren" mal zweigleisig fahren, oder x86 irgendwann ganz beerdigen?

Weil diese Gruppe könnte ja auch schlussfolgern, dass die Daseinsberechtigung von x86 schwindet, man aber den Phase Out harmonisieren möchte

[Shink]

Also glaubt ihr, dass speziell Intel/AMD der Meinung sind, dass sie in den nächsten "100 Jahren" mal zweigleisig fahren, oder x86 irgendwann ganz beerdigen?

Die fuhren doch schon öfters Zwei- oder gar Dreigleisig.

[Aquaschaf]

Selbst diese loszuwerden würde nichts bringen, x86 wäre immer noch ein ISA mit variabler Befehlslänge, was es aufwändiger und vor allem ineffizienter macht die Dekoder in die breite zu skalieren, und ohne ausreichend breite Dekoder verhungert irgendwann das Backend.

Da kann man noch so viele Zwischenpuffer einbauen um das Problem zu lindern, eine ISA die das Problem von haus aus nicht hat wird immer effizienter sein.

Fun fact Intel wollte schon in den 90ern x86 loswerden, und hat es eigentlich nur aufgrund von Verzögerungen noch weiterentwickelt, bis man erkannt hat dass deren Rückwärtskompatibilität eigentlich der big selling point ihrer CPUs ist.

Arm hat auch Instruktionen variabler Länge, und mit mehreren hundert Instruktionen ist es zwar schlanker als x86, aber auch kein "RISC". Und genau wie bei x86 dekodieren die komplexeren Arm-CPUs Instruktionen in ihre internen Micro-Ops.

Das einzige was indirekt einen Unterschied machen könnte ist der höhere Validierungsaufwand bei der Entwicklung. Es kostet bestimmt auch mehr Transistoren, aber das fällt absolut gesehen nicht ins Gewicht.

[fondness]

Ich denke man kann da jemanden wie Jim Keller schon vertrauen, der sowohl top ARM, x86 und jetzt RISCV CPUs in führenden Positionen entwickelt hat wenn er sagt die ISA spielt keine wirkliche Rolle.

[MORPHiNE]

Weil diese Gruppe könnte ja auch schlussfolgern, dass die Daseinsberechtigung von x86 schwindet, man aber den Phase Out harmonisieren möchte

Oder man will den Phase-Out so lange wie möglich verzögern, weil die derzeitige Duopol-Situation viel lukrativer ist, als sich den Markt mit einem Haufen asiatischer Anbieter teilen zu müssen.

Satya Nadella bringt es auf den Punkt:

“x86 has been foundational to modern computing for over four decades, and we want to ensure it continues to evolve and benefit everyone going forward. By bringing together partners across the industry, the x86 Ecosystem Advisory Board will play a critical role in shaping future x86 architectural features and help drive software consistency and standard interfaces.”


In other words: Wintel forever :freak:

[basix]

Ich denke man kann da jemanden wie Jim Keller schon vertrauen, der sowohl top ARM, x86 und jetzt RISCV CPUs in führenden Positionen entwickelt hat wenn er sagt die ISA spielt keine wirkliche Rolle.

Interessant wäre, wenn jemand einen x86 Core mit ARM Ansatz (Apple Mx, ARM X925) designen würde. Sehr breit und dafür max. 4-4.5 GHz. Ich vermute, das wird sich nicht viel nehmen hinsichtlich IPC und Energieffizienz. Performance sowie Multi-Core Energieffizienz heutiger High-End Cores ist ja ziemlich ähnlich, es gibt primär einen Unterschied bei der Energieeffizienz bei SC und mässiger CPU Last (was mit der SC Effizienz sowie Idle-Verbrauch zusammenhängt). Ist also eher eine Frage der Design-Auslegung (Core-Breite, IPC vs. Takt, Packaging, SoC, DRAM). Lunar Lake zeigt ebenfalls in diese Richtung. Apple hat den Fokus auf Consumer & Mobile, Intel & AMD sind eher bei Server unterwegs. Deswegen die verschieden Auslegung ihrer Designs. Aber anhand von Strix Point und Lunar Lake sieht man schon, dass sie ihre Cores bei entsprechenden Produkten immer mehr "Mobile-gerechter" umsetzen. Und dann gleichen sich die Performance vs. Power Charakteristiken von ARM und x86 sehr stark an.

[robbitop]

Die neusten P Cores sind doch total breit. 8 Decoder. Breites back end, dicker rob. Und hoher Takt auch ohne Frage.

Dass einfach nur breit (high level) keine Garantie für gute Performance ist zeigten ja auch Samsungs M Cores die auf dem Papier high level ja auch ganz toll aussahen und es aber nicht auf die Straße bringen konnten.

[Gast]

Ich denke man kann da jemanden wie Jim Keller schon vertrauen, der sowohl top ARM, x86 und jetzt RISCV CPUs in führenden Positionen entwickelt hat wenn er sagt die ISA spielt keine wirkliche Rolle.

Stellt sich nur die Frage, warum hat er mit x86 nirgends was vergleichbares geschafft wie mit ARM für Apple.

[robbitop]

Warum nicht geschafft? In Sachen Effizienz hält Lunar Lake und astrid doch grob mit. IPC bei niedrigen Taktraten ist auch etwas anderes als bei hohen. Niedrige Cache latencies in Takten zB muss man bei höheren Taktraten relaxen was IPC kostet.

[basix]

Die neusten P Cores sind doch total breit. 8 Decoder. Breites back end, dicker rob. Und hoher Takt auch ohne Frage.

Dass einfach nur breit (high level) keine Garantie für gute Performance ist zeigten ja auch Samsungs M Cores die auf dem Papier high level ja auch ganz toll aussahen und es aber nicht auf die Straße bringen konnten.

Dann schau dir an, wie breit Apples Cores sind. Der Reorder-Buffer war schon beim M1 einiges breiter als bei Lion Cove (~630 vs. 576 Entries). AMD ist bei Zen 5 nochmals einiges schmaler (448 Entries). Die Register Files INT/FP waren beim M1 auch schon >350 Entries (beide). Von M3 usw. finde ich auf die Schnelle keine Zahlen, die werden aber nochmals breiter als M1 sein. Dagegen sind die x86 Cores immer noch schmal ;) Und der 128kB L1D hilft Apple sicher auch.

"Nur" breit ist natürlich kein Garant für gute Performance. Das ist klar. Samungs Cores waren dort richtig schlecht. Aber Intel und AMD sind ja nicht neu im CPU-Core Design ;)

[Der_Korken]

Zen 5 und Lion Cove sind aber auch noch ein gutes Stück von Firestorm-IPC entfernt. Außerdem sind die Kerne so breit dann auch wieder nicht, wie es manchmal dargestellt wird: https://drive.google.com/drive/folders/1-Ls0SiqXBCBhMGr87ldA_47GETWfjCzQ

Zen 5 und Lion Cove haben auch je 6x INT und 4xFP, bei AGUs liegen sie sogar vorne. Zudem hat Firestorm keinen µOp-Cache, d.h. beim effektiven Decode-Durchsatz müssten auch Intel und AMD vorne liegen. Der ROB ist bei Apple zwar groß, aber zumindest beii Zen 4 war der ROB laut Chips&Cheese kein allzu großer Bottleneck - mit den +40% von Zen 5 wohl umso weniger.

Die großen L1-Caches sind dagegen Vorteil, der nicht wegzudiskutieren ist. Um hier aufzuholen, müsste man aber an der Pagesize drehen (was zudem auch viel Fläche bei den TLBs einsparen bzw. deren durchschnittliche Latenz deutlich drücken würde). Hier wäre eine Advisory Group von Vorteil, weil auch die Software-Seite vertreten ist. Das könnten Intel und AMD nicht einfach so ändern (und einer von beiden allein schon gar nicht).

[Gast]

Von M3 usw. finde ich auf die Schnelle keine Zahlen, die werden aber nochmals breiter als M1 sein.


M1-M3 hat sich bei den P-Kernen außer Takt nicht wirklich was nennenswertes getan. Da wurden hauptsächlich die E-Kerne und GPU weiterentwickelt.

Erst M4 hat ein neues Design für die P-Kerne.

[Badesalz]

Bleibt es eben nicht.

ARM hat große Vorteile in typischen Alltagsszenarien mit kurzen Bursts und dazwischen geringen Lasten.Das Verhältnis in der Akkulaufzeit bleibt! :|