News Abschied von Intel: Apples Mac wechselt ab Ende 2020 bis Ende 2022 zu ARM

[AlphaKaninchen]

Genau das wollte ich damit sagen Ohne GPU-Beschleunigung fehlt Effizienz unter Linpack.

Ups, ich hatte deinen Betrag so interpretiert dass der nur so gut aussieht weil der Benchmark auf der GPU läuft, Sorry.

 

[y33H@]

Ich hatte das gestern nicht komplett verfolgt aber laut Golem wurde wohl Parallels gezeigt: "[...] Eine Virtualisierung von anderen Betriebssystemen soll ebenfalls möglich sein, wobei Apple Linux und Windows erwähnte und eine Vorabversion von Parallels zeigte. [...]"

Jupp: https://www.glm.io/149241

https://scr3.golem.de/screenshots/2006/Apple-Silicon-WWDC20/Apple-Silicon-16.png

 

[PPPP]

Die hatte Intel wohl auch als man sich bei der Chipfertigung dazu entschied einen Schritt zu überspringen. Wohin das geführt hat sieht man ja bei 10nm...

Nokia dürfte die auch gehabt haben, wie die Geschichte ausging weiß man wohl auch..

Nokia hat den Smartphone Trend der die ganze Branche veränderte verschlafen und ist damit selbstverständlich schnell pleite gegangen.
Intel hat lediglich Probleme mit einer etwas effizienteren (≠ leistungsfähigeren) Fertigung und hat damit seit der Einführung von 7nm bei AMD bis heute ganze 2,2% Marktanteile bei den x86 Prozessoren verloren und steht somit aktuell „nur“ noch bei 85% Marktanteilen bei den x86 Prozessoren.
Der Verlust der Marktanteile dürfte aber selbstverständlich eher auf die aggressive Preispolitik von AMD zur Erlangung von Marktanteilen zurückzuführen sein, als auf die Fertigung die dem Ottonormalverbraucher offensichtlich nicht bekannt ist.
Darüber sind diese bestimmt nicht erfreut, aber das mit Nokia zu vergleichen ist schon etwas schwachsinnig ...

vor allem gleich als "dual boot" - wo es doch bspw. Parallels gäbe, bei denen Anwendungen seamless laufen

„seamless“ mit den ganzen Einschränkungen die eine VM mit sich bringt.

 

[Miuwa]

Das sehe ich anders. Wenn wir Apps entwickeln sind die unterschiedlichen Plattformen klare Kostentreiber. Mit Big Sur und ARM ist es nun möglich dass wir nur eine App im Appstore platzieren, welche dann auf allen Endgeräten (iPhone/iPad, Mac) verwendet werden kann - am Anfang in der iPhone/iPad Ansicht unter Big Sur, wenn es sich lohnt dann mit einem eigenen Layout für Desktop. So lassen sich auch Messenger auf den Mac bringen ohne dafür extra eine eigene App schreiben zu müssen.

unterschiedlichen Plattformen != unterschiedliche ISA (ISA ist ein Teil davon, aber meiner Erfahrung nach nicht der entscheidende).
Natürlich kann ich nicht sagen, was bei euch ein Problem ist und was nicht, aber wieviel von eurem Code ist denn wirklich x86-spezifisch? Evtl. ein paar Vektorinstruktionen falls ihr für's number crunching keine externe Bibliothek nutzt und vielleicht sind ein paar low-level Optimierungen architekturspezifisch (aber wahrscheinlich funktioniert der Code trotzdem auch auf ARM). Was würde euch daran hindern euren euren Code sowohl für ARM als auch für x86 zu übersetzten solange die OS-Schnittstelle identisch ist? Je nach Dev Umgebung und Sprache sind das ein paar Klicks - damals als Apple von PowerPC auf x86 geswitched ist war's sogar wort wörtlich ein Haken (war allerdings vor meiner Zeit also weiß ich nicht, wie das in der Praxis aussah). Am ehesten gibts noch Probleme, wenn man auf closed source 3rd party Bibliotheken angewiesen ist und es die nicht für die neue ISA gibt (oder man dafür extra zahlen muss).

 

[Schorsch92]

Tut es das wirklich?

Langsam und nicht mit 64Bit Code aber immerhin funktioniert es irgendwie als Notnagel für x86-32.

Apple hat viel mehr Kontrolle über die Anwendungen, die für MacOS entwicklet werden, als Microsoft über die für Windows oder gar irgendjemand (Linus Torvalds?) bei Linux.
...

