Notiz Apple Silicon: Auch World of Warcraft läuft nativ auf dem M1-Prozessor

[iSight2TheBlind]

@7H0M45

The future is already here — it's just not very evenly distributed.

William Gibson

@Trumpf Was einzelne Kerne betrifft haben sie aktuell wohl die Leistungskrone und was Multicore betrifft ist das ein Spiel welches sie mit dem M1 aktuell noch gar nicht spielen wollen...
Davon abgesehen: Nein, es müssten nicht mehrere Jahre vergehen!
Was meinst du denn wie die Entwicklung bei Apple passiert? Die fangen doch nicht jetzt erst mit den größeren M-SoCs an und der M-SoC ist auch nicht erst seit drei Wochen in Entwicklung.

Apple hat intern garantiert bereits seit Jahren eine Version von MacOS gehabt die auf ARM-Prozessoren lauffähig ist und hätte entsprechende Macs vor Jahren schon veröffentlichen können!
Hey, das DTK welches im Sommer erschien verwendet den Prozessor des iPad Pro 2020 und der wiederum unterscheidet sich nur in einem zusätzlichen GPU-Core von dem A12X aus dem 2018er iPad Pro (und der GPU-Core war da einfach deaktiviert).
Sicherlich hätte man bereits damals entsprechende Macs veröffentlichen können, hat aber gewartet bis man nicht nur in der Leistung (des MacBook Air und dem einfachen MacBook Pro 13) gleichzieht sondern sogar davonzieht, wie es jetzt passiert ist.

Apple arbeitet bereits seit vielen Jahren an den ARM-SoCs und auch seit vielen Jahren an den Varianten für die Macs - aber halt nicht in der Öffentlichkeit!

Apple arbeitet in der Regel immer heimlich an neuen Produkten!

 

[SoDaTierchen]

Auf dem Papier wesentlich schneller als die SATA Modelle, in der Praxis oft kein Unterschied zu erkennen. Das liegt einfach daran, dass die alte API immer noch auf den Zugriff von HDD's basiert und optimiert ist.

Leider falsch, auf vielen Ebenen. NVMe wurde explizit für Flash über PCIe konzipiert, HDDs wurden dabei null bedacht. Auf dem Papier hat NVMe nur höhere Durchsatzzahlen und IOPS, die Reaktionszeit hängt von den NAND-Zellen und dem eingesetzten Controller ab. Realistisch kann sich NVMe bei Durchsatz SEHR von SATA-SSDs absetzen, bei Zugriffszeiten aber kaum. Das spiegelt sich auch auf dem Papier wieder. Und das ist der große Punkt, warum es im Alltag wenig Unterschied gibt. SATA-SSDs sind auch nicht 100x schneller als SATA-HDDs, sondern eher so um den Faktor 4-5. Dass sich das trotzdem wie Welten anfühlt liegt daran, dass die Zugriffszeiten von NAND-Zellen bei ca. 25µs liegt, während HDDs hier eher mit 4,2ms (höher bei hohen IOPS) herumlaufen und dass SATA-SSDs statt den 120 IOPS einer normalen HDD eher so 70.000 IOPS und mehr schaffen.

Ein weiterer Punkt, warum sich NVMe nicht wie eine Offenbarung anfühlt ist einfach der, dass HDDs eine für Menschen deutlich wahrnehmbare Verzögerung gebracht haben. Mit den SATA-SSDs ist die Leistung so stark gestiegen, dass wir keine wahrnehmbare Komponente mehr haben, außer bei großen Aufgaben. Schnelle NVMe-SSDs arbeiten zwar in vielen Szenarien nochmal deutlich schneller, aber es treten dann 2 Effekte ein: Erstens kann plötzlich eine andere Komponente limitieren, sodass die nominell 14fache Leistung einfach nicht ankommen kann und zweitens interessiert uns bei nicht-kompetetiven Elementen nicht, ob ein Vorgang nun 13ms oder 0,95ms benötigt.

 

[Hellsfoul]

Wie schafft man es denn ein x86 Spiel mit nur einem Patch auf ARM zum laufen zu kriegen?
Ich hätte erwartet, dass da umfangreiche Änderungen am ganzen Code gemacht werden müssen.

