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

[TomH22]

Im MacBook Pro gibt es eigentlich kein Problem mit der Kühlung. Nur im Air drosselt die CPU etwas weil 100% passiv.

Und auch erst nach relativ langer Zeit unter Vollast. Ich nutze es z.B. für C/C++ Entwicklung und bei den meisten meiner Builds die ca. 10 Sekunden dauern, gibt es noch keine Drosselung.
Eigentlich habe ich mein Air nicht für diesen Zweck angeschafft, es ist aber deutlich schneller als mein Desktop mit Ryzen 5 3600.

Kosten diese Altlasten denn so viel Chipfläche, dass man weniger anderes verbauen kann oder muss moderner Code durch diese Altlasten?

Der Mehraufwand (an Fläche, Komplexität und letztendlich Energie) entsteht hauptsächlich im Frontend (also Instruction Fetch, Decode, Sprungvorhersage, usw.). Moderne CPUs führen die Maschinenbefehle der ISA (Instruction Set Architecture, also x86, ARM, usw.) nicht mehr direkt aus, sondern die Instruktionen werden in interne Instruktionen zerlegt.

Auch Beschränkungen der ISA, z.B. geringe Anzahl an Registern im Falle von x86 sind nicht mehr so wichtig.

Zusätzlich ist auch ARM kein Musterknabe was Altlasten und aufwändig zu optimierende Maschinenbefehle angeht. Außerdem ist die ISA mit allen Erweiterungen auch alles andere als klein.

Es gibt also keinen wirklich zwingenden Grund warum eine x86 CPU nicht so gut wie ein ARM CPU sein sollte.
Allerdings sollte man nicht unterschätzen, dass die Altlasten den Design- und Testaufwand erhöhen. D.h. mit einer gegeben Anzahl an Ingenieuren und Budget bleibt weniger Zeit für Performance Optimierung übrig.

Das Intel und AMD nicht hinterherkommen, hat meines Erachtens nichts damit zu tun.

Bei Intel ist es die veraltete eigene Fertigung, bei AMD vermutlich schlicht und ergreifend Mangel an Geld und Ressourcen.

Bei beiden kommt noch hinzu, dass die eine viel breitere Palette an CPU Produkten haben. Neben den Mainstream Desktop und Notebook CPUs kommen noch viele speziellere CPUs für spezielle Märkte (Intel hat z.B. CPUs für den Einsatz in Enterprise Networking Produkten).

AMD hat zudem das Problem, dass sie die monolithischen Mobile CPUs und die Chiplet basierten Desktop CPUs haben. Das kostet halt alles Entwicklungsressourcen, die woanders fehlen.

Das hätte ich nicht erwartet. Während der Präsentation hat es so gewirkt, als wäre es ein M3 mit zusätzlicher Hardware für das neue OLED Display und neuer NPU.

Ich vermute der Display Controller ist der Grund warum der M4 sein Debüt im iPad hat. Ein Tape-Out für einen Chip dieser Kategorie ist irre teuer. Der M3 hat den passenden Display Controller nicht, und extra für das iPad eine spezielle M3 Variante zu bauen, wäre wahrscheinlich genauso teuer, wie gleich auf den M4 zu gehen.

Hat jetzt natürlich den kosmetischen Nachteil, dass der gerade vor ein paar Monaten vorgestellte M3 schon nicht mehr the latest und greatest ist.

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.

Das Gejammer (zumindest hier im Forum) wäre dann aber sicher noch größer als bei Windows 11...

In der ARM Welt ist es tatsächlich einfacher, es gibt auch von ARM selber mittlerweile reine 64 Bit ARMv8 Cores, die keinen ARMv7 Anwendungen mehr ausführen können. Die sind natürlich hauptsächlich für Embedded Anwendungen gedacht, wo kein Endkunde selber Software installiert.

Cinebench ist noch dümmer. Der testet ja wirklich nur einen ganz spezifischen Anwendungsfall und ist im Zweifel überhaupt nicht praxisrelevant.

