Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Erster Benchmark des A18 Pro und weitere Messwerte des A18 aufgetaucht – beeindruckende Performance

Gestern erschien die allererste Geekbench-Geschwindigkeitsmessung des Apple A18, welchen der Konzern im neuen iPhone 16 und 16 Plus verbaut. Hier erreichte der A18 respektable 3.114 Zähler im Single-Core-Benchmark, jedoch nur maue 6.666 Zähler in der Multi-Core-Messung der Geekbench-Test-Suite. Dass die Multi-Core-Messung wohl ein verfälschtes Ergebnis war, bestätigen nun weitere Messungen, die nun in der Geekbench-Datenbank aufgetaucht sind.


Noch höherer Single-Core-Wert
Die neuen Messungen zeichnen sogar ein noch besseres Bild: Im Durchschnitt erreicht der A18 hier einen sehr hohen Single-Core-Wert von 3.410 Zählern – knapp 300 höher als der gestrige Wert. Der Multi-Core-Wert von 8.420 ist im übrigen genau so schnell wie ein M1 ohne Namenszusatz, welcher mit vier Performance- und vier Effizinenzkernen daherkommt (statt zwei Performance- und vier Effizienzkernen im A18).

ModellChipSingle-CoreMulti-Core
iPhone 16A183.4108.420
iPhone 16 ProA18 Pro3.4108.420
iPhone 15A162.5006.450
iPhone 15 ProA17 Pro2.8507.050
iPhone 14A152.2505.500
iPhone 14 ProA162.5006.650
iPad ProM43.65713.216
Mac miniM12.3908.600

A18 und A18 Pro gleich schnell
Wie zu erwarten war ist der A18 und der A18 Pro was die CPU anbelangt genau gleich schnell. Apple änderte auch den Prozessortakt nicht, denn dieser liegt bei beiden Chips bei 4,04 GHz. Der A18 und A18 Pro unterscheidet sich also nur hinsichtlich der schnelleren Grafikeinheit und der aufgewerteten Neural Engine – bei CPU-intensiven Aufgaben hat der A18 Pro weder Vor- noch Nachteile.

M4 bleibt im Single-Core-Benchmark schneller – jedoch nur aufgrund Taktrate
Verglichen mit dem M4, welchen Apple aktuell im iPad Pro verbaut, ist der A18 im Single-Core-Benchmark etwas langsamer. Der M4 erreicht hier 3.650 Zähler – der A18 3.410. Allerdings taktet der M4 im iPad Pro auch mit 4.4 GHz um rund 400 MHz höher als im iPhone 16, so dass sich der Geschwindigkeitsvorteil wohl fast ausschließlich durch den höheren Takt ergibt.

Kommentare

Reinraus11.09.24 19:35
Für das meiste was die Leute damit anstellen WhatsApp , im Internet surfen , Mails checken , Schnappschüsse braucht es diese Potenz doch gar nicht . Wie sagt man so schön haben ist besser wie brauchen 😀
+5
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 19:45
Reinraus
Früher war es mal so, dass die Software durch die limitierte Hardware eingeschränkt wurde. Heute ist die Hardware derart potent, dass man als Software-Entwickler meist gar nicht weiss, wie man das nutzen sollte
+13
ssb
ssb11.09.24 20:01
Mendel Kucharzeck
Reinraus
Früher war es mal so, dass die Software durch die limitierte Hardware eingeschränkt wurde. Heute ist die Hardware derart potent, dass man als Software-Entwickler meist gar nicht weiss, wie man das nutzen sollte
Schlimmer ist hingegen der Trend, dass die Software-Entwickler sich um Performance-Optimierungen mittlerweile weniger kümmern als früher. „Die App ist zu langsam, dann dann kauf ein iPhone“.
Der leidliche Ansatz zeigt sich auch in manchen Programmierumgebungen bzw. Programmiersprachen.
+20
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 20:13
ssb
Richtig, das sehe ich genau so. Guck dir mal Slack an: In der Summe frisst die App gerade 1,2 GB bei mir an Arbeitsspeicher – und es laufen SECHS Prozesse. WAS SOLL DER SCHEISS? Es ist ein dämlicher Chat-Client, warum kann ein Milliardenkonzern es hier nicht erreichen, einen nativen, normalen Client zu programmieren, sondern setzt auf Electron etc?
+20
Schmitti8111.09.24 20:22
Die CPUs werden flotter, bei gleichem Stromverbrauch.
Damit können die Aufgaben flotter beenden und wieder schlafen gehen.
Und das spart Strom und das iPhone läuft länger.
+5
MLOS11.09.24 20:24
Mendel Kucharzeck