Linux läuft schon mit vielen Anwendungen Recht gut auf ARM (in Diversen Router, Chromebooks, oder auch als Desktop Ersatz auf einem RasPi o.ä. da hier die meiste Software im Quellcode vorliegt ist man nicht darauf angewiesen das der Ursprünglichen Entwickler die Software anpasst sondern man kann sie bei Bedarf selbst portieren. Und zumindest über Treiber im Linux Kernel hat Torvalds wohl sogar mehr Kontrolle als Microsoft über Windows Treiber.

 

[McFritte]

Ein eingestelltes Projekt heißt nicht, dass es ein Fehler war, es auszuprobiert zu haben. Auch Apple probiert intern ständig alles mögliche aus und nur das wenigste davon erreicht je das Tageslicht. Aber manchmal kommt halt auch was Großes dabei raus. Nokia hat falsch gemacht, dass sie eben nicht Neues ausprobiert haben, sonder fest an den Status Quo glaubten.

Alles richtig. Mir ging es nur darum, das hier einige Apple als unfehlbar hinstellen. Die Entscheidung auf ARM zu wechseln kann der Heilige Gral sein oder in ener Bauchlandung enden. Top Berater hin oder her. Manchmal will der Markt halt nicht so wie gedacht. Die Zeit wird es zeigen. Ich persönlich wäre froh, wenn auch in der X86-Welt mal etwas komplett neu designtes kommen würde.

 

[Miuwa]

Eine Sache die mich Interessieren würde: Wenn ich mich richtig erinnere wurde damals bei Windows on ARM spekuliert, dass die Platform deshalb nur 32 Bit x86 code ausführen kann und nicht x64 weil Intel da noch auf wichtigen Patenten saß oder es sonst irgendwelche rechtlichen Hürden gab, die eine x64 emulation verhindert haben.

Frage 1: Sind meine Erinnerungen da korrekt und Frage 2: Falls ja, wie umgeht Apple das Problem?

Ergänzung (23. Juni 2020)

Langsam und nicht mit 64Bit Code aber immerhin funktioniert es irgendwie als Notnagel für x86-32.

Nur der vollständigkeit halber: 64Bit Arm code funktioniert meines Wissens problemlos. Nur halt nicht x64.

 

[MountWalker]

Zu Athlon64-Zeiten machte er x86-Decoder laut einem Anandtech-Interview mit AMD noch ca.10% der Die-Fläche aus. (Und deshalb war es AMD nicht wert, die x86-Kompatibilität aufzugeben, als sie ihre ersten 64Bit-CPUs brachten.)

Und 10% sind eine riesige Menge.

...
Es würde mich überraschen, wenn der Decoder auf modernen CPUs noch mehr als 1% der Die-Fläche bzw. Transistorenanzahl ausmachen würde. ...

Auf welcher Basis schätzt du das? Wie gesagt, es mutet auf dem DieShot bei anandtech größer an - auch wenn ich das ohne genaue eingezeichnete Eingrenzung nicht wirklich sagen kann. Ich kann mir nicht vorstellen, dass x86-Decode-Einheiten so winzig wenig an Transistorzahl und Stromverbrauch ausmachen, wenn AMD mit Bulldozer versucht hat, genau das einzusparen. Warum haben sie das bei Bulldozer gemacht, versucht eine Decode-Einheit über zwei Kerne zu strecken, wenn das nichts am Transistor- oder Stromverbrauch ausmacht?

 

[Banned]

Kurz: Apples zukünftige Chips werden alles zerlegen was es aktuell am PC Markt gibt. Da gibt es wenig Spielraum für Gegenmeinungen.

Und wie hoch können die stabil takten? Was bringt ne höhere IPC, wenn bestimmte Taktraten nicht stabil möglich sind? Wieso gehst du davon aus, dass die Leistungsaufnahme linear skalieren wird bei höheren Taktraten?

Für solche Prophezeiungen ist es viel zu früh. Abwarten und Tee trinken.

 

[TrueAzrael]

Darüber sind diese bestimmt nicht erfreut, aber das mit Nokia zu vergleichen ist schon etwas schwachsinnig ...

Hab ich das? Dann Verzeihung, meiner Ansicht nach hab ich zwei voneinander unabhängige Fälle genannt wo Unternehmen trotz x spezialisiertem Personal für genau den Zweck eben doch Fehler machten. Analysten etc. sind eben auch nur Menschen, auch wenn man eine Million davon in einen Raum wirft.

 

[Herdware]

Und 10% sind eine riesige Menge.

Es war klein genug, dass AMD die x86-Kompatibilität damals deswegen nicht opfern wollte. (Intel hat es versucht und ist damit auf die Nase gefallen.)

Auf welcher Basis schätzt du das? ...

Ein aktueller Ryzen 9 3900X hat z.B. knapp 100x so viele Transistoren wie ein K8 (large cache).
https://en.wikipedia.org/wiki/Transistor_count
Ok. Vielleicht ist unter <1% etwas übertrieben. Aber mit einem Decoder pro Core und wenn jeder auch etwas komplexer geworden ist, wären es wahrscheinlich nur etwas mehr als 1%.

 

[MountWalker]

Es war klein genug, dass AMD die x86-Kompatibilität damals deswegen nicht opfern wollte [...]

Und nochmal: Warum hat AMD dann danach beim Bulldozer versucht, ein Modul mit zwei Recheneinheiten von nur einer Decode-Einheit versorgen zu lassen und idesen Versuch dann mit Steamroller (pro Modulö zwei Decoder) wieder abgebrochen?

Und du kannst die allgemeine Erhöhung der Transistorzahl nicht so ummünzen, sonst hätte ein NexGen Nx586 bzw. K5 m,ehr als die Hälfte seiner Transistoren auf Decode verwendet.

 

[Ruff_Ryders88]

Fehler im Bericht:

Sicher ist, dass es neue Macs mit Intel-CPUs auch noch in Zukunft

...geben wird.

 

[Miuwa]

Noch ne andere Frage, die mir gereade gekommen ist: Die rückwärtskompatibilität zu 32Bit code ist bei ARMv8 (aarch64) doch glaube ich optional. Da apple support für 32 bit sowieso eingestellt hat könnten die den Teil doch sogar komplet aus ihren CPUs entfernen. Oder ist das komplett unrealistisch weil zu viel Aufwand für zu wenig Benefit?

 

[AlphaKaninchen]

Noch ne andere Frage, die mir gereade gekommen ist: Die rückwärtskompatibilität zu 32Bit code ist bei ARMv8 (aarch64) doch glaube ich optional. Da apple support für 32 bit sowieso eingestellt hat könnten die den Teil doch sogar komplet aus ihren CPUs entfernen. Oder ist das komplett unrealistisch weil zu viel Aufwand für zu wenig Benefit?

Da iOS und MacOS keine 32bit Apps mehr kann gehe ich davon aus das es nie 32bit auf ARMs für Macs geben wird.

 

[Schempi]

Jupp: https://www.glm.io/149241

Also da bin ich jetzt aber auch gespannt. In der Präsi habe ich von Windows nichts gehört und hatte eher den Eindruck, dass man bei der Parallels Demo sehr bemüht war, von "Betriebssystemen" im Allgemeinen und von Linux im Speziellen zu sprechen. --> Für mich war das auf ARM Betriebssysteme beschränkt, wenn es eine Möglichkeit gibt, weiterhin x86 Images auszuführen...hätte was! ;-)