Das stimmt. Aber da er sehr einfach auszuführen ist, und jeweils nur zwei Zahlen für Single Core und Multi Core liefert, kann man ihn gut nutzen, um das relative Leistungspotenzial von CPUs einzuschätzen.
Und z.B. bei meinen Anwendungen wie z.B. Compiler ist meist der reale Leistungsunterschied relativ ähnlich zum Cinebench.
Den M4 gibt es halt zur Zeit nur im iPad Pro, da kommt halt erst mal nur Geekbench infrage.

Für den durchschnittlichen Anwender sind sowieso alle CPUs schnell genug. Eigentlich gibt es bei Mobilgeräten nur eine einzige Zahl, die praxisrelevant ist, und das ist die Akkulaufzeit.

Vor >10 Jahren sah das noch anders aus, da war bei Tablets und Smartphones Javascript Performance oft noch ein Problem. Damals habe ich immer auf die Sunspider Ergebnisse geschaut.
Mein erstes Apple Produkt war damals ein iPad mini 2, als Nachfolger für mein Nexus 7, weil es bei Sunspider mit einem Laptop mithalten konnte. Bei allen Javascript basierten Benchmarks misst man natürlich immer eine Kombi aus CPU und Javascript Engine.

 

[immortuos]

Ein nicht CPU Hersteller, deklassiert Intel und AMD...

@nlr genau wegen solchen Leuten, die absolut falsche Schlussfolgerungen ziehen, wäre ein klarer Hinweis auf die Diskrepanz zwischen Geekbench Scores auf unterschiedlichen Plattformen im Vergleich zu Real-world Anwendungen durchaus gut

 

[Piktogramm]

Würde mich freuen, wenn CB wenigstens erklären würde woran das liegt. So etwas erwarte ich hier =S!
Wie kann es sein, dass eine mobile CPU, die wohl auch nur passiv gekühlt wird, zwei ausgewachsene Desktop CPUs "deklassiert"!?

Aus Sicht moderner CPUs sind die Subtests von Geekbench sehr klein und es werden Pausen zwischen den Tests gelassen. Damit kann eine CPU für jeden Test je den höchsten Takt ansteuern und wird den Test abgeschlossen haben, bevor thermische Limitierung greift. Gleichzeitig sind die Tests auch so klein, dass da große Caches viel helfen und die Speicherbandbreite weniger relevant ist.
Für so alltägliche Sachen, bei den Nutzer·innen irgendeine Aktion auslösen ist das durchaus repräsentativ. Für größere, längere Rechenaufgaben jedoch weniger.

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.

Die Altlasten was 16 und 32bit angeht werden etwas überbewertet Imho. Real laufen die meisten x86 Kisten im Betrieb durchgängig mit x64 Code, selbst 32bit x86 ist mittlerweile sehr selten und selbst wenn ist x86 und x64 in der Regel nicht gemischt sondern ein Wechsel bedingt einen Kontextwechsel. Es frisst etwas Transistorbudget, aber im Betrieb macht die Unterstützung das Kraut nicht fett.
Was weit schlimmer ist, ist die Fülle an Befehlssatzerweiterungen. MMX, SSE2, SSE3, SSE4, AVX, AVX2, AVX512 + Teileerweiterungen, ...
Das Intel da mit APX und AVX10 und folgend AVX20 aufräumen will wird im Frontend der CPUs deutlich mehr bewirken.

Und ARM hat zwar mit Aarch64 ausgemistet, aber seitdem auch wieder fröhlich Befehlssatzerweiterungen eingeführt. Das sieht (noch) übersichtlicher aus als bei x86, aber bedingt dennoch dicke Decoder. Das ARM bei Cortex X1 und Folgenden Op-Caches nutzt um die Decoder weniger zu nutzen kommt ja nicht von ungefähr.

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?

Die Subtests treffen eigentlich alles, außer "langanhaltende Last über große Speicherbereiche."

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.

