News Sonntagsfrage: ARM oder x86, wem gehört die Zukunft in Server und PC?

[ghecko]

So kann ich allerdings praktisch beliebige Hardware kaufen, eigenhändig zusammenbauen und Windows 10 oder 11 in weniger als 10 Minuten komplett installieren. Bei ARM? Fehlanzeige!

Die 10 Minuten unterbiete ich mit jedem Raspberry Pi.

 

[LencoX2]

Das würde ja bedeuten das die Umstellung vom Intel Mac auf M1 nicht möglich wäre. Es funktioniert aber alles und der Nutzer merkt außer einen ordentlichen Leistungszuwachs bzw. geringer Geräuschpegel nichts davon. Selbst emulierte! Programme laufen darauf schneller wie nativ auf der abgestaubten x86 Architektur.

Es war die Rede von PC, also non-Apple.
Nicht möglich gibt es nicht. Die SW müsste wie bei Apple neu gebaut und ggfs umprogrammiert werden.

 

[Piktogramm]

War aber wohl nur im Rahmen Microcontrollerentwicklung der Grafikabteilung.
Findet man, sofern es diese Anzeige war, noch über den Google Cache.

Ich denke, da sollte man nicht zuviel hinein interpretieren

Im Zweifelsfall heißt das trotzdem, dass AMD Mitarbeiter auf Entwicklung der Hardware, Validierung und Softwareentwicklung schmeißt.

Die Antwort, beiden! Es wird FPGA dazukommen und Architekturen, die man jetzt noch gar nicht auf dem Schirm hat.

FPGAs haben ein kleines Fenster, wo sie sinnvoll Verwendung finden können. Vor Corona und Chipkriese waren 45 und 28nm Kleinstproduktionen recht günstig. Wenn man die Flexibilität eines FPGA nicht braucht, lohnen sich da recht schnell eigene Chips.
Und Architekruren die nicht auf dem Schirm sind, haben keine Softwareinfrastruktur. Das lohnt einfach überhaupt nicht aus kommerzieller Sicht. Wenn überhaupt geht sowas nur, wenn man am Geldtropf von Militär & Geheimdiensten hängt wie die Elbrus CPU der Russen:
https://en.wikipedia.org/wiki/Elbrus-8S
Aus der Nische kommt der Kram aber nie raus.

 

[Raucherdackel!]

@SkipOutLaw Du kannst auch Win 11 auf jeder ARM Plattform installieren. Wenn der Hersteller die Treiber "frei" zur Verfügung stellt, kann Windows sie ggf. online suchen und installieren. Aber die ARM Hersteller geben halt ihre Treiber nicht frei, das ist das Problem. Win11 on ARM läuft jedenfalls auf sämtlichen Microsoft Geräten, auch dem Lumia 950. Allerdings legt der geschlossene Bootloader sein fettes Veto ein^^

 

[Miuwa]

Zum Vergleich:
Schon von Intel auf AMD tun sich extremst viele Leute schwer, obwohl annährend jede HW/SW läuft.

Kennst du da echt so viele? Im Bekanntenkreis und Büro hab ich noch nie von Problemen gehört, aber das ist natürlich nur ne sehr kleine und nicht repräsentative Samplesize.

 

[Raucherdackel!]

Doch, der M1 hat mit seinen Firestorm-Kernen genau eben das gezeigt, dass es generell mit einem ausgewachsenen x86-Design ebenbürtig ist.

Das hat eigentlich schon Microsoft mit dem Win10 ARM, ihrem SQ1 Prozessor und ihrer 32bit-Emulation gezeigt. Hier gibt es auf CB einen Community Test, der 100 Spiele emuliert auf dem Surface Pro X zeigt. Und siehe da: Counterstrike Source ist schneller als X86. Obwohl emuliert und obwohl Microsoft nur ARM Kerne verwendet und kein eigenes Design.

 

[mae]

ARM ist zum Ende der 90er in die Ecke der Embedded CPUs und Lowpower-CPUs gerutscht, weil es sehr einfach ist mit der ARM-ISA auch solche CPUs zu designen, da diese damals quasi keinen Overhead hatten - wie x86. Aber bereits damals skalierte ARM quasi von Klein bis Groß.

