News Geekbench: Apples M3 Max schlägt den Snapdragon X Elite teils deutlich

[mae]

Was qualcom braucht ist apples Mogel-Packung,
was ich damit meine, die apple chips schalten auf ein x86 memory model um wenn code in rosetta 2 ausgeführt wird, das spart massiv an memory barier instruktionen.

Nur weil der Apple-Prozessor dann nicht so schlecht arbeitet wie ARM das erlaubt, ist das noch lange keine Mogelpackung. Auch ARM erlaubt, dass ARM-Implementierungen besser funktionieren (das liegt bei den memory models in der Natur der Sache). Dass auf der anderen Seite Rosetta nur auf Prozessoren richtig funktioniert, die ein mindestens so starkes memory model implementieren wie Apple, AMD und Intel, kann man Apple vielleicht vorwerfen, aber da Rosetta ohnehin nur auf MacOS auf Apple-Hardware arbeitet, waere so ein Vorwurf schwachsinnig.

Allgemein wird jeder Hardware-Hersteller, der Intel und AMD abloesen moechte, mindestens so ein starkes Memory Model implementieren muessen, weil nur dann koennen Hersteller von multi-threaded Software die Software mit einfachem Neucompilieren portieren. Das betrifft sowohl die Server als auch Desktops und Laptops. Auch wenn man schon in der Cloud Server mit ARM-Prozessoren sieht, dann haben die entweder ein mindestens so starkes Memory Model implementiert wie AMD und Intel, oder es laeuft eben nur ein Teil der Software drauf (wohl vorwiegend single-threaded-Programme, eben viele davon parallel).

Ergänzung (5. November 2023)

Kommt diese hohe Leistung eventuell durch Verfahren, die Intel etc durch Spectre und Meltdown ggf einschränken musste und darum starke Leistungseinbußen hatten?

Ich weiss nicht viel ueber Geekbench, aber ich vermute, dass das nicht besonders viele System calls macht und daher viele Mitigations, die beim User->Kernel-Uebergang den branch predictor loeschen u.ae., Geekbench nicht besonders betreffen. Und Geekbench selbst wird die Mitigations ziehmlich sicher nicht verwenden (man kann also die Daten von Geekbench mittels Spectre-Exploits auslesen), weder hier noch dort. Das waere einmal ein Spass, einen Geekbench mit allen von Intel, AMD etc. empfohlenen Software-Mitigations mit der Version ohne Mitigations zu vergleichen.

Ist der M3 eventuell auch dagegeben anfällig dadurch und muss Apple dann diese Leistungseinschnitte auch vornehmen und liegt dann wieder weit zurück?

Ich gehe davon aus, dass Apples Mikroarchitekturen und der Oryon anfaellig fuer Spectre sind, denn sonst haetten sie das sicher laut herausposaunt, dass sie einen richtigen Fix eingebaut haben. Und klar kosten die diversen Mitigations auch auf Apple und Qualcomm-Hardware Leistung; wieviel, haengt von der Mitigation und der Anwendung ab.

Denn eine Spectre Lücke ist ja erst kürzlich bekannt geworden, die nach fast einen Jahr immer noch nicht offizell gefixt war

Spectre v1 und v2, das Intel und AMD im Juni 2017 bekannt gemacht wurde (und im Jaenner 2018 oeffentlich), ist auch noch nirgendwo gefixt. Es schaut so aus, als waeren die Hardwarehersteller damit zufrieden, dass sie eine Software-Mitigation-Empfehlung bekanntgeben, und dann kaum eine Software der Empfehlung folgt, weil es entweder extrem aufwendig in der Software-Entwicklung ist oder sehr viel Performance kostet (z.B. Ultimate Speculative Load Hardening gegen Spectre v1 kostet einen Faktor 2.5, wenn man es allgemein anwendet; und die selektive Anwendung ist sehr aufwendig, und wenn man zu selektiv ist, bleiben Luecken zum Ausnutzen durch Spectre-Exploits offen). Offenbar sind die Hardware der Meinung, dass es ihnen im Markt mehr Nachteile (ein bisschen mehr Hardware-Flaeche und vielleicht ein paar % weniger Performance fuer Software ohne Mitigations) bringt als Vorteile ("Kaufen sie eine CPU, die gegen Spectre sicher ist!"), wenn sie Spectre in der Hardware fixen.

Ergänzung (5. November 2023)

Ich gehe davon aus, dass Apples Mikroarchitekturen und der Oryon anfaellig fuer Spectre sind, denn sonst haetten sie das sicher laut herausposaunt, dass sie einen richtigen Fix eingebaut haben.

Und kaum habe ich das geschrieben, lese ich ueber iLeakage, ein auf Spectre basierender Exploit von Safari (auf Apple Silicon).

 

[Sebbi]

denn sonst haetten sie das sicher laut herausposaunt,