WHAT? Du solltest schon benennen können, was konkret eine andere ISA in der Architektur anders macht. Ansonsten ist das was du schreibst einfach nur Gebrabbel.

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.

Geekbench6 Dokumentation: https://www.geekbench.com/doc/geekbench6-benchmark-internals.pdf
Nach Changelogs gab es da keine Änderungen, ich würde also die Dokumentation weiter für Bahre Münze nehmen, dass Geekbench derzeit "nur" ARMv8 mit Neon (ohne SVE?!) nutzt.

Und genaugenommen hatte der M1 bereits eine/die Matrixextension.
https://github.com/corsix/amx
War nicht öffentlich dokumentiert, aber Apple eigene Bibliotheken haben sie genutzt bzw. nutzen sie.

 

[Randnotiz]

Ich kann mit den Werten relativ wenig anfangen, weil Apple und ARM was anderes als Linux/Windows und ist, doch Leistungssprünge bei wirklich effizienter Hardware zu erzielen, die keine bloße heiße Luft ausströmt und welche auch bei geringem Stromverbrauch was taugt, freut mich sehr.

Wie es mit dem Dragondragon X Elite und danach weiter geht, bleibt trotzdem interessant.

 

[bensen]

Heftig. Ein nicht CPU Hersteller, deklassiert Intel und AMD...

Nicht? Wer hat die denn dann hergestellt? Und warum deklassiert dann nicht der Hersteller?

 

[Cool Master]

Den Rechenwerken ist es egal, welche Sprache der Vorbau spricht.

Nicht wirklich. Es kommt schon drauf an was für eine Sprache genutzt wird. Es mach ein Unterschied ob ich Assembler nutze oder C++ und co.

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

Hört sich interessant, muss ich mir mal genauer anschauen da ich zum ersten mal davon höre.

Dadurch sind sie in Spezialfällen aber auch wesentlich langsamer.

Jup, schrieb ich ja schon:

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.".

Der M Chip hat(te) bspw. arge Probleme mit Docker und wurde da von Intel nahezu vernichtet.

Gut das kann auch einfach das übliche 1. Generation Problem gewesen sein. Kenne viele Apps die Probleme auf dem M1 hatten (selber erlebt) und die nach 3-6 Monaten deutlich besser liefen weil die Entwickler alles besser verstanden haben.

 

[Piktogramm]

@nlr genau wegen solchen Leuten, die absolut falsche Schlussfolgerungen ziehen, wäre ein klarer Hinweis auf die Diskrepanz zwischen Geekbench Scores auf unterschiedlichen Plattformen im Vergleich zu Real-world Anwendungen durchaus gut

Du hättest doch ebenso einen Hinweis nötig. Solang man nicht unter hohem Aufwand analysiert wieso irgendwas auf einem System, einer Architektur schneller oder langsamer Läuft ist das alles Käse. Es können genauso die Anwendungen sein, die größere Abweichgungen zeigen, weil sie weniger gut auf bestimmte Architekturen angepasst sind.

 

[Trelor]

Wenn Geekbench jetzt noch irgend eine Aussagekraft (zwischen Architekturen) hätte, dann wäre das vielleicht interessant

Hat es doch. Die Libraries die Geekbench durchtestet sind schon sehr verbreitet. Da gebe ich im Zweifelsfall deutlich mehr drauf als auf einen reinen render Benchmark wie Cinebench.

Meist deckt sich Geekbench ja auch ganz gut mit den Industriestandart SPEC Benchmarks.

@BAR86
Über die uOps ist man in der internen Ausführung der Befehle ja größtenteils vom Befehlssatz unabhängig. Da kann man beliebig zusammenfassen und auseinanderziehen wie man es als sinnvoll erachtet. Die wirklich definierenden Unterschiede sind am Ende des Tages die Decoder Komplexität und ein paar fixe Vorgaben zu Registergrößen. Der Rest (CISC vs RISC, Weak vs Strong memory modell, etc.) hat sich in der Dunstwolke der uOps aufgelöst und wird nach dem Decoder Architekturunabhängig.

