Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

Kurzfassung:

32-Bit:

Sprich: 4 Bits, die maximal 64GiB RAM in 16 × 4GiB 32-Bit Fenster aufteilen. Der Sinn dahinter: Daß 32-Bit Server länger überleben können, weil nun mehrere größere Serverdienste (SQL Server, Webserver, usw.) nebeneinander leben können, ohne sich ein einzelnes 4GB Fenster noch dazu mit dem Kernel teilen zu müssen.

Wie Tweakstone schon sagte ändert das aber nichts an den fundamentalen Limitierungen von 32-Bit Binärcode. Maschinencode der nur 32 Bits kennt, kann über diesen Tellerrand eben nicht hinausschauen. Man kann mehrere von denen nebeneinander im selben Land leben lassen (=PAE), aber das war's dann auch schon.

Das beleuchtet noch lange nicht, wie der Adressbus bzw. das virtuelle Speichersystem wirklich arbeiten, aber es macht evtl. ein bißchen was klar.

Edit: [Wikipedia zum Thema PAE].

Der Verdreher is mir auch schon mehr als einmal passiert, wurscht.

Unterdies sind mein XP x64 Retest und der Core 2 Test durch, aber irgendwie war er im Windows langsamer als zuvor? Das sollte so eigentlich nicht sein. Aber ich weiß auf dieser Kiste halt nie ob ned einfach andere VMs und Prozesse zuviel reingepfuscht haben...

Auch der Unterschied zum Run unter Linux is irgendwie ein wenig zu groß, die beiden sollten näher beieinander liegen.. Hm.

Ich müßte Mal nativ Windows mit Linux vergleichen, auf der selben Box. Oder daheim laufen lassen auf'm Xeon mit XP x64...

Edit: Inzwischen, abseits von der etwas aufwendigen Migration und den Tests von x265 2.4+2...

1.) UNIX: Quellcodeheader source/encoder/encoder.h unter UNIX gefixed, hier haben die x265 Entwickler mit Version 2.4 einen windowsspezifischen Ordnerseparator reingeschmuggelt, was den Bau auf *NIX bricht (Patch ist schon submitted, aber noch nicht live, wir fixen das selbst):

Aus...

#ifdef ENABLE_DYNAMIC_HDR10    #include "dynamicHDR10\hdr10plus.h"#endif

wird...

#ifdef ENABLE_DYNAMIC_HDR10    #include "dynamicHDR10/hdr10plus.h"#endif

...und die Dokumentation ist aktualisiert. Im Rahmen des Benchmarks wird der HDR10+ Anteil zwar gar nicht gebaut, aber sowas grausiges kann ich da einfach nicht stehen lassen.

2.) WINDOWS: VC++ 2015/2017 Detektion zusätzlich zur VC++ 2010 Detektion eingebaut (colorecho.exe verlangt nach VC++ 2010, x265.exe nach der VC++ 2015/2017, beide sind auch für XP x64 verfügbar). Ich poste die Links hier auch Mal rein:

• [Visual C++ 2010 Redistributable]
• [Visual C++ 2015 und 2017 Redistributable]

Die meisten Leute haben's normalerweise sowieso schon am System, weil es ja viel Anwendungssoftware und Spiele gibt, die diese Runtimes gleich mitinstallieren.

3.) WINDOWS: Aktualisierte x265 CMake Buildkonfiguration (sowie Update von CMake 2.8.12.1 auf 3.8.0):

Klassische x265 Version für XP x64 und Vista x64:

-T "v141_xp" -DCMAKE_BUILD_TYPE="Release"^-DCMAKE_CONFIGURATION_TYPES="Release" -G "Visual Studio^15 2017 Win64" -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF^-DWINXP_SUPPORT=ON -DENABLE_SHARED=ON -DENABLE_CLI=ON^-DENABLE_ASSEMBLY=ON -DMAIN12=OFF -DWARNINGS_AS_ERRORS=ON-DCMAKE_VS_PLATFORM_TOOLSET=v141_xp

Moderne x265 Version für Windows 7+:

-T "v141" -DCMAKE_BUILD_TYPE="Release"^
-DCMAKE_CONFIGURATION_TYPES="Release" -G "Visual Studio^
15 2017 Win64" -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF^
-DENABLE_SHARED=ON -DENABLE_CLI=ON -DENABLE_ASSEMBLY=ON^
-DMAIN12=OFF -DWARNINGS_AS_ERRORS=ON
-DCMAKE_VS_PLATFORM_TOOLSET=v141

4.) Einige kleinere Bugfixes bei der Windows Version und ein wenig Dokumentationsaktualisierung.