Nein, ARM war am Anfang (Mitte der 80er) eindeutig gross (32-bit-Speicherinterface, als der Mainstream noch 8 oder 16 bit hatte). Dann sind sie dort stehengeblieben und wurden (relativ zu den anderen) klein. Damals haben die nicht viel skaliert.

Sie haben offenbar erkannt, dass sie nicht mit dem Entwurfsaufwand der Konkurrenz mithalten konnten und haben sich ein anderes Geschaeftsmodell gesucht: Embedded-CPUs fuer Low Power als Design-Bloecke fuer kundenspezifische SoCs, waehrend die Konkurrenz noch versucht hat, Chips zu verkaufen; so kamen sie in die Mobiltelefone und spaeter in die ersten Smartphones.

Und als dann bei den Smartphones auf einmal Bedarf nach mehr Prozessorleistung da war, war das GHz-Rennen schon vorbei (das war toedlich fuer die anderen RISCs, weil jedes Design innerhalb kuerzester Zeit veraltet war). ARM hat dann nach langen Jahren des Stillstands doch kompliziertere Kerne entworfen, im Laufe der Zeit superskalare Kerne mit out-of-order execution, und da sind sie jetzt.

Zusaetzlich hatten sie noch das Geschaeft mit mit der Architekturlizenz; zuerst StrongARM, spaeter dann Apple, Qualcomm, Samsung, Nvidia (wobei ARM dann so konkurrenzfaehige Kerne gemacht hat, dass die meisten davon ihre eigenen Projekte aufgegeben haben).

 

[Miuwa]

Nicht zu vergessen sind SOC Systeme aufgrund ihrer Bauart günstiger und auch effizienter als modulare Systeme, bestehend aus einzelnen CPUs, Arbeitsspeicher, Mainboard und diversen Steckkarten.

Auch x86 gibts als SOC. Allerdings glaube ich nicht, dass es - egal ob x86 oder ARM - Server/Dektop SoCs gibt , bei denen der RAM auf dem Chip sitzt. Das kenn ich eigentlich nur von Microcontrollern und ähnlichem (Beim M1 ist der RAM meines Wissens zwar im gleichen Gehäuse, aber nicht auf dem gleichen Chip).

Allerdings vergleichen wir Generalisten (X86, alles muss laufen) gegen Spezialisten (ARM, mit spezifischen Baustein für spezielle Probleme/Einsatzgebiete).

Von welchen ARM systemen redest du denn Konkret? Diejenigen, die in Servern/Consumer Systemen eingesetzt werden sind meines Wissens auch nicht emhr

Wissen wir nicht, dass ist hier aber auch nicht das Thema, es geht darum ob x86 weiterhin die oberhand behält als ISA oder ob ARM als ISA übernehmen wird, vielleicht aus RISC-V.

Es ist dabei vollkommen irrelevant ob Apple ihren Prozessor anbieten würde oder nicht.

Eigentlich ist das durchaus Relevant - zumindest für die Zeitskala. Ich bin mir ziemlich sicher, dass die Frage, welche ISA sich am Ende durchsetzt nicht von den vorzügen der ISA selber, sondern von den verfügbaren Implementierungen abhängt und das ist Apple eben derzeit Vorreiter.

Wenn Apple die M1 Chips verkaufen würde, dann würde sich Windows on ARM vermutlich wesentlich schneller durchsetzen (bzw. überhaupt durchsetzten) als das momentan der Fall ist. Einfach weil man damit wesentlich Leistungsfähigere Windows Tablets bauen könnte, als das derzeit mit x86 CPUs oder den ARM SoCs von Qualcom möglich ist.


======

Noche ne generelle Sache, die mir bei der Diskussion hier auffällt: Es wäre hilfreich, wenn die Leute in Ihren Posts klar machen würden, ob sie über die Vor- und Nachteile der ISAs, den konkreten Produkten (CPUs /SoCs) oder dem jeweiligen Ökosystem reden. Ein großer Vorteil den x86 nämlich derzeit noch hat ist halt das Ökosystem. Das hat zwar inhärent erstmal nichts mit der ISA selber zu tun, aber ist natürlich für den Erfolg/Misserfolg durchaus relevant.

 