Die Decoderkomplexität durch die Fülle an Befehlen die in uOps übersetzt werden muss ist viel mehr das Problem. So ein Baum an Logik Gattern explodiert in der Komplexität irgendwann. Gerade wenn es performant sein soll. Deswegen sind die meisten X86 Decoder auch auf weniger Befehle gleichzeitig ausgelegt.

 

[TomH22]

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.

Sehe ich nicht so.
Ich nutze die gleiche Software (z.B. GCC, Python) für meine Projekte auf meinen MacBook Air wie auf meinem Desktop. Teilweise unter macOS mit Homebrew, aber auch in einer Debian @ ARM VM.

Und da kann ich schon direkt die Leistung vergleichen. Macht jetzt bei mir keinen Sinn, weil mein Desktop mit einem Ryzen 5 3600 hoffnungslos veraltet gegenüber dem M2 im Air ist.
Als realer Anwender kaufe ich mir halt nicht jedes Jahr alles neu...

Und klar, die von Dir genannten Chips sind im Multicore natürlich schneller als ein passiv gekühlter Mobil-Chip, denn auch Apple kann nicht zaubern.
Auch Single Core wird der 14900 schon aufgrund seines hohen Taktes und der bei Intel auch sehr guten IPC die Nase vorn haben. Bei AMD weiß ich es jetzt nicht, aber das kann man ja nachschauen.

Sobald es den M4 in einem Mac gibt und man mehr Benchmarks als Geekbench fahren kann, wird man das vergleichen können.

Bei Notebookcheck gibt es einen sehr guten Vergleichstest von M2 und M3 mit diversen Mobil Chips von AMD und Intel. Bei der absoluten Multicore Leistung liegen einige Intel und AMD CPUs vorne, aber eben um den Preis einer wesentlich höheren Leistungsaufnahme.

 

[Piktogramm]

Nicht wirklich. Es kommt schon drauf an was für eine Sprache genutzt wird. Es mach ten Unterschied ob ich Assembler nutze oder C++ und co.

Ja, Assembler ist auch genau Null portabel zwischen Architekturen. Alle Hochsprachen mit jeweils aktuellen Compilern spucken jedoch brauchbare Binaries für X86 und ARM aus. Da macht es echt keinen Unterschied. Zumindest solang der Code wirklich Agnostisch ist und nicht mit Compilermakros für eine bestimmte Architektur versehen wurde.

 

[Rock Lee]

nicht wirklich beindruckend.

 

[7H0M45]

Jedes mal wieder diese leidige Diskussion dass x86 so viel ineffizienter als ARM ist.

War es nicht so, dass bei gleicher Fertigung die Testergebnisse von AMD CPUs und M1 Chip völlig vergleichbar waren?

Meinst Du, der i9 würde mit einem kleinen Passivkühler im SingelCore-Benchmark keinen merkbaren Punktverlust haben?

Die Intel P Cores ziehen so irgendwas um die 25 Watt maximum. In diesem Betriebspunkt sind die allerdings wahnsinnig ineffizient.
Wenn dein Passivkühler mehr als 25 Watt kann, dann gibts gar keinen Unterschied. Wenn er weniger kann gibt es geringfügige Unterschiede, da mit sinkendem Takt die Effizienz steigt.

"keinen merkbaren Punkteverlust" ist halt sehr unterschiedlich interpretierbar

 

[lazsniper]

ich freu mich drauf am mittwoch ! eher aber wegen dem pencil pro und dem oled display... dass der m4 so gut ist, ist ein netter nebeneffekt

 

[Debian User]

Wenn man bedenkt das dass der Einstieg in die M-Reihe ist und der i9 im Multi Core gerade Mal 50% schneller als der M4 ist und das mit deutlich höherem Stromverbrauch und 14 Kernen mehr, dann trifft es das Wort deklassieren relativ gut....Heftig. Ein nicht CPU Hersteller, deklassiert Intel und AMD...

