Apple Silicon - Exot oder Gamechanger?

[Codehunter]

Hallo!

Wie schätzt ihr die Entwicklung bei Apple weg von x86 hin zu ARM ein? Inzwischen gibt es ja bereits einige Hardware zu kaufen und wurde ausgiebig gebenchmarked. Die Praxis scheint die Erwartungen zu erfüllen und teils zu übertreffen.

Die etwas älteren unter uns haben die Zeit in den 1980ern und 1990ern noch miterlebt, als es im Desktop-Segment (zu dem ich im weitesten Sinne auch die Homecomputer zähle) noch bunte Vielfalt an CPU-Designs herrschte. Da gab es M68k, Sparc, PPC, RISC, MIPS und x86 lustig nebeneinander.

Irgendwann kam es dann zu der inzwischen legendären (ich würde auch das Wort "unheiligen" gebrauchen) Allianz zwischen IBM und Microsoft. Von da an marschierte alles in Richtung x86. Apple hielt noch eine Weile dagegen und blieb bei PPC. Letztlich mussten sie sich eher übel als wohl der Tatsache beugen, dass keine leistungsfähigen PPC-Designs mehr entwickelt wurden. Man wechselte auch zu x86. Wohl nie so richtig glücklich damit, weil dadurch "Hackintoshes" überhaupt erst möglich wurden.

Nun also Apple Silicon a.k.a. M1, ein ARM-Derivat. Klar, Apple möchte sein Ökosystem noch weiter abschotten, was damit problemlos gelingen dürfte. Das hat ja irgendwo auch eine politische Komponente. Denn blickt man mal über den amerikanischen Tellerrand hinaus, tut sich da einiges. China werkelt mit Zhaoxin und Kunpeng an eigenen x86- bzw. ARM-Designs. Russland versucht sich mit der Elbrus-CPU (meines Wissens erstmals wieder seit dem Ende von Transmeta) an einem VLIW-Design. Die EU kann sich noch nicht so recht entscheiden (wie so oft) und lässt sowohl an ARM als auch RISC-V forschen. Allein gemein ist: Man will weg von der US-Dominanz.

Was dabei auffällt: x86 scheint außer in den USA meist nur noch als Übergangstechnologie gesehen zu werden. Teuer, ineffizient und zu komplex.

Mich würde jedoch eure Meinung interessieren, ob nun generell wieder eine Ära der CPU-Vielfalt im Desktop-Bereich anbrechen könnte.

Grüße
Cody

[Der schöne Günther]

Microsoft hatte schon früher mit Windows RT und eigenen ARM-Geräten erste Anläufe versucht, mittlerweile läuft auch das ganz normale Windows "on ARM" und die Emulationsschicht scheint mittlerweile wirklich sehr brauchbar zu sein (wenn auch nicht so performant wie die von Apple).

Ich bin in einem Microsoft-Entwicklerprogramm, und auch dort wird gerne Hilfe angeboten wenn man irgendwo ein Problem hat, seine Anwendung nun für ARM64 zu kompilieren. Im Enterprise-Markt ist mMn zwar (noch) null Bedarf, aber auf mittlere Sicht kann ich mir wirklich sehr gut vorstellen dass ARM-Laptops/2-in-1s in ein paar Jahren keine Exoten mehr sein werden.

Bei Apple habe ich mir das nicht richtig angeschaut, aber ich meine die emulieren genauso wie "Windows on ARM". Heißt: Nativ für ARM kompiliert ist toll, aber ohne geht auch. Grade bei Apple soll die Emulationsgeschwindigkeit überraschend gut sein. Habe ich so gehört, Quelle jetzt nicht zur Hand.

[Codehunter]

Zitat:

Zitat von Der schöne Günther (Beitrag 1483933)

Bei Apple habe ich mir das nicht richtig angeschaut, aber ich meine die emulieren genauso wie "Windows on ARM". Heißt: Nativ für ARM kompiliert ist toll, aber ohne geht auch. Grade bei Apple soll die Emulationsgeschwindigkeit überraschend gut sein. Habe ich so gehört, Quelle jetzt nicht zur Hand.

