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

Der Test am Mac Mini ist einfach mittendrin mit 0fps eingefroren. Habe das dann nicht weiter verfolgt, weil wir die Maschine dann auf der Arbeit für Softwaretests gebraucht haben.

Ergebnis ist drin!

Intel, kein ARM. Aktuell würde der Bechmark auf ARM oder PowerPC auch gar nicht laufen. Dazu gehörten die Skripte entsprechend angepaßt, aber das kann ich nicht machen, wenn mir die Hardware zum Testen nicht zur Verfügung steht.

Ergebnis ist drin!

Du hast schon wieder das "K" vergessen bei der CPU. Ich sag's nur, weil's auch einen 9900 ohne K gibt.

Ich glaub am RAM zu drehen (oder gar neuen zu kaufen!) ist da echt nicht sinnvoll. Ich würde sogar sagen Geldverschwendung. Ich würde ja sagen.. besser das Geld in Strom stecken und übertakten. Aber wieviel das VRM auf deinem Board aushält weiß ich auch nicht, und auf die Schnelle habe ich dazu keine definitiven Infos gefunden.

Vielleicht einfach so lassen? Is ja ned direkt kacklahm jetzt.. Ergebnis ist drin!

Ich kann nur Comet Lake anbieten, in Low-Voltage Form:

15:52:13.846 | GAT | 1/4/8 | Intel Core i7-10610U 1.80GHz | 16GiB LPDDR3/2133 16-20-20-45-224-1T | Fujitsu Lifebook U9310 | Intel Comet Lake-U/Y | Windows 10 Pro 20H2

Na dann schaun wir halt Mal, unveränderte Version des Benchmarks, also nicht weiter angepaßt für ARM...

Ich glaub' ja eher nicht daß dabei was gescheites herauskommen wird, aber schauen wir Mal... sowas habe ich ja letztens auf Bier.jpg's ARM Kiste versucht, da waren die Ergebnisse auch eher "fishy".

Edit: Ah so war das, die ursprüngliche Version vom Bench (bzw. von x265) kann keine Assembly-Optimierungen auf ARM, wenn man 64-bit baut. Geht die Custombuildscheiße wieder los.

Ist drin! Und hier der erste Custom bisher (regulärer Test folgt noch!):

191:05:48.472 || GAT || 1/4/4 || Broadcom BCM2711 B0 (ARM Cortex-A72) 1.50GHz || 4GiB LPDDR4/3200 || Raspberry Pi 4 (Model B, r1.4) || Raspberry Pi OS 10.9 Linux aarch64 Beta (GCC 8.3.0, custom v3.5-release build)

Diese x265 Release-Version vom Benchmark unterstützt auch ARM NEON SIMD im 64-bit Kontext, was die Standardversion nicht kann. Mal schauen was da an Leistungsunterschied vorhanden sein wird. Bedenken muß man natürlich auch den viel zu knappen RAM, und den Umstand daß die SD Karte eher nicht den geilsten Swapspace darstellt.

Edit: Noch was interessantes: x265 checkt auf aarch64 nicht, daß es ein 64-bit Kompilat ist. Auch nicht in der neuesten Reaseversion 3.5. Schreibt also "[32 bit]" hin. Das ist aber ein Blödsinn, wie sich mit file nachweisen läßt:

thrawn@raspberrypi:~/x265benchmark $ bin/x265 --version 2>&1 | grep build
x265 [info]: build info [Linux][GCC 8.3.0][32 bit][noasm] 10bit

thrawn@raspberrypi:~/x265benchmark $ file bin/x265
bin/x265: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=ca83ef608afa4c752c0e7687c0aabd9c8dafc2e0, not stripped

Ist nur ein kosmetischer Bug, wollt's aber angemerkt haben.

Klar ist Booten von USB eine Option! Aber: Zu faul dafür. Läuft ja nebenher auch schon live als Pi-Hole.