Meinst du Apple? Die sind doch CPU und GPU Hersteller. Die ARM CPU ist selbst designt.

 

[Cool Master]

Ja, Assembler ist auch genau Null portabel zwischen Architekturen.

Korrekt, und darum ging es in dem Post ja. Die jeweilige Architektur hat entsprechende Vorgaben die eingehalten werden müssen damit es so läuft wie es soll. Schrieb ich ja auch schon in Bezug auf die Befehlserweiterungen welche die Effizienz von x86 einfach nach unten treiben weil halt wie gesagt im Prinzip alles seit 1978 (hab noch mal geschaut wann 16 Bit kam) mitgeschleift egal ob man es noch brauch oder nicht und ja, ARM bläht sich aktuell auch auf aber das bleibt ja nicht aus, da man sieht was der Markt will/brauch.

Hardware technisch sind wir aktuell eh gute 5-10 Jahre vor aktueller Software. Es wird also Zeit, dass Software besser wird und die HW zu 100% ausnutzen kann.

Zumindest solang der Code wirklich Agnostisch ist und nicht mit Compilermakros für eine bestimmte Architektur versehen wurde.

Und genau das passiert halt leider nicht (immer). Sieht man ja immer wieder bei Intel und AMD oder AMD und Nvidia.

nicht wirklich beindruckend.

Im Prinzip stimme ich dir zu aber Apple kocht halt auch nur mit Wasser. Die Sprünge wie vor 10 oder 20 Jahren werden wir nicht mehr haben solange wir auf Silizium setzen. Aktuell ist es eher eine Weiterentwicklung statt echter Innovation. Wobei die Leistung durchaus Respektabel ist, da der M4 Pro, Max und Ultra ja noch kommen werden.

 

[ModellbahnerTT]

Das Ergebniss ist nicht verwunderlich da es anderen wie z.B. AMD64 und co. an RAM Bandbreite und Geschwindigkeit fehlt.

 

[Nixdorf]

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+.

Der Cinebench ist aber auch ein massiv parallelisierter Benchmark, und natürlich steht dann ein Achtkerner gegen einen 16-Kerner und einen 24-Kerner nicht so gut da. Da zeigt der Wechsel zu Cinebench also lediglich die nicht perfekte Skalierung des Geekbench mit vielen Kernen. Das soll auch so sein, denn es handelt sich um eine Benchmarksuite mit vielschichtigen Anwendungen, nicht um einen Einzelbenchmark wie Rendering.

Der korrekte Vergleich für Cinebench wäre der M3 Max gegen den 7950X, beide mit 16 Kernen. Dann ist man mit 24022 zu 37353 Punkten wieder auf Faktor 1,55 runter, mit deutlich höherer Leistungsaufnahme auf Seiten des x86-Prozessors zum Erreichen dieses Abstands.

Betrachtet man die Kontrahenten bei vergleichbaren Power Limits, dann liefert der 7950X auf 88W limitiert noch 30194 Punkte, oder 25162 Punkte bei 65W. Das zeigt, dass die x86-Architektur nicht notwendigerweise ineffizienter als ARM ist. Sie wird nur in Desktops meist ineffizienter betrieben.

 

[Piktogramm]

Korrekt, und darum ging es in dem Post ja. Die jeweilige Architektur hat entsprechende Vorgaben die eingehalten werden müssen damit es so läuft wie es soll. Schrieb ich ja auch schon in Bezug auf die Befehlserweiterungen welche die Effizienz von x86 einfach nach unten treiben weil halt wie gesagt im Prinzip alles seit 1978 (hab noch mal geschaut wann 16 Bit kam) mitgeschleift egal ob man es noch brauch oder nicht und ja, ARM bläht sich aktuell auch auf aber das bleibt ja nicht aus, da man sieht was der Markt will/brauch.

Hardware technisch sind wir aktuell eh gute 5-10 Jahre vor aktueller Software. Es wird also Zeit, dass Software besser wird und die HW zu 100% ausnutzen kann.