[Wölkchen]

Ok, aber weshalb sollte ein Land wie China eigene CPUs mit x86 Befehlssatz entwickeln und produzieren?

Um sie an diejenigen zu verkaufen, die sie haben wollen, auch international.

 

[Piktogramm]

Nein, ARM war am Anfang (Mitte der 80er) eindeutig gross (32-bit-Speicherinterface, als der Mainstream noch 8 oder 16 bit hatte). Dann sind sie dort stehengeblieben und wurden (relativ zu den anderen) klein. Damals haben die nicht viel skaliert.

ARM1 konnte 26bit adressieren und hatte 1985 32Datenleitungen zum Speicher.
Der Intel 30386 hatte anno 1985 32bit Adressierung bei 32Datenleitungen. Die SX Version vom 80386 war beschnitten (16it Adressen, 24Datenleitungen).
Die ARMs waren damit von Anfang an ein Kind ihrer Zeit und bei Grundlegenden Designentscheidungen schlicht davon bestimmt was wirtschaftlich auf Silizium zu brennen war. Erst ARM6 im Jahre 1990 sah dann wie eine volle 32bit Architektur aus, mit allen ARM32 Registern die wir heute kennen.

 

[DevPandi]

Nein, ARM war am Anfang (Mitte der 80er) eindeutig gross (32-bit-Speicherinterface, als der Mainstream noch 8 oder 16 bit hatte). Dann sind sie dort stehengeblieben und wurden (relativ zu den anderen) klein. Damals haben die nicht viel skaliert.

... ich würde an der Stelle mal schreiben: Bitte genau lesen, was ich geschrieben habe, statt versuchen mich zu verbessern, gerade wenn es absolut unnötig ist.

Ich habe die Anfänge - die 80er - bereits erwähnt und dass die damaligen CPUs mit ihren x86-Pendants quasi den Boden gewischt haben und das haben sie auch noch in den 90er getan, weil sich damals relativ einfach in ARM eine 2-fache und 3-fache Skalarität unterbringen konnte.

Der entscheiden Punkt ist aber, dass ARM mit seiner ISA damals bereits aus automaren OPS bestand und quasi kein Decodieraufwand vorhanden war, wodurch ein Decoder in den ersten ARM-Desigsn fehlte.

In diesem Zusamenhang konnte man bereits in den 80er mit ARM sehr sparsame CPU-Designs umsetzen, die aber teilweise relativ viele Transistoren brauchten im Vergleich zu x86 - die Registeranzahl.

Und jetzt kommt der wichtige Punkt: Ich spreche die ganze Zeit von der ISA, die durch ihren Aufbau sich gut von kleinen CPUs bis große CPUs skaliere lässt, nicht dass man damals die Möglichkeiten genutzt hat, das ist ein Unterschied.

Sie haben offenbar erkannt, dass sie nicht mit dem Entwurfsaufwand der Konkurrenz mithalten konnten und haben sich ein anderes Geschaeftsmodell gesucht: Embedded-CPUs fuer Low Power als Design-Bloecke fuer kundenspezifische SoCs, waehrend die Konkurrenz noch versucht hat, Chips zu verkaufen; so kamen sie in die Mobiltelefone und spaeter in die ersten Smartphones.

Das hat nichts damit zutun, dass man erkannt hat, dass man nicht mit dem Entwurfsaufwand der Konkurrent mithalten kann, ich habe sogar relativ genau erläutert, warum ARM in die Ecke abgerutscht ist, in die sie abgerutscht ist.

Noch einmal: Es hat mit der Kompatiblität zutun. In den 90er hat sich x86 quasi den Clientmarkt quasi weitgehend gesichert, weil Software aus den 80er ebenso noch lief wie aktuelle Software. Da Leute damals wie heute sehr viel Wert auf ihre "Software" legen, egal wie alt diese ist, hat man oder musste man zu x86-PCs greifen.