Bei Apple nennt es sich "Rosetta 2". Im Prinzip eine Emulationsschicht wie bei Windows auch. Interessant finde ich hier die Ansage, man wolle Rosetta 2 nur zwei Jahre lang supporten. Wer Apple kennt, der weiß, die ziehen das knallhart durch. Wer nach zwei Jahren keine native ARM-Software im Appstore hat, fliegt raus. Das erzeugt schon einen gehörigen Handlungsdruck. Daher erwarte ich in den kommenden beiden Jahren weniger Feature-Updates bei Mac-Software, weil die Entwicklerkapazitäten auf den Portierungen liegen. Premium-Anbieter wie Adobe bekamen natürlich lang vorher schon Entwickler-Hardware, sodass M1 zusammen mit einem angepassten Photoshop veröffentlicht werden konnte.

Man stelle sich Ähnliches doch nur mal bei Microsoft vor ^^ "Entweder ihr portiert euer Zeugs bis 2023 auf ARM oder ihr riskiert dass es danach nicht mehr läuft" Wird natürlich nicht passieren, weil bei MS die Philosophie eine andere ist, aber nur mal angenommen.

Uns könnten ja spannende Zeiten bevor stehen. Neue CPU-Architekturen, vielleicht sogar mehr Vielfalt bei den Desktop-Betriebssystemen.

[jfheins]

Es wird sich langsam aber sicher wieter verbreiten.

Ich tippe, zunächst wird es in der Cloud zum Einsatz kommen. Azure Functions, aws lambda wären da die ersten Schritte. Da braucht man ja u.U. nur den Code eintippen und er wird dann ausgeführt. Nachdem selbst der Compiler bei Microsoft läuft, kann man da auch einfach auf eine andere Arch kompilieren.
Als nächstes sowas wie webserver, was ja oft wenig direkte Abhängigkeiten zur Hardware hat und einfach nur CPU braucht + eine Verbindung zur DB. Wenn der Cloudanbieter da einen business case anbietet, wo man eine Anwendung nach ARM kompilieren muss und sie dann genauso so gut läuft und weniger kostet, wird das genommen werden.

Dann auch bzw. parallel Laptops, wegen der Energieeffizienz. Desktop wird noch dauern.

[Rollo62]

M1 zeigt doch nur was heute Alles möglich ist.
Ich sehe das als Weckruf für Intel (und auch AMD, die aber gar nicht so verschlafen sind).

Alternativen gibt es auch genug (Nvidia, OpenRISC, ...), aber ich hoffe doch das wir bei Intel/ARM bleiben können.

Die Verkäufe von ARM an Softbank und dann an Nvidia machen das aber nicht leichter.
Wenn jetzt das Heuschrecken-Geschacher um ARM losgeht sehe ich schwarz, auch wie Apple mit Nvidia klarkommt.

Es ist aber anzunehmen dass Nvidia weiss was ARM Wert ist, und es für sich selbst nutzt,
und hoffentlich noch allen Konkurrenten offen hält (Samsung, Apple, und Myriaden Andere, ...).
Besser fände ich eigentlich ein eigenständige ARM, wie früher :stupid:

Eine Multiprozessor-Welt würde uns doch wieder ziemlich zurückwerfen, auch wenn es im Moment ganz danach ausschaut.

[Codehunter]

NVidia+ARM sehe ich auch kritisch. Aber letztlich ist das der normale Lauf der Dinge, wenn man Schlüsseltechnologien dem freien Markt überlässt. Grad NVidia verdient sich grad mit dem Mining-Boom einen Buckel auf die Nase. Oder glaubt im Ernst jemand, man wäre nicht in der Lage, jederzeit ausreichend Grafikchips produzieren zu können? Im Moment besteht nur gar keine Notwendigkeit, immerhin werden Grakas dreifach überteuert gehandelt. Maximaler Gewinn bei minimalem Einsatz eben.

Offene Architekturen sind da eine denkbare Alternative. Aber dafür müssten auch die passenden Rahmenbedingungen geschaffen werden. Für etwas, das es noch gar nicht gibt, ist die Lobby bekanntlich nicht groß.

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1484045)

Offene Architekturen sind da eine denkbare Alternative. Aber dafür müssten auch die passenden Rahmenbedingungen geschaffen werden.

Ich denke offene Architekturen brauchen immer Jahrzehnte Anlauf, bevor sie dann exponentiell die proprietäten überrennen können.
Bestes Beispiel: siehe Linux.