Naja es wurde von Sprachen geschrieben. Du hättest an der Stelle entspannt "Hochsprache" verstehen können, musstest aber unbedingt "aber guck mal bei Assembly trifft das nicht zu" -.- . Für Hochsprachen ist es halt wirklich egal.
Und Wieso sollte die 16 bit Befehle die CPU langsam machen? Die 16bit Befehle laufen nach Übersetzung auf den 32bit Registern. Da gibt es im Backend also keine Nachteile. Im Frontend brauch es ein paar Transistoren beim Decoder dafür um ein paar Bit auseinanderzuhalten um 16bit, 32bit und 64bit zu trennen. Der Aufwand ist echt minimal im Vergleich zur Fülle an x64 Erweiterungen (oder dem was ARMv8/v9 bereithält, Selbst die finalisierten RISC-V Erweiterungen sind da aufwendiger beim Decode..)

Wo du herhast, dass Hardware Jahre vor der Softwareentwicklung sein soll wüsste ich gern. Pauschal würde ich das als abseits gammliger Softwarealtlasten als nicht Belastbar abtun.

 

[TomH22]

. Es mach ein Unterschied ob ich Assembler nutze oder C++ und co.

Das war vor 30 Jahren in Zeiten von Turbo Pascal so. Heute sind optimierende Compiler so gut, dass man es mit Assembler von Hand kaum schlagen kann.
Außerdem geht mit modernen CPUs Taktzyklen zählen nicht mehr, wie man es früher gemacht hat.

Hardware technisch sind wir aktuell eh gute 5-10 Jahre vor aktueller Software. Es wird also Zeit, dass Software besser wird und die HW zu 100% ausnutzen kann.

Eigentlich macht es mittlerweile umgekehrt: Man testet die CPU gegen real existierende Binaries, um schaut ob die Verbesserungen Wirkung zeigen.
So ist ja AMD zum 3D Cache gekommen: Eine bestimmte Klasse real existierende Anwendungen (in diesem Fall Spiele) profitiert davon erheblich. Hätte ich übrigens, bevor AMD es vorgeführt hat, nicht gedacht...

Bei RISC-V werden ISA Erweiterungen darauf geprüft ob sie Vorteile bei real existierenden Anwendungen bringen. Dafür lässt man die Anwendung in ISA Simulatoren laufen und schaut die Ergebnisse an.

War es nicht so, dass bei gleicher Fertigung die Testergebnisse von AMD CPUs und M1 Chip völlig vergleichbar waren?

Leistungsmässig teilweise ja, aber nicht bei der Effizienz. Suche mal bei Notebookcheck oder Anandech nach entsprechenden Tests.

Ergänzung (9. Mai 2024)

Was weit schlimmer ist, ist die Fülle an Befehlssatzerweiterungen. MMX, SSE2, SSE3, SSE4, AVX, AVX2, AVX512 + Teileerweiterungen, ...

Intel scheint auch mit AVX immer noch erhebliche Effizienzprobleme zu haben. Sobald eine Anwendung AVX nutzt (z.B. die Hintergrund Effekte in Teams Videos), geht die Leistungsaufname deutlich hoch.

Mein alter Core i7-8650U kann dann schon richtig ins TDP Limit und wenn man parallel eine etwas CPU intensiver Anwendung wie Power BI teilen wollte, wurde es wirklich zäh.
Der i7-12800H in meinen aktuellen Arbeits Laptop hat da zwar mehr Reserven, aber dafür ist der Akku dann nach weniger 1,5 Stunden leer.
Wie lange mein MacBook Air das durchhält konnte ich noch nicht messen, dafür war noch kein Meeting was ich damit machen konnte/durfte lang genug...

 

[MaverickM]

Schon sehr beeindruckend. An sich würde mich so ein iPad Pro mit dem neuen Pencil Pro in Zusammenhang mit meiner Software schon mal reizen. Schade nur, dass so ein Chip ausschließlich in Produkten einer Firma vorhanden ist, die ich absolut nicht guten Gewissens monetär unterstützen würde.