Ganz einfach: Das ist günstiger und man muss sich nicht mit den spezifischen Plattformen auseinandersetzen. Das heißt nicht, dass ich electron oder ähnliche Ansätze befürworte - ganz im Gegenteil. Gerade in Sachen Barrierefreiheit sind native Apps immer besser. Bei profitorientierten Unternehmen geht es aber nicht oder nur selten darum, was wirklich gut ist - leider. Bei electron muss man halt keine iOS Developer einstellen, die mit den Gegebenheiten und Schnittstellen der Plattform vertraut sind. Das können die JavaScript-Entwickler vom Frontend-Team hinklatschen.
+4
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 20:31
MLOS
Mir sind die Gründe schon klar, warum einige kleinere Firmen das genau so handhaben. Nur ein paar iOS-,Windows-,Mac- und Android-Entwickler für den Client tauchen doch in der Bilanz von SalesForce noch nicht mal auf weil die Kosten derart gering sind!

Also im Vergleich zum Konzern-Umsatz SEHR kleines Invest, dafür ein DEUTLICH besseres Produkt.
+5
MLOS11.09.24 21:09
Mendel Kucharzeck

Das Produkt mag für dich besser sein. Aber was bringt das bessere Produkt, wenn es so halb gut auch reicht? Wozu dann unnötige Kosten verursachen?
Edit: Electron reicht halt für die Masse, sonst würde man es ja nicht mehr nutzen.
+2
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 21:12
MLOS
Du machst dich weniger angreifbar durch Konkurrenz. Wenn ich durch ein Micro-Invest mein Monopol etwas besser schützen kann, mache ich das im Normalfall.

Sobald eine echte Slack-Alternative erscheinen würde, würden wir hier bei Synium wechseln. Die Funktionen sind gut, die Umsetzung echt mies.
+3
sudoRinger
sudoRinger11.09.24 21:29
Mendel Kucharzeck
Sobald eine echte Slack-Alternative erscheinen würde, würden wir hier bei Synium wechseln. Die Funktionen sind gut, die Umsetzung echt mies.
Ich bin dazu übergegangen Programme wie Slack oder Microsoft-Teams nicht mehr als Desktop-Electron-Software zu nutzen, sondern auf dem iPad. Aus Prinzip.
Das Problem mit der Mac-Bildschirmfreigabe bei Teams löse ich mit Jump Desktop.
+3
tangoloco11.09.24 21:29
Das ist eine Slack alternative:
https://noysi.com/site-de/
... sehr veraltete mentale Schaltkreise lassen Menschen überall geheimnisvolle Kräfte vermuten
+4
rkb0rg
rkb0rg11.09.24 21:33
Laut Liste haben A18 und A18 Pro dieselben Werte?
0
zoe
zoe11.09.24 21:42
Alle Jahre wieder wundere ich mich wieder, ob „mehr Performance“ bei den Kundenwünschen tatsächlich so weit vor „mehr Durchhaltevermögen“ steht.
+3
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 21:45
tangoloco
Ich seh da keinen Mac-Client? Nur iOS und Android
0
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 21:45
rkb0org
Lese mal den Text, da steht die Erklärung
+3
Mendel Kucharzeck
Mendel Kucharzeck11.09.24 21:48
zoe
Die beiden Zielvorgaben widersprechen sich nicht. Der Fachbegriff ist "Race to Sleep". Je schneller du eine Aufgabe erledigst, desto länger schläft der Prozessor insgesamt.
+3
rkb0rg
rkb0rg11.09.24 22:01
Mendel Kucharzeck
rkb0org
Lese mal den Text, da steht die Erklärung