naja herausposaunt haben die es nicht gerade ... sondern eher kleinlaut zugegeben nach Bekanntgabe, das es da eine Lücke gibt.
Zudem wurde auch gesagt, das der "Fix" nicht standardmäßig aktiv , sondern deaktiviert ist wegen starken Unstabilitäten.
Das ist in meinen Augen kein Fix sondern sagen wir mal ne Beruhigungspille an die Kunden.

Das waere einmal ein Spass, einen Geekbench mit allen von Intel, AMD etc. empfohlenen Software-Mitigations mit der Version ohne Mitigations zu vergleichen.

Spectre v1 und v2, das Intel und AMD im Juni 2017 bekannt gemacht wurde (und im Jaenner 2018 oeffentlich), ist auch noch nirgendwo gefixt.

die Sache ist ja die, das Änderungen auch in den Microcode eingeflossen sind bei Intel und AMD. so das es zwar eine Software-Mitigations am ende darstellt, das eine Deaktivierung gar nicht so möglich ist. Und diese Microcode Updates kommen bei Windows z.B. über das Windowsupdate mit.
Dies scheint aber bei Apple aber offenbar nicht der Fall zu sein.

Aber ja, komplett gefixt werden kann so eine Hardware Sache wohl nicht, aber immerhin besser als wenn gar nichts unternommen wird.

 

[Trelor]

Nur weil der Apple-Prozessor dann nicht so schlecht arbeitet wie ARM das erlaubt, ist das noch lange keine Mogelpackung. Auch ARM erlaubt, dass ARM-Implementierungen besser funktionieren (das liegt bei den memory models in der Natur der Sache). Dass auf der anderen Seite Rosetta nur auf Prozessoren richtig funktioniert, die ein mindestens so starkes memory model implementieren wie Apple, AMD und Intel, kann man Apple vielleicht vorwerfen, aber da Rosetta ohnehin nur auf MacOS auf Apple-Hardware arbeitet, waere so ein Vorwurf schwachsinnig.

Beide Memory Modelle verhalten sich in der Praxis sehr ähnlich. (sind halt nur eben nicht 1 zu 1 identisch)
Besser ist da keines von beiden. Ausherhalb von Rosetta nutzt Apple da natürlich das normale ARM Modell.

@StefanDW
Geekbench benchmarkt einfach eine Auswahl der am meisten benutzten Code libraries.
Die bottlenecks die dadurch auftreten (Speicherlatenz, Latenz zwischen den Kernen, fehler bei der Sprungvorhersage, Cache misses, ..) hast du auch in normalen Anwendungen.

Cinebench, Blender und andere CPU Grafikrenderer wäre da das andere extrem. Da werden solche Bottlenecks weitgehend umgangen (deswegen bringt hier ein größerer Cache z.B. nichts). Diese Art workload lässt sich von der CPU sehr leicht vorhersagen.

 

[mae]

die Sache ist ja die, das Änderungen auch in den Microcode eingeflossen sind bei Intel und AMD. so das es zwar eine Software-Mitigations am ende darstellt, das eine Deaktivierung gar nicht so möglich ist.

Je nach Luecke. Bei den meisten stellt das Microcode-Update nur die Moeglichkeit bereit dass das Betriebssystem etwas tun kann, das bei der "mitigation" hilft. In dem Fall kostet das Update selbst keine Performance, sondern nur im Zusammenhang mit den Mitigations im Betriebssystem. Aber es bringt auch recht wenig. Jede Software, die diese Mitigations nicht eingebaut hat, ist anfaellig, und die Mitigations selbst sind, wie beschrieben, entweder extrem aufwendig oder kosten extrem viel Performance.

Dann gibt's auch noch Faelle, wo man einfach ein Performance-Feature im Microcode abschaltet; WIMRE hat Intel das vor kurzem bei Downfall gemacht. Da ging's weil eh nur wenig Software die Gather-Befehle einsetzt, die betroffen waren. Das ist dann ein richtiger Fix, da braucht's dann keine Software-Mitigations mehr, dafuer verliert die Software, die die Gather-Befehle einsetzt, eben einen Performance-Vorteil.

Was ich aber meinte, sind richtige Hardware-Fixes, die die Luecken schliessen (und zwar ohne Software-Mitigations zu benoetigen), aber die Performance-Vorteile der spekulativen Techniken so gut wie moeglich erhalten. Ja, das ist moeglich, und da gibt's auch schon eine Reihe von Arbeiten dazu. Wenn Intel, AMD, ARM, Apple, oder Qualcomm wollten, haetten sie m.E. schon Hardware herausgebracht, auf der die meisten, wenn nicht alle Luecken schon geschlossen sind.

Ergänzung (5. November 2023)

Beide Memory Modelle verhalten sich in der Praxis sehr ähnlich. (sind halt nur eben nicht 1 zu 1 identisch)
Besser ist da keines von beiden.

