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

So, mein P4 2.8GHz unter Linux mit dem optimierten GCC4 Build ist fertig. Ganz so der Reißer ists aber auch ned. Ca. 30min schneller als die gleiche Kiste unter Windows XP Pro.

024:51:51.571 | 5.87x | GAT | P4 HT 2.8GHz | 1GB DDR-I/400 | CentOS 5.5 Linux x86_32 (custom build)**

Zum Vergleich nochmal die selbe Hardware auf WinXP Pro:

025:18:54.552 | 5.76x | GAT | P4 HT 2.8GHz | 1GB DDR-I/400 | XP Pro

Sobald ich meine neue i7 950 Kiste auf der Arbeit kriege, und das CentOS 5.5 mal aufgesetzt und alles migriert ist usw., dann probier ichs nochmal mit mehr Flags für SSE3, SSE4.2 usw.

Gebaut mit GCC 4.1.2 auf CentOS 5.5 Linux, mit folgenden CFLAGS: "-march=native -O2 -pipe -mmmx -msse -msse2 -fomit-frame-pointer -ffast-math".

-O2, nicht -O3!

-O3 teste ich wenn erst am i7 950 dann.

Also viel hat's ned direkt gebracht, aber ein klein bisserl schneller war er immerhin. Teile des Codes sind übrigens sowieso in Assembler geschrieben (yasm), das sollten die hochoptimierten Codepfade für unterschiedliche CPUs sein.. wobei ich die Details ned kenne.

Ich werds probieren, wenn mein i7 dann fertig ist

Wennst ihn im Linux laufen lassen willst, hast aber keine Wahl. Da werden die Windows Binaries und Batch Scripts nie laufen. Also mußt in der Regel den x264 Encoder Source neu kompilieren, und ein neues Script drumherumwrappen, z.B. mit der Bash oder sh Shell. Da sich sowieso keine wirkliche Vergleichbarkeit ergeben kann (GCC statt mingw als Compiler, andere Versionen des Quellcodes..) kann man auch gleich versuchen, den Code so hart optimiert wie möglich zu bauen, solange der Output noch passt.

Derart erzielte Ergebnisse werden ohnehin in jedem Fall mit den roten Sternen markiert, um darauf hinzuweisen, daß die Vergleichbarkeit nicht mehr gegeben ist, dies betrifft alle Custom Builds, egal auf welchem Betriebssystem, weiters betrifft es generell den Einsatz aller Betriebssysteme, die nicht Microsoft und >=NT5.0 sind, also Linux, MacOS, BSD, auch Win9x usw.

Aber wie gesagt, WENN man unter Linux damit rumspielen will, hat man keine Wahl. Man kann die Referenzvorgaben dann gar nicht mehr erfüllen. Dabei wird übrigens nicht das Script optimiert (das bringt dir sowieso keine Leistung), sondern der tatsächliche x264 Binärcode.

Einen Zweck erfüllt es aber dennoch: Solange man die Optionen für die x264 Encoding Passes gleich läßt, so läßt sich dadurch (halbwegs..) darstellen, um wie viel schneller sich x264 durch Compileroptimierungen auf die jeweilige CPU Architektur noch ausführen läßt. Sieht momentan aber ned so aus als würds gewaltiges bringen, da x264 ja schon optimierte Assemblercodepfade drin hat...

Edit: So, Ergebnisse, die nicht mit Referenz vergleichbar sind, sind jetzt noch ein wenig deutlicher markiert, um das hervorzuheben!

Edit 2: Ich hoffe die meisten von euch verwenden das "Voodooalert Inception" Template für das Forum, sonst sieht man die Farbmarkierungen halt nicht alle so optimal, wenn man eines der hellen Templates einsetzte.

Ich weiß ned recht. Ich möchte mindestens eine Liste halten, in der alles drin ist, weil man dann einfach alles auf einen Blick sieht. Ergebnisse, die nicht unter Referenzbedingungen entstanden sind können ja trotzdem noch für manche User im Vergleich interessant sein. Wie wirkt sich Swapping aus? Wie wirken sich Compileroptimierungen aus? Linux/Windows? Virtualisierungseinflüsse? usw.

Ich weiß nicht, ob ich mit der Meinung alleine da stehe, aber ich finde, es macht mehr Sinn diese Ergebnisse im Kontext zu belassen. Ich glaube auch, daß die Markierungen nicht zu undeutlich sind?

Is drin! Habe mir wieder die Freiheit genommen, selbst rumzuschneiden. Raus mit dem "DualCore" (is eh klar) und auch mit dem "Lenovo" (von wem anderen gibts eh kein ThinkPad R60), und dafür rein mit dem CPU Takt.

Edit: @Bier: Eine Datenbank zu erzeugen is ein winziges Problem. Ein Interface dazu (PHP usw.) schon eher. Außerdem hat das den signifikanten Nachteil, daß es sich ned mehr ins Forum einbetten läßt, und der Bench ist explizit nur für VA gedacht gewesen. Wie gesagt, ein Release auf breiterer Ebene ist eher nicht sinnvoll aus bereits genannten Gründen. Und die Ergebnisliste ausm Forum rauszureißen und auf ein eigenes Web zu setzen find ich auch nicht gut. Sicher kann man dann sortieren und gruppieren. Aber es is dann halt ned mehr in VA eingebettet..

Hmm, scheinbar hats irgendein Problem bei der RAM-Disk, vielleicht ein Datenkonsistenzproblem? Frage wär nur wieso..

Datenbank hätte ich schon eingerichtet auf meinem Server (nur zum Spaß eigentlich). Ist zwar ned wirklich normalisiert, aber najo. Werds wohl eher wieder löschen als sonst was.

Und Kontrolle is auch gut, da hast recht. Und ein Login-/Sessionmanagement in PHP, nein danke... Is wohl besser, wir lassens hier, wie gesagt.

Edit: ACHTUNG!

Es gibt jetzt eine neue Version von x264benchmark.zip! Diese Version löscht den Ausgabebildschirm von x264 nicht nach Beendigung des Encodingvorganges, so ist es möglich, die Ausgabe von x264 recht einfach zu lesen, falls etwas schief läuft! So sieht man also alle Fehlermeldungen, und auch ob pro Pass die vollen 15.691 Frames kodiert wurden.

Wenn der Benchmark aus irgendeinem Grund vorzeitig abbricht, kann man das so sehr gut sehen, und man läuft nicht mehr so leicht Gefahr, fehlerhafte Ergebnisse einzuschicken. Verpflichtend für die Ergebnisgültigkeit ist die Version aber nicht.

Momentan ist das aktualisierte File nur auf [Mirror 0] erhältlich, seth wird noch benachrichtigt, um seinen Mirror upzudaten.

Trag ich gleich ein.

Wie gesagt, verpflichtend is da nix. Nur lassen sich so Fehler besser erkennen.

Edit: Wie hastn den Faktor errechnet? Ich komm auf 5.26x..