Sie sind nicht angemeldet.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

261

Donnerstag, 27. April 2017, 21:19

PAE

Kurzfassung:

32-Bit:
  1. Ein 32-Bit Programm kann niemals mehr als 4GiB RAM adressieren, weil nur 32-Bit Datentypen und Adressbus nutzbar sind.
  2. "Richtige" Betriebssysteme teilen den Speicher in Kernel Space und User Space, aus Sicherheitsgründen. Das schränkt den für Userprogramme verfügbaren Speicher weiter ein.
  3. Üblicherweise ist die Aufteilung 1:1: 2GiB für User, 2GiB für Kernel. Man kann das Verhältnis beeinflussen, z.B. zu 3GiB User, 1GiB Kernel, auch mit Windows, per Boot-/Kernelparameter.
  4. Um die Bitness zu erhöhen (Kernel wie User) müßte alle Software komplett neu gebaut und evtl. umgeschrieben werden. Einem 32-Bit Programm "einfach so" mehr RAM als theoretisch 4GiB zu geben ist vollkommen unmöglich.

PAE:
  1. PAE fügt 4 weitere Adressbusbits hinzu, also 36 Bits statt 32 Bits. Programme sind aber weiterhin 32-bittig, die Limitierung bleibt. Nur 232 Elemente (Bytes) sind für so ein Programm adressierbar.
  2. Was also tun diese 4 Bits? Sie bilden einen "sekundären" Adressbus, der 24=16 Elemente ansprechen kann. Userprogramme wissen davon nichts und können davon nichts wissen. Nur die Hardware und ein entsprechend angepaßter Kernel "kennen den Trick". Ein Kernel der kein PAE beherrscht bedeutet im Endeffekt, daß PAE nicht funktioniert (z.B. Windows NT 4 und früher).
  3. Diese 16 Elemente bilden "Speicherfenster", die von einem Kernel dynamisch zugewiesen werden können. Mittels der 4 Bits "mapped" der Kernel den User- und Kernel-RAM einzelner Prozesse in unterschiedliche Bereiche des virtuellen, und letztendlich physikalischen Speichers.
  4. Applikation A kann also 2GiB fressen, Applikation B kann 2GiB fressen, Applikation C und D, E und F ebenso. Das macht z.B. 16GiB in Summe.
  5. Weder Applikation A, noch B noch sonst eine kann individuell mehr RAM als im Userspace Adressfenster verfügbar fressen, üblicherweise 2GiB unter Windows und Linux.
  6. Auf einem 64-Bit System kann eine 32-Bit Applikation (unter Windows: nur eine, die mit LAA Bit kompiliert ist) volle 4GiB fressen. Das ist allerdings mehr oder weniger ein "Sonderfall", nur auf einem 64-Bit System kann ein 32-Bit Programm seinen vollen Speicherbereich wirklich ausreizen (Das ist auch der Grund, warum es 32-Bit Spiele gibt, die dennoch ein 64-Bit Betriebssystem voraussetzen).

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].

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »GrandAdmiralThrawn« (27. April 2017, 21:26)


Tweakstone

Rampage

Beiträge: 14 459

Wohnort: Versmold City

Beruf: IT-System Elektroniker

  • Nachricht senden

262

Freitag, 28. April 2017, 06:54

bzw. einem einzelnen Prozeß.

Haha oh man ist mein Gehirn behindert :D
Mein erster Gedanke vor dem Kommentar war "Thread", da hab ich mich sofort gedanklich korrigiert "junge, du meinst _Prozess_".. um Sekunden später wieder "Thread" zu schreiben :D xD

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

263

Freitag, 28. April 2017, 08:29

Hm..

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.

11:57:57.251 | GAT | 1/6/6 | Intel Core i7 980X 3.33GHz (no HT) | ASUS P6T Deluxe V2 | 16GB DDR-III/1333 CL9 | Windows XP x64 on VBox 5.1.2/CentOS 6.9 Linux

07:55:19.303 | GAT | 2/4/4 | Intel Xeon E5430 2.66GHz | ASUS DSBV-D | 17GB DDR-II FBDIMM | CentOS 6.8 Linux

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...

