News Geekbench 7: M6 lässt den Ryzen 9 9950X3D2 weit hinter sich

ich hätte gedachte das man mit claude sowas beschleunigen könnte, aber so einfach ist es tatsächlich nicht
 
Nur mal nebenbei, ein Mac Studio mit 96GB RAM und 1TB SSD (weniger geht nicht) und dem großen M5 Ultra mit 80 Kernen kostet 8029€...
 
Ich persönlich nutze zwei Mac Minis (M2 und M4) und einen MacBook Air (M3), stelle aber fest, dass ich beim Desktop doch hauptsächlich meinen PC nutze...warum? weil dort eine RTX 4090 Graka drin steckt und diese schon mal öfter sowohl für Gaming als auch für lokale KI-Geschichten benutzt wird...an meinem Verhalten würde auch ein künftiger Neukauf mit M6 nichts ändern, schon seltsam... 😉
 
Okay, meinen Prozesser lässt der neue M6 alt aussehen und an meine GPU kommt er nicht im Ansatz dran... spannend. Kommt bei mir jetzt also auf den genauen Task drauf an und ob dieser sequentiell oder parallel arbeitet bzw. arbeiten kann. Obwohl ich Apple noch nie was abgewinnen konnte (bis auf mein Dienst-iPadpro und Dienst-iPhoneSE), diese M-Chips basteln sie jedes Jahr ordentlich hin.
 
Easy1991 schrieb:
In den Bereich ist es Silizium und Flächen Verschwendung, da Leistung mehr zählt als paar watt einzusparen, okay im mobilen Bereich nicht aber in einer Workstation schon
Wenn wir Apple, Qualcomm, Intel, AMD oder ARM nehmen, dann sind die mittleren und oftmals selbst die kleinen Out of Order Kerne mittlerweile allesamt recht mächtig. Die mittleren Cores sind mittlerweile oftmals ~6fach superskalar und können 4x 128bit bzw. 2x 256bit Vectoreinheiten nutzen. Das liefert schon ganz ordentlich Durchsatz und ist weit weg von Langsam.

Zudem, die großen Kerne schaffen es bei vielen Workloads sowieso nicht im Mittel mehr als 4 Befehle/Takt auszuführen[2]. Entsprechend lohnt es auch nur sehr bedingt die Anzahl an fetten Kernen zu erhöhen. Mehr mittlere/kleine Kerne bringen da oftmals mehr.


Diablokiller999 schrieb:
Das ist mir alles zu undifferenziert betrachtet, ich habe manchmal echt das Gefühl Apple optimiert gegen Benchmarks um 'ne Show abzuziehen.
Die Apple Prozessoren sind durchweg schnell. Selbst beim viel gescholtenem Geekbench kommen durchweg Bibliotheken zum Einsatz, die in der freien Wildbahn etabliert sind.

Diablokiller999 schrieb:
Letztlich hat auch Apples Architektur Schwächen, das breite RAM Interface frisst Unmengen an Platz auf dem Die und ist als IO schwer zu shrinken.
Wer kennt es nicht, die Auswahl des Prozessors/SoC über den Filter bei Geizhals: "Anteil an Chipfläche die für Memory PHY verschwendet wird:"

Zudem die Memory PHY für Speicher auf dem selben Interposer deutlich kleiner ausfallen kann, als PHYs die die Übertragungsverluste gesockelter Prozessoren, gesteckten RAM überwinden müssen. Konsequent solltest du diese Kritik also ab jetzt so unter jeden Artikel über gesockelte CPUs setzen ;)

Diablokiller999 schrieb:
Apple hat dadurch eine vollkommen andere Cache Struktur mit riesigem L1-Cache, großen Shared-L2 und einen System Level Cache vor dem RAM um CPU/GPU Zugriffe auf den RAM möglichst zu verhindern.
Dadurch? Die Größe der Caches hat mit dem Speicherinterface wenig zu tun. Die großen L1 Caches kommen vor allem daher, dass Apple von den 4KB Pages abgerückt ist und 16KB Pages nutzt. Damit wird mit annähernd konstantem Verwaltungsaufwand/gleichbleibenden Latenzen der L1-Cache "einfach" um Faktor 4 größer. Analog gilt das für den L2-Cache.
Ja, Caches sind dazu da um Zugriffe auf den Arbeitsspeicher zu vermeiden. Bei jeder CPU mit entsprechenden Caches ist diese Aussage wahr -.-