Die Spiele sind inzwischen ziemlich modular aufgebaut. Man nutzt Software Frameworks. Wenn etwas im Spiel geändert wird, dann müssen die keine 2 Versionen für Mac und Windows bauen. Siehe Unreal Engine usw.
Der Vorteil ist die gute Wartung und weniger Bugs. Der große Nachteil ist aber die fehlende Optimierung für die jeweilige Plattform.

Man muss nur mal ein Programm im guten alten MFC erstellen. Auf modernen Rechnern gibt es null Ladezeit. Das ist wirklich schon geöffnet, wenn man die Maustaste loslässt. Nutzt man aber zB QT oder WPF, müssen zuerst die ganzen Bibliotheken des Frameworks geladen werden. Und man hat dann bei der Ausführung viele Sprünge in die Funktionen des Frameworks. Das macht die Sache langsam.

Daher würde es mich nicht wundern, wenn x86 kaum schneller ist, weil die Programmierer schon seit Jahren die Rechenleistung mit aufgeblasenen Frameworks verschwenden. Die Anwendung ist schnell genug, dass es die Anwender nicht nervt, also wenn juckts.

 

[M@tze]

Leider falsch, auf vielen Ebenen.

Du meinst Deinen Beitrag?

Entweder reden wir zwei gerade komplett aneinander vorbei oder Du hast nicht verstanden was ich aussagen wollte (vielleicht habe ich mich schlecht ausgedrückt?).

NVMe wurde explizit für Flash über PCIe konzipiert, HDDs wurden dabei null bedacht.

Etwas anderes habe ich nicht geschrieben.

Realistisch kann sich NVMe bei Durchsatz SEHR von SATA-SSDs absetzen, bei Zugriffszeiten aber kaum.

Ja, in Benchmarks. Davon kommt in der Praxis aber kaum etwas an, da die normale Software über die API des OS auf die Disk zugreift. Und genau diese API ist eben NICHT auf die Vorteile der NVMe SSD ausgelegt, nutzt sie daher auch gar nicht. Die Geschwindigkeitszuwächse, die man von HDD auf SSD erlebt hat, lag hauptsächlich an den extrem verringerten Zugriffszeiten und der damit verbundenen erhöhten Lese/Schreibgeschwindigkeit.

Lies Dir doch einfach mal den hier bei CB veröffentlichten Beitrag über Direct Storage durch.

Inzwischen haben SSDs den herkömmlichen Festplatten den Rang abgelaufen und erreichen mit NVMe-Technik Datentransferraten von mehreren Gigabyte pro Sekunde. Die Leistung wird aber oftmals nicht genutzt, da veraltete Software und APIs noch auf langsame HDDs abgestimmt sind. Auch die Workloads bei Spielen haben sich inzwischen geändert, schreibt Yeung. So würden moderne Spiele viel mehr Daten laden und dies durch Optimierungen auf intelligentere Weise. Statt große Datenblöcke mit wenigen I/O-Anfragen zu laden, gehe der Trend bei Spielen dahin, dass Inhalte wie Texturen in kleinere Blöcke zerlegt werden und nur noch die gerade benötigten geladen werden, was effizienter sei, jedoch die I/O-Requests in die Höhe treibe.

Und genau für diese hohe Zahl der I/O-Anfragen sind moderne SSDs mit PCIe-Schnittstelle und dem NVMe-Protokoll prädestiniert. Jedoch können sie ihre Leistung nur abrufen, wenn auch die API für die hohe Befehlsanzahl optimiert ist, was bisher nicht der Fall sei – DirectStorage soll dies ändern.

Schau Dir auch mal Ladezeiten von Multiplattform Titeln auf der Series X und PS5 an. Obwohl die SSD der PS5 auf dem Papier doppelt so schnell ist, lädt die Series X die Spiele schneller, da diese bereits Direct Storage nutzt - die PS5 nutzt noch die alte API. Und dabei sind die Spiele noch nicht mal auf DirectStorage optimiert...

Schnelle NVMe-SSDs arbeiten zwar in vielen Szenarien nochmal deutlich schneller, aber es treten dann 2 Effekte ein: Erstens kann plötzlich eine andere Komponente limitieren, sodass die nominell 14fache Leistung einfach nicht ankommen kann

Eben, und die limitierende Komponente ist hier die alte API. Nichts anderes habe ich geschrieben...

Eine NVMe SSD "lebt" von hohem I/O und langer Queue Depth, welches aber vom aktuellen System gar nicht geliefert werden kann. Du hast einen 10.000PS Motor, der eigentlich von mehreren Benzinpumpen parallel versorgt werden müsste - Du hast aber nur eine verbaut und das Benzin kommt nur tröpfchenweise an...

 

