News Geekbench: Apple M4 hat die mit Abstand höchste Single-Core-Leistung

Cr4y schrieb:
Was testet und gewichtet der Geekbench eigentlich? Integer, Floating Point, Speicherbandbreite, Sprungvorhersage? Oder anders gefragt: was bleibt von den 30% mehr im Geekbench bei Alltagsanwendungen übrig?
Der Geekbench will "reale Szenarien" nachstellen und da wird schon alles mögliche berücksichtigt. Wie hoch die einzelnen Punkte gewichtet sind, weiß ich nicht. Man kann sich aber auch die Scores in "Anwendungskategorien" wie Dateikompression usw. anschauen: https://browser.geekbench.com/v6/cpu/6016039

Cr4y schrieb:
Kosten diese Altlasten denn so viel Chipfläche, dass man weniger anderes verbauen kann oder muss moderner Code durch diese Altlasten?
Ja, muss er. Denn jede Anweisung an die CPU kommt ja als Code in die CPU. Dieser Code ist einfach eine Zahl. Zum Beispiel könnte Code "4" bedeuten, dass zwei Zahlen addiert werden sollen. Und durch diese Entscheidung, was gemacht werden soll, muss jeder Code immer. Und je mehr dieser Codes man hat, desto mehr Zeit oder Fläche benötigt man, um diese Codes überhaupt auszuwerten.
Man könnte ja ganz geschickt diese Codes um ein Bit länger machen. Dann sieht man direkt am ersten Bit, ob man einen neuen, schnellen Befehl hat oder einen alten. Aber allein das ist eben ein zusätzlicher Schritt, der danach für jeden Befehl getan werden muss.
Ergänzung ()

bensen schrieb:
Sehe gerade den Zusammenhang nicht. Deklassiert vielleicht bei Single Thread. Aber da ist die TDP ziemlich nebensächlich.
Meinst Du, der i9 würde mit einem kleinen Passivkühler im SingelCore-Benchmark keinen merkbaren Punktverlust haben?
 
  • Gefällt mir
Reaktionen: Strahltriebwerk, Project 2501 und Cool Master
Cr4y schrieb:
Kosten diese Altlasten denn so viel Chipfläche, dass man weniger anderes verbauen kann oder muss moderner Code durch diese Altlasten?

Na ja es ist nicht unbedingt Chipfläche die man per se gewinnt sondern wie man Sachen anordnet. Bei x86 muss(!) das nach dem Muster A, B, C, D, .... passieren, da es sonst kein x86 ist. Da man bei ARM oder anderen neuen Architekturen nicht daran gebunden ist kann man ein völlig anderes Muster nehmen wie A, Z, F, H, ... wenn dies besser ist. Paart man diese Neuerung nun mit modernem Code ist das ein Erfolgsrezept.

Aber ja Altlasten bremsen Innovationen bei x86. Wenn du z.B. ein 64 Bit OS hast und wirklich nur 64 Bit Apps, warum brauchst du 32 Bit oder 16 Bit Kompatibilität? Das ist dann unnötiger Platz auf dem Chip weil aus 1000 Käufer das ggf. 10 brauchen und das steigert sich halt mit alten Befehlserweiterungen ebenfalls. x86 ist halt der "Ich kann alles dafür nicht super effizient." und ARM oder andere Architekturen der "Ich kann vieles dafür aber sehr effizient.". Das ist z.B. auch was ich super bei Apple finde, dass die vor ~10 Jahren gesagt haben wir machen unser OS nur noch 64 Bit (glaube Lion), ja das wird einige Apps töten wenn sie nicht aktualisiert werden aber damit können wir leben und ich finde es war super und das müsste Windows auch tun. Damit wären auch viele Altlasten weg und eine Optimierung auf Win on ARM wäre schneller.
 
  • Gefällt mir
Reaktionen: Bullz, Project 2501, tomasvittek und 11 andere
incurable schrieb:
Wenn ich mich nicht irre sind die 29xx/15xxx Punkte für ein "Hochleistungs"-Gerät mit 16,8mm Dicke, 80W Maximalverbrauch und aktiver Kühlung vorgeführt worden.
Die 23 W Werte von CB waren 2765/13950.
 
  • Gefällt mir