Ansonsten: Das Win 10 ARM Image bekommt man offiziell nur über das MS Insider Programm, oder?

 

[AlphaKaninchen]

Ansonsten: Das Win 10 ARM Image bekommt man offiziell nur über das MS Insider Programm, oder?

Man kann in Parallels direct Windows images downloaden, würde mich nicht wundern wenn da in Zukunft auch das ARM Image dabei ist.

 

[PPPP]

Das ist gelinde gesagt einfach nicht wahr, Quelle?
Apples A13 in Sachen IPC leicht über aktuellen Intel/AMD Designs. . Bei einem Bruchteil des Energieverbrauchs.

Die GPU des A13 ist ca. so schnell wie ne 1060 Desktop (die natürlich nur 1/100 so schnell wie ne 2080Ti is.....nicht ).
In einem Handy....

Kurz: Apples zukünftige Chips werden alles zerlegen was es aktuell am PC Markt gibt. Da gibt es wenig Spielraum für Gegenmeinungen.

(Quelle: https://browser.geekbench.com/ios-benchmarks)
(Quelle; https://www.notebookcheck.net/Apple-A13-Bionic-GPU.434833.0.html)

Kannst du anhand deiner Quellen nochmal aufzeigen, wo genau dort Apples A13 so schnell wie eine GTX 1060 ist?
Deine Quellen belegen das nämlich nicht ansatzweise, dort ist dein heiliger A13 nur etwas schneller als ein Tegra 4, welcher natürlich deutlich (!) langsamer als eine GTX 1060 ist ...

 

[aLimp]

Eher nicht. Alleine schon wegen den Aktiverungs-Server für das iPad.

Auf Youtube gibt es von LinusTechTips schon ein Video zu einem der ersten AppleTVs mit erfolgreicher Installation von macOS. Also so abwägig ist das gar nicht - zumal die Aktivierungsserver hier meine ich gar keine Rolle spielen. Das wird das neue Geschäft für einen Hackintosh. :-)

 

[AlphaKaninchen]

AppleTVs mit erfolgreicher Installation von macOS.

Das war die erste Gerneration von Apple TVs, das waren intern Mac minis, das man da MacOS installieren kann finde ich nicht sehr verwunderlich.