x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

Ich kenne keine derartigen Linux Kernelversionen um ehrlich zu sein, nur x.y.z. Alles dahinter hat mit Linux an sich normal nichts zu tun, und spezifiziert Modifikationen bzw. Patchlevels des Distributors? Lieber wäre mir eine exakte Raspbian Versionsnummer, so wie halt auch bei Debian üblich. In der Regel sagt das mEn in Summe sogar mehr über die Systemleistung aus, als die Kernelversion. Da sollte es wohl irgendein Release-File in /etc/ geben oder so?

Abseits davon aktualisiere ich das morgen, heute mag ich nicht mehr in der Datenbank herumreißen.

Edit: Es ist also immer der Buchstabe l, nicht die Zahl 1? Auch beim aktualisierten Kernel? Ich nehme das Mal so an (wohl wegen ARMv7l?). Sollte jetzt passen, aber bitte nochmal gegenkontrollieren. Das zweite Ergebnis wurde wieder aus den Zwischentaktergebnissen herausgenommen, weil sich hier ja das Betriebssystem verändert hat. Mußt also nicht extra einblenden lassen.

01:50:33.217 | GrandAdmiralThrawn | 2/4/4 | Intel Xeon X5355 2.67GHz | 16GiB DDR-II/667 FBDIMM | Intel S5000VSA | Intel 5000V Blackford | CentOS 5.11 Linux (Custom GCC 9.2.0 r2984 Build)

Das hier war Mal unser Core Server, das Herz unserer Infrastruktur auf der Arbeit mit OpenLDAP+Samba als Authentifizierungsdomäne für Linux und Windows Clients, Webserver, SQL Server und einem in-House enwickelten Java Application Server für's automatisierte Annehmen, Testen und Bewerten von Übungs- und Prüfungsergebnisprogrammen von Studenten. Wurde damals von Netburst auf Core 2 hochgerüstet, weil die Leistung einfach nicht gereicht hat.

Jetzt ist das Betriebssystem schon eine Weile aus'm Support raus und die Maschine wurde komplett ersetzt, weil auch das Storagesubsystem (altes SATA HDD RAID) nicht mehr flott genug war. Damit konnte er jetzt nach 12 Jahren Betrieb erstmals diesen Bench durchlaufen.

Das Fehlen von SSE4.1 ist scheinbar deutlich spürbar bei dieser neuen x264 Version, eine ähnliche Box mit neueren "Core 2" Xeons ist deutlich flotter. Najo.

Ist drin!

Habe jetzt übrigens beschlossen, mit den römischen Zahlen beim RAM aufzuhören, das schaut zumindest bei DDR-IV einfach irgendwie lächerlich aus. Sämtliche römischen Ziffern wurden damit vom Speicher entfernt, und durch indisch-arabische Ziffern ersetzt. Nur bei "DDR-I" habe ich das ganz weggelassen, und den Speicher einfach auf "DDR" umbenannt, weil "DDR1" nicht ganz so üblich war oder ist wie die anderen Bezeichner.

Eingetragen.

Und die Windows 10 Betriebssystemangaben wurden etwas mehr vereinheitlicht. Wird Mal wieder Zeit für ein Datenbankbackup.

Liste ist aktualisiert!

Nicht daß es wichtig wäre, aber beim x264 Bench muß man die RESULTS.txt nicht hochladen. Da steht eh nichts drin, außer dem Endergebnis, anders als beim x265er, wo ein ganzer Systemreport drinsteckt.

Nein, ist sie nicht, du brauchst nur nach "DDR/" statt nach "DDR-I" zu suchen, damit bekommst du alle Systeme mit DDR Speicher der ersten Generation, abzüglich eventuell existierender Systeme ohne Datentaktangabe (kA ob sowas je existiert hat in der Liste).

Edit: Scheinbar nicht, womit "DDR/" funktionieren sollte. Elegant ist das zwar nicht, aber elegant war diese selbstgestrickte Suchfunktion sowieso von Anfang an nie.

00:24:55.020 | GAT | 1/32/64 | AMD Ryzen Threadripper 3970X 3.7GHz | 64GiB DDR4/3200 16-18-18-36-1T | ASRock TRX40 Taichi | AMD TRX40 Castle Peak | Windows 10 Pro N 1909 x64

