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

Und ich hol mir irgendeinen Transmeta Müll, ich schwörs euch!

Tjo, leider is das ned so einfach. Weil da wieder Mal ein Verkäufer glaubt, sein Land wär der ganze Kontinent, und sonst nirgendwo hin versendet.

Na Mal sehen...

@S2: Is drin!

richie_k: Ich habe selber auch Zugriff auf Linux Maschinen, und habe gestern einen Custom Build vom neuesten x264 Checkout kompiliert, mit GCC4 Compilerflags für - ich denke recht aggressive - Codeoptimierung, die mir Harrold gegeben hat. War ganz schön mühsam, den Müll auf CentOS zum Bau zu bewegen.

In so einem Fall müßte man die Encodingzeilen natürlich in ein Shellscript kopieren, ein klein wenig anpassen, und kann sie dann mit time <shellscript> aufrufen.

"benchmark.sh":

#!/bin/bash
# pass 1:
x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f -2:0 --bitrate 10000 --aq-mode 1 -p 1 --slow-firstpass --stats ./benchmark.stats -t 2 --no-fast-pskip --cqm flat ./elephantsdream_source.264 -o ./benchmark-1stpass.264
# pass 2:
x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f -2:0 --bitrate 10000 --aq-mode 1 -p 2 --stats ./benchmark.stats -t 2 --no-fast-pskip --cqm flat ./elephantsdream_source.264 -o ./benchmark-2ndpass.264

Und dann einfach: chmod +x ./benchmark.sh && time ./benchmark.sh | grep real 1>./results.txt 2>./results.txt

Man kann natürlich nicht erwarten, daß hier die Ausgabe der unter Windows gleicht. Außerdem ist das Ergebnis dann nicht wirklich gültig, da nicht mit Referenzsoftware ausgeführt, und würde in der Liste mit den roten Sternchen markiert werden, so wie es auch bei meinem Resultat sein wird, wenn der lausige P4 hier mit dem Custom Build durch ist. Mal sehen, ob er schneller fertig wird als die WinXP Box mit der selben Hardware drin. Denke aber fast ja, denn nachdem ich x264 Mal mit den optimierenden Compilerflags gebaut habe, hat er noch Mal ein klein wenig zugelegt im Vergleich zu einem Bau mit Standardeinstellungen für GCC4.

War der ServerSet III HE doch flotter als der i840.

Edit: Wenn das wirklich ein HE is, dann unterstützt der Chipsatz 4-Way Bank Interleaving (min. 4 DIMM Sockets zu bestücken), falls es doch eher ein HE-SL ist, wär's Dual-Channel.

Bei einem sehr, sehr schnellen System, das z.B. mit 7fps kodiert, hätte man mit einem Schreib-Datendurchsatz von ca. 330kB in der Sekunde zu rechnen, und mit einer Leserate von ca. 305kB/s, also knapp über 600kB/s, nicht einmal ein Megabyte in der Sekunde. Damit kann man davon ausgehen, daß der File I/O eine mehr als untergeordnete Rolle spielt, speziell da x264 immer einige Frames im Input vorausliest, damit es zu keinen Stalls kommt. Den Rest macht der Writecache des Betriebssystems.

Die meisten getesteten Systeme kodieren aber nicht einmal ansatzweise so schnell, und liegen damit noch deutlich darunter. Ein Pentium4 2.8GHz, der z.B. mit 0.25fps kodiert, hätte gerade einmal einen Durchsatz von knapp 23 Kilobyte in der Sekunde.

Daher würde ich meinen, sofern man nicht über 10MBit LAN / 802.11b WLAN oder über einen extrem lahmen USB Stick testet und gleichzeitig eine Monster-CPU einsetzt, ist die Leistung des I/O Subsystems vollkommen zu vernachlässigen.

Werd ich doch ned der erste sein, der einen XPe Thinclient ins Rennen schickt? lol

Edit: Verdammt, je mehr ich lese, desto mehr gewinne ich den Eindruck, daß der Transmeta Efficeon nicht Scheiße genug ist...