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

  • 1.) Intro und Ergebnisliste:

    Willkommen zum Voodooalert x265 Benchmark, einem plattform- und betriebssystemübergreifenden Benchmarkprojekt zur Stabilitätsverifikation und für's Benchmarking von modernen 64-Bit Rechnern für Microsoft® Windows NT®, UNIX® (Auch Apple® macOS®/MacOS® X), Linux® und Haiku® OS. Eine Warnung vorweg: Dieser Test ist kein Schnelldurchgang, siehe Ergebnisliste!

    x265 Benchmark Ergebnisliste

    Hinweis: Der Zugriff auf die Ergebnisliste per HTTPS:// funktioniert nur mit älteren und ggf. mit entsprechend konfigurierten Web Browsern. Wenn man Fehlermeldungen in Bezug auf die Verschlüsselung und/oder Sicherheit der Webseite erhält, bitte einfach auf unverschlüsseltes HTTP:// wechseln.

    2.) Download

    Der 64-Bit VA x265 Benchmark in seiner aktuellsten Version für UNIX (inkl. macOS)/Linux/Haiku OS (~230 MiB):


    Der 64-Bit VA x265 Benchmark in seiner aktuellsten Version für Microsoft Windows (~237 MiB):


    Update 2023-01-23: !!! WICHTIGER HINWEIS FÜR WINDOWS 11 NUTZER !!!

    Aktuelle Microsoft Updates haben das cmd.exe Terminal bei der Ausführung von Batch Skripten hochgradig destabilisiert, womit aktuell kaum mehr ein stabiler Betrieb möglich ist. Um das zu umgehen, muß ich Nutzer ersuchen, die Powershell auszuführen, und das Benchmarkskript darin manuell auszuführen! Man wechsle zuerst in den Benchmarkordner, wo die Datei launchbenchmark.bat liegt, z.B.: CD /D X:\benchmarks\x264benchmark\ und führe den Benchmark dann aus: .\launchbenchmark.bat. Eine bessere Lösung liegt mir derzeit leider nicht vor.

    Danke an Torsten für das Melden des Fehlers und für die Unterstützung bei der Fehlersuche.


    SHA-512 Prüfsummen für die aktuellste Version (UNIX: 0.4.0-r0, Win64: 0.4.0-r0) , nachprüfen mittels [sha512sum] (Win64) Tool möglich:

    • UNIX: 266c3ef43f82b2e97d568ced4e64dbc6de8774074ee1499f07bd738264944b255c2cc7fb5ee42d6cdc819152c2b215eb840d2051c74d2a2fc293c1880fa08ab8 UNIX/x265benchmark-0.4.0-r0-2021-10-09.tar.xz
    • Win64: 8f00b9e9a53d9989a931d6bf6fab1054a43df63f8a8b0a0792547d6d39aa1888503bb0e016a326ab4c07ec2d01d8902ffab125654755d91de508c9f2ab9f832a *win64\\x265benchmark-0.4.0-r0-2021-10-10.7z


    Ältere Versionen:

    Noch ältere (Entwicklungs)versionen im [ursprünglichen Thread] zur Bedarfserhebung und Entwicklung.

    Die Änderungen von Version zu Version sind einen Beitrag weiter unten angeführt.


    3.) Wie startet man das?

    Hinweis: Der Benchmark ist bitte in einer solchen Art und Weise zu betreiben, daß er von anderen Programmen nicht übermäßig in Speicher und CPU Zeit beeinträchtigt wird, sodaß das Ergebnis nicht langsamer ausfällt, als für die Maschine zu erwarten (das sollte auch im Sinne der Nutzer sein).

    Unter Microsoft Windows:

    Einfach auf das Skript launch_x265benchmark.bat doppelklicken, oder selbiges innerhalb eines Konsolenfensters starten: .\launch_x265benchmark.bat. Nach dem Durchlauf wird der Benutzer im Konsolenfenster darüber benachrichtigt, daß er sein Ergebnis aus der RESULTS.txt abholen kann.

    Unter UNIX / Linux / macOS / Haiku OS:

    Das Skript bootstrap.sh durch Doppelklick starten oder auf einer Konsole aufrufen: $ ./bootstrap.sh. Den Aufforderungen folgen, bis der Bootstrapper alles erfolgreich kompiliert und eingerichtet hat. Danach das Skript launch_x265benchmark.sh durch Doppelklick starten oder auf einer Konsole aufrufen: $ ./launch_x265benchmark.sh. Erneut den Aufforderungen in der Konsole folgen, bis der Benchmarkbetrieb hinreichend gewährleistet worden ist, sodaß er sauber durchlaufen kann. Nach dem Durchlauf wird der Benutzer im Konsolenfenster darüber benachrichtigt, daß er sein Ergebnis aus der RESULTS.txt abholen kann.


    4.) Ergebnisse einsenden; Was genau wird gebraucht?

    Wie schon zuvor beim x264 Benchmark würde ich euch höflich bitten, beim Einsenden eines Ergebnisses auf das Format zu achten, und bitte die RESULTS.txt die vom Benchmark erzeugt wird als Anhang an eure Ergebnisposts anzufügen. Das Format eines Ergebnisses sollte so aussehen:

    <Zeit in HHHH:MM:SS.mmm> | <Nickname des Urhebers> | <Anzahl der bestückten CPU Sockel>/<Anzahl der Kerne pro Sockel>/<Anzahl der Threads pro Sockel> | <CPU-Name(n)> | <RAM-Typ & Menge> | <Mainboard/Rechner/Plattform> | <Mainboard-Chipsatz> | <Betriebssystem> <auf Virtueller Maschine, wo anwendbar> (<Compiler, wo anwendbar>)


    Es ist beim Test bitte unbedingt drauf zu achten, daß nicht an der Systemzeit gedreht wird, solange er noch läuft! Das schließt Sommer-/Winterzeiteinstellungen (DST) mit ein, solche sollte es während des Tests nicht geben! Falls dies doch passiert, so ist dies bitte unbedingt gemeinsam mit dem Ergebnis mit anzugeben!

    Hier ein Beispiel:

    11:09:44.290 | GAT | 1/8/8 | AMD FX-9590 4.70GHz | 16GB DDR-III/1866 9-10-9-27 | Gigabyte GA-990FX-UD3 v4.0 | AMD 990FX | FreeBSD 11.1 UNIX (Clang 4.0.0)

    Für Windows Versionen muß i.d.R. kein Compiler angegeben werden, wenn man nicht wirklich von Quellen selbst übersetzt. Die Windows Version des Benchmarks so wie er ausgeliefert wird, verfügt über eine x265.exe, die mit Microsoft VisualStudio 2017, C++ Compilerversion 19.11.25547 übersetzt und tlw. mit yasm 1.3.0 assembliert wird. Das beiliegende ffmpeg.exe wird mit GCC 6.3.0 übersetzt und mit gas 6.3.0 / yasm 1.3.0 assembliert.

    Wenn man virtualisiert, dann sei das bitte wie folgt anzugeben:


    <Betriebssystem> (<Compiler, wo anwendbar>) in <Hypervisor+Version> auf <Hostbetriebssystem>


    Ein Beispiel:

    Debian 9.2.1 Linux (GCC 6.2.0) in VirtualBox 5.1.2 auf Windows 10 Pro 1703

    Für UNIX und Linux kann es sein, daß die Zeit als Millisekundenwert in der RESULTS.txt steht. Ist dem so, ist der Wert entweder selbst umzurechnen, oder der ms-Wert einfach so zu posten (ich rechne dann um). Manchmal fehlen auch die Millisekunden in der Angabe der Zeitmessung, und man erhält nur Sekundengenauigkeit. In solchen Fällen werden die Millisekunden auf 0 abgerundet.

    Beim RAM dürfen natürlich gerne wieder die Latenzen angegeben werden! Je mehr Info desto besser.

    Weiterführende Informationen finden sich einen Beitrag weiter unten.

    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!"

    66 Mal editiert, zuletzt von GrandAdmiralThrawn (23. Januar 2024 um 15:20)

  • Inhaltsangabe:

    1. ) Usertopliste, Betriebssystemstatistik und CPU Statistik
    2. ) Frametime-Statistik / Verlaufsgraph
    3. ) Gültige Ergebnisse aus dem Bedarfserhebungsthread, nachgereicht
    4. ) Allgemeine Zusatzinformationen
      1. ) Gültigkeit von Ergebnissen
      2. ) Unter welchen Softwarelizenzen steht der Benchmark?
      3. ) Wo finde ich den Quellcode der Benchmarkkomponenten?
      4. ) Unter welcher Lizenz stehen die von mir erzeugten Bilder und Textinhalte der x265 Ergebnisliste und Beiträge in diesem Thread?
    5. ) Version Changelog der Releaseversionen
    6. ) Bekannte Bugs und Probleme


    Inhalte:

    1.) Usertopliste, Betriebssystemstatistik und CPU Statistik:

    Diese Statistiken bieten eine Übersicht über die Aktivität der Benutzer, die Ergebnisse eingesenden haben, über die teilnehmenden Betriebssysteme und Betriebssystemfamilien, sowie über die Prozessoren und Prozessorfamilien und deren Virtualisierung:


    2.) Frametime Statistik / Verlaufsgraph:

    Auch beim x265 Benchmark habe ich eine Frametime-Statistik für euch, damit der Benchmark eingeschätzt werden kann, was seine Laufzeiten angeht. Diese Statistiken zeigen also, welche Teile des Videos das da kodiert wird langsamer, und welche schneller kodiert werden:

    Frametimes des x265 Benchmarks in Pass 1 (Klicken zum Vergrößern)



    Frametimes des x265 Benchmarks in Pass 2 (Klicken zum Vergrößern)

    3.) Gültige Ergebnisse aus dem Bedarfserhebungsthread, nachgereicht:

    Hier noch die ersten gültigen Ergebnisse aus dem [Bedarfserhebungsthread], damit die auch gleich hier mit drinstehen:

    • 03:05:30.241 | exxe | 1/12/24 | AMD Ryzen Threadripper 1920X 3.50GHz | 32GB DDR-IV/2400 | ASUS PRIME X399-A | AMD X399 | CentOS 7.4.1708 Linux (GCC 4.8.5)
    • 03:53:25.130 | GAT | 2/8/16 | Intel Xeon E5-2620 v4 2.10GHz | 64GB Reg. ECC DDR-IV/2133 | HP ProLiant DL360 G9 | Intel C610 Wellsburg | CentOS 7.3.1611 Linux (GCC 4.8.5)
    • 09:01:55.138 | feinripp | 1/4/8 | Intel Core i7-4790K 4.40GHz | ASUS Z97 Pro Gamer | Intel Z97 Lynx Point | 16GB DDR-III/1600 9-9-9-24-2T | Windows 10 Pro
    • 10:36:54.000 | GAT | 1/6/12 | Intel Core i7 980X 3.33GHz | 48GB DDR-III/1333 9-9-9-24-2T | ASUS P6T Deluxe V2 | Intel X58 Tylersburg | CentOS 6.9 Linux (GCC 7.2.0)
    • 11:09:44.290 | GAT | 1/8/8 | AMD FX-9590 4.70GHz | 16GB DDR-III/1866 9-10-9-27 | Gigabyte GA-990FX-UD3 v4.0 | AMD 990FX | FreeBSD 11.1 UNIX (Clang 4.0.0)
    • 12:28:47.687 | GAT | 1/6/12 | Intel Xeon X5690 3.47GHz | 48GB DDR-III/1333 8-8-8-24-2T | ASUS P6T Deluxe | Intel X58 Tylersburg | Windows XP Pro x64 SP2
    • 16:59:23.843 | Bier.jpg | 2/4/4 | Intel Xeon X5470 3.33GHz | 64GB FBDIMM DDR-II/667 5-5-5-15 | SuperMicro X7DWA-N | Intel 5400B Seaburg | Windows XP Pro x64 SP2
    • 32:28:26.000 | 666psycho | 1/4/4 | AMD Phenom II X4 955 3.20GHz | 16GB DDR-II/667 | Gigabyte M57SLI-S4 Rev 2.0 | nVidia nForce 570 SLI | Debian 9.2 Linux (GCC 6.3.0)
    • 51:16:48.954 | Stranger2k1 | 1/4/4 | AMD A8-3550MX 2.00GHz | 16GB DDR-III/1333 9-9-9-24 | HP Pavilion G7-1280eg | AMD K12 | Windows 10 Home
    • 64:40:37.007 | Bier.jpg | 1/2/2 | Intel Core 2 Duo T9300 (Dual IDA) [pp.] 2.50GHz | 8GB DDR-II/557 5-5-5-15 | Lenovo ThinkPad X61 | Intel GM965 Crestline | Windows 7 Ultimate x64 SP1


    4.) Allgemeine Zusatzinformationen:

    4a.) Gültigkeit von Ergebnissen

    Beim [x264 Benchmark] war es so, daß die Gültigkeit eines Resultats davon abhing, daß eine bestimmte Binärversion von x264.exe für Windows benutzt werden mußte, um ein gültiges Ergebnis abliefern zu können. Hier half auch keine Virtualisierung, denn auch diese wurde als Grund gewertet, das Ergebnis nur als "inoffizielles" in die Ergebnisliste mit aufzunehmen. Auch das Unterschreiten der Mindestanforderungen führte zu einer Verweigerung der Gültigkeit, was im Falle der verlangten SSE Befehlssatzerweiterungen einschränkend auf die Nutzer gewirkt hat.

    Ganz zu schweigen natürlich vom unsinnigen Aussperren von UNIX-, Linux-, macOS- und Haiku OS Systemen, die den portablen Benchmark natürlich auch haben ausführen können.

    Der x265 Benchmark räumt mit dieser Unzulänglichkeit auf! Anstatt "binary-locked" zu sein, ist der x265 Benchmark "version-locked". Solange die x265 Version 2.5+48-bd438ce10843 und die ffmpeg Version 3.2.4 (mit libavutil 55.34.101, libavcodec 57.64.101, libavformat 57.56.101, libavfilter 6.65.100, libswscale 4.2.100 und libswresample 2.3.100) zum Einsatz kommen, und die Anforderungen an Hauptspeicher, Festspeicher und notwendiger Software zum Betrieb des Benchmarks an sich erfüllt werden, ergibt das ein gültiges Resultat!

    Alle anderen Parameter wie etwa Betriebssystem, eingesetzter C/C++ Compiler (solange mit unveränderten Standardeinstellungen), vorhandene NUMA Unterstützung (sofern nicht fehlerhaft) oder auch Hardwarevirtualisierung werden als natürliche Einflüsse gewertet, die die Gültigkeit nicht beeinflussen!

    Der x265 Benchmark ist in Sachen Plattformen somit fairer und unabhängiger als es der x264 Benchmark jemals war!

    4b.) Unter welchen Softwarelizenzen steht der Benchmark?

    Siehe -> README/README.txt des fertig entpackten Benchmarks!

    4c.) Wo finde ich den Quellcode der Benchmarkkomponenten?

    Siehe -> README/README.txt des fertig entpackten Benchmarks!

    4d.) Unter welcher Lizenz stehen die von mir erzeugten Bilder und Textinhalte der x265 Ergebnisliste und Beiträge in diesem Thread?


    Alle von mir selbst im Rahmen des x265 Benchmarks erzeugten Webseiten (//www.xin.at/x265/*, //wp.xin.at/*) sowie Forenbeiträge auf Voodooalert innerhalb dieses [Threads], wie auch des alten [Bedarfserhebungsthreads] und alle von mir erzeugten Bilder sind © Michael Lackner (GrandAdmiralThrawn) und stehen unter einer [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)] Lizenz.

    Im Falle des Logos im ersten Beitrag sowie auf der Ergebnisliste gilt zusätzlich noch ein © David Baum in Bezug auf das Voodooalert.de Logo. Die Nutzung dieses Logos durch mich geschieht mit ausdrücklicher Erlaubnis durch David Baum (ernesto.che).

    5.) Changelog: (neuere zuerst)

    0.4.0-r0:

    • Alle Plattformen:
      • src/x265/source/common/threadpool.h bzw. src\x265\source\common\threadpool.h, Zeilen 37-44 und die daraus resultierenden Binärprogramme bin/x265, bin\x265.exe & bin\x265-NT6.1+.exe: Ändern der Breite des CPU Adressierungsbitvektors bzw. Felds von 64 auf 256 Bit, passend zu den Konventionen moderner Betriebssysteme. Damit können auf kompatiblen non-NUMA Systemen bis zu 256 CPUs adressiert werden, auf NUMA Systemen nun bis zu 256 CPUs pro NUMA Knoten.

        Im Hinblick auf existierende, SMT-fähige Many-Core CPUs wie z.B. den AMD Threadripper 3990X (64 Kerne, 128 Threads) oder den Intel Xeon Platinum 8380 (40 Kerne, 80 Threads) soll dies eine Auslastung der Prozessoren ohne das Erzeugen unsinniger NUMA Threadpools gewährleisten.

        Zudem sollen derartige Prozessoren in Einsockel- und Mehrsockelkonfigurationen auch auf Betriebssystemen ohne Win32 NUMA oder libnuma unterstützt werden, so z.B. auf Solaris, FreeBSD, macOS, etc.

        Dies betrifft auch jene Systeme, wo die NUMA Unterstützung zwar vorhanden wäre, aber schlichtweg in der Systemfirmware (z.B. UEFI) deaktiviert wurde.

        Hinweis 1: Dies umgeht nicht die Limitierungen älterer Betriebssystemekernel! Wenn der Systemkern nur 64 CPUs zu adressieren vermag (Beispiele: Windows XP Professional x64 Edition, Linux 2.4 x64, FreeBSD 9.x x64), so gilt diese Limitierung weiterhin!

        Hinweis 2: Dieser Wert kann in Zukunft noch weiter erhöht werden, sodenn die Betriebssystemkerne entsprechend aufgestockt werden.

        Code vor der Modifikation (Max. 32 CPUs für 32-bit, max. 64 CPUs für 64-bit):
        Code
        #if X86_64
        typedef uint64_t sleepbitmap_t;
        #else
        typedef uint32_t sleepbitmap_t;
        #endif
        
        static const sleepbitmap_t ALL_POOL_THREADS = (sleepbitmap_t)-1;
        enum { MAX_POOL_THREADS = sizeof(sleepbitmap_t) * 8 };
        enum { INVALID_SLICE_PRIORITY = 10 }; // a value larger than any X265_TYPE_* macro
        Modifizierter Code (256 CPUs, 32-Bit Unterstützung entfernt, da für den Benchmark irrelevant):
        Code
        typedef uint64_t sleepbitmap_t;
        static const sleepbitmap_t ALL_POOL_THREADS = (sleepbitmap_t)-1;
        enum { MAX_POOL_THREADS = sizeof(sleepbitmap_t) * 32 };
        
        enum { INVALID_SLICE_PRIORITY = 10 }; // a value larger than any X265_TYPE_* macro
      • /sbin/transcoder.sh (Zeilen 21 & 29) bzw. sbin\transcoder.bat (Zeilen 56 & 69): Anzahl der zu kodierenden Frames nicht nur für den Encoder, sondern auch für den Decoder fixiert, um den Decoder bei Schnelltests in der Entwicklung nicht mehr unsinnig lange auf eine Pipe schreiben zu lassen, deren Gegenstelle bereits terminiert hat.
      • launch_x265benchmark.sh bzw. launch_x265benchmark.bat: Mehrere kleinere Fehlerkorrekturen.
      • share/version.txt bzw. share\version.txt: Versionsstring erhöht auf 0.4.0-r0 (Version 0.4.0, Patchlevel 0)
    • UNIX:
      • Neue Systemarchitektur: aarch64, verifiziert in Zusammenarbeit mit [Bier.jpg]. Der Benchmark ist damit auf 64-Bit ARMv8 unter wenigstens Linux lauffähig, weitere Betriebssysteme verbleiben noch ungetestet. Lediglich die x265 Versionsanzeige in RESULTS.txt gibt noch "32 bit" an. Dies ist aber nur ein kosmetischer Fehler, der ignoriert werden kann.
      • launch_x265benchmark.sh: Sinnfreie Kommentarzeile von Zeile 1242 entfernt.
      • README/README.txt & README/README-GER.txt: Etliche Tippfehler korrigiert und Quellcodemodifikationen zur Erweiterung des CPU Adressierungsbitvektors in x265 dokumentiert.
    • Win64:
      • bin\cpuz_x64.exe: Aktualisiert von 1.87.0 -> 1.97.0. Neuer CPU- und Plattformsupport, diese Liste ist nicht zwingend vollständig:
        • ARM: Vorabunterstützung (Windows 10 on ARM), Achtung! Das bedeutet nicht zwingend, daß der x265 Benchmark in Zukunft ARM auf Windows unterstützen wird!
        • AMD: Threadripper 3000 (Zen 2), Threadripper Pro 3000 (Zen 2), Ryzen 7/5/3 5000, Ryzen 7/5/3 3000 Pro (Zen 2), Ryzen 9/7/5 3000XT series, Ryzen Picasso (Zen+), Renoir APU, Ryzen 5000G APU, Cezanne/Lucienne
        • Hygon/海光: Dhyana/中科海光 (Zen)
        • Intel: Bestimmte Core i-9000F/KF, Core i-10000, Core i-11000 & Core i-12000 Serien (Cascade Lake, Comet Lake, Ice Lake, Tiger Lake)
        • VIA: CHA NCore, Centaur CHA
        • Zhàoxīn/兆芯: Kāixiān/开先 KX-5000 (Wǔdàokǒu/五道口) & Kāixiān/开先 KX-6000 (Lùjiāzuǐ/陆家嘴)
      • bin\ptime.exe: Neues Zeitmessungswerkzeug von [Jem Berkes], das Microsoft TimeThis.exe ersetzt. Verbesserungen: Kein ~600h Überlauf mehr. Keine einstündigen Zeitsprünge mehr, sollte die Systemuhr gerade während eines laufenden Tests von der Normalzeit auf die Sommerzeit oder in die Gegenrichtung wechseln. Auch das manuelle Ändern der Systemzeit beeinflusst die Zeitmessung jetzt nicht mehr.
      • launch_x265benchmark.bat & sbin\transcoder.bat: Überflüssiger %NicePrg% Programmcode entfernt, da kein nice Programm mehr benutzt wird.
      • README\README.txt & README\README-GER.txt: ptime.exe Lizenzinformationen hinzugefügt und TimeThis.exe Lizenzinformationen entfernt, etliche Tippfehler korrigiert und Quellcodemodifikationen zur Erweiterung des CPU Adressierungsbitvektors in x265 dokumentiert.
      • Offizielle Unterstützung von Microsoft Windows 11 (kosmetische Updates, keine funktionalen).

    0.3.1.2-r5:

    • Win64:
      • launch_x265benchmark.sh: Tippfehler in den Codekommentaren korrigiert.
      • bin\cpuz_x64.exe: Aktualisiert von 1.83.0 -> 1.87.0. Neuer CPU Support (Intel bis Coffee Lake, AMD bis 2nd Gen Ryzen), AMD AGESA Reporting und besserer Support für DDR-IV Speicher-Reporting.

    0.3.1-r3:

    • UNIX:
      • launch_x265benchmark.sh: Korrekte URLs zu den Webseiten in den Kommentaren und in den Fehlermeldungen eingepflegt und auf HTTPS geändert.
      • README\README*.txt: Korrekte URLs zu den Webseiten eingepflegt und auf HTTPS geändert.

    0.3.1.2-r4:

    • Win64:
      • launch_x265benchmark.bat: Korrekte URLs zu den Webseiten in den Kommentaren und in den Fehlermeldungen eingepflegt und auf HTTPS geändert.
      • README\README*.txt: Korrekte URLs zu den Webseiten eingepflegt und auf HTTPS geändert.

    0.3.1.2-r3:

    • Win64:
      • bin\cpuz_x64.exe: Aktualisiert von 1.81.1 -> 1.83.0. Damit unterstützt das System Reporting nun Xeon Phi "Knights Landing" manycore CPUs, sowie AMD Ryzen 2xxx "Raven Ridge" Desktop APUs.

    0.3.1.1-r2:

    • Win64:
      • launch_x265benchmark.bat: Der CPU-Z Aufruf war unzureichend, was das Erfassen der Chipsatzinformationen angeht. Das wurde jetzt durch ein Erweitern der grep Parameter korrigiert.

    0.3.1-r2:

    • Alle Plattformen:
      • launch_x265benchmark[.sh|.bat]: Neue RAM-Anforderungsskalierung. Für Systeme mit 1-32 logischen CPUs werden nur noch 12GiB RAM gefordert, anstatt 16GiB. Systeme mit 33-64 logischen CPUs benötigen weiterhin 16GiB, Systeme mit >=65 logischen CPUs benötigen 24GiB RAM. Diese Staffelung kann sich noch ändern bzw. erweitert werden.
      • README/README.txt: Information über aktuelle RAM-Anforderungsstaffelung hinzugefügt.
        share/version.txt: Version inkrementiert, 0.3.0 (r1) => 0.3.1 (r2).
    • UNIX:
      • README/README.txt: Tippfehler korrigiert.
      • launch_x265benchmark.sh: String Quoting Fix für die zusätzliche Speicherbenachrichtigung unter OpenBSD UNIX und kosmetische Verbesserungen.
      • share/version.txt: Trademarksymbole hinzugefügt.


    6.) Bekannte Bugs und Probleme: (neuere zuerst)

    • 0.3.1-r2:
      • Win64:
        • bin\cpuz_x64.exe: Auf Windows 10 kann es passieren, daß CPU-Z beim Aufruf mit einem Treiberfehler abstürzt. Hierbei meldet CPU-Z, daß eine andere Version seines Kernelcodes schon laufen würde, daß aber 1.39 benötigt würde. Die Ursache für diesen Fehler ist noch unklar.
        • launch_x265benchmark.bat - Hotfix 0.3.1.1 r2 verfügbar: Aufruf von CPU-Z unzureichend, kein Erfassen der Chipsatzinformationen gegeben.
        • launch_x265benchmark.bat und bin\cpuz_x64.exe: Benötigt Administratorrechte per UAC bzw. per se wenn auf NT 5.2 getestet werden soll. In Zukunft ist ein Durchlaufzähler geplant, der nach 3 erfolglosen UAC Admin-Aufrufen abbricht und den Benchmark ohne CPU-Z Systemreporting weiter ausführt. Auf NT 5.2 soll einfach eine Warnung anstatt eines kritischen Fehlers erzeugt werden. So soll es Nutzern ermöglicht werden, den Test auf Windows auch dann laufen zu lassen, wenn keine Administratorrechte zur Verfügung stehen.
    • 0.3.0-r1:
      • Alle Plattformen:
        • launch_x265benchmark[.sh|.bat]: Der Test verlangt auch auf Maschinen mit geringer logischer CPU-Anzahl (32 und weniger) nach 16GiB RAM, was überzogen ist. Mit der nächsten Version soll eine feinere Staffelung eingeführt werden, sodaß kleinere Maschinen auch mit 12GiB in die Gültigkeit entlassen werden.

    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!"

    54 Mal editiert, zuletzt von GrandAdmiralThrawn (10. Oktober 2021 um 17:25)

  • Das Format eines Ergebnisses sollte so aussehen:

    <Zeit in HHHH:MM:SS.mmm> | <Nickname des Urhebers> | <Sockel>/<Kerne pro Sockel>/<Threads pro Sockel> | <CPU-Name(n)> | <Mainboard/Rechner/Plattform> | <Mainboard-Chipsatz> | <RAM-Typ & Menge> | <Betriebssystem> <auf Virtueller Maschine, wo anwendbar> (<Compiler, wo anwendbar>)


    Hier ein Beispiel:

    11:09:44.290 | GAT | 1/8/8 | AMD FX-9590 4.70GHz | 16GB DDR-III/1866 9-10-9-27 | Gigabyte GA-990FX-UD3 v4.0 | FreeBSD 11.1 UNIX (Clang 4.0.0)

    3 kurze Hinweise:
    - in deiner Formatvorgabe kommt der RAM erst nach Mainboard/Chipsatz, in Praxis (und auch im Beispiel) ist es aber umgekehrt, das evtl. noch ausbessern ;)
    - in deinem Beispiel fehlt die Angabe des Chipsatzes
    - bei den Ergebnissen aus dem vorigen thread hast du das von feinripp noch nicht mit rübergezogen, siehe https://voodooalert.de/board/index.ph…7733#post427733

    Ansonsten :respekt: danke für den Aufwand, den du dir hier wieder gemacht hast, damit alle Irren dieses Forums (und darüber hinaus) ihre modernen Systeme (im Sinne von 64 Bit... the battle of slowness möge beginnen) wieder adäquat quälen können :spitze:

    Ich werd gleich meinen Ryzen mal damit beschäftigen.

    Und weil ichs gerade sehe, die Angabe der Timings hat bei meinem Phenom gefehlt, wenn du das noch ergänzen magst: 16GB DDR2/667 6-6-6-18

  • Mein Ryzen glüht schon
    ETA 3:29:55 :spitze:

    Diskutiere niemals mit Idioten, sie ziehen dich auf ihr Niveau runter und schlagen dich mit ihrer Erfahrung.
    Mein Herzblut:
    AMD 5x86-P75, 64MB-Ram, Voodoo I, Win3.11
    AMD K6-2+ 550 @ 600MHz, 256 MB-Ram, Voodoo II SLI, Win98SE
    AMD 3700+, 3072MB-Ram, ATi FireGL X3-256
    , WinXP SP3 (Sockel 754)

  • Die ETA gilt im Übrigen pro Pass, sollte ich dann auch noch irgendwo anmerken.. falls es nicht schon in den Readmes steht. :D

    666psycho: Danke für's Drüberschauen und Korrigieren, habe die Fehler ausgebessert!

    Posts #1 und #2 sind genauso wie die Liste momentan eh noch in einem traurigen Zustand, aber das wird schon noch. :].

    Edit: Noch eine Core 2 Xeon Maschine fertig, da sieht man im Vergleich zu Biers Kiste schön, daß die spezielle NT 5.2 Version für Windows (also für Server 2003 und XP x64) wirklich merklich langsamer ist (ich schätze da muß man dankbar sein, daß die Entwickler den XP x64 Zusatzhack überhaupt bis heute maintainen):

    • 0015:16:54.197 | GAT | 2/4/4 | Intel Xeon E5430 2.67GHz | 17GB FBDIMM DDR-II/667 | ASUS DSBV-D | Intel 5000V Blackford | CentOS 6.7 Linux (GCC 4.4.7)

    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!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (17. November 2017 um 19:04)

  • [Blockierte Grafik: https://abload.de/thumb/20171117_193400_resiz3brr9.jpg][Blockierte Grafik: https://abload.de/thumb/20171117_193419_resizh6qo3.jpg]

    Ich bekomme bei den 4 Opteron nur wirklich Last auf eine CPU, kommt mir merkwürdig vor.
    (sorry für den sch... Monitor und die Handy Bilder, habe das Ding gerade nicht am Netz, ging schneller)
    In den Betas war es zu Anfang auch so, hat sich dann aber normalisiert.

    Ich lasse das jetzt auf jeden Fall mal zuende laufen, mal sehen was dabei raus kommt.

    2 Mal editiert, zuletzt von Maniac81 (17. November 2017 um 19:54)

  • Das issn NUMA Fuckup. Schau bitte im BIOS nach, wie die NUMA Topologie konfiguriert ist. Damit gibts immer wieder Probleme, leider. Ich kenn jetzt dein BIOS nicht, aber dazu gibt's normal Einstellungen, mit denen du eine Flat Topologie erzwingen kannst (deaktiviert NUMA quasi), und evtl. auch andere Settings. Daß er drei NUMA Pools zu je 4 Threads spawned kann ja schon Mal nicht passen. Es sollten 4 NUMA Pools zu je 8 Threads sein..

    Hat bei dir jede der vier CPUs auch lokalen RAM (meistens in den Slots am nächsten zu den CPU Sockets) installiert? Das ist bei NUMA Architekturen auch kein unwichtiger Punkt.

    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!"

  • Naja, jetzt ist er auf so 9-10 Stunden runter, aber es liegen immer noch so 10-12 Threads brach.

    Ne, das Ding hat ja auch pro CPU 2 Numa Nodes, also insgesamt 8. (Zeigt er zumindest in Taskmanager und im Bios an)
    Der Ram ist definitiv (zumindest laut Handbuch) richtig drin

    Naja, ich breche den run dann mal ab. Ist eh ziemlich laut mit den kleinen 40er(?) Southbridgelüftern.

    Ich versuche es Morgen mal aufs neue.

    Einmal editiert, zuletzt von Maniac81 (17. November 2017 um 20:52)

  • Jo, sowas darf normal nicht passieren. Ich würde vorschlagen den Versuch zu wagen, ob du im BIOS evtl. NUMA einfach abdrehen / auf "flat" schalten kannst. Ich weiß nicht warum das auf manchen Systemen mit MS Windows so ein Problem ist, aber es gab auch schon HP Server, die sowas hatten.

    2 NUMA Nodes pro CPU sind natürlich seltsam, vielleicht verwirrt ihn das?

    Irgendwie macht NUMA das Leben nicht wirklich leichter...

    Wie gesagt, der spawned da drei Pools zu je 4 Threads, also 12 Threads auf deinen Screenshots. Du hast aber 32 Kerne. Die anderen Parallelisierungsoptionen können damit im Leben nicht ausreichen. Also da issn Bug. Frage is nur WO. Aber dieser NUMA Fuck sekkiert mich schon länger massiv (ned nur in x265).

    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!"

  • Kannst nur ausschalten. Dann gibt es quasi nur mehr einen Node zu 32 Kernen. Mit 32 sollte es so grade noch gehen. Manche Systeme können "flat" nicht über 32. 64 ist sowieso das Limit, weil der CPU-Kern Adressbitvektor auf Windows nur 64 Kerne ansprechen kann (mit NUMA Pools geht mehr, weil der Adressvektor dann pro NUMA Node separat existiert).

    Aber die Scheiße is leider ziemlich buggy, und den wahren Grund für die Probleme habe ich auch noch nicht eruieren können. :(.

    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!"

  • Ok, alles klar!

    Abgesehen davon werde ich demnächst Mal die x265 Entwickler fragen, was da genau passiert (inkl. Verlinkung deiner Screenshots). Wär nice wenn mir die endlich erklären könnten, wieso das mit den NUMA Pools auf Windows so gerne schiefläuft. Weil in der Doku is davon keine Rede, außer daß es ab Windows 7 "hinreichend funktioniere". :rolleyes:

    Mal schaun was du mit deaktiviertem NUMA erreichst, aber ich denke es wird besser sein!

    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!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (17. November 2017 um 21:19)

  • Maniac81
    Hast mal geschaut, ob es evtl. ein Bios Update gibt, das möglicherweise solche Probleme behebt?


    Hier mein Ryzen-Ergebnis, ich hätte eigentlich damit gerechnet, etwas näher am 4790k zu landen. Naja, immerhin fast am 980X Hexacore vorbei :spitze:

    10:41:10.364 | 666psycho | 1/4/8 | AMD Ryzen 5 1400 @3.70GHz | 16GB DDR-IV/2687 16-16-16-39 | Biostar B350ET2 | AMD B350 | Windows 10 Home 1703

  • Gibts irgendwas neues @Maniac? War heute (bzw. gestern mittlerweile) leider den ganzen Tag nicht da...

    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!"

  • @GAT
    du hast den OC Takt (3,7GHz) bei meinem Ryzen nicht mit in die Liste übernommen, der ist nicht mit seinen 3,2GHz Standardtakt gelaufen ;)

    Und noch zwei Ergebnisse :spitze:

    11:20:07.262 | 666psycho | 1/4/8 | Intel Core i7 6820HQ 2.70GHz | 32GB DDR-IV/2133 15-15-15-36 2T | Lenovo Thinkpad P50 | Intel CM236 Skylake | Windows 10 Pro 1511

    12:12:18.000 | 666psycho | 1/4/4 | Intel Core i5 4590 3.30GHz | 20GB DDR-III/1600 8-8-8-24 2T | MSI H97M Eco | Intel H97 Lynx Point | Debian 9.2

    Unter Debian hab ich den Benchmark diesmal als root gestartet, die Time-Ausgabe in der result.txt ist aber immernoch etwas zerschossen. Der Windows 10 Run des i5 folgt vielleicht noch heute, muss erst mal das dämliche "Fall Creators" Update durchrödeln lassen... :mauer:

    edit... hier mal spaßhalber die Laufzeiten der einzelnen Passes auf dem i5 4590 unter Debian:
    Pass1: 21938,91s
    Pass2: 21995,61s

  • @Ryzen: Fixed!

    @Debian und time: Debian ist halt ein Härtefall, weil es unter der /bin/sh (also der dash Shell) gar kein time Keyword hat. Bei dir war das extra GNU time Programm scheints installiert, aber auf einem blanken Debian hast auch das ned. Najo, bei dir isses drauf, daher hat der Benchmark nicht mit einem Fehler abgebrochen, aber das GNU time Binary erzeugt eben diese ungenaueren Zeiten. Und dabei isses leider auch egal, welcher User das Teil ausführt. Also die Loginshell des Nutzers ist egal, weil immer die /bin/sh genommen wird, aus Gründen der Portabilität.

    Um das zu fixen, müßtest den /bin/sh Link von der dash auf die bash umbiegen. Aber sowas will ich den Leuten eigentlich nicht unbedingt einreden, wenn's so auch irgendwie halbwegs geht...

    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!"

  • etwas langsamer als unter Linux mit der Beta5...

    03:26:24.264 | exxe | 1/12/24 | AMD Ryzen Threadripper 1920X | 32GB DDR-IV/2400 | ASUS PRIME X399-A | AMD X399 | Windows10 Pro

    Dateien


    VoodooAlert IRC Channel


    Und hier noch ein blöder Spruch den nicht jeder sehen kann.
    :spitze: Anscheinend ist es ja mittlerweile modern, Schriftfarben zu nutzen die man nur in einem der beiden Designs sehen kann :spitze:

  • Hmm, das is mir fast ein bissl zuviel um mit ca. 11%. Vor allem weil der x264er bei dir unter Windows 10 sogar einen Hauch [schneller war] als unter CentOS 7 Linux (mit Custom Builds). Irgendwie scheint (auch modernes) Windows ein wenig benachteiligt zu sein von x265. ?( 666psychos' Ryzen 5 1400 hätte ich ja eigentlich auch eher vor meinem Hexcore erwartet. Wär er vielleicht auch gewesen, wenn da ned Windows vs. Linux noch eine Rolle gespielt hätte? Und der FX-9590 schaut unter FreeBSD UNIX auch verdammt schnell aus. Hmm.

    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!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (20. November 2017 um 08:32)