Oh ja, vielen Dank! Habe den Absatz wohl übersehen. Ist schon fantastisch wie leistungsstark das iPhone über die Jahre geworden ist.
+3
tjost
tjost11.09.24 22:11
schneller als mein M1, belastend
+5
Maxlgraf12.09.24 00:44
Mendel Kucharzeck
ssb
Richtig, das sehe ich genau so. Guck dir mal Slack an: In der Summe frisst die App gerade 1,2 GB bei mir an Arbeitsspeicher – und es laufen SECHS Prozesse. WAS SOLL DER SCHEISS? Es ist ein dämlicher Chat-Client, warum kann ein Milliardenkonzern es hier nicht erreichen, einen nativen, normalen Client zu programmieren, sondern setzt auf Electron etc?
Waren das noch Zeiten als man mit Assembler auf dem Atari das letzte Quentchen Performance aus dem 68000er gequetscht hat.
+6
tangoloco12.09.24 01:09
@Mendel Kucharzeck
Noysi app fürs OS gibts im Appstore.

Link zum Appstore

... sehr veraltete mentale Schaltkreise lassen Menschen überall geheimnisvolle Kräfte vermuten
+2
MLOS12.09.24 07:17
Mendel Kucharzeck

Die Frage ist, ob das tatsächlich zu einer Festigung des Monopols führen würde. Nur, weil ihr bei Synium bei einer nativen Alternative wechseln würdet, heißt das ja nicht, dass das jeder macht. Wenn die Electron-Version auf breiten Widerstand stoßen würde, wäre schon längst eine brauchbare Alternative entwickelt worden.
Hinzu kommt dann ja auch noch, dass man wahrscheinlich auch nicht einfach so wechseln kann (Kenne mich mit Slack nicht so aus, wir nutzen in der Firma nur MS Teams). Aber da setzt man doch wahrscheinlich auf einen eingespielten Workflow, der dann mit einer Alternative nicht so gut funktionieren würde. Bei Synium mag das funktionieren, aber große Konzerne, die ebenfalls auf Slack setzen, werden das nicht nur wegen einer Electron-Version durch eine native Alternative ersetzen. Das Monopol bleibt also. Daher lohnt sich das Micro-Investment hier wahrscheinlich nicht und daher bleibt es leider bei Electron mit den Vorteilen für Slack, weniger Entwicklungsaufwand zu betreiben.
Bei uns in der Firma regen sich alle auch über MS Teams auf, aber das Unternehmen ist inzwischen im MS Ökosystem gefangen und irgendwie läuft es ja doch dann. Der Aufwand zum Wechsel ist mit für den (geringen) Nutzen (für manche bessere UX) zu hoch. Daher hat MS wie auch Slack Spielraum für solche Entscheidungen. Die sind etabliert, werden genutzt und müssen sich daher nicht durch eine native App behaupten.
+1
MetallSnake
MetallSnake12.09.24 08:20
Mendel Kucharzeck
Sobald eine echte Slack-Alternative erscheinen würde, würden wir hier bei Synium wechseln. Die Funktionen sind gut, die Umsetzung echt mies.

Einfach selbst entwickeln.
Das Schöne an der KI ist, dass wir endlich einen Weg gefunden haben, wie die Wirtschaft weiter wachsen kann, nachdem sie jeden Einzelnen von uns getötet hat.
+1
ssb
ssb12.09.24 09:04
Mendel Kucharzeck
Sobald eine echte Slack-Alternative erscheinen würde, würden wir hier bei Synium wechseln. Die Funktionen sind gut, die Umsetzung echt mies.
Ich würde da RocketChat in die Runde werfen - aber die Clients sind auch Electron-basiert. Aber immerhin ist RocketChat OpenSource und man kann sich relativ flott einen eigenen Server aufsetzen. Dann hat man wenigstens bezüglich DSGVO weniger Probleme.
Matrix/Elements wäre auch eine Lösung, die man selbst hosten kann. Aber auch da dürften die Clients auf Electron basieren und für macOS gibt es glaube ich keinen (aber man kann den vom iPad nehmen).