ARM wäre aber nicht da wo sie jetzt sind wenn es anfangs OpenSource gewesen wäre (meine Meinung).
Ohne vernünftig planbare Roadmaps wären große Player vielleicht nicht ernsthaft aufgesprungen.

Ausserdem fand ich im Anfang Mips viel performanter und vielversprechender als ARM, hat sich aber auch nicht durchgesetzt.
Nach dem Motto: Hinterher ist man immer schlauer :stupid:

Interessant fand ich auch immer die Beziehung zu KEIL, einem meiner Meinung nach sehr schlechten Tool mit hohem Preis.
Das hatte mich Jahre von ARM abgehalten.

[jfheins]

Zitat:

Zitat von Rollo62 (Beitrag 1484037)

Eine Multiprozessor-Welt würde uns doch wieder ziemlich zurückwerfen, auch wenn es im Moment ganz danach ausschaut.

Wieso eigentlich? Viel Software wird ja ohnehin zunächst in platformunabhängigen Bytecode compiliert, und dann auf dem Zielsystem fertig compiliert. Da sind doch dann verschiedene Architekturen kein großen Problem...

Dieses fertig-kompilieren hat dann auch den Vorteil, dass man moderne CPUs optimal ausnutzen kann, ohne ältere auszuschließen. Bei C, C++ und Delphi müsste man ja 2 Codepfade machen (bspw. einen für AVX2 und einen nur mit SSE2) und dann wählen. So eine Arbeit kann man dem Entwickler einer Software ja durchaus abnehmen.

Zugegeben, Delphi hätte da noch einiges zu tun :wink:

[Codehunter]

Zitat:

Zitat von Rollo62 (Beitrag 1484046)

Ich denke offene Architekturen brauchen immer Jahrzehnte Anlauf, bevor sie dann exponentiell die proprietäten überrennen können.
Bestes Beispiel: siehe Linux.

Das erste Mal dass ich mit Linux zu tun hatte war Mitte der 1990er Jahre. Damals gabs noch viele Hardware, die noch kein PnP unterstützte. Soundkarte und Netzwerkkarte zankten sich gern um den IRQ5 und mussten per Jumper "belehrt" werden. Das führte jedesmal dazu, dass man umständlich den Linux-Kernel parametrieren und neu kompilieren musste. Das war damals eine Pest und ich habs gehasst. Ein Pinguin-Fan bin ich wahrlich nie gewesen, aber inzwischen nutze ich privat zu 95% nur noch Linux (Mint). Und im Kollegenkreis bin ich nicht der einzige. Wobei jeder für sich allein dazu kam, "angestiftet" haben wir uns nicht. Das ist inzwischen einfach das rundere System geworden. Nur seinen schlechten Ruf wirds halt so "schnell" nicht wieder los.

Zitat:

Zitat von Rollo62 (Beitrag 1484046)

ARM wäre aber nicht da wo sie jetzt sind wenn es anfangs OpenSource gewesen wäre (meine Meinung).
Ohne vernünftig planbare Roadmaps wären große Player vielleicht nicht ernsthaft aufgesprungen.

Die meisten Lehren hat man ja inzwischen dank Open-Source-Software bereits gezogen. Das lässt sich genauso auf Open-Hardware übertragen (siehe z.B. Arduino & Co). Dennoch, ganz klar: Die Diversität von Open-Irgendwas ist Fluch und Segen zugleich.

[Rollo62]

Zitat:

Zitat von jfheins (Beitrag 1484048)

Wieso eigentlich?

Weil ich glaube das jeder Hersteller bemüht ist seine speziellen Features reinzubauen,
die dann immer nur schwerlich von den Compilern unterstützt werden.

Sinnvoller fand ich ARM, die das zentral gesteuert haben, aber sicherlich auch immer Druck
von Apple, Nvidia, Qualcomm, Samsung ... in die eine oder andere Richtung bekommen hatten.
So konnten die alle guten Einwürfe von allen Kunden einbauen, und ein insgesamt besseres Produkt bauen.

Das der M1 jetzt so locker Intel schlägt ist schon eine Sensation für mich,
ich hatte ARM immer noch deutlich hinter Intel gesehen, aber da lag ich wohl falsch.
Die Dinosaurier sterben halt immer plötzlich aus, und sind dann von dem Meteoriteneinschlag überrascht :-D