Die Großestärke von x86 war nie wirklich die Geschwindigkeit, sondern dass IBM und später Microsoft und damit auch Intel auf die Kompatiblität geachtet haben. Und ich wiederhole mich erneut: Intel ist zweimal über genau diese Kompatibilität gestolpert: Pentium Pro - führte 16-Bit-Code nicht oder nur sehr langsam aus, floppte dadurch. Und der Itanium - IA64 - war zwar zu IA32 kompatibel - erst mal per Firmware-Emulation - und dadurch auch zulangsam und konnte so im Serverbereich keinen Fuß fassen.

Wie wichtig Kompatiblität ist hat AMD dann mit AMD64/x86_64 bewiesen, dass dann auch im Servermarkt die Dominanz von x86 eingeläutet hat. In dem haben sich damals nämlich PowerPC, Sparc und ein paar andere getummelt, weil man von "Problemen" von IA32 profitiere konnte. Als der Opertron jedoch 32-Bit x86-Code mit den Vorteilen von 64-Bit verband und Intel auch da auf Sprang und plötzlich eine riese Softwarebasis vorhanden war, war das quasi der Sargnagel für PowerPC, Sparc und Co.

Eigentlich ist das durchaus Relevant - zumindest für die Zeitskala. Ich bin mir ziemlich sicher, dass die Frage, welche ISA sich am Ende durchsetzt nicht von den vorzügen der ISA selber, sondern von den verfügbaren Implementierungen abhängt und das ist Apple eben derzeit Vorreiter.

Ich würde sogar noch ein Stück weiter gehen, stimme dir aber weitgehend zu: Die ISA wird hier am Ende nicht entscheidend sein, wer als Sieger vom Platz über Kurz oder Lang gehen wird, sondern es wird davon abhängen, welche Implementierungen wir von Qualcomm, Samsung und Co in Zukunft sehen werden, ebenso von AMD und Intel und noch wichtiger für die Frage wird sein, wie schnell MS und Co auch entsprechen die Tools so fertig bekommen, dass man gut Crosscompilate anfertigt und dass man die Lücken, bei denen man noch plattformabhängig programmiere muss, geschlossen werden.

Die ISA ist heute wie damals 2. Ranging, es kommt auf die Softwareunterstützun an.

 

[Piktogramm]

@DevPandi
Decode braucht es immer! Da kommt man nicht drumherum und wenn das ganze als Pipeline vorsieht, geht bei Decode selbst den simpelsten Designs immer ein Takt drauf. Da nehmen sich X86 bzw. Cisc und ARM bzw. Risc erstmal nichts. Vor allem da bis zum ersten Intel Pentium die CISC Befehle wirklich noch nativ implementiert wurden, erst die Pentiums selbst setzten auf eine CISC zu RISC Übersetzung. Letzteres erfordert dann Decode Schritte, die 1 oder mehr Takt benötigen[1].
Vor dem Pentium gab es RISC-Designs, die superskalar waren, jedoch waren die nicht von ARM! ARMs erste superskalare Designs waren die Cortex A8 mit ARMv7 im Jahre 2005[2].

Also bitte ARM nicht überhöhen, historisch haben die lange Zeit nur kleine, energiesparende RISC-CPUs geliefert. Das ARM auf einmal mit dabei ist, wenn es um die Leistungskrone geht ist recht neu.

Die Performancemonster aus den 1990ern sind Power, Sparc und was es nicht noch gab.

[1] Im besten Fall braucht ein CISC Decoder aber weniger Takte fürs Decode als die µOps an Takten für die Ausführung auf den Ausführungsports der restlichen Pipeline
[2]https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a8
Und aufpassen ARM7 ist eine spezielle Implementierung einer µArchitektur, ARMv7 ist die Generation der ISA und die Zählweisen sind komplett unabhängig.


Edit:
Die erste ARM CPU, der ARM1 hatte auch schon ein Befehlsdecoder:
https://en.wikichip.org/wiki/acorn/microarchitectures/arm1

Es geht halt wirklich nicht ohne.

 

[mae]