5.) WINDOWS: UTF8-CPP Lizenz hinzugefügt (für die UTF8-CPP Library in MKVToolnix, unter UNIX liegt selbiges nicht bei).

6.) WINDOWS: nice.exe Programm und Aufruf entfernt. Nach Inspektion des Quellcodes ist klar, daß x265 seine Niceness selbst korrekt setzt (nicht auf Prozeßebene, aber auf Threadebene).

7.) Tests

8.) Mehr Tests

x265 kannst du ersetzen (das ist zulässig für "inoffizielle" Resultate), indem du vor dem eigentlichen Benchmark rehashed: `.\launch_x265benchmark.bat --rehash´. Dann brauchst den Code nicht zu ändern. Siehe `.\launch_x265benchmark.bat --help´.

Das Video ist identisch zwischen Alpha 5 und Beta 1, die De- & Encodereinstellungen auch, bis auf einen kleinen Bugfix. Die Laufzeit ist nur wegen des neueren, schnelleren x265 Encoders anders. Mein X5690 Test ist jetzt auch durch, und bestätigt mir, daß meine VM im Test oben einfach nur zuviel Mitstreiter auf der CPU hatte (und daß x265 2.4 wirklich merklich mehr Dampf macht):

Der Test ist jetzt fast einen Hauch zu flott. Eventuell drehe ich die B-Frames noch Mal einen Satz runter um ganz auf Nummer sicher zu gehen was den RAM angeht, und hebe dafür die Bitrate um die ungefähre vormalige Laufzeit wiederherzustellen.

PS.: Bin ich eigentlich der einzige Spinner, der Windows XP-kompatible x265 Releases im Netz [rausgibt]?

Die Laufzeitbalance zu finden ist keine leichte Aufgabe, vor allem weil es eine Lösung für alles sein soll. Ich will einen Dual Socket Server mit 2 × 32 Kernen und 128 Threads nicht all zu sehr unterfordern. Ich will aber auch einen normalen Desktopuser nicht all zu sehr ÜBERfordern. Die Breite des Leistungsspektrums ist einfach ziemlich groß. Was bei mir 6½h dauert, sollte eher so knapp 10h brauchen, dachte ich.

Ich meine, überleg Mal, du hast da einen Haswell Quadcore, der liefert in gut 5h ab. Was macht dann eine Maschine mit 64 Kernen? Die wäre 16 Mal so schnell? Ok, nehmen wir an der Takt wäre niedriger und wir haben noch abnehmenden Ertrag zu fürchten (nicht daß ich WISSEN würde, ob ich so viel überhaupt wirklich auslasten kann), aber seien wir konservativ, und sagen wir "Faktor 10".

Dann haut der das in nur 30min raus, und solche Maschinen wird's schon 2017 geben, bzw. so ähnliche gibt's ja jetzt schon, bei Intel halt (20 & 24 Kerne).

AH, aber ich sehe, beim Rehash gibt's ein Sprachmischmasch! Den entsprechenden Kosmetikfix werd ich dann am Dienstag gleich einpflegen.

Also das is echt geil. Umlüx hatte ja schon Probleme mit NUMA Support auf seinem HP Bladecenter mit dem 2-Sockel Blade, und ich hab grade einen brandneuen HP ProLiant DL360 Gen9 hier, also Broadwell. 2 × E5-2620 v4. Betriebssystem ist CentOS 7.3 Linux, x86_64 natürlich. Also quasi das neueste RedHat Enterprise Linux. Die Kiste unterstützt das sogar offiziell! (!)

x265 ist hier ganz brav dabei, NUMA zu erkennen und die Info-Ausgabe schaut absolut sauber aus. Zwei Pools (einer pro Sockel) und genug Threads pro Pool. Nur... Das Endergebnis ist noch desaströser als auf dem modernen Windows Server. Der lastet grade Mal 2 Kerne aus und ist langsam wie Schwein. Untragbar.

Also rein in's UEFI, NUMA Topologie von Clustered auf Flat, Node Interleaving auch noch an (glaub ned nötig bei Flat, aber egal), was NUMA definitiv abdreht. Jetzt spawned x265 30 Threads, und belastet auch meistens "nur" 30 logische CPUs. Ab und zu geht er dann rauf auf 32 für ein paar Sekunden, dann wieder 30, hin und wieder frißt auch ffmpeg einen Kern weg, wenn er wieder einen Schub Daten in die Pipe reindekodiert, damit x265 genug zu fressen hat.

Ned perfekt, aber "recht ok".