Source code

1
2
3
#ifdef ENABLE_DYNAMIC_HDR10
    #include "dynamicHDR10\hdr10plus.h"
#endif

wird...

Source code

1
2
3
#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:

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:

Source code

1
2
3
4
5
6
-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+:

Source code

1
2
3
4
5
6
-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

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von »GrandAdmiralThrawn« (28. April 2017, 11:03)


264

Freitag, 28. April 2017, 16:55

Ich hatte ja hier mal die alpha5 mit dem i7 getestet:
Ein aktueller alpha5-Testlauf unter Windows 10:

06:16:29.388 | xxx** | 666psycho | 1/4/8 | Intel Core i7 4790 3,6GHz | MSI H97M Eco | Intel H97 | 20GB DDR3/1600 | Windows 10 x64


Aktuell läuft die Kiste die Beta1 mit der aktuelleren x265 2.4-2 (10 bit) durch, um einen Vergleich zu haben.

Bzgl. PAE, das Thema hatten wir doch schon zu Beginn des Threads mit Bier :D - einfach mal auf Seite 1 ganz nach unten gucken

265

Freitag, 28. April 2017, 18:46

Hier das Ergebnis mit der neueren x265 2.4, um genau zu sein diese hier: http://x265.ru/soft/x265/GCC/x265[gcc]_2.4+2_64-10bit.zip

05:13:16.853 | 666psycho | 1/4/8 | Intel Core i7 4790 3,6GHz | MSI H97M Eco | Intel H97 | 20GB DDR3/1600 | Windows 10 x64 (x265[gcc]_2.4+2)

Hatte sich das Video nochmal geändert zwischen Alpha5 und Beta1? Dann müsste ich zum Vergleich noch einen normalen Beta1-run machen nehme ich an.

Edit: noch die results mit angehängt / die Konsolenausgabe hab ich vergessen zu speichern - um das launchbenchmark-script auszuführen musste ich aber die Prüfsummenchecks für die x265-NT6.1+.exe und für das launchscript selbst rauslöschen, damit es funktioniert hat :topmodel:
»666psycho« hat folgende Datei angehängt:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »666psycho« (28. April 2017, 18:48)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

266

Freitag, 28. April 2017, 19:11

x265

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):

06:24:33.687 | GAT | 1/6/12 | Intel Xeon X5690 3.47GHz | 6GB DDR-III/1066 8-8-8-20 2T | ASUS P6T Deluxe | Windows XP Pro x64 SP2 (closed Beta 2, x265 2.4+2-5bc5e73760cd)

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]? :rolleyes:

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

267

Samstag, 29. April 2017, 13:36

Rehash funktioniert auch unter windoof in der Kommandozeile:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
x265benchmark>launch_x265benchmark.bat --rehash

launch_x265benchmark aufgerufen um 13:26 am 29.04.2017!

Führe initiale Prüfungen aus:

colorecho............................. OK [`.\bin\colorecho.exe`]
VC++ 2010 Laufzeitbibliotheken........ OK ['C:\WINDOWS\System32\MSVCP100.DLL']
  NOTIZ: `.\bin\colorecho.exe` und VC++ Redistributable erkannt, wechsle zu
  Farbausgabe auf der Konsole.

Creating new checksums file based on current data...

DONE

Drücken Sie eine beliebige Taste . . .


Wegen der Laufzeit, ich finde die eigentlich noch ok? Gute 5h für einen halbwegs aktuellen Quadcore mit HT reichen doch, oder nicht? Wobei es natürlich interessant wäre zu wissen, wie lange ein aktueller 8 Kerner (Ryzen 1700, i7 6900k oder ähnlicher Xeon) braucht.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

268

Samstag, 29. April 2017, 16:15

Laufzeiten

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. :)

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

269

Samstag, 29. April 2017, 16:48