ARM1 konnte 26bit adressieren und hatte 1985 32Datenleitungen zum Speicher.
Der Intel 30386 hatte anno 1985 32bit Adressierung bei 32Datenleitungen.

Der war aber gross. ARM war ja fuer Homecomputer gedacht, und wenn man sich da die Konkurrenz anschaut, war 1985 der C64 (8-bit) mainstream, und der Amiga 1000 kam gerade erst heraus, und der Atari ST erst 1986 (beide mit dem 68000, mit 16-bit Datenbus und 24-bit Adressbus).

Dass der ARM nur 26 Adressleitungen hatte, war eigentlich egal, weil man sich damals gerade einmal RAM fuer ca. 20 Adressbits leisten konnte (mein 486er von 1993 war mit 16MB (also 24 Adressleitungen) schon gut ausgestattet).

 

[Opa Hermie]

Wenn Apple die M1 Chips verkaufen würde, dann würde sich Windows on ARM vermutlich wesentlich schneller durchsetzen (bzw. überhaupt durchsetzen) als das momentan der Fall ist. Einfach, weil man damit wesentlich leistungsfähigere Windows-Tablets bauen könnte, als das derzeit mit x86 CPUs oder den ARM SoCs von Qualcomm möglich ist.

Möglicherweise, aber das funktioniert nur so gut, wie die Softwarehersteller und -Entwickler mitziehen.

Hier wird ja gerne der Apple-Prozessor als Inbegriff für ARM genannt, das trifft aber nicht zu bzw. lässt sich nicht auf andere übertragen. Ich denke, das funktioniert bei Apple so gut, weil:

• Man sich mit sehr viel Geld in die Fertigung eingekauft hat, um ein Spitzenprodukt bauen zu lassen
• "Abwärtskompatibilität" bei Apple ein Fremdwort ist bzw. eine eher kurze Halbwertszeit hat
• Softwareentwickler quasi schon immer eine Extrawurst für Apple gemacht haben
• Vorhandene Entwicklungswerkzeuge, Bestandssoftware und Erfahrung aus dem iOS-Bereich, also kein totales Neuland

Die meisten Voraussetzungen fehlen einfach bei Windows und x86; ich halte es garnicht für abwegig, dass erstklassige Windows-Geräte auf ARM-Basis möglich sind, aber sobald Softwareschmieden nichts dafür entwickeln wollen, sind die Geräte für viele Kunden nutzlos.

 

[Piktogramm]

@mae
Der C64 kam mitte 1982 mit einer auf kosteneffizienten 6510 CPU für $595, die ARM1 gab es als quasi DevKit für Normalsterbliche gar nicht und die Acorn Archimedes mit ARM2 kam erst 1987 für 800Pfund.

Da ist ein deutlicher Preisunterschied und auch 3 bzw. 5Jahre zwischen 6510 und ARM1/2
Schaut man sich an, was 1985 bis 1990 sonst noch auf den Markt geworfen wurde, dann ist das ARM1/2 halbwegs typisch für damalige Desktopsysteme, die sich an Privatanwender, kleine Unternehmen und Bildungseinrichtungen orientierten.

Elegant sind die ersten ARM Designs allemal.

Edit:
Kleine Ergänzung, es findet sich zwar weit weniger zu MIPS und deren ersten R2000 (Jahr 1985) im Netz. Was man jedoch findet, da sehen sich ARM3(1987) und MIPS R2000 ebenfalls recht ähnlich. Dem ARM2 fehlen halt noch Caches.
Ich bleibe dabei, ARM1 ist ein Kind seiner Zeit.

 

[Raucherdackel!]

; ich halte es garnicht für abwegig, dass erstklassige Windows-Geräte auf ARM-Basis möglich sind, aber sobald Softwareschmieden nichts dafür entwickeln wollen, sind die Geräte für viele Kunden nutzlos.

Ja, so geschehen vor 10 Jahren mit Windows RT. Allerdings gibt es seit zwei jahren Das Surface Pro X, inklusive x86- und AMD64-Emulation. Und das Teil ist so gesehen schon erstklassig.

 

[LencoX2]