Reaktionen: Project 2501, Benjamin_Blume und incurable
AthlonXP schrieb:
Weshalb performt Apple bei Multi-Thread nicht so gut? Liegt es nur an der Kernanzahl, oder ... ?
"Nicht so gut" heißt ja immer noch schneller als sehr viele Desktop-CPUs auf dem Markt.
Aber konkret bezogen auf den Core i9-14900K: Deutlich mehr Kerne und wahrscheinlich Faktor 10 mehr elektrische Leistung bzw. Abwärme, die der Intel sich erlauben kann zeigen dann doch irgendwann ihre Wirkung.

Cool Master schrieb:
Ganz einfach keine Altlasten. M-Chips sind 64 Bit only und haben keine andere Altlasten wie x86 die noch Code aus 1970 ausführen können.
Ich bezweifle ja wirklich dass da irgendwas "Ganz einfach" ist. Diese Altlasten haben sicher ihren Preis, aber jedesmal, wenn ich versuche dazu im Internet Schätzungen oder sogar konkrete Zahlen zu finden heißt es im Prinzip immer, dass die Altlasten eigentlich nur nen relativ kleinen Overhead ausmachen. Die AVX Rechenwerke, Sprungvorhersage und erst recht Caches brauchen auf nem "großen" x86 Prozessor scheinbar einfach um Größenordnungen mehr Platz und Strom, als alles was nötig ist um die alten 16 und 32 Bit Operationen zusätzlich auch noch zu supporten. Was ja irgendwo auch Sinn macht, wenn man bedenkt, dass ein kompletter Pentium 4 Prozessor wahrscheinlich weniger als 5% der Transistoren eines modernen i9 benötigt.

Ist wie schon gesagt, nur Hörensagen und natürlich ist es von außen schwer zu beurteilen, inwiefern diese Rückwärtsstabilität Intel auch beim Design und Optimieren von modernen Features behindert. Trotzdem scheint mir das zumindest nicht die ganze Geschichte zu sein.

bensen schrieb:
Sehe gerade den Zusammenhang nicht. Deklassiert vielleicht bei Single Thread. Aber da ist die TDP ziemlich nebensächlich.
Auch Single Threaded braucht der Intel vermutlich ein mehrfaches der Leistung des M4.
 
  • Gefällt mir
Reaktionen: Project 2501, Flutefox, eigsi124 und eine weitere Person
Haggis schrieb:
Meinst Du, der i9 würde mit einem kleinen Passivkühler im SingelCore-Benchmark keinen merkbaren Punktverlust haben?
Meinst du eine Apple CPU mit dem ganzen IO und Interconnect für 8+16 Kerne den gleichen Verbrauch haben?
Das sind einfach völlig absurde Vergleiche.
Ergänzung ()

Miuwa schrieb:
Auch Single Threaded braucht der Intel vermutlich ein mehrfaches der Leistung des M4.
Siehe oben. Das sind völlig andere CPUs mit anderem Design-Ziel. Es macht wenig Sinn CPUs mit weit höherer TDP zu nehmen und sich dann über tolle Effizienz zu freuen. Wenn man die TDP des M4 verdoppelt, ist die Effizienz auch dahin.
 
  • Gefällt mir
Reaktionen: Deinorius
Wo wird der Snapdragon X Elite überhaupt verbaut? Ich würde gern solch ein Gerät mal kaufen.
 
  • Gefällt mir
Reaktionen: dualcore_nooby
@Zanza

Samsung Galaxy Book4 Edge, welches "bald" kommen soll.
 
AthlonXP schrieb:
Weshalb performt Apple bei Multi-Thread nicht so gut? Liegt es nur an der Kernanzahl, oder ... ?
Nein, hier wird schlicht ein passiv gekühltes 5,1mm Tablett mit einem 16,8mm Hochleistungsreferenzgerät mit aktiver Kühler verglichen. 🤷‍♂️
 
  • Gefällt mir
Reaktionen: Project 2501, eigsi124, -Stealth- und 2 andere
KlaasKersting schrieb:
Die Ergebnisse waren bei den bisherigen Apple M-CPUs auch weitestgehend reproduzierbar.
Eben nicht. Im Cinebench sieht die Welt wieder ganz anders aus. Von Notebookcheck:

Cinebench R23 SingleCinebench R23 Multi
14900K235141193
7950X200137353
M3 (8c CPU/10c GPU)190010298

Da ist nichts (Multicore) mit Faktor 1,62-1,75 wie hier im Geekbench zwischen M3 und 7950X/14900K. Da reden wir entspannt über Faktor 3,6+.
Zudem waren auch die Abstände im Geekbench 5.5 noch höher (Faktor 2-2,5).