@ GAT
Danke. Folgendes habe ich noch zum Thema gefunden:
https://www.quora.com/Linux-Kernel-What-…d-normal-memory
Die Funkion ist mir jedenfalls jetzt klar; der RAM wird ab 4GB in weitere bis zu 4GB Blöcke eingeteilt und
Prozesse können jede dieser "Schubladen" über die PAE-Verwaltung nutzen.

Was mich irgendwie verwirrt: Sind "PAE Kernel" und "HighMemory Kernel" von der Bedeutung identisch?
PAE Kernel ist logo, bietet eben PAE Unterstützung, HighMemKernel sind
1. Kernel, die den Kernelspace in den Bereich über dem Userspace anlegen und nutzen?
2. Kernel, die eine Verwaltung von mehr als 1GB ermöglichen?

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

270

Donnerstag, 4. Mai 2017, 09:21

NUMA Shit

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... :grr:

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

01:54:45.494 | GAT | 2/8/16 | Intel Xeon E5-2620 v4 2.1GHz | 64GB Reg. ECC DDR-IV/2133 | HP ProLiant DL360 G9 | Intel C610 Wellsburg | CentOS 7.3 Linux (GCC 4.8.5)

Das is schon recht flott vonstatten gegangen... Fast ein bissl zu flott.
»GrandAdmiralThrawn« hat folgende Datei angehängt:
  • RESULTS.txt (3,31 kB - 2 mal heruntergeladen - zuletzt: 4. Mai 2017, 10:42)

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GrandAdmiralThrawn« (4. Mai 2017, 10:50)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

271

Donnerstag, 4. Mai 2017, 11:19

NUMA Update

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:

01:41:59.584 | GAT | 2/8/16 | Intel Xeon E5-2620 v4 2.1GHz (NUMA) | 64GB Reg. ECC DDR-IV/2133 | HP ProLiant DL360 G9 | Intel C610 Wellsburg | CentOS 7.3 Linux (GCC 4.8.5)

01:42:29.381 | GAT | 2/8/16 | Intel Xeon E5-2620 v4 2.1GHz (no NUMA) | 64GB Reg. ECC DDR-IV/2133 | HP ProLiant DL360 G9 | Intel C610 Wellsburg | CentOS 7.3 Linux (GCC 4.8.5)

Der QPI Link lief hier mit 8GT/s.

Edit: Es ändert sich nun doch einiges auf dem Weg zur Beta 2...
  • ALLE: Parallelität: --pmode und --pme werden entfernt und zur Sicherheit gleich durch --no-pmode und --no-pme ersetzt. Das löst ein Problem mit aktivem NUMA auf QPI und HyperTransport Systemen, wobei viel zuwenige Kerne ausgelastet wurden. Betroffen waren hiervon Windows 7 oder neuer sowie Linux.
  • ALLE: Parallelität: --lookahead-threads für Maschinen mit >=32 logischen CPUs wird komplett entfernt. Die Einstellung reserviert Kerne für Lookaheads, was die Auslastung problematisch werden läßt, weil dort sonst kein Code mehr drauf darf. Damit kann es zu stellenweisen Leerläufen auf einigen Kernen/Threads kommen. Ohne genaue, reale Manycore Tests/konkrete Statements von Seiten der Entwickler kann ich keine Lookahead Threads umsetzen. Schwer zu sagen wie man da vorgehen sollte. Im Fall des Falles bleiben sie einfach draußen (so wie pmode und pme), was dem Normalverhalten von x265 entspricht. Für Systeme mit extrem vielen Kernen natürlich ein Nachteil.
  • UNIX: Bootstrapper: C++ Compilererkennung löst keinen Fehler bei Fehlen eines C++ Compilers aus, solange ein C Compiler vorhanden ist. Das wurde durch eine Zusatzabfrage gefixed. Kein sehr schöner Code aktuell, die Compilerdetektion, aber immerhin funktioniert's jetzt so halbwegs.
  • UNIX: Fehler in der cleanUp() Funktion des Benchmarkskripts behoben. Bei mehrfachem Ausführen konnte das zu einem massiven Fehler beim Erzeugen & Auswerten der Framestatistik führen, weil das Ausgabeverzeichnis nicht korrekt bereinigt wurde.
  • ALLE: Speichernutzung: B-Frames von 8 auf 4 reduziert. Tut mir innerlich nicht mehr so weh wie die Reduktion von 16 auf 8. ;) Das sichert das Einhalten der 16GiB RAM-Grenze auf Systemen mit deutlich mehr Kernen, zumindest bis ~64 logischen CPUs.
  • ALLE: Bitrate erhöht, um die schnellere Laufzeit zu kompensieren, die von --pmode und --pme, sowie --bframes 4 verursacht wird. Aktuell teste ich eine Erhöhung auf 15000kib/s, statt 10000kib/s.
  • UNIX: Festplattenspeicherverbrauch von 600MiB auf 800MiB erhöht.

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!

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »GrandAdmiralThrawn« (5. Mai 2017, 15:51)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

