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

Ajo, ich sollte noch dazusagen: Ich gebe im Virtualisierungsfall nur das an, was die VM auch bekommt (so gut als möglich). Die VM hat als Gast aber 28 CPUs gesehen? Verstehe ich das richtig? Weil dann passt meine Angabe. Oder hat die VM volle 56 vCores bekommen? Oder gibts jetzt schon explizit die Möglichkeit, 28 vCores mit HT Fähigkeit durchzureichen, sodaß der Gast wirklich "28 physische und 56 logische" Cores zu Gesicht bekommt?

Ah, Neuzugang beim x264, willkommen.

Ich sehe, du hast den all-core Turbo der CPU angegeben. Mir ist natürlich klar, daß der bei den meisten CPUs näher (oft WEIT näher) an der Realität liegt als der Base Clock, das verzerrt so ja auch die Effizienzwerte. Allerdings ist der Turbo für mich deterministisch nicht zu 100% einschätzbar, daher habe ich mich dazu entschlossen, bei modernen Prozessoren immer den Referenz-/Basistakt in der Liste anzugeben. Auch im übertakteten Zustand kommt der angehobene Basistakt als "OC Takt" in die Liste (auch wenn der Nutzer den Turbo im OC aktiv läßt).

Mich wundert's direkt, daß da noch keine negative Kritik gekommen ist...

Und ich nehme das zum Anlaß, wieder Werbung für die Nebenprodukte zu platzieren:

Ich trage das morgen ein, wenn es genehm ist, heute mag ich nicht mehr.

Aber, um das zu klären, ein paar Worte extra: Auch wenn du den latest Build nutzt, der besser parallelisiern kann (offizielle Resultate sind übrigens auch immer mehr als willkommen in solchen Fällen btw., um die Vergleichbarkeit sicherzustellen), x264 hat als praktische und qualitativ BESTE Applikation aus dem Videosektor ein ganz klares Ziel: Niemals Qualität für Leistung zu opfern.

Viele Encoder, die massiven CUDA/OpenCL/QuickSync GPU Support haben, werben mit massiver Performance, verschweigen dabei aber eine der Grundwahrheiten des parallelisierten Videoencodings: In blockorientierten Kodierungen opfert man einfach Qualität, wenn man ZU parallel wird - weil jeder einzelne Mini-Thread einfach "zu wenig Ahnung" davon hat, was um ihn herum in seinem Frame passiert. Je nach Auflösung ist das mehr oder weniger schlimm. Je mehr Auflösung, desto mehr Threads kann man spawnen. Der x264 Benchmark ist mit 1080p schon fast am unteren Ende des Spektrums mittlerweile. Er lebt ja auch schon seit über 5 Jahren (holy hell, echt nämlich).

Das resultiert dann auch darin, daß du mit deinem "Irrsinn" aus 40 oder gar 48 Threads das Maximum an 32 halbwegs sinnigen Encodingthreads in x264 mehr als überschreitest.

In diesem Sinn treibt der x264 Benchmark das "praktisch" im "praxisorientierten" Benchmark ans Maximum: Mehr Threads als für maximal mögliche Qualität gesund sind werden schlichtweg nicht unterstützt. Die x264 Entwickler sind neben der extremen Optimierung des Codes immer noch mehr auf ihre ungebrochene Ergebnisqualität stolz, als auf ihre Performance. Da kann in Sachen Qualität pro MB sogar das noch junge H.265/HEVC nach wie vor in Frage gestellt werden.

Quali > Leistung.

Leider sind massiv parallele Systeme benachteiligt was das hier angeht, es SEI denn man sieht sich Clusterlösungen und entsprechende Ansätze in Sachen Splitting an (die auch für "normale" Systeme anwendbar sind).

Das GEHT, aber dann mußt einiges in dazulernen, und ein "gültiges Standardergebnis" wird das dann sowieso nicht mehr...

Letzten Endes mißt der x264 Benchmark nur eines: Wie gut eine Maschine mit x264 Videos encoden kann.

Wollte das nur Mal gesagt haben, weil so viele Leute in letzter Zeit Many-Core Systeme ins Rennen schicken.

Edit: Und eingetragen! Wenn du die Suche entsprechend einschränkst, dann stellt sich die sinkende Effizienz von Mehrkernsystemen auch schön dar, siehe [dieser Vergleich]. Da mußt natürlich auch zusehen, keine Vergleiche zwischen unterschiedlichen CPU Architekturen oder Generationen zu ziehen. Wenn du in einer Familie bleibst, siehst du, daß die Effizienz mit der Kernanzahl sinkt. Oder auch [hier]! Vergleicht man die beiden GCC Ergebnisse auf dem Itanium² SHM Cluster, dann sieht man einen scharfen Drop von 10 auf 16 Sockel, wobei hier noch Busprobleme dazukommen.

Ich bin froh, daß die Anleitungen noch immer so wie sie da stehen funktionieren, immerhin habe ich das schon seit Ewigkeiten nicht mehr step by step so durchgespielt und getestet... Bei den BSDs und Solaris hat sich ja doch einiges geändert (ist einfacher geworden), da müßte man direkt Mal updaten... wenn die Faulheit nicht wäre.