Aber das NUMA Desaster is mir unerklärlich. Ich werde die Weiterentwicklung bis auf wichtige Bugfixes stoppen, bis das geklärt ist. Eine Anfrage an die x265 Entwickler ist gestellt. Vielleicht isses ja Mal wieder das "großartige" UEFI von HP, das hier irgendwie Schuld trägt, keine Ahnung. Auf jeden Fall katastrophal. Ich kann Usern ja schlecht sagen daß sie auf ihren Kisten das ganze NUMA verpfuschen müssen damit's rennt...

Edit: Wie auch immer, hier ist die Kiste mit 2.4+2 und mit deaktiviertem NUMA:

Doublepost!

Mario Rohkrämer aus der Entwicklermailingliste hat mir empfohlen, die Parallelisierungsoptionen --pmode und --pme für das Wave-Front Parallel Processing wegzulassen, da das angeblich ohnehin selten was hilft, und sich oft sehr eigenartig und fehlerhaft verhalten soll. Um ganz sicher zu gehen, habe ich das durch --no-pmode --no-pme ersetzt, NUMA reaktiviert und den Test neu gestartet.

Anfangs sah es mies aus mit wieder nur 200% CPU (2 Threads), aber nach 10-20 Sekunden hat er angefangen richtig Gas zu geben und die Maschine konstant auszulasten. Das verändert natürlich auch die Laufzeit ein klein wenig.

Ich werde (zwecks der Neugierde) mit diesen neuen Einstellungen jetzt einmal MIT und einmal OHNE aktives NUMA benchmarken, weil jetzt will ich wissen was das wirklich bringt! In der Theorie sollten dadurch ja der Speicherdurchsatz und vor allem die reale Zugriffszeit auf den RAM deutlich sinken.

Diese neuen Optionen werde ich aber wohl in jedem Fall übernehmen müssen. Eine leichte Bitratenanpassung soll auch noch stattfinden.

Die Ergebnisse poste ich hier rein, sobald verfügbar.

Edit: Und hier haben wir das Ergebnis mit --no-pmode --no-pme, und zumindest bei zwei Sockeln scheinen die höhere Latenz bzw. der geringere Durchsatz bei Deaktivierung von NUMA kaum eine ernste Rolle zu spielen. Diese Optionen waren offenbar generell kompletter Schrott, weil sie (wie einige Leute nun auch angemerkt haben) meistens eher alles langsamer machen:

Ein aktuell noch bleibendes Problem ist das Rehashing unter Windows, das zuviele Dateien mitmacht, auch solche die der Nutzer gar nicht ändern darf. Das gehört noch in ein separates Skript ausgegliedert, was bei der UNIX Version bereits passiert ist.

Zudem erkennt der UNIX Bootstrapper keine Compilergemische. Wer also den gcc ohne g++ im Suchpfad hat, dafür aber einen clang++, der wird wahrscheinlich in ein Minenfeld reinlaufen. Diesen Fall werde ich wohl nicht abfangen. Wer sowas hat/macht, soll's gefälligst selber durch Setzen der CC und/oder CXX Variablen richten!

So, mit ein bißchen Bitratenerhöhung war es nicht getan. Der Benchmark ist nach Abändern einiger der Optionen so unverschämt schnell, daß ich die Bitrate direkt hätte versechs- bis verachtfachen müssen. Weil das aber größere Files erzeugt (was ich nicht unbedingt will), habe ich einen Mittelweg gewählt, und den Lookahead sowie die Motion Estimation Schwierigkeit erhöht, zusätzlich zu einer moderaten Steigerung der Bitrate um Faktor 2.5×. Die neuen Optionen sind:

Zudem gibt es noch eine Änderung, und zwar werden alle Releases künftig per anonymem FTP anstatt HTTP verlinked (HTTP nur mehr als Fallback). Das ist im Falle meines Servers deutlich schneller, sodaß man etwas mehr Bandbreite rausbekommt. Zudem gibt es Browsingzugriff, man kann sich also bequem alle Files anschauen. Das hat auch eine Änderung am Dateisystem am Server nach sich gezogen, alle HTTP Links in diesem Thread sollten aktualisiert sein. Wenn noch welche gebrochen sind, bitte ich mir das einfach mitzuteilen.

Der FTP steht hier zur Verfügung (Anon Zugriff mit beliebigem Passwort), die Ordnerstruktur is ein bißchen ein Kack, aber wurscht:

[x265 Benchmark FTP Zugriff]

Dort findet ihr ggf. auch Zwischenreleases bzw. Candidates, die im Forum so nicht zu finden sind.