272

Dienstag, 9. Mai 2017, 11:43

Neuer Server

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:

Source code

1
--subme 7 --merange 92 --max-merge 5 --rc-lookahead 60 --bitrate 25000


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.

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »GrandAdmiralThrawn« (9. Mai 2017, 11:59)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

273

Donnerstag, 11. Mai 2017, 10:26

Anzeige

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!):

Source code

1
[1.1%] 9/800 frames, 0.04 fps, 80137.41 kb/s, eta 5:10:16


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.

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GrandAdmiralThrawn« (11. Mai 2017, 10:37)


274

Sonntag, 14. Mai 2017, 11:16

Interessant, was sich alles getan hat, freut mich, dass sich die NUMA-Problematik nun gelöst hat :)

Ziehe mir gerade den Beta2candidate vom 9.5. und lasse den dann bei Gelegenheit mal auf dem i7 losrennen. Sollte der nun etwas länger brauchen, als die Beta1?

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

275

Sonntag, 14. Mai 2017, 18:16

8K

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.

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

276

Dienstag, 16. Mai 2017, 11:21

Weiterführende Optimierungen

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

source/input/input.h:30

Source code

1
#define MAX_FRAME_HEIGHT 4320

SO nicht, daher:

source/input/input.h:30

Source code

1
#define MAX_FRAME_HEIGHT 4608

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):

source/encoder/encoder.cpp:139

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if (!p->bEnableWavefront)
    p->frameNumThreads = X265_MIN3(cpuCount, (rows + 1) / 2, X265_MAX_FRAME_THREADS);
else if (cpuCount >= 128) // 128 or more   
    p->frameNumThreads = (p->sourceHeight > 2000) ? 16 : 13;
else if (cpuCount >= 64)  // 64-127
    p->frameNumThreads = (p->sourceHeight > 2000) ? 12 : 10;
else if (cpuCount >= 32)
    p->frameNumThreads = (p->sourceHeight > 2000) ? 8 : 6; // dual-socket 10-core IvyBridge or higher
else if (cpuCount >= 16)
    p->frameNumThreads = 5; // 8 HT cores, or dual socket
else if (cpuCount >= 8)
    p->frameNumThreads = 3; // 4 HT cores
else if (cpuCount >= 4)
    p->frameNumThreads = 2; // Dual or Quad core
else
    p->frameNumThreads = 1;

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:

source/encoder/encoder.cpp:138

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
        if (!p->bEnableWavefront)
            p->frameNumThreads = X265_MIN3(cpuCount, (rows + 1) / 2, X265_MAX_FRAME_THREADS);
        else if (cpuCount >= 128) // 64 cores with SMT or 128 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 16 : 13;
        else if (cpuCount >= 112) // 56 cores with SMT or 112 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 15 : 13;
        else if (cpuCount >= 96)  // 48 cores with SMT or 96 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 14 : 12;
        else if (cpuCount >= 80)  // 40 cores with SMT or 80 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 13 : 11;
        else if (cpuCount >= 64)  // 32 cores with SMT or 64 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 12 : 10;
        else if (cpuCount >= 56)  // 28 cores with SMT or 56 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 11 : 9;
        else if (cpuCount >= 50)  // 25 cores with SMT or 50 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 10 : 8;
        else if (cpuCount >= 44)  // 22 cores with SMT or 44 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 9 : 7;
        else if (cpuCount >= 32)  // 16 cores with SMT or 32 cores
            p->frameNumThreads = (p->sourceHeight > 2000) ? 8 : 6;
        else if (cpuCount >= 24)  // 12 cores with SMT or 24 cores
            p->frameNumThreads = 7; 
        else if (cpuCount >= 20)  // 10 cores with SMT or 20 cores
            p->frameNumThreads = 6; 
        else if (cpuCount >= 16)  // 8 cores with SMT or 16 cores
            p->frameNumThreads = 5; 
        else if (cpuCount >= 12)  // 6 cores with SMT or 12 cores
            p->frameNumThreads = 4; 
        else if (cpuCount >= 8)   // 4 cores with SMT or 8 cores
            p->frameNumThreads = 3;
        else if (cpuCount >= 4)   // 2 cores with SMT or 4 cores
            p->frameNumThreads = 2;
        else                      // 1 core with SMT or 1-3 cores
            p->frameNumThreads = 1;


Die ternary Conditionals lasse ich drin bzw. führe ich mit weiter, auch wenn für uns eigentlich unnötig (weil im Fall des x265 Benchmarks WPP sowieso immer aktiv is, der Fall "ohne WPP" also gar nicht eintritt), aber schadet ja nicht. Also:
  • 1-3 logische CPUs: 1 Frame Thread
  • 4-7 logische CPUs: 2 Frame Threads
  • 8-11 logische CPUs: 3 Frame Threads
  • 12-15 logische CPUs: 4 Frame Threads
  • 16-19 logische CPUs: 5 Frame Threads
  • 20-23 logische CPUs: 6 Frame Threads
  • 24-31 logische CPUs: 7 Frame Threads
  • 32-43 logische CPUs: 8 Frame Threads (Hierüber hinaus spawned das originale x265 keine weiteren Frame Threads mehr)
  • 44-49 logische CPUs: 9 Frame Threads
  • 50-55 logische CPUs: 10 Frame Threads
  • 56-63 logische CPUs: 11 Frame Threads
  • 64-79 logische CPUs: 12 Frame Threads
  • 80-95 logische CPUs: 13 Frame Threads
  • 96-111 logische CPUs: 14 Frame Threads
  • 112-127 logische CPUs: 15 Frame Threads
  • >=128 logische CPUs: 16 Frame Threads (entspricht dem Maximum in Konstante X265_MAX_FRAME_THREADS)


Hat nieeemand eine Maaaaschiiiine mit 256 hübschen CPUs für miiich? :rolleyes:

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »GrandAdmiralThrawn« (16. Mai 2017, 20:34)


hutzeputz

VA Clan Enemy Territory

Beiträge: 12 713

Wohnort: bayern

Beruf: Tz Ma

  • Nachricht senden

277

Dienstag, 16. Mai 2017, 21:13

Aktuelle Version ist jetzt...? Dann teste ich nochmal....
x200-21U

3dfx-voodoo.de

Windows Sever 2008 R2 Standart / 2x AMD Opteron 2419EE 6-Core / 8x 4 GB PC2-6400R ECC REG / MSI K9ND Speedster2

Ut Cache Cleaner 3

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

278

Dienstag, 16. Mai 2017, 21:22

x265

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!

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GrandAdmiralThrawn« (16. Mai 2017, 21:24)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 857

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

279

Mittwoch, 17. Mai 2017, 19:47

Hilfe bitte!

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:

  1. wmic ComputerSystem GET NumberOfProcessors

  2. CoreInfo -n

  3. CoreInfo -s


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.

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »GrandAdmiralThrawn« (17. Mai 2017, 19:50)


280

Mittwoch, 17. Mai 2017, 22:26

Mit Dual-Sockel Systemen kann ich leider nicht dienen. Aber dann warte ich mit dem nächsten Testlauf mal, bis die neue Beta bereitsteht, wenn sich da jetzt eh noch viel geändert hat.

Ähnliche Themen