derkleinedieb schrieb:
Ich habe keine große Ahnung von Programmierung und den Unterschieden der beiden Lager ARM versus x86 und was es da noch gibt.
Die primären Unterschiede zwischen x86 und ARM ist heute in der Anzahl der Register zu suchen und ggf. in den Erweiterungen, das meiste davon wird aber in der Regel von eingesetzten Bibliotheken sowie dem Compiler abgefangen und ist daher in der Regel während des Programmierens für die meisten Entwickler irrelevant.
Anders sieht es aus, wenn man wirklich eine Bibliothek optimieren will oder Code und deswegen per Assembler direkt in die Extensions geht.
derkleinedieb schrieb:
Was ich jedoch sehe, ist der feuchte Traum dem Modell von ARM nachzueifern. Liefere zeitlich begrenzte Lauffaehigkeit von Software auf aktuellen Prozessortypen und die Konsumenten sind gezwungen jedesmal die Hardware zu erneuern wenn eine neue Softwaregeneration herauskommt. Stichwort Konsumzwang.
Die Probleme mit der begrenzten Lauffähigkeit sind in der Regel keine Probleme der Architektur, sondern liegen in wirtschaftlichen Überlegungen.
derkleinedieb schrieb:
DIe derzeitige Entwicklung im Mobilmarkt ist schon sehr grenzwertig, 2-3 Software Updates und ein an fuer sich ohne Probleme lauffaehiges System wird nicht mehr up-to-date gehalten. Wo bleiben da die Nachhaltigkeitsansaetze?
Kommt auf den den Hersteller an. Apple bietet aktuell bis zum Apple iPhone 6S die Updates für neue Versionen an - also nun 6 Jahre. Die Probleme bei Android wiederum sind bei Google, den Herstellern als auch den SoC-Herstellern zu suchen.
WinnieW2 schrieb:
Soweit stimmt das, nur wissen wir gar nicht ob Apple den M1 SoC, oder auch nur die dessen Architektur, überhaupt anderen Unternehmen zum Kauf anbieten würde.
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.
WinnieW2 schrieb:
Die Icestorm und Firestorm Kerne nutzen zwar den ARM Befehlssatz sind aber Eigenentwicklungen von Apple, andere Unternehmen müssten diese bei Apple lizenzieren.
Genauso wie Qualcomm bald wieder eigene Kerne anbieten wird und eine Zeitlang tat und ebenso wie Nuvia es vorhatte.
Die meisten Firmen verlassen sich auf die Kerne von ARM, was auch kein Problem ist. Es geht aber eben nicht um die CPU-Kerne von ARM sondern um die ISA.
WinnieW2 schrieb:
Ausserdem erzeugt derzeit nur der Compiler von Apple den zum M1 passenden optimalen Code.
Nicht ganz richtig, man kann auch über andere Compiler gehen, ich compiliere zur Zeit viele Projekte unter Windows für iOS und MacOS.
Das Geheimnis hinter ARM bei Apple ist nicht der Compiler. Ich habe es ein paar mal bereits ausgeführt, was das Geheimnis bei Apple ist und warum zum Beispiel der Wechsel jetzt relativ schnell - schneller als bei PowerPC zu x86 - ging und wo die Probleme zum Beispiel bei Microsoft liegen und an welcher Microsoft jetzt arbeitet.
Das Geheimnis hinter MacOS, iOS und iPadOS ist nicht der Compiler, das Geheimnis ist die Softwarearchitektur des Kernel (Darwin) den generellen APIs die für alle 3 Betriebssysteme gelten - Metal z.B. sowie weite Teile von Cocoa - sowie eben die APIs, die zwar das gleiche Machen aber an die jeweiligen Geräte angepasst sind - z.B. Cocoa UI.
Apple hat seit Ende der 90er ihre Hausaufgaben gemacht, was ISA Umzüge angeht und hat weitgehdn "Assembler" und plattformabhänigen Code aus den Programmen verbannt und für fast jeden Fall eine API, die genau das abdeckt.
Natürlioch, du hast recht, dass hier auch der Compiler eine Rolle spielt, aber der Compiler ist hier nicht der Schlüssel, sondern ein Teil der ganzen Kette. Apple hat sehr viel Erfahrung und Know-How in die Software-Architektur gesteckt und damit verbunden in die APIs und zwar weit mehr als MS es bis heute getan hat und auch weit mehr als die Linux-Welt bis heute. Und genau das führte auch dazu, dass Apple jetzt so einen Sprung machen konnte.
SoDaTierchen schrieb:
Wie kann man denn auf dieser Faktenlage behaupten, ARM wäre besser? Das ist blind. ARM und x86 sind Architekturen mit verschiedenen Fähigkeiten und Altlasten.
Deine Beiträge sind - entschuldige die Ausdrucksweise - in weiten Teilen einfach nur falsch und das fängt, oder besser gipfelt in genau dieser Aussage!
Du wirfst anderen Blindheit vor, behauptest hier aber, dass die Architekturen verschiendene Fähigkeiten und Altlasten haben. Das ist in weiten Teilen einfach nur falsch oder stark vereinfacht.
ARMv8 und nun auch ARMv9 - und erst recht dieses - steht dem aktuellen Featureset von x86 in keinerweise nach. Beide Architekturen beherrschen die normalen Wort-Befehle, die grundlegende INT-Arithmetik, dazu Floating Point über Vektor-Extensions und nun auch Vektorbreiten mit 256 Bit bis 512 Bit - bei SVE2 bis zu 2048 Bit-Breite.
Im Bereich der Register hat ARM Vorteile - INT und FP jeweils 31/32 gegen 16/16(16/32), ansonsten sind beide Architekturen gleichwertig.
SoDaTierchen schrieb:
Bisher konnte kein Design auf ARM-Basis jemals zeigen, dass es generell ebenbürtig mit x86 ist.
Doch, der M1 hat mit seinen Firestorm-Kernen genau eben das gezeigt, dass es generell mit einem ausgewachsenen x86-Design ebenbürtig ist. Der Strohhalm, dass hier Apple ja ein entsprechendes Ökosystem hat ist zwar durchaus verständlich, aber eben nichts als ein Strohhalm.
Das primäre Problem, dass die meisten mit dem M1 haben und ebenso ARM allgemein ist, dass sie immer denken, dass ARM ja als Lowepower-Architektur konzipiert und gedacht wurde und das ist einfach nur falsch. Gerade die frühen ARM-Designs als auch die ersten Geräte, die ARM-CPUs einsetzten, waren alles andere als Lowpower-Architekturen und Maschinen, sondern konnte es zu ihrer Zeit mit den schnellsten x86-CPUs aufnehmen und haben bei vergleichbaren Takt mit diesen CPUs in der Regel den Boden gewischt! Du kannst dir ja mal Wikipedia zu Gemüte führen was
Acorn Archimedes angeht und was da steht.
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ß.
ARM scheiterte in den 90er - genau so wie IA64 aka Itanium - als auch andere Architekturen an einer ganz banalen Sachen und die nennt sich Kompatiblität und über die ist Intel selbst gestolpert und das quasi zwei mal: Pentium Pro und Itanium. x86 hat sich durchgesetzt und ist geblieben, weil man quasi 20 Jahre - nun bald 40 Jahre - die gleiche Software auf der CPU laufen lassen kann und das ist viel wert gewesen.
Die Software-Welt war damals eine andere. Es gab Anfang der 80er zwar durchaus schon Hochsprachen, aber vieles wurde damals - auch wege Speicherplatz als auch Rechenleistung - oft noch optimiert und speziell auf eine CPU zu geschnitten. Dazu kam auch, dass Geräte damals extrem teuer waren, wir sprechen hier nicht mehr nur von Monatsgehältern für einen Rechner, sondern von teilweise mehren Monatsgehältern, wenn man x86, ARM, 68k, PowerPC und Co als Rechner wollte. Ein Acorn Archimedes kostete zwischen 3000 - 5000 DM - je nach dem was man wollte, da sind heute 3000 - 5000 € und das ist heute auch noch eine Stange Geld, damals quasi ein kleines Vermögen!
Aber auch das ist eigentlich alles Nebensache, es gibt für die Betrachtung ARM gegen x86 gegen RISC-V einige Aussage die man treffen kann, die relevanteste ist dabei aber: Erst jetzt durch Apple und dem erzwungene Wechsel zu ARM, hat der x86-Bunker ein paar Risse bekommen und man merkt nun über alle Bereiche hinweig, dass Entwickler und Firmen langam anfangen Geld in die Hand zunehmen um ihre Bibliotheken und ihre Software auch ARM fit zu machen. Auf Softwareseite hat ARM dabei immer noch sehr viel Boden gutzumachen und sollte das aktuelle Momentum verfliegen und nicht genutzt werden, dann hat der x86-Bunker ein paar Risse bekommen, aber das war es schon und x86 wird uns noch für lange Zeit begleiten.
Sollte aber MS ihre Bemühungen nun bei der neuen "Win32-API" wirklich ernst meinen, sollte es bei .NET auch so weiter gehen, sollten Firmen über ihre Anpassungen für ARM bei Apple hinaus am Ball bleiben, dann könnte es passieren, dass x86 einen schweren Stand bekommt und in dem Fall nicht, weil man mit x86 keine schnellen CPUs designen kann, sondern weil das Design schneller CPUs mit x86 "komplexer" ist als mit ARM.
Schnelle CPUs kann man mit x86 - beweist aktuell Alderlake mit nun 5-facher Skalarität im INT-Bereich und 2 facher (bei bis zu 512 Bit) bei den Vektor-Einheiten. (Somit 7-fach, die LD, AGU und ST lass ich raus!). Gleichzeitig zeigt Alderlake aber auch, welcher Aufwand betrieben werden muss um diese 7-fache Skalarität wirklich zu befeuern UND genau hier liegt der Vorteil für ARM und noch mehr bei RISC-V.
Aber und das sollte man beachten: Der Bunker hat erst mal nur einen Knacks in der äußerten Hülle bekommen, Intel wird alles dafür tun, dass sie diesen Knacks mit Zement aufüllen und hier ist Beharlichkeit von ARM selbst aber auch Qualcom, Windows und den freien Entwickler bei Linux und die Firmen hinter Linux wichtig!
