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

[Teralios]

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%.

Ich suche gerade die ganze Zeit mal nach einem Bild, in dem man einen Kern mit den entsprechenden Funktionseinheiten sieht.

Aber ja, durch immer breitere Vektor-ALUs und mehr ALUs und AGUs, wird der Platz, den der Decoder braucht, immer geringer in Relation.

Mit der momentanen Technik kann ich mir auch nicht vorstellen einen 10900K, 3950X, Xeon oder so zu ersetzen, außer Apple zieht echt was komplett neues aus dem Ärmel.

Wie gesagt, von der eigentlichen Rechenleistung - INT/FP - hängen die modernen ARM-Kerne ihren Intel und AMD-Pendantes in nichts wirklich nach.

Probleme bekommen die Kerne erst, wenn die Daten nicht schnell genug nachkommen. Aber dieses Problem lässt sich relativ einfach lösen: Breiteres Interconnects zu den Caches, breiteres SI.

Egal wie geil XCode ist - am Ende kommt da auch x86-Maschinencode raus, wenn man für x86 kompiliert und ein Emulator hat immer Overhead den Maschinencode strukturell zu übersetzen. Effizient ist das nie. Das ist nur nativer Code. Mein Kritikpunkt sind halt Treiber, und die sind nochmal auf einer anderen Ebene als wenn man jetzt high-level APIs nutzt.

Rosetta 2 ist kein Emulator, sondern ein - wenn man den Begriff verwenden will - Recompiler!

Natürlich wird er nicht ganz so effizient sein, wie direkt erzeugter ARMv8-Code aus dem Source-Code, jedoch deutlich effizienter als eine klassische Emulation. Man kann den Maschinencode der x86-Binary analysieren und anhand der nachfolgenden Befehle auch Muster erkennen und damit entsprechend optimierten ARMv8-Maschinencode erzeugen, weil man so auch auf Eigenheiten und spezielle Fälle reagieren kann.

Oder anders ausgedrückt:

Ein Emulator übersetzt während der Ausführung den Befehl durch einen entsprechend passenden Befehl. Hier wird Befehl für Befehl ausgeführt. Der langsamste Ansatz.

Rosetta 1 ist bereits kein "reiner" Emulator mehr, sondern mehr ein JIT-Compiler. Dieser Übersetzt nicht mehr Befehl für Befehl während der Ausführung, sondern nimmt einen gesamten Maschinencode-Block und übersetzt ihn als ganzes. Geschwindigkeit steigt, da mehr Befehle am Stück übersetzt werden. Bereits hier greift Mustererkennung um zusammenhängende Befehle durch passenden für Zieltplattform optimierten Code zu ersetzten.

Rosetta 2 ist "Maschinencode-Compiler". Während der Installation wird der Maschinencode des Programmes analysiert und abhängig von dieser Analyse ein vollständig neues Binary erschaffen und abgespeichert. Es findet bei der Anwendung des Programmes KEINE Übersetzung mehr statt.

--
Manchmal wünschte ich mir, manche würden erst mal lesen und sich zumindest mit den Grundlagen befassen. Alle Informationen sind hier zugänglich. Aber statt desssen wird schwadroniert, was das Zeug hält und man dreht sich ständig im Kreis, weil man immer und immer wieder die bekannten Sachverhalte erläutern muss, statt wirklich mal eine sinnvolle Diskission zu führen... Nervig!

 

[stevefrogs]

Wäre dann die Frage, was ihr dann als nächstes nehmen wollt. Das aktuelle SE 2 basiert auf dem Gehäuse vom iPhone 8 und da das alte SE auf dem 6s aufsetzte, wird euch das damals auch schon von den Ausmaßen her zu groß gewesen sein.

Nicht korrekt. Der SoC war aus dem 6s, von außen war es aber ein 5s-Gehäuse, das deutlich kleiner ist.

 

[pitu]

sehe ich das richtig? Apple verbaut ab jetzt SOCs aus dem Iphone und Ipad in ihre Workstations?

 

[PS828]