Zum RAM: Sehr gute Frage! Ich denke es wird schon was um sein, weil ich in den kurzen Phasen der Beobachtung der CPU Auslastung durchaus Abfälle gesehen habe. Ich gehe Mal davon aus, daß das dem Swapping gschuldet war. Bei der benchmarktechnischen Standardversion von x265 ist das noch stärker ausgeprägt, vielleicht wurde unterwegs Mal der Speicherverbrauch optimiert? Aber das basiert jetzt nur auf sehr kurzen, oberflächlichen Beobachtungen, nicht auf akkuraten Messungen.

iotop zeigt jedenfalls starke Swappingaktivitäten.

Ich gehe daher schon davon aus, daß der 8GiB Pi4 besser performen sollte. Ich war nur untypischerweise zu geizig um mir den zu kaufen. Weil für Pi-Hole braucht's den RAM ja nicht. Die 4GiB Version habe ich ja auch nur gekauft, weil die 2GiB Version sogar teurer und die 1GiB gar nicht erst verfügbar war.

Was ich noch immer gar nicht packe ist, daß der Bench an sich überhaupt auf aarch64 rennt... ohne Modifikation. Da sind 5% vorausschauendes Denken und 95% pures Glück zusammengekommen, um ein fröhliches Fest der Unwahrscheinlichkeit zu feiern...

Mag mir nicht jemand eine Raptor Talos II Workstation schenken? Nein? Eine root Shell tut's auch!

Tja, schön blöd daß die x265 Entwickler eher an der Videoausgabequalität schrauben (auch wenn es CPU Zyklen kostet) als daran, Geschwindigkeitsrekorde zu brechen. Die aktuelle Release-Version 3.5 ist daher trotz NEON Unterstützung am RPi4 sogar deutlich langsamer als die alte Version, die beim Benchmark dabei ist:

147:18:56.610 | GAT | 1/4/4 | Broadcom BCM2711 B0 (ARM Cortex-A72) 1.50GHz | 4GiB LPDDR4/3200 | Raspberry Pi 4 (Model B, r1.4) | Raspberry Pi OS 10.9 Linux aarch64 Beta (GCC 8.3.0)

Da kann man sich die custom Builds (siehe oben) also echt sparen, und das wohl noch für viele Jahre. Zumindest auf ARM. Was vielleicht auch gar nicht so schlecht ist.

Edit: Huch, meine eigenen Richtlinien nicht befolgt und auf die Ergebnisdateien vergessen. Najo, auf RPi4 sind die zwar eh recht nutzlos, hab's jetzt aber für dieses Ergebnis wie auch für das Custom oben mit angehängt.

Der Unterschied: Das schnelle Ergebnis lief mit dem unveränderten Benchmark, der auf x265 2.5+48-bd438ce10843 aus dem Jahre 2017 basiert. Das langsamere Ergebnis ist ein Custom Build der aktuellen Releaseversion 3.5 des Encoders, der jetzt in dieser Version auch NEON auf aarch64 / 64-bit ARMv8 unterstützt.

Der neuere ist dennoch langsamer, weil die Entwickler zwar Optimierungen eingebaut haben, aber auch viel Code so verändert wurde, daß er CPU Leistung für Ausgabequalität opfert. Daher wird x265 über die Zeit in neueren Versionen tendenziell eher langsamer.

Bei x264 wird dahingehend schon lange nichts mehr gemacht, hier werden nur mehr Fehler korrigiert und die Geschwindigkeit optimiert. Daher sind neuere x264 Versionen immer schneller als alte. Bei x265 ist es hingegen genau umgekehrt. Wobei... ich müßte diese Aussage in Wahrheit noch auf x86_64 gegetesten, weil da fließt ja viel mehr Optimierungsarbeit rein.

Beim Vergleichsversuch mußt du denke ich gar nichts am Bench selber tun. Solange du ein aarch64 Linux System hast, sollte alles recht von selbst gehen. Ich mußte nur noch die "sh" auf "bash" umbiegen, damit die Zeiterfassung funktioniert hat. Standardmäßig zeigt der "sh" Link auf Raspberry Pi OS bzw. Debian nämlich auf die Dash.

Edit: Solltest du doch irgendwo anecken, weil mir ein Detail entfallen wäre, einfach melden!