Diablokiller999 schrieb:
Apple hat bei ARM den Vorteil der festen µOP Größen, die können sich einen riesigen Decoder sparen weil jeder Befehl eine feste Länge hat. AMD/Intel brauchen hier einen fetten Decoder mit Cache. Dazu kann Apple einfach weit im Voraus dekodieren durch einen riesigen Reorder Buffer für Out-of-Order, kann x86 zwar auch aber der Buffer ist wegen CISC wieder schwerer zu managen (Mehr Fläche, mehr Strombedarf).
Die E-Cores bei Intel kommen ohne µOp Cache aus und schaffen ganz gut Durchsatz bei deutlich veringerter Komplexität der Decoder ;). Die µOp Caches bracht es also nicht zwingend bei x86.
Der Reorderbuffer für x86 sieht nur µOps und die sind eher RISC als CISC. Entsprechend ist das Reordering bei X86 ähnlich Komplex wie unter ARM.

Diablokiller999 schrieb:
Die Sprungvorhersage ist dafür bei x86 nochmal mächtiger, da x86 Kerne aber auch gerne mal mit 6GHz takten sind Pipeline Flushes auch kostspieliger. Dadurch hat x86 aber die bessere Vorhersage und Speculative Execution, was für (meiner Meinung nach schlechten) Code mit vielen Verzweigungen ein Seegen ist und viele Miss-Predictions durch den µOP-Cache ausgleichen. Der hohe Takt ist bei einer Penalty doof, weil Cache-Misses lange auf RAM warten müssen und der wird in zweistelligen Nanosekunden gemessen.
Da verhaust du aber Dinger..
Die Frequenz einers Prozessors ist garnichtmal der ausschlaggebende Punkt wieso es gute Branchprediction braucht. Das Ziel ist es die Ausfürungseinheiten auszulasten. Wenn man Prozessoren baut, die in Theorie 8..10 OPs/cycle baut, sollten die auch sinnvolle Arbeit tun. Wenn die Ausführungseinheiten die ganze Zeit spekulativ Berechnungen durchführen, diese aber verworfen werden, weil es eine Falschvorhersage beim Sprung gab, dann ist dass maximal ineffizient. Entsprechend brauchen alle massiv superskalaren Prozessoren potente Sprungvorhersageeinheiten.
Wenn ein Prozessor halbwegs Durchsatz hat (haben die Dinger von Apple), dann haben die mächtige Sprungvorhersagen.

An sich ist das das Problem Intels NetBurst Architektur in anderer Form. Die wurden mit Pipelines und vielen Stages auf hohe Frequenzen getrimmt. Wobei die langen Pipelines mit spekulativer Ausführung gefüllt wurden wenn immer es ging. Bei Falschvorhersagen mussten die spekulativ ausgeführten Rechnungen verworfen werden. Vielleicht hast du daher das Ding mit der Frequenz. Was so nicht mehr relevant ist, da bei modernen CPUs so lange Pipelines nicht mehr verwendet werden.

Diablokiller999 schrieb:
Zudem hat x86 bei Single-Threaded Workloads durch den hohen Takt die Nase vorn
Schreibst du unter einen Artikel, wo die Benchmarks Gegenteiliges zeigen.

Diablokiller999 schrieb:
AVX-512 / AMX Workloads kann Apple nicht da sie keine Einheiten dafür haben
Die Vectorbefehle bei ARM sind etabliert, und heißen schlicht anders. Apples M1 hatte von Anfang an eine Matrixerweiterung: https://www.realworldtech.com/forum/?threadid=198706&curpostid=198706
Die war undokumentiert, aber zugänglich. Bei neueren Apple Prozessoren offiziell (ARM macht Vorgaben, wenn man Features implementiert, die außerhalb der ARM Spec liegen (zB Armv8.2), dann ist das als propritäre Erweiterung zu behandeln).

Ansonsten haben ARM Prozessoren seit Ewigkeiten ARM neon und mittlerweile auch schon Länger ARM SVE(2) für Vektorbefehle.

Wobei die großen Kerne beim Apple M5 4x 128bit Neon/SVE (Vector) können und 512b x 512b SME2 (Matrix) können. Was auch einer der Gründe ist, wieso die Apple Prozessoren bei den Geekbench beim den Vektorlastiken Teiltests sehr gut dastehen.

Diablokiller999 schrieb:
, der große L3-Cache hilft bei unvorhersehbaren Speicherzugriffen enorm (Spiele, Datenbanken) was bei Apple RAM-Latenz verursacht.
Hast du eigentlich Quellen für das was du hier schreibst? Wäre mir jetzt neu, dass Apple Si bei irgendwelchen Aufgaben auf einmal schlecht dastünde.

Diablokiller999 schrieb:
Auch wird kein Cache für GPU Daten gebraucht, da x86 dedizierte GPUs unterstützt und die das selbst managen. Jedes Byte im L3-Cache ist also für die CPU.
Als gäbe es keine iGPUs in der x86-Welt. Wobei es schon sehr praktisch ist, CPU und GPU aus dem selben Speicher zu bedienen. Unified Memory und Datenaustausch via ZeroCopy[1] ist schon sehr elegant.

[1] Das war Stand der Technik für die x86-Welt und ARM lange bevor Apple "Unified Memory" herausgestellt hatte. Selbst Macs mit Intel Haswell konnten das schon..