Man darf durchaus getrost anzweifeln, dass der Geekbench 6.2 auch nur ansatzweise ein guter Maßstab ist. Hat eher etwas von Userbenchmark oder so. Bekannt ist auf jeden Fall die übermäßige Affinität für große&schnelle Speicher/Caches (M3: 16+4 MB L2 Cache (für die Perf. + Eff. Cores)).

Die Apple-Cpus sind nicht schlecht, aber die Darstellung im Geekbench zeigt nicht die ganze Wahrheit.

Edit: Hmmm... Hab mir nochmal ein paar Sachen zu Geekbench und Cinebench angeschaut. Da hab ich den Geekbench vllt. doch etwas zu voreilig verurteilt (also zumindest der Vergleich zum Userbenchmark war jedenfalls überzogen). Es ist aber schon so, dass die tlw. sehr unterscheidlichen Cache-Strukturen/Aufbauten bei dem einen Benchmark mehr anschlagen, als bei dem anderen. Man benötigt eben eigentlich mehr verschiedene Benchmarks. Und daher finde ich das alleinige ausrufen der Geekbench-Werte immer etwas zweifelhaft, da in anderen Workloads (eben z.B. u.a. der Cinebench) das wieder anders aussehen kann.
(Der von Nuvia angestellte Vergleich zu SPEC bezog sich lediglich auf die INT-Performance; wobei fairerweise beim End-Score des Geekbenchs INT mit 65% und Float mit 35% gewichtet wird.)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: [F]L4SH, Project 2501, Flutefox und 12 andere
Cool Master schrieb:
Na ja es ist nicht unbedingt Chipfläche die man per se gewinnt sondern wie man Sachen anordnet. Bei x86 muss(!) das nach dem Muster A, B, C, D, .... passieren, da es sonst kein x86 ist. Da man bei ARM oder anderen neuen Architekturen nicht daran gebunden ist kann man ein völlig anderes Muster nehmen wie A, Z, F, H, ... wenn dies besser ist. Paart man diese Neuerung nun mit modernem Code ist das ein Erfolgsrezept.
Den Rechenwerken ist es egal, welche Sprache der Vorbau spricht.
 
  • Gefällt mir
Reaktionen: Project 2501, sigsegv und Piktogramm
Cool Master schrieb:
Na ja es ist nicht unbedingt Chipfläche die man per se gewinnt sondern wie man Sachen anordnet. Bei x86 muss(!) das nach dem Muster A, B, C, D, .... passieren, da es sonst kein x86 ist. Da man bei ARM oder anderen neuen Architekturen nicht daran gebunden ist kann man ein völlig anderes Muster nehmen wie A, Z, F, H, ... wenn dies besser ist. Paart man diese Neuerung nun mit modernem Code ist das ein Erfolgsrezept.

Aber ja Altlasten bremsen Innovationen bei x86. Wenn du z.B. ein 64 Bit OS hast und wirklich nur 64 Bit Apps, warum brauchst du 32 Bit oder 16 Bit Kompatibilität? Das ist dann unnötiger Platz auf dem Chip weil aus 1000 Käufer das ggf. 10 brauchen und das steigert sich halt mit alten Befehlserweiterungen ebenfalls. x86 ist halt der "Ich kann alles dafür nicht super effizient." und ARM oder andere Architekturen der "Ich kann vieles dafür aber sehr effizient.". Das ist z.B. auch was ich super bei Apple finde, dass die vor ~10 Jahren gesagt haben wir machen unser OS nur noch 64 Bit (glaube Lion), ja das wird einige Apps töten wenn sie nicht aktualisiert werden aber damit können wir leben und ich finde es war super und das müsste Windows auch tun. Damit wären auch viele Altlasten weg und eine Optimierung auf Win on ARM wäre schneller.
Ich kenne mich in der Materie ehrlich gesagt zu wenig aus, aber ist es nicht genau das, was Intel ändern möchte mit "x86s" https://www.intel.com/content/www/u...visioning-future-simplified-architecture.html
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Project 2501
Cool Master schrieb:
Ganz einfach keine Altlasten. M-Chips sind 64 Bit only und haben keine andere Altlasten wie x86 die noch Code aus 1970 ausführen können.
Dadurch sind sie in Spezialfällen aber auch wesentlich langsamer.
Der M Chip hat(te) bspw. arge Probleme mit Docker und wurde da von Intel nahezu vernichtet.
 
