x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)

So, Mal einen Apple M1 mit einem Macbook Air 10,1 in die Finger bekommen und gleich auf's neueste macOS und die neuesten Tools upgraded. Ich hätte mir echt nicht gedacht, daß der Bench mit so deutlich weiterentwickelter und andersartiger Unterlage so (relativ) problemlos runterbaut und rennt. Lediglich eine Zeile im Launcherskript funktioniert leider nicht mehr, weil das Auslesen der Taktfrequenz des Prozessors nicht mehr klappt, s.u. Und natürlich muß man einen Haufen Tools mit Homebrew nachinstallieren und Apple XCode drauf haben, aber das war eh schon immer so auf macOS.

Das war Mal wieder ein guter Test um die Robustheit der Tools auf die Probe zu stellen. Ein modernes OpenBSD 7.3 läuft auch grade aus zum Teil diesem Grund.

Dafür daß der Bench ohne jedwede Assembleroptimierungen auf'm M1 gelaufen ist war der kleine Chip echt nicht so lahm muß man sagen! Bissl geswapped hat er halt, aber okay, war zu erwarten bei zu knappem RAM. Spannend wär noch ein modernes x265, das auch ARM NEON nutzen könnte. Mal schauen ob ich mir das antue.

Ergebnis:

13:46:48.043 | GAT | 1/8/8 | Apple M1 (4PC@3.2GHz + 4EC@2.06GHz ARMv8) @ 3.2GHz | 8 GiB LPDDR4X/4266 | Apple Macbook Air 10,1 | Apple M1 | macOS 13.3.1 (clang 14.0.3)

Nicht wirklich nötig, aber hier is noch'n Screenshot:

Screenie (Klicken zum Vergrößern)

Apple gibt leider keinerlei Referenztaktfrequenzen, sondern nur Maximaltakte an. Daher stehen die hier drin.

Zum veränderten Code: Entfernt bzw. auskommentiert werden mußte die Zeile 1168:

cpuMHz="$(($(system_profiler SPHardwareDataType | ${grepPrg} -i -e 'processor speed' | cut -d':' -f2 | cut -d' ' -f2 | tr -d '[:punct:]') * 10))"

Der Apple system_profiler gibt für die CPU keinerlei Taktfrequenzen mehr aus, womit die Binärarithmetik plötzlich unär wird, was zu einem Syntaxfehler und damit zu einem Absturz führt. Das Auslesen der Taktfrequenzen funktioniert jetzt auf'm Terminal mittels Apple powermetrics, und das braucht leider Superuser Rechte. Hier ein Beispiel wie das gehen kann, jeweils für den Power Core Cluster und den Efficiency Core Cluster der ARM big.LITTLE Architektur von Apple:

% sudo powermetrics -s cpu_power -n1 | grep -A12 'E-Cluster instructions per clock' | grep -e 'Cluster' -e 'frequency'
E-Cluster instructions per clock: 0.948569
CPU 0 frequency: 972 MHz
CPU 1 frequency: 972 MHz
CPU 2 frequency: 972 MHz
CPU 3 frequency: 972 MHz

% sudo powermetrics -s cpu_power -n1 | grep -A12 'P-Cluster instructions per clock' | grep -e 'Cluster' -e 'frequency'
P-Cluster instructions per clock: 3.51011
CPU 4 frequency: 2643 MHz
CPU 5 frequency: 3192 MHz
CPU 6 frequency: 600 MHz
CPU 7 frequency: 600 MHz

Da wird es wirklich Mal wieder ein Update brauchen. Da das Auslesen von Taktraten ohne Superuser sowieso nicht mehr zu gehen scheint, wird das für macOS auf ARM einfach entfernt werden müssen. Außer irgendein macOS User hier kann mir zwitschern, wie es auch mit gewöhnlichen Nutzerrechten geht.

Hat er das nicht schon längst? Bzw. nie müssen, weil er nur einen temporären Ban bekommen hat? Na was auch immer, egal.

