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

  • Joa, lief alles auf einer 16GB SDHC Karte. Mit schnellerem Swap/mehr RAM wäre die Wii sicher um einiges schneller.
    Linux auf der Playstation 2 hab ich mir auch schon überlegt, nur leider etwas teuer. :spitze:

  • Stimmt, deswegen hab ich's auch sein lassen. Die linuxfähigen gehen ja für irrsinnige Preise über'n Tisch..

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Einer Playstation 2 ging's da wohl noch schlechter, die hat ja nur 32MB Rambus drin? Die 4MB eDRAM sind ja denk ich ned CPU adressierbar, sondern eher nur Cache? Wobei ich das ned sicher weiß, kann schon falsch sein auch.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Ergebnis von nem Kumpel (manche kennen ihn ausm irc):

    01:49:53.854 | TheDwoon | 1/4/8 | Intel Core i7-2600 | ASRock H61M/U3S3 | 8GB DDR3 1333 | Windows 7

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

  • Hey GAT, ich bekomme weiterhin Probleme beim selber kompilieren. Fehler ist wie folgt:

    Code
    dependency file generation.../usr/bin/gcc-4.8 -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -m64  -Wall -I. -I. -std=gnu99 -mpreferred-stack-boundary=5         -fomit-frame-pointer -fno-tree-vectorize   -c -o x264.o x264.cx264.c: In Funktion »print_csp_names«:x264.c:445:15: Fehler: Variable »i« hat Initialisierung, aber unvollständigen Typ     for( enum PixelFormat i = AV_PIX_FMT_NONE+1; i < AV_PIX_FMT_NB; i++ )               ^x264.c:445:27: Fehler: Speichergröße von »i« ist unbekannt     for( enum PixelFormat i = AV_PIX_FMT_NONE+1; i < AV_PIX_FMT_NB; i++ )                           ^x264.c:445:5: Fehler: »enum PixelFormat« in Anfangsdeklaration einer »for«-Schleife deklariert     for( enum PixelFormat i = AV_PIX_FMT_NONE+1; i < AV_PIX_FMT_NB; i++ )     ^x264.c:445:27: Warnung: Variable »i« wird nicht verwendet [-Wunused-variable]     for( enum PixelFormat i = AV_PIX_FMT_NONE+1; i < AV_PIX_FMT_NB; i++ )                           ^<eingebaut>: die Regel für Ziel „x264.o“ scheitertemake: *** [x264.o] Fehler 1

    ich habe es auf dem aktuellen S413 so wie auf dem alten T23 probiert, gleicher Fehler. Ich habe es mit gcc 4.8.5 und 5.2.0 probiert, gleicher Fehler.

    ./configure Ausgabe war wie folgt:

    (configure Ausgabe T23 war natürlich minimal anders weil 32Bit System etc)

    Edit: wie guckt man eigentlich bei libav vernünftig die version nach? Dateiname war libav-HEAD-7778859 das ist ein paar Tage her, hab mir jetzt nochmal die aktuelle Version gezogen (libav-HEAD-7bb1c1b) und kompilier die. wenns ich eine bestimmte ältere brauche: welche geht und wo bekomm ich die? Da libav doch etwas zum bauen braucht hab ich eigentlich keine Lust das 20 mal zu bauen und jedes mal aus zu probieren ob es geht... (erst recht nicht auf dem T23 um das es eigentlich geht)

    Edit2: noch mal mit aktuellster libavf Version getestet und nach wie vor gleicher Fehler. Kann man allgemein irgendwie rausbekommen mit welcher libavf Version welche x264 Version erfolgreich gebaut wurde?

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    4 Mal editiert, zuletzt von Giovannie (19. September 2015 um 14:27)

  • Also zumindest mit der zum Zeitpunkt dieses Posts aktuellen x264 Variante von hier: ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2 tut es nicht. Ich versuch mal mir das direkt aus dem git zu ziehen falls die da wirklich ganz frisch was verändert haben.

    edit: auch mit dem git-repo nix besseres. Sollte ja auch tendenziell das gleiche sein.

    edit2: mit libav 11.4 teste ich gerade, braucht ja leider ein bisschen zum bauen, Update gibts dann sobald ich den kram gebaut hab.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    Einmal editiert, zuletzt von Giovannie (19. September 2015 um 14:29)

  • Hey, es baut. Dann demnächst nochmal neu gebencht mit dem S413, das T23 wird wohl eine Weile zum bauen brauchen, und ob ich da das Problem mit der unterirdischen Geschwindigkeit durch selber bauen weg hab weiß ich auch noch nicht.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

  • Alles hat korrekt gebaut und auf dem S413 läuft der bench grad mit neuestem x264

    bei dem T23 bekomme ich aber einen Fehler beim benchmark starten:

    launchbenchmark.sh line 3: 9467 Illegal instruction (core dumped) ...

    launchbenchmark.sh line 6: 9469 Illegal instruction (core dumped) ...

    (statt ... kommt die Zeile des scriptes)

    ich werd nochmal die Dateiversionen überprüfen, möglich das ich auf dem T23 was hier grad nicht am Netz hängt eine paar Stunden früher x264 gezogen hab und es nicht gleich neu ist wie auf dem S413 wo es grad funktioniert, sonst wüsste ich (außer der Hardware) keinen Unterschied.

    Edit:60 min 44s auf dem S413, also keine Verbesserung zu der Version mit der es vorher gelaufen war. Aber das war ja auch eher zum testen weil ich beim S413 mal eben Dinge testen kann die auf einem P III einen halben Tag dauern (wie libav kompilieren) bleibt das problem das T23 zum laufen zu bekommen.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    Einmal editiert, zuletzt von Giovannie (19. September 2015 um 21:18)

  • "Illegal instruction" bedeutet, daß du Optimierungen eingebaut hast, die dein Hostprozessor nicht unterstützt. z.B. eine SSE2 Instruktion auf einem Prozessor, der gar kein SSE2 hat. Das kann durch eine fehlerhafte C/C++ Compileroptimierungsoption passiert sein, oder auch durch einen Fehler in der Assembly-Codepfaddetektion. Ich würde instinktiv eher ersteres vermuten...

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • hmm, wie kann ich beim bauen nachgucken für was der optimierungen einbaut? bin im Prinzip nach deiner Linux Anleitung vorgegangen außer das ich libav 11.4 genommen habe, da sollte der doch eigentlich automatisch nur die Sachen einbauen die die zu Grunde liegende Architektur kann, wenn kein Fehler bei dem autodetect auftritt.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

  • [...] wenn kein Fehler bei dem autodetect auftritt.


    Und genau sowas hatte ich selbst schon, auf meiner MIPS/Loongson-2f Maschine. Es ist also nicht unmöglich. Was du tun könntest, wäre es, libav neu zu bauen, aber ohne die Assemblyoptimierungen. Das verlangsamt den Build zwar, aber libav hat ja rechentechnisch nur einen winzigen Anteil am Ganzen. Also zuerst libav runterreißen, dann konfigurieren und neu bauen und installieren:

    Code
    $ make uninstall$ make distclean$ ./configure --disable-asm$ make# make install

    Dann kommt x264 dran, ebenfalls runterreißen, normal neu konfigurieren (zur Sicherheit, damits auch echt sauber is), bauen und installieren.

    Benchmark neu starten. Wenn der illegale Opcode bzw die illegale Instruktion wieder aufgerufen wird und den Bench zum Absturz bringt, dann liegt der Fehler wohl in x264 und nicht libav. Wenn's an x264 liegt, muß man sich die Arbeit leider antun, das von configure gebaute Makefile zu inspizieren und ggf. ungünstige Optimierungen zu entfernen, sowohl was den GCC angeht, wie auch die Assembler (gas & yasm).

    Letzer Verdacht wäre dann noch, daß deine GCC Version per default SSE2 Code baut - oder sogar schlimmeres. Wenn das der Fall ist, müßtest die C und C++ Optimierungen manuell einschränken. Wie das geht, steht [hier]. Also in den CFLAGS und CXXFLAGS Umgebungsvariablen sowas wie das hier setzen:

    Code
    -march=pentium3m -mno-sse2 -mno-sse3 -mno-ssse3 -mno-sse4 -mno-sse4a -mno-sse4.1 -mno-sse4.2 -mno-avx -mno-avx2 -mno-avx512f -mno-avx512pf -mno-avx512er -mno-avx512cd -mno-fma -mno-fma4

    ...um die meisten zu nennen, die Probleme machen könnten. Weitere siehe Doku. Ältere Compilerversionen verstehen ein paar der Switches eventuell ohnehin noch nicht, weil's dafür noch keinen Code gab. Es kann auch emfpehlenswert sein, den Code mit dem Plattformcompiler zu bauen, also mit dem Compiler, mit dem dein ganzes Betriebssystem gebaut wurde, und der der Distribution standardmäßig beliegen sollte.

    Ist leider eine Suche nach der Nadel im Heuhaufen sowas..

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • also ich werds nachher mal probieren, aber sicherlich erst beim x264 nach Fehlern suchen und nicht bei libav, libav braucht auf dem P3 ca. 4h zum bauen, da ist "mal eben ohne optimierungen" bauen schon eine längerwierige sache^^

    edit: hab jetzt doch das T23 libav ohne asm laufen lassen, gleiches resultat. also reingehen und makefile prüfen.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    Einmal editiert, zuletzt von Giovannie (20. September 2015 um 15:39)

  • Problem gefunden: der baut SSE2 instructions mit ein.

    Edit:Bringt aber nüscht viel, das Geschwindigkeitsproblem, das er nur noch 1/4 der Geschwindigkeit macht bleibt...

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

    2 Mal editiert, zuletzt von Giovannie (20. September 2015 um 16:50)

  • Nachdem mein T23 sich beharrlich weigert mit halbwegs modernem x264 schnell zu laufen würde ich gerne den Fehler eingrenzen. Dafür brauch ich mithilfe.

    Bisher gibt es fast keine (nur 2) Ergebnisse von Pentium III CPUs die nicht mit der Referenzsoftware durchgeführt wurden (eigentlich löblich das die immer mit Referenzsoftware betrieben wurden). Wenn mal jemand gegen testen könnte ob es bei ihm schnell tut wäre das super, am besten jemand der sein System schon mit der Referenzversion durchgehauen hat (ansonsten kann man das ja auch noch machen :topmodel: ) damit ich weiß ob der Fehler Maschinenspezifisch oder allgemein für Pentium III CPUs ist.

    Bisher weiß ich nur das awe-soem mit r2245 schnell war. Wenn es ein allgemeiner Geschwindigkeitsfehler ist, dann kam er erst mit einer späteren x264 Version rein.

    Dafür würde es mir auch helfen wenn möglichst viele Leute posten könnten welche x264, libav Versionskombinationen gebaut haben, damit ich weniger Arbeit hab beim zurückspringen im x264 git-repo, neu bauen, testen.

    Wenn ich zu viel Zeit hab lass ich ihn vlt. auch mal so langsam komplett durchlaufen, wird halt statt 2 7-10 Tage brauchen aber eigentlich wollte ich lieber erst nach dem Problem suchen :)

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!

  • Heyho,

    mein T23 ist aktuell dabei alle win32 x264 Binaries aus dem videolan archiv gegeneinander zu benchen (sind 16 Versionen, die älteste ist r2345 vom 30. Juli 2013) nun haben aber offensichtlich einige Leute hier mit älteren offiziellen x264 Builds gebencht, falls die noch wer rumfliegen hat oder irgendwo einen Mirror findet wär ich dankbar, dann würde ich von denen vlt. auch welche testen.

    btw: morgen früh kommt das erste Ergebnis von r2345 rein und sieht deutlich schneller aus als die Referenzversion, ich rechne so mit 43 Stunden.

    all I can do is be me, whoever that is. -Bob Dylan

    Römer sind keine Bieber!