[calluna]

Und wohlgemerkt, Tomb Raider ist emuliert...

Das Wort "Übersetzt" oder "Translation" trifft es vielleicht besser... denn was Apple da macht, ist keine Emulation in dem Sinne, was das Wort sonst bedeutet.

 

[Gr.mm]

Was einzelne Kerne betrifft haben sie aktuell wohl die Leistungskrone und was Multicore betrifft ist das ein Spiel welches sie mit dem M1 aktuell noch gar nicht spielen wollen...
[...]
Apple arbeitet bereits seit vielen Jahren an den ARM-SoCs und auch seit vielen Jahren an den Varianten für die Macs - aber halt nicht in der Öffentlichkeit!

Apple arbeitet in der Regel immer heimlich an neuen Produkten!

Sie haben die Leistungskrone in einem frei von ihnen gewählten Segment. Absolut sind x86 auch im SC sowohl bei Laptops z.b. 1165G7, als auch Desktop CPUs immer noch schneller. Gibt schon erste Benches mit CB R23, das nativ ARM und x86 unterstützt.
BTW: Es arbeiten alle Hardwarehersteller heimlich an neuen Produkten, sowas öffentlich zu machen verschafft Mitbewerben nur unnötige Vorteile

 

[iSight2TheBlind]

@Gr.mm Jain!
AMD und Intel releasen jedes Jahr den dann bei ihnen aktuellen Stand in den Markt, da sie so Geld verdienen müssen.
Kündigen Prozessoren Monate im Voraus an, um Käufe bei der Konkurrenz zu verhindern.

Apple hat einfach seit Jahren an einer eigenen Desktop-CPU gearbeitet und die jetzt mit gerade mal einem halben Jahr Vorankündigung (und die bezog sich auch nur auf die Architektur, nicht darauf welche Macs jetzt eigentlich dieses Jahr so eine CPU bekommen, das ist erst seit einer Woche bekannt) veröffentlicht und was sie aktuell für den Mac Pro entwickeln müssen sie erst bekanntgeben wenn der nächste Mac Pro erscheint.

 

[iGameKudan]

Mich erstaunt es selber, welche Macht Apple zu haben scheint. ARM-CPUs im Windows-Bereich gibts ja schon ne Weile, aber kaum darauf angepasste Software. Ergo ist die Performance von 99% aller Anwendungen für die Tonne.

Aber kaum kommt Apple mit Apple Silicon um die Ecke, springen Größen wie Adobe und Blizzard/WoW direkt. Mal sehen wie sich das entwickelt...

 

[AlanK]

Finde auch im Blizzard Forum nichts zum Thema Classics.
Wird der Patch auch für Classic kommen?
Classic ist doch eh schon Metal kompatibel.

 

[DJMadMax]

Apple wagt sich mit eigenen Prozessoren in den x86-Bereich? Ja geil!

User startet Anwendung XY ->
Apple: "Nö, ich möchte nicht, dass du das jetzt startest, stattdessen mach ich iTunes auf".

User rechnet 4+6 im Taschenrechner ->
Apple: "Ich weiß das Ergebnis, aber du brauchst es nicht zu wissen, das ist viel zu kompliziert für den Anwender".

User schließt ein Lenkrad für Rennspiele an ->
Apple: "Nur Lenkräder mit maximal einem Pedal werden unterstützt, User-Experience und so!"

Ich mag die Welt

 

[cruse]

Ich freu mich schon auf erste Tests zwischen einem M1 Mac und einem nicht Apple x86 System mit nicht unnötig gebremster CPU.

Synthetische Benchmarks sind Schwachsinn.

Was für Tests denn?
Wie schnell der Browser öffnet mit Stoppuhr?
Wie schnell 7zip 8gb zusammenpackt?

Wenn man etwas wiederholgenau testen will, ohne den Einfluss Mensch, nimmt man einen benchmark!

Nicht mal ein Controller ist ausreichend dafür,

Geht mit Controller ganz gut, schon ausprobiert.
Ein paar spells weniger und schon lässt sich das ganz easy zocken. Für die meisten specs reichen ja auch ein paar Buttons. Man könnte das Skillsystem noch etwas voller packen, so dass man da noch mehr skills drin hat, zwischen den man auswählen muss oder kann, so kann man sogar die selben spells benutzen, nur halt nicht alles auf einmal. Dafür halt immer wechselbar.
Das Game selbst würde gut laufen.

 