Habe es mir jetzt noch angetan, die aktuellste x265 Version 3.5+100 aus dem Multicoreware git zu ziehen, für den Benchmark zu patchen und das ganze mit ARMv8 NEON Assembly Unterstützung zu testen. Das ist nicht mit "modernem x264" zu vergleichen, weil x265 über die Zeit eher langsamer geworden ist. Die Entwickler haben sich einfach entschieden, sehr viel CPU Zeit in Ausgabequalität zu stecken anstatt das Ding nur schneller zu machen. Dennoch ist das Ergebnis mit NEON SIMD besser geworden. Jetzt sollte ich halt noch hergehen und Mal das selbe auf x86_64 machen, damit man das in Relation setzen kann... vielleicht nächste Woche Mal:

10:33:57.001 | GAT | 1/8/8 | Apple M1 (4PC@3.2GHz + 4EC@2.06GHz ARMv8) @ 3.2GHz | 8 GiB LPDDR4X/4266 | Apple Macbook Air 10,1 | Apple M1 | macOS 13.3.1 (Custom clang 14.0.3 3.5+100 Build)

Screenshot (Klicken zum Vergrößern)

Ziemlich effizient ist der Chip aber wohl wirklich. Dafür, daß das hier ein passiv gekühltes, flaches Macbook Air mit einer 10W TDP CPU ist. Apple hin oder her, das ist nicht so mies im Vergleich zu x86_64, was Leistung pro Watt angeht, denke ich mir Mal.

Ein realer Vergleich zu x86_64 steht aber natürlich noch aus: Nämlich eben der Test einer eben vergleichbaren Version der Software auf einer modernen Intel oder AMD CPU. Bin selbst gespannt was da rauskommt.

Leistung hier gemeint als Laufzeit pro Watt. "Leistung" ist für mich in dem Kontext kodierter Inhalt. Bin kein Elektriker, sondern halt IT'ler.

Also sprich: Wieviele Stunden Content in einer bestimmten Quali kann ich pro Watt runterkodieren. Vielleicht gibt es dafür eine andere Einheit? Ich weiß es nicht. "Arbeit" isses ja auch nicht?

So, noch die Box für'n OpenBSD 7.3 Test, ein richtig abgefucktes, älteres Teil das ich auf der Arbeit zurück reinbekommen habe:

42:11:25.910 | GAT | 1/2/4 | Intel Core i7-2620M @ 2.70GHz | 16 GiB DDR3/1333 | HP EliteBook 8460p | Intel QM67 Cougar Point | OpenBSD 7.3 (clang 13.0.0)

Screenshot (Klicken zum Vergrößern)

Klassisch für OpenBSD muß man eine Limitierung in der /etc/login.conf für z.B. die staff Gruppe ändern, und den Nutzer zur ebensolchen hinzufügen, sonst darf er nicht so viel RAM nutzen wie der Benchmark braucht. Also :datasize-cur=1536M;\ z.B. auf :datasize-cur=32768M;\ oder so, weil der Benchmark ansonsten halt flott vom Betriebssystem umgebracht wird. Aber das war's noch nicht.

Interessanterweise haben die Entwickler seit ca. Version 6.4 aus Sicherheitsgründen [SMT deaktiviert]. Die zusätzlichen logischen CPUs scheinen u.a. in htop auf, aber als "disabled". Ein simples sysctl Tunable in /etc/sysctl.conf richtet das: hw.smt=1

Zu guter letzt noch'n sysctl Tunable, damit er die Taktfrequenz vom RAM mittels dmidecode auslesen kann: kern.allowkmem=1.

Das Book war komplett im Anus als ich es reinbekommen habe: 6-Zellen Akku tiefentladen, die (mechanische!) Disk kaputt, Delle im Deckel, außen wie innen stark verdreckt und voller Staub, und kein Netzteil mehr... Für'n Mistkübel. Wollte ich aber nicht, also eine 500 GB Sandisk Ultra rein, 16 GiB NoName DDR3, einen Chinaakku mit 9 Zellen und ein Chinanetzteil mit 90W. Alles richtig billige Teile. Damit sollt's halbwegs brauchbar sein.