Ich glaube das liegt an der Evolution der Chips und Moores Law generell.
RISC war schon immer die richtige Entscheidung, davon war ich schon lange überzeugt.
Nur gab es damals das Silizium eben noch nicht her,
wodurch CISC einen Vorteil hatte.

Die haben damals aber wohl nicht erkannt das auf Dauer Moores Law die Chips zu immer kleineren aber flexibleren Kernen und Strukturen drängen würde, was mit CISC immer schwerer umzusetzen ist.
Deshalb bin ich ziemlich überzeugt das CISC aussterben wird, oder sich zumindest mehr dem RISC nähern muss.

[Codehunter]

Zitat:

Zitat von Rollo62 (Beitrag 1484064)

Weil ich glaube das jeder Hersteller bemüht ist seine speziellen Features reinzubauen, die dann immer nur schwerlich von den Compilern unterstützt werden.

Das war doch bisher bei x86-64 auch nicht anders. Intel und AMD haben je nach CPU-Generation auch verschiedene Featuresets eingebaut, von den CPU-Bugs gar nicht zu reden. Das ist dann am Ende eine Frage der Compiler, dass diese Features dann bedingt genutzt werden wenn sie da sind. Ich glaube nämlich nicht, dass z.B. dcc32 nur den kleinsten gemeinsamen Nenner anspricht.

Zitat:

Zitat von Rollo62 (Beitrag 1484064)

Das der M1 jetzt so locker Intel schlägt ist schon eine Sensation für mich,ich hatte ARM immer noch deutlich hinter Intel gesehen, aber da lag ich wohl falsch.
Die Dinosaurier sterben halt immer plötzlich aus, und sind dann von dem Meteoriteneinschlag überrascht :-D

Ich nicht ganz so sehr. Bin schon eine Weile mit den ganz kleinen ARMs befasst, auf den Himbeeren. Dort haben sich die Fortschritte auch schon angekündigt. Zwischen RPi3B und RPi4B liegen auch schon Welten, wenn auch in einer anderen Liga als M1 und um den Preis von mehr Abwärme. Im Serversegment gibt es schon länger recht leistungsfähige ARM-Blades. Soweit ich weiß, laufen bei Facebook ganze Cluster damit. Man musste doch eigentlich nur Eins und Eins zusammenzählen, also die kleinen General-Purpose-CPUs vom RPi und die spezialisierten HPC-CPUs. Dennoch, dass es so schnell geschah, hätte ich auch nicht erwartet. Wobei ich mir nicht sicher bin, wie lange Apple wirklich daran gearbeitet hat. Wenn ich spekulieren soll: Sie begannen an dem Tag mit der Arbeit am M1, als damals der erste x86-Mac vorgestellt wurde.

Zitat:

Zitat von Rollo62 (Beitrag 1484064)

Ich glaube das liegt an der Evolution der Chips und Moores Law generell.
[ ... ]
Die haben damals aber wohl nicht erkannt das auf Dauer Moores Law die Chips zu immer kleineren aber flexibleren Kernen und Strukturen drängen würde, was mit CISC immer schwerer umzusetzen ist.
Deshalb bin ich ziemlich überzeugt das CISC aussterben wird, oder sich zumindest mehr dem RISC nähern muss.

Ich denke der Physik sind irgendwo Grenzen gesetzt. Ob wir jemals bei der Lithografie Picometer-Strukturen sehen werden, würde ich bezweifeln. Selbst Geldschleuder Intel hat seine liebe Not, überhaupt auf 5 nm zu kommen. AMD konnte auch nicht deswegen mit dem Ryzen so viel aufholen, sondern weil man das Risiko eines komplett neuen Designs einging und auf massiv-parallele Infrastruktur gesetzt hat. Dafür muss die Software auch erst mal optimiert sein (wir Single-Thread-Monster aus der Delphi-Ecke ^^)

Nachtrag: Mich würde interessieren, wie viel rückwärtskompatibler Ballast in heutigen x86-64-CPUs drin steckt. Man erinnere sich doch nur an das berüchtigte Gate A20, das noch bis zum Haswell-Core unterstützt wurde und nur dazu diente, noch 8086-Code ausführen zu können. AMD hat sich sogar erst mit dem R1000 davon verabschiedet. Man bedenke, Gate A20 gabs seit dem 80286 und damit seit 1982. Ich möchte nicht wissen, wie viel solcher Ballast noch in heutigen x86-CPUs steckt, den niemand mehr nutzt. Selbst an "neuere" Extensions wie MMX würde ich inzwischen ein Fragezeichen machen. Weniger ist manchmal eben mehr.