Kennst du da echt so viele? Im Bekanntenkreis und Büro hab ich noch nie von Problemen gehört, aber das ist natürlich nur ne sehr kleine und nicht repräsentative Samplesize.

Klingt so als wenn du mein Argument anders rum interpretiert hast.
Gemeint war, sie sträuben sich, obwohl binaer kompatibel und x86-64 und keine wirklichen Probleme existieren.
Wie wird sich erst viel mehr gesträubt werden, wenn binaer inkompatibel wie Arm?
Darum wird es schwer im PC Segment

 

[Miuwa]

Klingt so als wenn du mein Argument anders rum interpretiert hast.
Gemeint war, sie sträuben sich, obwohl binaer kompatibel und x86-64 und keine wirklichen Probleme existieren.

Nein, das habe ich schon verstanden. Ich kenne schlicht niemanden, der sich gegen den Wechsel auf AMD gesträubt hat.

 

[mae]

Ich habe die Anfänge - die 80er - bereits erwähnt und dass die damaligen CPUs mit ihren x86-Pendants quasi den Boden gewischt haben und das haben sie auch noch in den 90er getan, weil sich damals relativ einfach in ARM eine 2-fache und 3-fache Skalarität unterbringen konnte.

80er ja, 90er nein. Wie @Piktogramm schreibt, haben die vor 2005 keine superskalaren Prozessoren gemacht. Und beim GHz-Rennen haben sie auch nicht mitgespielt. Und das war gut so.

Der entscheiden Punkt ist aber, dass ARM mit seiner ISA damals bereits aus automaren OPS bestand und quasi kein Decodieraufwand vorhanden war, wodurch ein Decoder in den ersten ARM-Desigsn fehlte.

Einen Decoder hat jede CPU, bei RISCs wie ARM ist er nur einfacher. Dafuer haben sie noch einen fuer Thumb und spaeter einen fuer Aarch64 dazugegeben.

Das hat nichts damit zutun, dass man erkannt hat, dass man nicht mit dem Entwurfsaufwand der Konkurrent mithalten kann

Vielleicht war's ja auch nur ein Glueckstreffer. Andere sind in die Falle getappt und haben sich uebernommen. Die entsprechenden Architekturen wurden dann aufgelassen (Alpha, HP-PA, AMD 29K, Motorola 88k), rutschten in den Embedded-Bereich ab (MIPS), oder brauchten den finanziellen Hintergrund von IBM (Power), um zu ueberleben.

In den 90er hat sich x86 quasi den Clientmarkt quasi weitgehend gesichert, weil Software aus den 80er ebenso noch lief wie aktuelle Software. Da Leute damals wie heute sehr viel Wert auf ihre "Software" legen, egal wie alt diese ist, hat man oder musste man zu x86-PCs greifen.

Die Großestärke von x86 war nie wirklich die Geschwindigkeit, sondern dass IBM und später Microsoft und damit auch Intel auf die Kompatiblität geachtet haben.

Aber die Geschwindigkeit war um 2000 herum auch eine Staerke. Die fuehrte dazu, dass Apple auch ohne Intel-Legacy-Software dann 2006 auf Intel wechselte, weil Motorola zwar niedrigen Verbrauch, aber auch niedrige Leistung beim PPC 7447A etc. lieferte, und IBM beim PowerPC 970 zwar einigermassen hohe Leistung, aber auch hohen Verbrauch.

 

[WinnieW2]

Um sie an diejenigen zu verkaufen, die sie haben wollen, auch international.

Ich schätze mal dass das Risiko zu hoch ist im Vergleich zu den zu tätigenden Investitionen. Ein Unternehmen müsste Stand heute so viel Entwicklungsarbeit in ein konkurrenzfähiges Design stecken dass ein Geldgeber Milliarden vorstrecken müsste bei ungewissem Ausgang.
Die x86-CPUs aus China müssten ja auch von den Kunden akzeptiert werden, zudem hat China keine Chipfabriken welche Chips in einem konkurrenzfähigen Verfahren (im Vergleich zu Intel oder TSMC) herstellen können.
16 nm Strukturgröße ist (in China) die Spitze der Chipfertigung, soweit mir bekannt.