Lässig wäre jetzt noch ein Extreme Edition Quadcore als Upgrade, der i7-2960XM. Offiziell geht maximal der i7-2860QM, aber der Extreme rennt und boosted laut Internet einfach trotzdem korrekt. Der kostet aber leider schon so 120 - 150€ und ich krieg' den nicht so leicht mit sauber ausgestellter Rechnung, die unsere Finanzbuchhaltung akzeptieren würde, fürchte ich. Hab die Chips fast nur in China finden können. Schad.

Ok, bei dir schlägt also der Bootstrapper fehl. Ich gehe davon aus, daß dir einfach etliche Pakete fehlen, um die nötige Software bauen lassen zu können. Dazu braucht es [Homebrew] und eine gewisse Vertrautheit mit der Kommandozeile und dem Editieren von Textdateien.

Homebrew braucht es, um die noch fehlende Software zu installieren, üblicherweise durch Aufruf eines brew install <paketname> Befehls. Analog zu Linux, BSD und ähnlichen Systemen. In den Sinn kommen mir ad hoc insbesondere die Pakete cmake, git, mercurial, gawk, gsed, pkgconfig, autoconf und mkvtoolnix in den Sinn. Apple XCode alleine gibt dir nur eine IDE und die C/C++ Compiler, Linker und Archiver usw. Das reicht leider nicht.

Sobald du homebrew installiert hast, stehen dir die Weiten der meisten Linux/UNIX Pakete weitestgehend offen. z.B.: brew install cmake, und du hast das cmake Buildsystem nur wenige Sekunden später installiert.

D.h., installiere bitte homebrew, und dann entsprechend die gelisteten Pakete:

• cmake
• git
• mercurial
• gawk
• gsed
• pkgconfig
• autoconf
• mkvtoolnix

Versuche dann bitte folgende Befehle in deinem Benchmarkordner:

1. ./bootstrap.sh --purge
2. ./bootstrap.sh (Warte, bis es durch ist)

Dann machst du bitte die erzeugte Datei launch_x265benchmark.sh in deinem favorisierten Texteditor auf, und suchst die Zeile cpuMHz="$(($(system_profiler SPHardwareDataType | ${grepPrg} -i -e 'processor speed' | cut -d':' -f2 | cut -d' ' -f2 | tr -d '[:punct:]') * 10))" und kommentierst sie aus, indem du ihr ein # voranstellst und die Datei speicherst.

Danach führe bitte folgenden Befehl im Benchmarkfolder aus:

• ./launch_x265benchmark

Wenn es danach immer noch nicht funktioniert, einfach melden, und dann schauen wir uns das an! Ich sollte eine sinnvolle Anleitung schreiben, aber macOS ist derart unterrepräsentiert, daß ich mich dahingehend bis jetzt einfach nicht gekümmert habe...

So ein Chip wäre aber schon Mal cool im Bench zu sehen, da bin ich schon fast motiviert hier!

Hat mein kleiner M1 (kein M1 Pro!) auch, also ein paar hundert MHz unter Maximum. Aber das ist wohl zu erwarten, die rechnen ja nicht damit, daß man das Trumm konstant voll auslastet.

Alles klar, bin gespannt. 0,07 ist schon Mal über dem was der kleine im Air geschafft hat, da waren's 0,04 und 0,05 bei dem Custom Run mit NEON.

Marlon : Überall muß man seine schmutzige Phantasie auch nicht aufdrehen!

Vielen Dank!

Leistung schaut schon beachtlich aus, mehr als doppelt so schnell als der M1 in der Standardversion. Liegt wohl auch an dem deutlich höheren Energiebudget deiner Maschine. Du mußt dein Ergebnis übrigens nicht rot markieren, ich mache das nur damit's irgendwie mit der Liste zusammenpaßt. Die Änderung der einen Textzeile im Launcher ist nicht leistungsrelevant, damit akzeptiere ich das Ergebnis als gültig. Ich gehe Mal nicht davon aus, daß du ein eigenes Kompilat von x265 oder ffmpeg angefertigt hast.

Nur deine "RESULTS_MacBookProM1_10C.txt" ist irgendwie fast leer, ist da was beim Hochladen schief gelaufen? Irgendwo mußt die Laufzeit ja rausgelesen haben.

Ok, muß jetzt nicht unbedingt sein, nur wenn du wirklich zuviel Zeit (und zu billigen Strom) hast.