Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

Ah, und noch was: Zur NUMA-Geschichte: Das platzt, hutze. Grund ist, daß ich jetzt Statements von einem x265 Kernentwickler (Herrn Pradeep Ramachandran) bekommen habe, die klarstellen, daß dieses Verhalten zumindest unter Linux leider bekannt ist, also der Leistungsverlust beim Splitten von NUMA Pools. So gesehen ist der NUMA Support leistungstechnisch komplett sinnlos. Allerdings habe ich auch gelernt, daß man unter allen 64-bit Betriebssystemen nie mehr als 64 CPUs pro Prozess nutzen kann, es sei denn man erzeugt Prozessgruppen und/oder NUMA Pools. Für 32-bit sind's 32 CPUs. S.u.

Unter Windows gibt es das zusätzliche Problem, daß man bei aktivem NUMA scheinbar keinen Prozeß starten kann, der Threads über ALLE Numa Knoten (=Sockel!) spawned.

Hier muß eine Applikation also Threadgruppen bzw. NUMA Pools erzeugen. In jedem "Pool" gibt es einen separaten 32/64 Bits breiten Bitvektor, der die entsprechende Anzahl von CPUs innerhalb des Pools ansprechen kann. Darüber existiert ein weiterer Adressierer, der individuelle Pools bzw. Threadgruppen anspricht. Weil's im Pool ein Bitvektor ist, heißen 64 Bit hier eben nicht 2⁶⁴, sondern wirklich genau 64.

Die x265 Entwickler MUSSTEN also NUMA Pools unterstützen, um in der Zukunft überhaupt mehr als 64 CPUs ansprechen zu können, bzw. auf Windows auch, um überhaupt mehrere Sockel auf NUMA Systemen ansprechen zu können.

Laut Entwickler trifft x265 hierbei immer die bestmögliche Entscheidung, also NUMA Pools immer auf Windows, und niemals auf Linux, es sei denn es sind zuviele CPUs da, und es geht nicht mehr ohne.

Soviel dazu. Werde in diesem Bereich also NICHT eingreifen, mit Ausnahme von Haiku OS, weil dort muß ich, weil die Detektion der CPU Anzahl fehlschlägt.

666psycho: Am FTP liegen aktuell keine Public Releases, die nicht im ersten Post wären, deswegen steht er (noch!) nicht drin. Kommt noch. Und jo, die Settings sind noch nicht optimal angepaßt!

Ich habe aktuell ein wenig Zeit für macOS Sierra verbraten, hier funktionierte der Bootstrapper super (langsam, weil noch nicht viele Binärpakete in Homebrew, aber er hat alles fehlende super nachkompiliert, dauert nur etwas). Der eigentliche Benchmark jedoch hat Schwächen in meiner Apple Unterstützung (und enorme Seltsamkeiten in Mac OS X' Speicherverwaltung) aufgedeckt.

Das hat etwas Zeit gekostet, aber Mac OS X / macOS ist das zweite große, kommerzielle Desktop OS, daher wollte ich neben Windows 10 halt auch Sierra unterstützt wissen, auch wenn ich persönlich die Nutzung beider Betriebssysteme nur wenig gutheiße. Unterstützt gehören's trotzdem.

Grindhavoc: Hier sind logische CPUs gemeint, es zählen also auch HT/SMT CPUs. Sprich: 32 echte Kerne mit HT = 64, und er "steht an". Das bedeutet eine Reihe von Dingen (nicht nur für x265 übrigens, aber eben auch dafür):

Hmm, Arbeit ist wie Streß: Distress und Eustress. Es gibt eben zwei Arten: Die, die du machen mußt, und die die du machen willst!

Die, die du machen willst, fühlt sich nicht Mal wie Arbeit an, sondern wie Spaß! So gesehen ist die Zeit auch kein Verlust.

Mir ist nicht ganz klar, warum du überhaupt 4 NUMA Knoten haben sollst?! Macht das in irgendeiner Form Sinn? Weil normal hast lokalen RAM ja pro Sockel.. Oder sind da zwei komplett getrennte Dies mit getrennten Speichercontrollern in jeder CPU, und die müssen selber über Hypertransport miteinander reden, anstatt direkt?

Ok, macht Sinn. Antwort habe ich aber auf die prinzipielle Frage keine. Es sollten die gesamten CPUs ausgelastet werden, mit 32 Kernen unter Linux hat das auch vorzüglich funktioniert. Da ist auch (für Windows) kein besonderer Hickhack drinnen soweit ich das jetzt im Kopf habe, also das sollte x265 Standardverhalten sein. 24 Kerne wären eigentlich ein Klacks, wenn sich 32 schon so fein ausfahren lassen.

Es ist nicht ganz abnormal, daß es eine Zeit dauert bis er Gas gibt. Das liegt daran, daß es braucht, bis der Input Buffer gefüllt ist. Am Anfang baut sich der erst Mal eine Weile auf, und in dieser Phase bleibt die Last geringer. Das konnte ich auch am 32-CPU System unter Linux so beobachten. Nach einer Zeit ist der Buffer prall gefüllt, und dann geht's erst richtig los. Das muß ich so auch noch in der Readme vermerken.

Das legt nahe, daß der x265er im Vergleich zum alten x264er Test in der Tat besser (=also so wie es sich gehört) skaliert, und die 32 Kerne nach der "Warmlaufphase" auch wirklich hinreichend belastet.

Hast vielleicht hin und wieder im Taskmanager zugeschaut, was die CPU Auslastung angeht? Rein aus Neugierde. Ist immerhin die erste 32-Kern Box mit MS Windows auf der des gelaufen ist.

Alles klar, dann funktioniert der Windows NUMA Code schon Mal sauber (anders als unter Linux). Das deckt sich dann alles mit den Aussagen der Entwickler. Danke für's Testen!

So, nach einem Hiatus von fast einem halben Jahr habe ich mich heute Mal wieder ein wenig in den ganzen Buildprozeß einarbeiten müssen (nicht Mal mehr gewußt wo hinten und vorne ist nach all der Zeit).

Diese Beta ist nicht public.