[Atent123]

Jedenfalls würde Apple die Leistungskrone nicht einfach aus dem Ärmel schütteln können. Mehrere Jahre müssten vergehen, bis sie mit Intel und AMD gleichziehen können. Ich habe auch erhebliche Zweifel, ob das mit einem ARM-Design ohne Befehlssatzerweiterung überhaupt möglich ist.

Von welchen Befehlssatzerweiterungen redest du ?
Mir fällt außerhalb einer Neon Erweiterung auf 256b relativ wenig ein.
Momentan gibt es dafür 4 dedizierte pipelines zum Ausgleich.
Dürfte für Rosetta 2 nicht ganz einfach sein. Für native Anwendungen schon.

Man muss halt vor allem im Hinterkopf behalten, dass IPC Krone nicht gleich Leistungskrone ist.

 

[cruse]

Apps starten blitzschnell, Seiten unter Safari laden einfach sofort.

Also so wie mein PC seit Jahren?^^

 

[USB-Kabeljau]

Ist die Mac Fraktion größer als das Potenzial für eine ordentliche Linux Version? Jahrelang muss man hier mit Wine darben 🤔

Viel größer.
Und große Teile der Fanbase kaufen die Geräte auch direkt ohne drüber nachzudenken.

Hinzu kommt, dass Apple genug Geld hat, die Entwickler entsprechend dafür zu bezahlen, dass sie ihre Software zeitnah auf das neue System porten.

Hätte MS auch machen können. Aber sie raffen's einfach nicht, wie wichtig sowas ist.

 

[riloka]

Sind die Mac Nutzer nicht die kreativen und die Firmen und weniger die Spielefans? Ich mein die Hardware is gemessen an der Leistung pro € nicht unbedingt die beste.

 

[Autokiller677]

Man muss nur mal ein Programm im guten alten MFC erstellen. Auf modernen Rechnern gibt es null Ladezeit. Das ist wirklich schon geöffnet, wenn man die Maustaste loslässt. Nutzt man aber zB QT oder WPF, müssen zuerst die ganzen Bibliotheken des Frameworks geladen werden. Und man hat dann bei der Ausführung viele Sprünge in die Funktionen des Frameworks. Das macht die Sache langsam.

MFC als "gut" zu bezeichnen, ist aber auch ein ziemlicher Stretch^^
Also ja, ist schnell. Aber im Gegensatz zu modernen Frameworks mit ordentlicher Abstraktion usw. schon ein Albtraum. Und das bekommt ja auch der Nutzer am Ende zu spüren, der hat dann zwar etwas bessere Responsivität, aber es geht auch jede Menge Entwicklerzeit in die Nutzung des alten Frameworks - mit der Zeit könnte man aber auch neue Features entwickeln.

Und wenn man ordentlich shared Libraries nutzt, hat man vor allem mit WPF wenig Ladezeitverluste, weil die Bibliotheken meist eh schon geladen sind, wenn man mal ein paar Programme aufhat. Das neue Programm muss da dann nicht warten, ist alles schon da.

Hätte MS auch machen können. Aber sie raffen's einfach nicht, wie wichtig sowas ist.

Ist ihnen möglicherweise auch einfach nicht so wichtig. Die Bindung an ihr Ökosystem läuft eh für viele Kunden über Office. Und richtig Geld macht MS mit Azure, nicht mit ein paar Windows Lizenzen.

Möglicherweise ist es ihnen sogar ganz recht, dass Windows aktuell etwas an Marktanteil verliert, dann steht nicht bei jeder etwas krummen Aktion direkt jemand da und verklagt sie wegen Monopolstellung & Machtmissbrauch.

 

[Miuwa]

Mich erstaunt es selber, welche Macht Apple zu haben scheint. ARM-CPUs im Windows-Bereich gibts ja schon ne Weile, aber kaum darauf angepasste Software. Ergo ist die Performance von 99% aller Anwendungen für die Tonne.

Aber kaum kommt Apple mit Apple Silicon um die Ecke, springen Größen wie Adobe und Blizzard/WoW direkt. Mal sehen wie sich das entwickelt...