Achtung: Nur 3 gleichzeitige Zugriffe pro IP bitte, und passives FTP! Weitere Verbindungen werden dropped. Wer multi-conn Hammering betreibt, wird automatisch banned! Wer sich benimmt, wird kein Problem haben.

Edit: Wer möchte, kann auch z.B. per explizitem SSLv3 oder TLSv1.2 auf den FTP zugreifen.

Eine weitere, nette kosmetische Verbesserung: Der Encodingparameter --frames wird jetzt im Transcodingskript gesetzt. Damit zeigt er jetzt beim Benchmark pro Pass eine kleine Fortschrittsanzeige und eine nützliche ETA mit an (Mir gefällt das!):

Neben dem wird --pmode --pme doch wieder eingeführt. Ich weiß nicht, welches kleine Knöpfchen es war, aber irgendwie bin ich die NUMA Probleme los geworden. Das ist ausgesprochen nützlich, denn einer der x265 Entwickler hat bereits 64-Kern Tests damit ausgeführt, und es scheint der Parallelität doch zugute zu kommen, wenn diese Optionen gesetzt sind. Ohne das zeigen sich scheints erste Abstriche ab 64T.

--subme 7 --merange 92 --max-merge 5 --rc-lookahead 60 müssen wieder raus, das Aufblasen des Raumes für Motion Estimation und der größere "Blick in die Zukunft" für Lookaheads kosten zuviel RAM! Daher muß statt dessen doch die Bitrate aufgeblasen werden.

Jo also, ich habe da noch rumgepfuscht, die Laufzeit wird in jedem Fall abweichen, das gehört noch tuned.

Aktuell bin ich grade dabei, den Content auf die maximale Auflösung zu skalieren, bzw. den Test dafür zu adaptieren. Bei Versuchen hat sich herausgestellt, daß ich mit 4K schon Probleme habe, 32 Threads dauerhaft vollzumachen. 8K ist natürlich die vierfache Bildgröße, aber da man von linearer Skalierung ja eher nicht ausgehen kann, wäre es schon gut denkbar, daß es ab 128 Threads ernsthaft eng wird mit der Auslastung.

Daher gehe ich auf's Maximum was der H.265 Standard zuläßt, also nicht wie bisher die 8192×3428, sondern 8192×4320. Damit kann das Wavefront Parallel Processing 270 Rows statt nur 214 nutzen, sollte die Parallelität auf Manycore Kisten noch etwas stützen. Da große Frames natürlich auch wieder mehr RAM fressen, bin ich grade wieder beim Speichertuning.

Ich fürchte ich werde das doch aufsplitten müssen. Also mit 16 logischen CPUs und weniger reichen 16GiB RAM, und mit mehr verlange ich dann halt 20GiB oder sowas. Die Langlebigkeit ist mir einfach am wichtigsten.

Die Beta 2 wird wohl nicht Public, sehe das mittlerweile mehr als Zwischenversion. Auch wenn an den Kernfeatures wirklich nichts mehr geändert wird, am Tuning isses doch einiges. Die B-Frames habe ich zwischen 2-8 getestet, und bleibe jetzt wohl bei 2. Als zweiten Speicherfresser habe ich den Lookahead identifizieren können, womit der auf's Minimum an Frames reduziert wird (B-Frames + 1). Also aktuell teste ich grade --rc-lookahead 3 --bframes 2.

Aber der wahre Grund für die weitere Reduktion ist der, daß ich daran festhalten möchte, auf 16:9 zu gehen, also 8192×4608. Da das aber eben den H.265/HEVC Standard verletzt, quittiert x265 das für Y4M Input mit einem Abbruch (für rohen YUV Input interessanterweise nicht). Da ich den Standard mit 16×16 Pixel CTUs für die Einstellungen des Benchmarks aber sowieso schon verletze, dachte ich mir "pfeifst drauf, das läßt sich wohl im x265 Quellcode ändern":

In einem kurzen Moment aufflackernden Wahnsinns habe ich Mal 8192×8192 getestet, aber das quittiert x265 mit einem Crash. War wohl zuviel des extremen. Mit 8192×4608 sind jetzt jedenfalls 288 WPP Reihen drin, statt der 214 der Beta 1, also eine gesteigerte Parallelität.

Zuerst genannte Einstellungen sind also in erster Linie dazu da, den nun noch schlimmeren Speicherverbrauch durch die nochmals höhere Auflösung einzudämmen. Aktuellen Tests zufolge schaut es so aus, daß es bis zu 64 logischen CPUs ein Auslangen mit 16GiB RAM gibt. Darüber muß ich dann definitiv 24GiB RAM verlangen.