Workstations würde ich bis auf eine Ausnahme Apple Produkte nicht nennen
Klar kommts drauf an was man macht aber es gibt hier klare Einschränkungen ^^

 

[Ltcrusher]

@stevefrogs das meinte ich eigentlich mit "auf dem 6s aufsetzen". Da sich das direkt auf @B.XP bezog, der ein solches Gerät nutzt, habe ich das dann nicht mehr weiter ausgeführt.

 

[Shrimpy]

Bin da noch skeptisch, aber hört sich vielversprechend an. ARM ist im low power Bereich seht effizient aber wie das jetzt bei größeren Chips wird muss man dann sehen. Ich frag mich vor allem wie die GPU wird, kann mir eigentlich schwer vorstellen das sie so viel besser wird als die der Konkurrenz.

Hat man schon bei server gesehen und 230W.
Sobald da ein Dickes SI dran hängt und man über die üblichen 2,6GHz will kann man gleich einen Rome Epyc nutzen.
Für Lowpower und mobile sehr wohl zu gebrauchen, am desktop sehe ich kein land.
x86 frist inzwischen weniger als 2% der leistungsaufnahme einer CPU, macht kein sinn das zu entfernen auser lizenzkosten zu sparen.
Und das ist apples ziel, war auch amazons ziel bis epyc dahergekommen ist.

 

[D708]

Ich hab dir jetzt mehrere Quellen genannt, auch eine von Spec2006 wo fast alles was man mit Rechnern machen kann getestet wurde, eben nicht nur Spezialfälle.
Wo sind also deine Quellen, deine Benchmarks? Behaupten kann man viel, Belege zählen 😉

Hier im eigenen Forum. x86/64 Software auf einer ARM CPU vs. einer alten HighendCPU.
Deswegen sag ich ja Spezialfälle.

https://www.computerbase.de/forum/t...marks-getestet-vs-4750hq-irispro5200.1951629/

Da zeigt ARM sehr viele Schwächen, aber auch viele Stärken, wenn man es von den Passivzwängen befreit.

Oder auch der 3D Mark ICE Storm Physic Unlimited:
Da ist der Apple ARM gleich auf mit dem i5-6200U. Bin ich jetzt beeindruckt, es geht. Ist ARM weit vor x86, ich sehe es nicht.

Oder 3DMark - Sling Shot Extreme. Weit abgeschlagen hinter den Intel CPUs

Dann zur GPU:
Im 3DMark - Ice Storm Unlimited Graphics Score konkurriert die GPU mit der Gt 1030 in keinem Fall mit der GTX 1060.

Im GFXBench 3.0 - Manhattan Onscreen OGL on screen ist die GPU gleich auf mit einer GTX 920m. Das kann jetzt auch jeder für sich bewerten.

Und ich wiederhole mich gerne, diese Benchmarks sind auch Schrott, zwischen Gt 1030 und GTX 1060 liegen knapp 20%. Kann sich jeder selber überlegen, ob das einen guter Benchmark ist.

So sehr du es dir wünschst, Apple ARM ist in der jetzigen Form keine Wachablösung im HighendChip Himmel.
Wenn es Apple gelungen sein soll, einen ARM Design für ein 95W Modell zu kreieren, das 1:1 skaliert, kommen sie ins Fahrwasser von Intel/AMD. Die Schwaffelei, dass ein mobiler Prozessor, der vollgemerkt sehr gerne throttlet, es jetzt schon mit den „Big Boys“ aufnehmen könnte, könnte bei den Grimms im Buch stehen.

Niemand weiß wirklich, wo die mobilen Apple ARM wirklich stehen.
MS ARM hat das erste Mal eine grobe Einschätzung gegeben
(4x 3.00GHz (ARM Cortex-A76) + 4x 1.80GHz (ARM Cortex-A55))
Die Ergebnisse war für die Meisten ernüchternd, ich fand sie gut.