Der Unterschied ist dass Apple Klipp und Klar gesagt hat, dass sie in 2 Jahren nurnoch ARM Prozessoren verbauen werden, d.h. im Apple Ökosystem wird das Verhältnis x86 vs ARM in den nächsten Jahren dramatisch kippen, während die ARM System im Windows Ökosystem auf absehbare Zeit wohl eher ein Nischendasein fristen werden (es seidenn natürlich der PC Mark springt auf den von Apple erzeugten ARM Hype mit auf).

Spoiler: Vorsicht: RANT

Was mir bei Apple gefällt: Sie haben ein Ziel wo sie hin wollen (häufig vielleicht auch eine Vision), sie kommunizieren es klar und deutlich und dann wird das auch konsequent umgesetzt.

Microsoft dagegen stellt zig Coole Ideen/Technologien vor, schmeißt sie halbgar auf den Markt ohne richtig darin zu investieren, wundert sich dann, dass die Kundschaft nicht so recht auf den Zug aufspringen will und lässt sie dann wieder fallen oder kommt nach ein paar Jahren wieder mit was neuem ums Eck.

Die wievielte Designumstellung hat Win10 jetzt erfahren und das wievielte mal wurde der Upgrade/Release prozess umgestellt? Wie lange doktern sie schon an der Migration der Systemsteuerung? Macht der Store auch nur im entferntesten den Eindruck hinter ihm stünde eines der größten Softwareunternehmen der Welt? wie lange hat es gedauert, bis man Vollständiges MS-Office im Store beziehen konnte (Ich glaube als richtige UWP apps gibts die immer noch nicht oder)? Wie lange warten wir jetzt schon auf eine vernünftige Integration von c++/winirt in Visual Studio? Hat Microsoft mal irgendwo ihre mittelfristigen Pläne bzgl. 32Bit Windows öffentlich gemacht? Von der scheinbar nicht existierenden Strategie damals im Smartphonemarkt will ich erst garnicht anfangen)


Bei dieser Historie bin ich überhaupt nicht überrascht, dass weder Nutzer noch Entwickler sich sofort auf die neueste Microsoftplatform stürzen.

Ergänzung (18. November 2020)

Nutzt man aber zB QT oder WPF, müssen zuerst die ganzen Bibliotheken des Frameworks geladen werden. Und man hat dann bei der Ausführung viele Sprünge in die Funktionen des Frameworks. Das macht die Sache langsam.

Kannst du mal ein Besipiel für eine QT/WPF Software nennen, die wirklich langsam ist - Idealerweise, wo sich das auch wirklich auf das Framework zurückführen lässt?

Ich hab Qt bisher nur für ein paar simple GUIs genutzt (Wrapper um irgendwelche Kommandozeilentools oder um mit nem embedded device zu sprechen) und zumindest da war der Start immer gefühlt Verzögerungsfrei also wohl zumindest deutlich unter ner halben Sekunde. Denkst du evtl. eher an electron apps?

 

[conspectumortis]

Unfassbar was da Apple an Technologie hingezaubert hat und wenn es erst nativ unterstüzt wird. Ich habe schon viele Videos gesehen, auch mit WoW (Rosetta) auf einem MacBook Air M1. Das Ding lief ohne zu Murren in nativer Auflösung.

 

[karamba]

Ist die Mac Fraktion größer als das Potenzial für eine ordentliche Linux Version? Jahrelang muss man hier mit Wine darben 🤔

Ich könnte mir vorstellen, dass Apple das auch sponsert. Genug Geld auf der hohen Kante haben sie ja.

 

[7H0M45]

Was für Tests denn?
Wie schnell der Browser öffnet mit Stoppuhr?
Wie schnell 7zip 8gb zusammenpackt?

Ja im Grunde genau das. Man kann aber natürlich jetzt auch so tun als wäre das totaler quatsch!

Wenn es in den Anwendungsprogrammen sinnvolle Benchmarks gibt, kann man die ja durchaus nutzen. Aber wir wissen ja alle das CPUs gerne mal auf bestimmte Benchmarks tatsächlich hinoptimiert werden.

Wenn ich jetzt ne x-beliebige Videospur mal umwandeln lasse. Oder ein beliebiges Zip wandeln lasse oder Musik schneiden oder ...

Es geht ja nicht darum welche CPU 0,x% schneller besser ist. Es geht darum wie sich das ganze in der Praxis auswirkt

Da gibts sicher das ein oder andere was man machen kann