Das führte mich im Code zur nächsten Seltsamkeit im Bereich des Frame-basierten Multithreadings. Also wieviele ganze Frames parallel abgearbeitet werden können. x265 unterstützt hier ein Maximum von 16 Frames (X265_MAX_FRAME_THREADS), das aber nur manuell zu erreichen ist. Laut dem C++ Code behandelt x265 nämlich nur 2, 4, 16 und 32+ Kerne, wobei für die letzte Stufe bei aktivem WPP 8 Frames parallel kodiert werden. Darüber wurden aber keine Einstellungen mehr justiert?! Warum?! Weil noch ungetestet? Wie auch immer, ich habe das für Fälle von 64-127 logischen CPUs sowie 128+ CPUs erweitert, in ersterem Fall werden 12 Frame Threads genutzt, im letzteren das Maximum von 16 (bei aktivem Wave-Front Parallel Processing):

Damit steigt die Parallelität nochmals weiter, und es müßte in jedem Fall klappen, zumindest 128 logische CPUs auszulasten (so hoffe ich zumindest). Wie das bei ~256 CPUs und mehr aussieht läßt sich leider nicht Mal mutmaßen. Ich fürchte aber, daß das ursprüngliche Ziel, bis zu 512 logische CPUs dicht machen zu können nicht ganz erreichbar sein dürfte... aber solange das kein Mensch getestet hat, kann man nicht Mal zu 128 CPUs eine wirklich klare Aussage treffen.

Vielleicht mache ich diese Framethreadskalierung auch noch ein bissl feingranularer.

Edit: Erledigt! Damit möchte ich verhindern, daß es zu einem "welligen" Auslastungsprofil kommt, wo er vielleicht 96 CPUs nicht mehr richtig auslastet, ab 128 aber schon wieder usw., weil er die Framethreads zu grob umschaltet (von 12 auf 16 in genanntem Fall). Statt dessen mache ich das jetzt feingranularer:

Public Beta 1, die ist allerdings weit hinter dem was ich grade baue, was Tuning und Laufzeit angeht. Ein neuer Test macht erst Sinn, wenn ich mit meinen ganzen Parallelisierungsverbesserungen am Code und den nötigen Performanceevaluierungen endlich Mal fertig bin, und die nächste Beta rauslassen kann. Da ich diese Woche auch sonst noch viel zu tun habe, kann ich nicht versprechen, daß es noch was wird. Eventuell erst nächste Woche, dann habe ich Zeit für ausgiebigere Evals und Regression / Bug Tests auf verschiedensten Systemen.

Ich will das nicht in die freie Wildbahn entlassen, sofern das nicht halbwegs solide ist!

Ich brauche eure Hilfe

Und zwar bräuchte ich einen oder zwei User (je nachdem), die Windows 7+ oder Windows Server 2008+ betreiben, und zwar auf 2-Sockel Maschinen. Die Crux:

Ich brauche eine Maschine, die keine NUMA Architektur hat, sondern einen klassischen FSB! Also sowas mit Sockel 603/604 oder 771 und Core 2 o.ä., kann auch eine alte 32-Bit Kiste sein, also auch Athlon MP reicht mir, solange das Betriebssystem modern genug ist. Und dann brauche ich eine zweite Maschine, die sehr wohl in NUMA aufgebaut ist, also eine Intel QPI oder AMD HyperTransport Kiste. Sockel 1366 oder neuer, irgendein dual AMD Opteron System, sowas.

Von beiden Maschinen bräuchte ich eine wmic Ausgabe, und Ausgaben des von Windows Hacker und Microsoftmitarbeiter Mark Russinovich entwickelten Tools [CoreInfo].

Folgende Kommandozeilenbefehle hätte ich gerne getestet gehabt, und ich bräuchte die jeweils kompletten Ausgaben davon:

Hintergrund: NUMA wird jetzt zwar von x265 korrekt erkannt, aber der Code ist zu dämlich, von selbst entsprechende Threadpools anzulegen. Statt dessen behandelt er NUMA Systeme nicht viel anders als "flache" Systemarchitekturen. Ich brauche einen Weg, um FSB Systeme von NUMA Systemen zu unterscheiden, und die Anzahl der NUMA Knoten auszulesen... Für Linux wird das relativ gut machbar (so hoffe ich Mal...), aber unter Windows kratze ich mich noch etwas am Kopf...

Zur Not muß ich mir den [NumaExplorer] Quellcode holen, und beinhart versuchen den Code für die CLI zu adaptieren. Glaube aber ned, daß ich sowas schaffen würde.