Apples Ergebnisse werden wir nächstes Jahr zu Gesicht gekommen, aber auch die kochen nur mit Wasser. Man kann auf den Hypetrain hüpfen, wenn es belastbare Nachweise gibt und nicht irgendwelche synthetischen Benschmarks.

 

[B.XP]

Wäre dann die Frage, was ihr dann als nächstes nehmen wollt. Das aktuelle SE 2 basiert auf dem Gehäuse vom iPhone 8 und da das alte SE auf dem 6s aufsetzte, wird euch das damals auch schon von den Ausmaßen her zu groß gewesen sein.

Wenn Apple da nicht wieder etwas aus dem Hut zaubert, wo keiner jetzt mit rechnet, werdet ihr euch mit 5" plus x an Größe gewöhnen müssen, wenn das alte SE durch Supportende oder Defekte ersetzt werden soll.

Sorry, ein "SE 2", nicht das alte SE. Kann man Namentlich nicht auseinander halten. Das alte SE bzw. iPhone5-Format wäre mir auch zu klein gewesen. Ich hatte in den letzten 10 Jahren ein iPhone 3G, ein Galaxy S2, ein Lumia 925, ein Xperia Z3, ein Galaxy S8 und jetzt das SE 2, in der Arbeit noch ein paar andere. Mir ist wirklich vollkommen egal, welches OS drauf läuft und ob da Fenster, ein buntes G oder ein angebissener Apfel drauf ist. Wichtig ist, dass es seine Funktion gut erfüllt und gut nutzbar ist. Und wenn ich ein Gerät nicht mit einer Hand nutzen kann, dann schränkt das den Spaß schon erheblich ein, wenn Updates die Nutzbarkeit verbessern, gerne. Wenn Updates die Nutzbarkeit einschränken (siehe iPhone 3G, siehe Lumia) dann bin ich erstmal "not amused".

Rosetta 2 ist "Maschinencode-Compiler". Während der Installation wird der Maschinencode des Programmes analysiert und abhängig von dieser Analyse ein vollständig neues Binary erschaffen und abgespeichert. Es findet bei der Anwendung des Programmes KEINE Übersetzung mehr statt.

Ja in einem gewissen Sinne unterscheidet sich das am Ende weil die Laufzeitumgebung eben fehlt. Über Kompatibilität und Performance zu sprechen ist aktuell noch müßig; Insbesondere wie solche Dinge wie Compileroptimierung und Obfuscation da eine Rolle spielen werden.

 

[Ltcrusher]

@B.XP sagen wir es dann mal so: also wirklich viel kleiner vom Gehäuse als andere Wahlmöglichkeiten ist das dann doch nicht.

 

[andi_sco]

7% Marktanteil hat Apple bei Computern/Notebooks, mehr als acer oder Asus.

Naja, wird intel überleben

 

[Redragonzensor]

Sowohl Unity als auch Unreal laufen prinzipiell auf ARM. Jetzt wissen wir nicht welche APIs bei Apple dabei sind, aber es wird sicher nicht an der Architektur scheitern wenn es keine Spiele mehr für macOS gibt.

 

[adius]

Für mich ein logischer Schritt um sich "Störfrei" zu machen. Es gibt ja genug andere Hersteller die weiter Intel aber zum Glück auch AMD verbauen. Ein weiterer Schritt ins geschlossene und damit sichere Appleuniversum.
Bei den Marktanteilen sollte sich Intel wohl kaum Sorgen machen müssen.

 

[new Account()]

Ein Emulator übersetzt während der Ausführung den Befehl durch einen entsprechend passenden Befehl. Hier wird Befehl für Befehl ausgeführt. Der langsamste Ansatz.

Rosetta 1 ist bereits kein "reiner" Emulator mehr, sondern mehr ein JIT-Compiler. Dieser Übersetzt nicht mehr Befehl für Befehl während der Ausführung, sondern nimmt einen gesamten Maschinencode-Block und übersetzt ihn als ganzes. Geschwindigkeit steigt, da mehr Befehle am Stück übersetzt werden. Bereits hier greift Mustererkennung um zusammenhängende Befehle durch passenden für Zieltplattform optimierten Code zu ersetzten.