Nun, Technologien wie Electron (oder etwas besser Tauri), die Webtechnologien nutzen (das sind ja im Prinzip nur Browserfenster die mit „localhost“ kommunizieren - was eben wenigstens 2 Prozesse verlangt) sind ja noch OK, wenn die App dann auch was im Internet macht. Es gibt aber Nasen, die so etwas auch für Anwendungen nutzen, die gar keinen Internetzugriff brauchen, sondern nur „On-Premise“ sind. Also man programmiert (oder konfiguriertI) einen Webserver (Backend) damit man in einem WebView (Frontend) Dinge machen kann, die dann nativ auf dem Rechner ausgeführt werden. Das ganze packt man dann in ein App-Bundle und alles wird an 127.0.0.1:12345 von Frontend ins Backend geschickt - so als wäre das Backend ein Server irgendwo in Internet. Und da das meiste auf Javascript-Varianten basiert (React, NodeJS, …) ist es auch besonders resourcenschonend. 5 solcher Apps bedeuten, dass man 5 Webserver und 5 WebViews betreibt um mit weiteren 5 externen Webservern zu kommunizieren - was man eigentlich im Browser auch machen könnte - und dann hätte man nur jeweils 1 WebView und keinen Server.

(Leidvoll muss ich mich grad in React/Rust einfuchsen, weil mein Chef so was will. Um so leidvoller, weil ich das auf Windows machen muss).
+1
macfreakz12.09.24 09:09
Ich bin kein Fürsprecher von auf Electron basierenden Apps. Jedoch ist der App auf allen Plattform gleich aussehend und bedienbar, wobei native Features / UX Vorgaben vollkommen ignoriert werden.

Das finde ich nicht cool - aber das ist scheinbar vielen egal geworden.
+1
ssb
ssb12.09.24 13:23
macfreakz
Ich bin kein Fürsprecher von auf Electron basierenden Apps. Jedoch ist der App auf allen Plattform gleich aussehend und bedienbar, wobei native Features / UX Vorgaben vollkommen ignoriert werden.

Das finde ich nicht cool - aber das ist scheinbar vielen egal geworden.
Der wirklich einzige Vorteil von Frameworks wie Electron ist, dass die Software-Hersteller keine Ausrede mehr haben, wenn sie eine Platform nicht unterstützen. Dass die Unterstützung am Ende minimal nativ angepasst ist, stört tatsächlich nicht. Wichtiger ist, dass man einen verhältnismäßig günstigen Entwickler braucht um alle Plattformen zu unterstützen. Das zählt bei den Anbietern, leider auch bei kommerzieller Software.
0
macfreakz12.09.24 13:28
Ja, aber das Sagen hat immer der Endnutzer: Mag und nutzt es das Produkt? Dann ist es egal, ob das Produkt nativ implementiert wurde oder nicht. Es lässt sich super verkaufen. Angenommen, 90% von iOS Nutzer lehnen Electron Apps ab ... dann würde der Hersteller sich Mühe geben, die Anwendung ordentlich zu implementieren.

Die meisten merken nicht den Unterschied zw. Electron und UIKit geschriebene Apps, nehme ich mal an.
0
Marcel_75@work
Marcel_75@work12.09.24 16:52
Mendel Kucharzeck
Sobald eine echte Slack-Alternative erscheinen würde, würden wir hier bei Synium wechseln.

Also ich weiß natürlich nicht, ob ihr euch das schon mal angesehen habt bzw. das für eure Anforderungen ausreicht – aber ich werde mal Mattermost in den Raum.



Der Server ist recht einfach zu administrieren und läuft "auf eigenem Blech", Clients gibt es für alle möglichen Systeme.

Und hey, selbst die NASA arbeitet damit!

Aber im Ernst, wir pflegen das bei einem größeren Verlag und das funktioniert seit vielen Jahren sehr zuverlässig.
+1
Meddog14.09.24 02:50
Maxlgraf
Mendel Kucharzeck
ssb
Richtig, das sehe ich genau so. Guck dir mal Slack an: In der Summe frisst die App gerade 1,2 GB bei mir an Arbeitsspeicher – und es laufen SECHS Prozesse. WAS SOLL DER SCHEISS? Es ist ein dämlicher Chat-Client, warum kann ein Milliardenkonzern es hier nicht erreichen, einen nativen, normalen Client zu programmieren, sondern setzt auf Electron etc?
Waren das noch Zeiten als man mit Assembler auf dem Atari das letzte Quentchen Performance aus dem 68000er gequetscht hat.


Oder auf dem Amiga oder noch früher auf dem C64 in reiner Maschinensprache
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.