Elverado schrieb:
Im Cinebench sieht die Welt wieder ganz anders aus.
Cinebench ist noch dümmer. Der testet ja wirklich nur einen ganz spezifischen Anwendungsfall und ist im Zweifel überhaupt nicht praxisrelevant. Die Geekbench Singlecore Werte lassen sich allerdings meist ganz gut mit den Goldstandards von SPEC nachstellen. Siehe der erste Test von Anandtech zu den M1 APUs, wo die extrem abgeräumt haben.
 
  • Gefällt mir
Reaktionen: Darkseth88, Aniwon, Project 2501 und 4 andere
Elverado schrieb:
Man darf durchaus getrost anzweifeln, dass der Geekbench 6.2 auch nur ansatzweise ein guter Maßstab ist. Hat eher etwas von Userbenchmark oder so. Bekannt ist auf jeden Fall die übermäßige Affinität für große&schnelle Speicher/Caches (M3: 16+4 MB L2 Cache (für die Perf. + Eff. Cores)).
Daraus könnte man aber auch den anderen Schluss ziehen und sagen, dass Cinebench weniger aussagt als Geekbench.
 
incurable schrieb:
Den Rechenwerken ist es egal, welche Sprache der Vorbau spricht.
Wenn ich es richtig verstehe, muss der Vorbau halt ordentlich liefern, um nicht der Flaschenhals zu sein. Könnte schon sein, dass eine hohe Komplexität aufgrund von vielen Prüfungen eben länger braucht, und daher nicht so effizient arbeiten kann. Aber wie viel % das ausmacht...
 
Der M4 setzt wohl auf ARMv9, damit auf SME, was bei einem der Geekbench Tests einfach mal die doppelte Leistung bringt. Lässt man den Test drin sinds 9% IPC, lässt man ihn weg sind 3% IPC.
 
estros schrieb:
Das ist doch Quatsch. Eine hohe SC Leistung ist die Basis einer guten CPU. Immer und überall. Denn nur wer eine hohe SC Leistung besitzt, ist auch stark in zwei und vier Threads. MC Leistung ist hingegen für jeden Anwendungsbereich skalierbar. Daher gehört Big.Little in vielen Bereichen die Zukunft.
Es gibt immer verschiedene Level von gut und skalierbar. Und in Single Core Anwendungen ist der Apple Silicon nunmal schneller, da bringt auch skalierbare MC Leistung nichts
 
Bin ein wenig angefressen darüber, dass es den "vollen" M4-Chip sowie 16GB Ram erst ab der 1tb-Version gibt.

Das Apple die gebinnten Chips irgendwie verwenden will/muss verstehe ich, aber wenn ich das Ding wieder so lange verwende wie mein bisheriges 11"-ipad-pro von 2018, könnte gerade der größere Arbeitsspeicher die Nutzungszeit stark verlängern (selbst wenn 8gb unter iPadOS für alles was nicht high-end-Videobearbeitung ist derzeit ausreichen sollte).
Aber 1tb ist eigentlich Overkill für das, was ich mit dem Tablet so anstelle und der Aufpreis hat es in sich.
 
  • Gefällt mir
Reaktionen: [F]L4SH, Project 2501, StefanSch87 und 2 andere
Sagt leider überhaupt nichts aus. Ein M4 ist niemals so schnell wie ein 14900K(S) oder 7950X(3D) in deren Universum, sondern eben in seinem eigenen.

Bezogen auf ARM ist die Leistung aber mal wieder enorm.
 
  • Gefällt mir
Reaktionen: Whetstone, Project 2501 und Ja_Ge
@NonOptionalName sehe ich ähnlich, hätte auch gedacht das der Ram ansteigen wird, aber wenn man sich die Macbooks anschaut, dann ergibt das schon Sinn. Wer weiss welchen Weg Apple softwareseitig mit den iPads noch gehen wird und wenn man jetzt auf 8gb setzt und Apple iPad OS weiter Richtung MacOS öffnet, dann erscheinen 8Gb doch wenig. Apple tut sich mit seinem Verhalten und der halbgaren Software vom iPad keinen Gefallen, insbesondere bei den Preisen. Aus meiner Sicht hätte es die 16gb bereits bei 512gb geben müssen. Aber die 40% Umsatzrendite kommen nicht von ungefähr.
 
  • Gefällt mir
Reaktionen: StefanSch87 und Wizard of Wor
Zurück
Oben