Also wenn das so stimmt, dann macht die ARM Emulation unter Windows exakt das gleiche, bzw. einen Mix von Rosetta 1 und 2.

 

[Teralios]

Also wenn das so stimmt, dann macht die ARM Emulation unter Windows exakt das gleiche.

Kann gut sein, wobei ich mir nicht ganz,so,sicher bin, ob es wirklich bereits auf dem Level von Rosetta 1 ist, oder zwischen der klassisches Emulation und Rosetta 1: https://threatvector.cylance.com/en_us/home/teardown-windows-10-on-arm-x86-emulation.html

Was ich bisher finde ist, dass er immer noch Befehlsweise arbeitet, aber durchaus ganz Blöcke dann am Stück abarbeitet. Frage ist, ob er auch ganze Blöcke durch ebenso optimierte Blöcke ersetzen kann.

 

[zett0]

AMD hat doch bereits eine Kooperation mit ARM am Laufen, da gab es doch mit Samsung einen Prototypen.
Nur Intel scheint den Sprung noch nicht zu schaffen, mal schauen wann und wie sie reagieren. Könnte nicht die erste Firma sein, die eigentlich nichts falsch macht, aber trotzdem flöten geht. Vor allem in einer so schnelllebigen Branche...

Hat AMD nicht die Entwicklung des ARM-Prozessors fallen gelassen um sich verstärkt auf x86 zu konzentrieren?

 

[Velines]

Rosetta 2 ist "Maschinencode-Compiler". Während der Installation wird der Maschinencode des Programmes analysiert und abhängig von dieser Analyse ein vollständig neues Binary erschaffen und abgespeichert. Es findet bei der Anwendung des Programmes KEINE Übersetzung mehr statt.

Und interessanterweise hat Apple schon seit 5 (fünf !) Jahren darauf hingearbeitet: https://thenextweb.com/apple/2015/0...s-at-wwdc-that-nobodys-talking-about-bitcode/

Dieses Detail fand ich damals schon die spannendste Neuerung überhaupt, mich hat schon immer gewundert dass das nirgends großartig erwähnt wurde.

 

[Felixxz21]

Hier im eigenen Forum. x86/64 Software auf einer ARM CPU vs. einer alten HighendCPU.
Deswegen sag ich ja Spezialfälle.

https://www.computerbase.de/forum/t...marks-getestet-vs-4750hq-irispro5200.1951629/

Da zeigt ARM sehr viele Schwächen, aber auch viele Stärken, wenn man es von den Passivzwängen befreit.

Oder auch der 3D Mark ICE Storm Physic Unlimited:
Da ist der Apple ARM gleich auf mit dem i5-6200U. Bin ich jetzt beeindruckt, es geht. Ist ARM weit vor x86, ich sehe es nicht.

Oder 3DMark - Sling Shot Extreme. Weit abgeschlagen hinter den Intel CPUs

Dann zur GPU:
Im 3DMark - Ice Storm Unlimited Graphics Score konkurriert die GPU mit der Gt 1030 in keinem Fall mit der GTX 1060.

Im GFXBench 3.0 - Manhattan Onscreen OGL on screen ist die GPU gleich auf mit einer GTX 920m. Das kann jetzt auch jeder für sich bewerten.

Und ich wiederhole mich gerne, diese Benchmarks sind auch Schrott, zwischen Gt 1030 und GTX 1060 liegen knapp 20%. Kann sich jeder selber überlegen, ob das einen guter Benchmark ist.

So sehr du es dir wünschst, Apple ARM ist in der jetzigen Form keine Wachablösung im HighendChip Himmel.
Wenn es Apple gelungen sein soll, einen ARM Design für ein 95W Modell zu kreieren, das 1:1 skaliert, kommen sie ins Fahrwasser von Intel/AMD. Die Schwaffelei, dass ein mobiler Prozessor, der vollgemerkt sehr gerne throttlet, es jetzt schon mit den „Big Boys“ aufnehmen könnte, könnte bei den Grimms im Buch stehen.