ecth schrieb:
Ich finde die Benchmarks seltsam herausgepickt. Ist der X3D bei den normalen synthetischen Workloads nicht langsamer, als ein "normaler" 9950X? Wenn wir von 36 Kernen reden, wäre dann nicht ein Vergleich mit einem Epyc mit 32 Kernen spannender?
Scr1p schrieb:
Geil, wieder ein synthetischer Test für Apples übermächtige Hardware
OpenSystemFan schrieb:
Wenn du, aus irgend einem Grund, Geekbench gauptberuflich testest
[2] https://chipsandcheese.com/p/evaluating-geekbench-6
blablabla synthetischer Benchmark. Wenn man halbwegs verstehen würde, was der Geekbench abbildet, würde man sowas nicht schreiben.
Ein Prozessor, der im Geekbench liefert, hat gute Chancen im Alltag auch gut dazustehen.

end0fseven schrieb:
Der Bootloader ist meines Wissens ja nicht das Problem.
Naja, der Bootprozess ist schon hacky bei Asahi und geht gelegentlich kaputt, wenn Apple selber etwas ändert. Die Writeups wie die Apple M1 initial überhaupt dazu gebracht wurde etwas andere als MacOS zu booten waren spannend.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: klausk1978, input_iterator, sikarr und 2 andere
Apple war für mich die letzten (20?) Jahre nur einer von vielen PC-Zusammenlötern, die halt Intel Chips verbaut haben mit Standardhardware zum Premiumpreis. Überlebt haben die durch ihre Telefone.
Mit ihren M Chips sehe ich die Sache anders.
Eine richtige Alternative zum Desktop Einheitsbrei: Schnell und stromsparend, nice!
Ein Freund ist richtiger Apfelfan, kann nichts mehr dagegen sagen mittlerweile^^
Wir reden hier über einen SoC mit richtig dicker Grafikleistung. Wirklich gelungen.
 
  • Gefällt mir
Reaktionen: klausk1978
Syntax_41 schrieb:
Wenn Apple jetzt ne Konsole rausbringen würde...
Ja ich frage mich wie viel mehr dann eine PS5 oder 6 oder die nächste XBox mehr im Vergleich zu einem AMD Soc kosten würde?
 
  • Gefällt mir
Reaktionen: SweetOhm
Weckt mich, wenn ich mir das OS auf einem Gerätmit M-Prozessor frei aussuchen darf.
 
  • Gefällt mir
Reaktionen: smashbrot
end0fseven schrieb:
Der Bootloader ist meines Wissens ja nicht das Problem. Du kannst ja bereits Linux auf einem M-Prozessor Mac installieren. Nur muss das von den Linux Leuten Reverse Enginierd werden da Apple keine Treiber gibt.
Aktuell geht's nur mit dem M1 und M2. Mit Kernel 7.3 kommen Änderungen, die M3-Support ermöglichen.

Omarchy bzw. die Omacom Foundation kann hier evtl. einiges beschleunigen, weil sie finanziell gut aufgestellt sind und es jede Menge Interesse gibt, Omarchy auch auf aktuellen MacBooks lauffähig zu machen. Ein signifikanter Teil der User sind Umsteiger, die zwar gerne Apples Hardware hätten, aber keine Lust mehr auf macOS haben.
 
Piktogramm schrieb:
[2] https://chipsandcheese.com/p/evaluating-geekbench-6
blablabla synthetischer Benchmark. Wenn man halbwegs verstehen würde, was der Geekbench abbildet, würde man sowas nicht schreiben.
Ein Prozessor, der im Geekbench liefert, hat gute Chancen im Alltag auch gut dazustehen.
Na dann. Wo sind dann die ganzen Apple M Supercomputer, Serverfarmen und KI Zentren. Seltsam. Aber hab wohl keine Ahnung.
 
@Scr1p

Dafür fehlt in Apples Ökosystem noch sehr viel und kostenmäßig dürfte dies auch nicht unbedingt konkurrenzfähig sein. Apple nutzt sehr viel und sehr kostspielige Chipfläche in ihren Chips.

So ein M5 Ultra hat mal eben je nach Quelle 210–240 Milliarden Transistoren.
Der Chip der RTX 4080 (AD103) kommt auf ~46 Milliarden und der Ryzen 9950X auf ~20 Milliarden.

Dazu kommen noch ein teurer Node und deutlich teureres Packaging zum Einsatz.
Viel hilft bei Apple viel, kostet aber nunmal auch Geld.
 
STM64 schrieb:
Der Kopierschutz der Dreamcast wurde durch eine Funktion der Dev-Kits quasi direkt zum Launch geknackt.
Der Verbreitung hat es nicht geholfen.
Also genau das Gegenteil :D Na dann.
 
Zurück
Oben