Es scheint erste Benchmarks des M4 zu geben:

Single-Core Score: 3800
Multi-Core Score: 14500
Metal Score: 53000

Durchaus beeindruckend.

Zum Vergleich iPad M2:
Single-Core Score: 2500
Multi-Core Score: 9600
Metal Score: 45000
(ähnlich gerundet)

entsprich recht genau dem aktuellen MacBook Pro 16-inch, 2023
(Apple M2 Max 12 CPU cores - 8 performance cores and 4 efficiency cores and 30 GPU cores)

Metal GPU Score mit 137768 ist allerdings deutlich besser

Ich stimme zu: Durchaus beeindruckend!

Der Metal Score des M4 hat jetzt grade mal den Score der Radeon 5500XT in meinem iMac 27“ 2020 erreicht…
Da ist GPU-seitig immer noch viel Luft nach oben.
CPU absolut beeindruckend!

Wenn ich score beim iMac 5K allerdings auch nur ganz leicht anfordere, brüllt der Lüfter nahezu sofort los

Das iPad hat keinen Lüfter und ist 5mm dünn - beim alten 24“ könnte man es vermutlich in den CD Schlitz stecken (vom Format abgesehen)

Ja eine, aber stell dir mal den M4 Ultra vor.

News dazu ist jetzt raus – habe die Werte mit den einzelnen M-Generationen verglichen:

Single-Core-Benchmark ist ECHT beeindruckend!

Wirklich eindrucksvoll!

Vielleicht wird ein neuer "großer" iMac einfach ein 32"-6K-Display, in das man ein iPad pro einschieben kann.
– nein, damit lässt sich wohl nicht genug Geld umsetzen...

Gruß, svenski.

Irgendwann wird eh das iPhone diese Aufgabe übernehmen – leg es neben einen Bildschirm+Tastatur+Maus und arbeite dann darauf. Leistung hat es ja schon jetzt genug für viele Tätigkeiten.

Apples Perspektive hast du korrekt erfasst: Wenn die so was wie von dir oder mir vorgeschlagenes umsetzen würden, würde der Umsatz deutlich leiden. Wären wir CEO, hätten wir es aber genau so wie es aktuell ist entschieden – und derartige Projekte auf die lange Bank geschoben

Ja, die Leistung hat es, aber nicht das Betriebssystem ...

Ich frage mich auch manchmal, wie wir „damals“ mit 7-14Mhz Prozessoren und 0,5-2MB RAM überhaupt arbeiten konnten. So Textverarbeitung, Tabellenkalkulation oder sogar mit Grafikprogrammen!!! Gemessen an den heutigen Werten hätte alleine der Start eines Programmes Stunden dauern müssen 🤦🏻‍♂️😅

Naja, damals verstanden Programmierer noch was con ihrem Job. Die mußten ständig Lösungen finden, um mit minimalsten Hardware-Ressourcen (die nicht mal ein Tausendstel heutiger Rechner hatten!!!) potente Programme zu entwickeln. Heute, wo Rechner leistung im Überfluß hatten, wird gequast was nur geht. Überfluß macht faul und bequem. Armut und Knappheit machen erfinderisch. Sieht man heuer an allen Ecken und Enden 🤷‍♂️

BMPBrother
Ich gebe dir recht in einem Punkt recht: Programmierer haben heute nicht mehr den Druck, die möglichst effiziente Software zu schreiben (siehe z.B. Slack, was ja mit Electron läuft – das ist eigentlich eine Webseite. Performance-Mäßig unterirdisch). Der Überschuss an Performance lädt oftmals dazu ein, faul zu werden. Sau viele Apps im App Store sind keine nativen Mac- oder iOS-Apps, sondern Wrapper für Webseiten – natürlich mit miesem Performance-Ergebnis und Speicher-Hunger ohne Ende (sowie auch meist echt beschissene GUI).

Auf der anderen Seite: Mitte der 90er war es einfach nicht möglich, ein Photoshop-Dokument mit kurz mal paar GB Daten zu bearbeiten. Außerdem erledigen Computer ja heute im Hintergrund VIEL mehr Aufgaben, als das früher der Fall war (denk an Spotlight, iCloud-Sync, Foto-Sync, Foto-Erkennung…).

Wo sollte man damals auch ein psd dokument mit ein paar GB herbekommen? Meine erste festplatte war ne quantum eps mit 52MB speicherplatz. Das freut mich die Leute, was ich damit will. Die würde ich doch nie voll kriegen. 😅 mWn wurde das amiga magazin damals komplett mit pagestream aufgelegt, DEM DTP programm auf dem amiga. Und das mußte sich jetzt optisch echt nicht vor modernen magazinen verstecken 🤷‍♂️

Wahr ist, dass heutzutage Programmierer nicht mehr so stark auf Performance achten müssen - sonst hätten sich Sprachen wie Java nicht halten können. Ähnliches gilt für Apps, die Frameworks wie Electron nutzen, um mit Web-Technologien (Javascript) auf einem Desktop laufen zu können. Die Rechner seien ja performant genug, dass man auf Resourcen nicht so achten muss.

Was man aber auch bei nativen Apps berücksichtigen muss: die Systeme sind viel stärker vor unberechtigtem Zugriff zu schützen. Daten wurden auf Disketten oder SyQuest/ZIP ausgetauscht und nicht einfach per Internet verschickt. Für einen Angriff auf ein Gerät brauchte man physikalischen Zugang zum Gerät. Man war schon froh, wenn man zwei Computer so vernetzen konnte, dass man eine Datei von A nach B kopieren konnte (und das ging bei AppleTalk/LocalTalk oder NullModem-Kabel oft per Diskette schneller). Ein „globales“ Adressbuch pro Benutzer gab es auch nicht, Es fließt also nicht unerheblich viel Rechenleistung in den Schutz vor externen Angriffen, Apps sind in einer Sandbox und müssen über eine API Daten austauschen, die ebenfalls vom System überwacht wird. Wenn man eine Datei einlesen wollte, hatte man auch weniger Aufwand mit Input-Validation (Malformed Files) und man musste auch keine Subprozesse in einer Sandbox verwenden. Hier und da waren auch viele Regeln des Secure Coding noch gar nicht erfunden.

Das entschuldigt schlechten Code oder ineffiziente Frameworks nicht, aber selbst wenn man gut optimierten Code schreibt, fühlt er sich nicht in dem Maße flotter an, wie man aufgrund der technischen Entwicklung vermuten würde. Per Hand optimiert wird mittlerweile auch deshalb weniger, weil gute Compiler bereits sehr gut optimieren (LLVM). Aber schon bei einem malloc() (Speicher für eine Anwendung beim System anfragen - was ständig passiert) passiert im System inklusive Kernel sehr viel. Wenn du dann im Speicher arbeiten willst, passiert noch viel mehr. Mehr als: „ich hab da Platz, den darfst du benutzen“.

unbedingt auch mal die ergebnisse fuer den M4 beachten welche mit Geekbench 5 gemessen wurden. die sind bei weitem nicht so spektakulaer. so wie es aussieht generiert die routine "Object Detection" (laeuft etwa doppelt so schnell wie auf einem M3) einen ausreisser nach oben.

Geekbench 5.5.1 M3 Max Vs. M4

Geekbench 6.3.0 M3 Max Vs. M4

Interessanter Aspekt. Danke für den Tipp! Ich bin gespannt auf die Vergleiche bei praxisrelevanten Anwendungsfällen.