Niemand weiß wirklich, wo die mobilen Apple ARM wirklich stehen.
MS ARM hat das erste Mal eine grobe Einschätzung gegeben
(4x 3.00GHz (ARM Cortex-A76) + 4x 1.80GHz (ARM Cortex-A55))
Die Ergebnisse war für die Meisten ernüchternd, ich fand sie gut.

Apples Ergebnisse werden wir nächstes Jahr zu Gesicht gekommen, aber auch die kochen nur mit Wasser. Man kann auf den Hypetrain hüpfen, wenn es belastbare Nachweise gibt und nicht irgendwelche synthetischen Benschmarks.

hahaha ich wünsche mir das gar icht, aber so sieht die Welt ja nunmal aus. Und nicht wenige Experten sehen das genauso.

Ich finds ja schön, dass du jetzt immerhin mal Quellen dargelegt hast und die sind auch nicht schlecht, jedoch wirkt es auf mich eher so als ob du die Spezialfälle zeigst und nicht ich.Du hast dir jetzt 1-2 Rosinen rausgepickt, aber wenn man sich halt Spec2006 ansieht, was einer der realistischeren Benches ist, dann ist Apple da im Average auf Augenhöhe. Mit einem Handychip.

was bei 30W und einem weiteren jahr Entwicklung geht kann man sich denken.

bin jetzt aber auch raus, wollte hier eigentlich vor allem ganz nüchtern paar Ideen liefern, um den Switch einzuordnen und mich nicht rumstreiten. 😊

 

[Schorsch92]

Ehrlich gesagt weiß ich nicht was genau im Hintergrund passiert, Java hat ja sowieso eine eigene Runtime. Ich habe halt im Rahmen des Studiums eine App in Qt mit C++ entwickelt. Jedenfalls hat das starten der AVM um die App zu testen immer ewig gedauert - könnte aber auch einfach an meinem Laptop liegen der eigentlich maximal für Office ausgelegt ist.

Die selbe App startete aber sofort im x86 Modus auf meinem Kartoffellaptop, deswegen hier die Hoffnung dass die Emulation eines Android-Devices einige Magnituden schneller funktionieren wird wenn der Laptopprozessor auch auf arm basiert.

Den C++ Quellcode kann für die x86 AVM auch einfach in x86 Binärcode übersetzt werden das Lag bei dir wohl Entweder an der Hardware, der Android Studio Konfiguration, dem Betriebssystem oder an den BIOS Einstellungen denn leider unterstützt Android Studio eine schnelle Hardwarevirtualisierung unter Windows nur auf Intel CPUs mit Intel VT-x, Intel EM64T (Intel 64), und Execute-Disable-(XD)-Bit-Funktionalität unter Linux geht es mit allen CPUs die KVM Unterstützung bieten also auch aktuellen AMD CPUs und ja eine Android VM ohne Hardwarebeschleunigter Virtualisierung braucht ewig zum Starten.

 

[GTR]

Viele wissen gar nicht das MacOS derzeit aus BridgeOS und MacOS besteht. Diese Kombination hat viele Probleme verursacht. BridgeOS ist notwendig da es ja schon ARM in Mac Produkten gibt aber mit X86 Produkten arbeiten muss (T2). Einheitlich nur noch ARM zu nehmen ist daher deutlich besser als diese Mischung die sehr fehleranfällig ist. Muss sich nur noch zeigen wie leistungsfähig die Prozessoren werden.

 

[AlphaKaninchen]

Sowohl Unity als auch Unreal laufen prinzipiell auf ARM. Jetzt wissen wir nicht welche APIs bei Apple dabei sind, aber es wird sicher nicht an der Architektur scheitern wenn es keine Spiele mehr für macOS gibt.

Schaut doch einfach die State of the Union da wird genau so etwas gezeigt/erklärt, Unity läuft schon brauchst nur recompile drücken und eventuell deinen Code anpassen. An APIs gibt es Metal, wie man es von Apple erwartet.