[freimatz]

Zitat:

Zitat von Codehunter (Beitrag 1484068)

Nachtrag: Mich würde interessieren, wie viel rückwärtskompatibler Ballast in heutigen x86-64-CPUs drin steckt. Man erinnere sich doch nur an das berüchtigte Gate A20, das noch bis zum Haswell-Core unterstützt wurde und nur dazu diente, noch 8086-Code ausführen zu können. AMD hat sich sogar erst mit dem R1000 davon verabschiedet. Man bedenke, Gate A20 gabs seit dem 80286 und damit seit 1982. Ich möchte nicht wissen, wie viel solcher Ballast noch in heutigen x86-CPUs steckt, den niemand mehr nutzt. Selbst an "neuere" Extensions wie MMX würde ich inzwischen ein Fragezeichen machen. Weniger ist manchmal eben mehr.

Das "den niemand mehr nutzt" möchte ich bezweifeln. Da steht sich noch irgendwo in einer Halle eine 20 Jahre alte Maschine mit einem PC zur Datenübermittlung. Und wenn der PC kaputt geht muss Ersatz her der kompatibel zu der alten Software und DR-DOS ist.

[Codehunter]

Zitat:

Zitat von freimatz (Beitrag 1484129)

Das "den niemand mehr nutzt" möchte ich bezweifeln. Da steht sich noch irgendwo in einer Halle eine 20 Jahre alte Maschine mit einem PC zur Datenübermittlung. Und wenn der PC kaputt geht muss Ersatz her der kompatibel zu der alten Software und DR-DOS ist.

Na das wären wohl eher 40 Jahre im Fall vom Gate A20 ^^ 20 Jahre, das dürfte Windows XP sein. Das kannst du heute auf den allermeisten Rechnern noch laufen lassen, wenn auch mit diversem Treibertheater. Was aber bei einem Signaldulli in irgendeiner Steuerungsanwendung nachrangig sein sollte.

Trotzdem, sollte das das Maß sein, weshalb wir Uralt-Ballast herumschleppen müssen? Da finde ich Apples Vorgehensweise fast besser. Nicht vergessen, wir reden von Desktop- bzw. Consumeranwendungen und nicht von Industriesteuerungen. Am Rande bemerkt bekommt man ja sogar 8085er immernoch neu zu kaufen ;-)

[Codehunter]

Es scheint langsam interessant zu werden.

[Stevie]

Im Gegensatz zu Apple wird bei Windows aber vermutlich x86 einfach so kompatibel sein (siehe https://docs.microsoft.com/de-de/win...-x86-emulation) und ich glaube der 64bit Emulator ist auch seit Ende letzten Jahres im Test.

[himitsu]

Wieso eigentlich "Emulator" ?

Ich dachte die machen sowas wie WINE, also in der Hardware eine Übersetzung der Bytecodes von dem Einen in das Andere.

[mkinzler]

Zitat:

Zitat von himitsu (Beitrag 1484902)

Wieso eigentlich "Emulator" ?

Ich dachte die machen sowas wie WINE, also in der Hardware eine Übersetzung der Bytecodes von dem Einen in das Andere.

Aber das genau macht Wine nicht. Es werden nur API-Zugriffe umgelenkt.

[Codehunter]

Ich finds ja jetzt wieder vielsagend, dass bei uns als allererstes über Emulatoren diskutiert wird, anstatt darüber, was nötig wäre, dass wir keine Emulatoren bräuchten :lol:

Am Rande bemerkt steht "Wine" für "Wine is not an Emulator"

[mkinzler]

Mir kennen halt EMBT/Idera :zwinker: :roll:

[himitsu]

WINE biegt einen Befehl auf einen Anderen um. Und diese "Emulatoren" biegen doch auch nur einen Code auf einen anderen um, womit sie doch dann kein Emulator wären, oder wie war das?

[mkinzler]

WinE steht ja eigentlich für "WinE is not an Emulator", weil es keiner ist.

[Codehunter]

Sehr interessant anzuhören.