00:10:29.062 | GAT | 1/32/64 | AMD Ryzen Threadripper 3970X 3.7GHz | 64GiB DDR4/3200 16-18-18-36-1T | ASRock TRX40 Taichi | AMD TRX40 Castle Peak | Windows 10 Pro N 1909 x64 (Custom GCC 8.3.0 r2991 x64 Build)

00:10:45.327 | GAT | 1/32/64 | AMD Ryzen Threadripper 3970X 3.7GHz | 64GiB DDR4/3200 16-18-18-36-1T | ASRock TRX40 Taichi | AMD TRX40 Castle Peak | Fedora 31 Linux x64 (Custom GCC 9.2.1 r2991 x64 Build)

00:10:07.085 | GAT | 1/32/64 | AMD Ryzen Threadripper 3970X 3.7GHz | 64GiB DDR4/3200 16-18-18-36-1T | ASRock TRX40 Taichi | AMD TRX40 Castle Peak | FreeBSD 12.1 UNIX x64 (Custom clang/LLVM 9.0.0 r2991 x64 Build)

Edit: Sodalla, jetzt ein paar Kommentare dazu. Der Noctua NH-U14S TR4-SP3 Kühler war hier mit nur einem Lüfter ausgestattet. Zudem war das Gehäuse noch nicht voll mit Lüftern bestückt, und die die drin sind, sind äußerst langsam drehende SilverStone Lüfter. Die Kiste hat man im Leerlauf nicht gehört, und unter Last eigentlich auch nicht. Eventuell ließe sich hier noch mehr Leistung rausholen, aber leider sind die restlichen Noctua Lüfter noch nicht hier. Zudem war hier wirklich nichts custom. Ich habe keine Lüfterdrehzahlen eingestellt oder Kurven definiert, oder gar Spannungen modifiziert, kein gar nichts. Einfach Plug & Play.

Einen erneuten x264 Test unter Windows 10 wird es wohl aus zeitlichen Gründen nicht geben, da die Maschine noch zwei Betriebssysteme zu durchlaufen und in der ersten Jännerwoche produktiv zu werden hat.

Das "Unter 10 Minuten" Custom-Ergebnis überlasse ich also - zumindest für MS Windows - anderen.

Unter Linux und UNIX werde ich aber die exakt selbe x264 Version auch noch durchjagen. Um Mal zu sehen, ob es hier auch irgendwelche Betriebssystem- oder Compilerabhängigkeiten gibt, so wie für x265.

Edit2: Linux Ergebnis hinzugefügt, und die exakt gleiche Version (den gleichen Quellcode) verwendet wie unter Windows 10. Linux war hier einen Hauch langsamer. Damit deckt sich das auch mit den Ergebnissen, die man auf Phoronix hin und wieder so sieht.

Auslastung unter Linux ca. so (In Pass 2, in Pass 1 aber hier ähnlich):

x264 Benchmark Pass 2 unter Fedora 31 Linux, ungefähre Auslastung

Die Auslastung des custom Builds sieht ähnlich aus wie unter Windows 10 (Hier habe ich leider keinen Screenshot).

Edit 3: Und zum Abschluß noch FreeBSD 12.1 UNIX unter Einsatz der clang/LLVM 9.0.0 Compilersuite. Das UNIX-System hat sich leistungstechnisch nicht nur vor Linux, sondern auch noch vor Windows 10 setzen können. Für das Knacken der 10-Minuten-Barriere hat es aber um knappe 7 Sekunden nicht gereicht.

Ein Last-Schnappschuß:

x264 Benchmark Pass 2 unter FreeBSD 12.1 UNIX, ungefähre Auslastung

Jo, das habe ich schon gesehen. An den Spannungen will ich aber ehrlich gesagt nicht rumdrehen, und ich will die Kiste nur so benchen wie sie dann auch wirklich 24/7 läuft. Wenn mir die dann im Akkord größere Datenmengen verarbeitet, und in Woche 3 stürzts auf einmal ab, weil doch nicht zu 100% stabil... na... nach sowas dürstet es mich nicht. Also einfach Lüfter drauf, Power Budget taste ich (über Spannungen) nicht an. Und über 280W kann man's ja nicht rauftreiben. Unter UNIX (ohne Ryzen Master) sowieso nicht, schätze ich.

Edit: Linux durch. Ich editiere das einfach in den obigen Post dazu.

Ach so, du meintest genau so wie im Artikel geschehen. Verstehe. Weiß aber noch nicht ob ich das mental schaffe, den RAM zu untertakten...

Auch wenn's vielleicht wirklich sinnvoll wäre.