Ich habe mich nicht so genau damit beschaeftigt, aber die Informationen, die ich habe, sind, dass IA-32 und AMD64 fuer die haeufig gebrauchten Befehle ein strong consistency model verwendet, und ARM ein weak model; Und wenn ich mir die Tabelle hier anschaue, wo bei "x86" und "AMD64" fast alles weiss ist (also die Hardware nur wenig umordnen darf) und bei ARMv7 fast alles rosa (wo also die Hardware alles Moegliche umordnen darf und die Software den Schlamassel ausbaden muss, indem memory barriers o.ae. eingefuegt werden), sind die ueberhaupt nicht aehnlich. ARMv8-A und ARMv9-A sind in der Tabelle nicht drinnen, vielleicht ist ARM bei denen von weak zu strong konvertiert (wuerde mich aber eben nach allem, was ich so drueber gehoert habe, wundern).

Bezueglich besser:

Ich empfinde strong memory ordering besser (ideal ist sequential consistency), weil man dafuer leichter multi-threaded Software schreiben kann.

Hardware-Hersteller empfinden wohl weak memory ordering als besser, weil sie dann wenig Aufwand in die Implementierung stecken muessen und trotzdem fuer single-threaded software effizient sind. Und bei multi-threaded software haben sie den Aufwand einfach auf die Software-Entwickler abgeschoben (der klassische Supercomputer-Ansatz; dort kommen die weak memory models auch daher); und wenn das Ergebnis langsam ist, schiebt man die Verantwortung auch auf die Software.

Egal, was man als besser empfindet, solange die ARMs (ob von ARM, Apple, oder Qualcomm) nicht ein mindestens so starkes memory model wie AMD64 hat, wird es ein Wahnsinnsaufwand sein, multi-threaded software auf ARM zu portieren. Den Aufwand werden sich die wenigsten Softwarefirmen antun, also wird ARM nur fuer single-threaded software eingesetzt werden. Apple hat das offenbar erkannt und hat eben auch ein strong memory model implementiert. Und es wuerde mich sehr wundern, wenn nur Rosetta davon Gebrauch macht, und nicht jede Menge andere multi-threaded Software, die von MacOS auf Intel portiert wurde. Und wenn Qualcomm schlau ist, haben sie fuer Oryon ebenfalls ein starkes memory model implementiert. Weil mit einem weak memory model wird eben die Portierung von multi-threaded Software nicht erfolgen (bzw. die Versuche werden scheitern).

 

[Trelor]

Ich habe mich nicht so genau damit beschaeftigt, aber die Informationen, die ich habe, sind, dass IA-32 und AMD64 fuer die haeufig gebrauchten Befehle ein strong consistency model verwendet, und ARM ein weak model; Und wenn ich mir die Tabelle hier anschaue, wo bei "x86" und "AMD64" fast alles weiss ist (also die Hardware nur wenig umordnen darf) und bei ARMv7 fast alles rosa (wo also die Hardware alles Moegliche umordnen darf und die Software den Schlamassel ausbaden muss, indem memory barriers o.ae. eingefuegt werden), sind die ueberhaupt nicht aehnlich. ARMv8-A und ARMv9-A sind in der Tabelle nicht drinnen, vielleicht ist ARM bei denen von weak zu strong konvertiert (wuerde mich aber eben nach allem, was ich so drueber gehoert habe, wundern).

ARM hat in den neueren Versionen gar nichts mehr dazu spezifiziert, da es eh egal ist.
In der eigentlichen Microops Architektur der Hersteller werden die Konzepte wild durcheinander gewürfelt.

Das muss alleine schon geschehen, um so viele SIMD Pipelines überhaupt füllen zu können.
Bei modernen ARM CPUs führt der Decoder auch sehr gerne mehrere Maschinencode Befehle zu einem großen Microops (CISC ähnlichen) zusammen.

Ich habe beruflich recht viel mit Custom MIPS und semi Custom ARM design zu tun, an denen wir in House mit entwickeln. ARM selbst spricht mittlerweile nur noch von memory model compatible to ARMx.x .
Intern hat man sogar zwischen den pipelines andere Möglichkeiten beim memory ordering. Ich habe auch Kollegen die vor ein paar Jahren noch bei Intel waren und von dort ähnliches berichten. ISA Standards sind tod, Kompatibilitätsschichten zur eigenen Architektur außerhalb des Embedded Bereichs die Norm.

Software sorgt leider sehr häufig für Schlammasel bei der Pipeline Auslastung (und weiß auch schlicht nicht welche Microops Befehle in der CPU dann letztendlich existieren). Deswegen zerpflücken Decoder und Coder alles was in die CPU rein und raus geht. Der Decoder wird in aller Regel 2-3 Jahren auf Herz und Nieren geprüft, damit er eben keinen Schlamasel anrichtet.

Apple hat bei den M SoCs die basic X86 Befehle einfach fest im Decoder drin und ist dabei auch zum memory Modell kompatibel. Dann muss Rosetta 2 die nicht mehr umschreiben. Außerhalb von Rosetta 2 nutzt Apple zur Kompatibilität die ganz normale ARM 8.1 ISA.

 

[deekey777]

Werte des M3 Pro in Geekbench 6:
https://www.macrumors.com/2023/11/05/m3-pro-chip-benchmark-result/

Die zwei Performance-Kerne weniger machen sich bemerkbar.