Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

666psycho

Hab eben mal die Alpha16 auf meiner Debian Kiste runtergeladen, bootstrap.sh funktioniert bislang einwandfrei, auch die Fehlerausgabe und was man zu tun hat:

Zitat

root@****:/****/x265/alpha16# ./bootstrap.sh

Bootstrapping for: Linux 3.16.0-4-amd64 [x86_64]

Looking for C and C++ compilers........... OK
C : '/usr/bin/gcc', gcc (Debian 4.9.2-10) 4.9.2
C++: '/usr/bin/g++', g++ (Debian 4.9.2-10) 4.9.2
Looking for yasm assembler................ OK
'/usr/bin/yasm', yasm 1.2.0
Looking for GNU Autoconf.................. FAIL

GNU autoconf not found! Please install GNU autoconf first!

Aborting...

Alles anzeigen

Soso, autoconf fehlt, also installieren:

Code

root@****:/****/x265/alpha16# apt-get install autoconf

Nächster Anlauf bootstrap.sh:

Zitat

root@****:/****/x265/alpha16# ./bootstrap.sh

Bootstrapping for: Linux 3.16.0-4-amd64 [x86_64]

Looking for C and C++ compilers........... OK
C : '/usr/bin/gcc', gcc (Debian 4.9.2-10) 4.9.2
C++: '/usr/bin/g++', g++ (Debian 4.9.2-10) 4.9.2
Looking for yasm assembler................ OK
'/usr/bin/yasm', yasm 1.2.0
Looking for GNU Autoconf.................. OK
'/usr/bin/autoconf', autoconf (GNU Autoconf) 2.69
Looking for GNU make...................... OK
'/usr/bin/make', GNU Make 4.0
Looking for cmake......................... FAIL

cmake not found! Please install cmake first!

Aborting...

Alles anzeigen

... und cmake installieren:

Code

root@****:/****/x265/alpha16# apt-get install cmake

Anschließend noch Warnings:

Zitat

root@****:/****/x265/alpha16# ./bootstrap.sh

Bootstrapping for: Linux 3.16.0-4-amd64 [x86_64]

Looking for C and C++ compilers........... OK
C : '/usr/bin/gcc', gcc (Debian 4.9.2-10) 4.9.2
C++: '/usr/bin/g++', g++ (Debian 4.9.2-10) 4.9.2
Looking for yasm assembler................ OK
'/usr/bin/yasm', yasm 1.2.0
Looking for GNU Autoconf.................. OK
'/usr/bin/autoconf', autoconf (GNU Autoconf) 2.69
Looking for GNU make...................... OK
'/usr/bin/make', GNU Make 4.0
Looking for cmake......................... OK
'/usr/bin/cmake', cmake version 3.0.2
Looking for mercurial..................... WARN
Mercurial ('hg') not found! hg is required for x265 version reporting!
Looking for git........................... WARN
git not found! May be required for MediaInfo build on certain systems!

There have been potentially problematic warnings! This might result in a
weird build (e.g. x265 reporting that it's version '0.0') or even in a broken
build (e.g. with MediaInfo missing). The benchmark will likely still function,
but you might want to fix the issues before continuing (see above warnings).

Do you want to [C]ontinue or [A]bort to fix this issue?

[C|A]?

Alles anzeigen

->Abort und die beiden fehlenden Kompnenten noch installiert:

Code

root@****:/****/x265/alpha16# apt-get install mercurial

+

Code

root@****:/****/x265/alpha16# apt-get install git

Jetzt alles OK nach Ausführen der Bootstrap und er bastelt vor sich hin

@GAT
Frage, sollte man bootstrap.sh nochmal neu ausführen, wenn man am System die CPU gewechselt hat (z.B. von Athlon64 auf Phenom II)?
Oder müsste man da vorher bereits erstellte ffmpg Komponenten z.B. erst wieder entfernen, bevor man das neu bauen lässt?

edit... noch eine Frage, sind die Ergebnisse dann schon für die künftige Ergebnisliste gültig? Hab hier nämlich gerade ein CPU Upgrade für das System da liegen und würde dann erst noch den alten Opteron 1352 mal durch den gültigen Bench jagen wollen, bevor er ausgetauscht wird

edit2...
Nachdem bootstrap.sh mit allem fertig war, den Benchmark gestartet und weitere Warnings erhalten:

Zitat

/x265/alpha16$ ./launch_x265benchmark.sh

launch_x265benchmark.sh invoked on Sa 15. Apr 16:17:04 CEST 2017

Running initial checks:

Operating system........................ OK [Linux, 3.16.0-4-amd64]
Operating system bitness................ OK [x86_64, 64-bit]
Free disk space......................... OK [102377MiB]
Free physical memory.................... OK [16083MiB]
Free virtual (physical+swap) memory..... OK [24271MiB]
dmidecode and /dev/mem read access...... WARN
dmidecode not found, reporting seriously impaired!
MKVtoolnix / mkvmerge binary............ WARN
mkvmerge missing. Will not multiplex output video for playback testing.
If you want this to work, please install MKVtoolnix >=8.6.0!
Bundled MediaInfo binary................ OK
lshal on Linux.......................... WARN
We're missing the lshal program. Reporting impaired!
lspci on Linux.......................... OK

Verifying SHA-512 checksums:

'./share/input.h265'.................... OK
`./bin/ffmpeg`.......................... OK
`./bin/x265`............................ OK
`./launch_x265benchmark.sh`............. OK
`./sbin/transcoder.sh`.................. OK

WARNING
Reporting is seriously impaired due to a missing dmidecode or missing read
access to '/dev/mem' for your user. If possible, please install dmidecode
and then try...
1.) adding your user to the 'kmem' group temporarily (Warning: This gives
your user read access to physical memory!) or, if that won't do...
2.) becoming root and running `# chmod +s $(command -v dmidecode)`
(Warning: This gives all users the permission to run `dmidecode` with
root privileges)

The benchmark will still work if you don't do this, but platform/mainboard/
RAM reporting won't work on a lot of systems. You'll likely need to report
your mainboard or OEM system and your RAM type, speed and latencies manually
(e.g. on Linux without HAL, or on BSD UNIX)! Note, that after adding yourself
to the 'kmem' group, you'll have to re-login to your system for the change to
take effect, while chmod doesn't need this!

Do you want to [C]ontinue or [A]bort to fix this issue?

[C|A]?

Alles anzeigen

Wenn ich nun dmidecode nachinstallieren will, sagt mir apt, das es schon installiert ist.... -> nochmal mit root getestet und damit funktionierts, man muss also launch_x265benchmark.sh als root ausführen oder mittels sudo, Ausführung nur unter normalen Userberechtigungen lässt dmidecode fehlschlagen.

lshal -> hab ich kein passendes Paket über Apt gefunden?

Und nach Installation von MKVtoolnix via apt-get install hab ich eine zu alte Version bekommen:

Zitat

MKVtoolnix / mkvmerge binary............ WARN
mkvmerge version older than 8.6.0 [7.3.0], H.265/HEVC multiplex may fail.

Ok, Problem gelöst durch das Einbinden der Paketquelle: https://mkvtoolnix.download/downloads.html#debian
-> nochmal die aktuelle Version installiert und seihe da:

Code

/x265/alpha16$ mkvmerge --version
mkvmerge v10.0.0 ('To Drown In You') 64bit

Das Einzige was mir jetzt noch fehlt ist lshal:

Zitat

/x265/alpha16$ sudo ./launch_x265benchmark.sh

launch_x265benchmark.sh invoked on Sa 15. Apr 16:47:08 CEST 2017

Running initial checks:

Operating system........................ OK [Linux, 3.16.0-4-amd64]
Operating system bitness................ OK [x86_64, 64-bit]
Free disk space......................... OK [102297MiB]
Free physical memory.................... OK [16083MiB]
Free virtual (physical+swap) memory..... OK [24271MiB]
dmidecode and /dev/mem read access...... OK
MKVtoolnix / mkvmerge binary............ OK [version 10.0.0]
Bundled MediaInfo binary................ OK
lshal on Linux.......................... WARN
We're missing the lshal program. Reporting impaired!
lspci on Linux.......................... OK

Verifying SHA-512 checksums:

'./share/input.h265'.................... OK
`./bin/ffmpeg`.......................... OK
`./bin/x265`............................ OK
`./launch_x265benchmark.sh`............. OK
`./sbin/transcoder.sh`.................. OK

Alles anzeigen

GrandAdmiralThrawn

Hah ja, es is halt schon etwas Arbeit, aber das läßt sich leider nicht verhindern!

Die lshal Warnung sollte ich noch umformulieren. Grund: Der HAL (Hardware Abstraction Layer) wird unter Linux als ganzes fallengelassen, und existiert schon in zig modernen Distributionen nicht mehr. Auch unter FreeBSD besteht ein Plan, den HAL zur Gänze wegzuwerfen, und nur mehr sysctl zu nutzen (unter Linux soll wohl procfs als Ersatz dienen denke ich mir).

Daher sollte ich die Warnmeldung evtl. anpassen, sodaß klar ist, daß lshal ohnehin nur auf etwas älteren Linuxen und auf FreeBSD zur Verfügung steht... Es is nur deswegen drin, weil es stellenweise mehr Hardwareinfos liefern kann als procfs auf Linux und sysctl auf BSD UNIX.

@dmidecode: Wurde wohl nur deswegen nicht gefunden, weil es für normale User nicht im Suchpfad lag. dmidecode braucht leider root. Wenn du es auffindbar machst (als normaler Nutzer) kommen Warnungen die dir erklären wie man /dev/mem lesbar macht und/oder dmidecode mit SUID Bit ausstattet, damit du den Bench als normaler Nutzer starten kannst. Du hast ihn gleich als root gestartet, so kann man's natürlich auch machen..

Im Endeffekt: Wenn es ein System gibt, auf das man keinen root Zugriff bekommt / bekommen darf, dann soll der Benchmark trotzdem ausführbar sein! Fehlende Tools muß dann halt der Operator / Sysadmin für den Nutzer nachinstallieren. Und wenn der Operator entscheidet, daß er SUID auf dmidecode nicht zulassen will, dann kann der Nutzer den Bench immer noch komplett ohne root-Teile starten. Dann werden halt deutlich weniger Hardwareinfos ausgelesen.

Das sind die Gedanken dahinter.

Muß wohl nur die Warnungen noch ein bisserl besser ausformulieren.

666psycho

Das macht nix, das es noch mit Arbeit verbunden ist, ich wollte das aber gleich für die Allgemeinheit hier mit festhalten, falls es jemandem weiterhilft.

Hab jetzt mal den Opteron 1352 durch die Linux Alpha 16 laufen lassen und das Ergebnis ist etwas besser, als mit der Alpha5 auf Windows7:

Ist die verwendete x265 Version eigentlich schon final? Wäre das schon für eine Ergebnisliste gültig? Dann könnte ich mal den Opteron gegen den Phenom II tauschen, der letztens hier eingetroffen ist als Maximalausbau für das Board
Ansonsten würde ich den Opteron noch solange drin lassen, bis ein gültiger Run möglich ist, damit ich mir das einmal mehr Umbaúen sparen kann.

Konsolenausgabe und results sind im Anhang. Bei der results.txt ist das Ergebnis noch etwas zerschossen und die Hardware wird wohl mangels lshal nicht komplett ausgelesen, CPU Takt hat er auch den Idle-Takt ausgelesen und nich den Maximaltakt von 2,1GHz, der dann auch im Benchmark dauerhaft anlag.

GrandAdmiralThrawn

Interessant, daß er hier 8 logische CPUs anzeigt, obwohl du nur einen einzelnen Quadcore hast. Da komme ich wohl noch Mal extra auf dich zu, um rauszufinden wieso das passiert is, sollte eigentlich nicht sein.

Das Hardwarereporting wird unter Linux und UNIX nie wasserdicht sein. Es ist eine Ergänzung zu den Infos die der Nutzer selbst beim Einsenden bereitstellt, aber mehr auch nicht.

Danke in jedem Fall für den Test, das gibt mir noch einige Anhaltspunkte zu mehr Feinschliff!

@x265 Version: Guuute Frage, ich kann es dir jetzt noch nicht mit absoluter Sicherheit sagen. Nächste Woche werde ich Mal schaun was in der Entwicklermailingliste so alles passiert ist (dort werden auch Patches submitted), dann kann ich erst wirklich entscheiden. Ich kann nur sagen, daß ich aktuell keinen Grund sehe, diese Version noch auszutauschen. Gemäß meiner Beobachtungen über die letzten Monate hinweg wäre es leistungstechnisch nicht nötig. Einziger Grund um x265 doch zu aktualisieren wäre es, wenn im Bereich der Parallelisierung etwas signifikantes passiert.

Glauben tu ich das nicht, aber ich kann's natürlich auch nicht vollständig ausschließen. Mh. Sagen wir, das ist "mit 95% Wahrscheinlichkeit" die finale Version von x265 (und ffmpeg sowieso, das tausch ich sicher nicht mehr).

hutzeputz

Sollen wir jetzt diesen Topic oder wir machen einen neuen auf den wir oben Anpinnen als "Wichtig" ?!

GrandAdmiralThrawn

Also, meiner persönlichen Meinung als Projektentwickler nach wäre dieser Thread nicht anzupinnen, zumindest jetzt nicht. Ich habe schon drüber nachgedacht, den "eigentlichen" Benchmarkthread einfach sein zu lassen, und hier weiterzumachen. Alternativ ein neuer Thread, aber Mal schauen, was ich mache. Derweilen würde ich es noch sein lassen. Solange das ganze nur in irgendeiner Alpha (Linux/UNIX/MacOS X) und Beta (Windows) Phase steckt, ist es keinen Pin wert.

Eventuell sollte man sogar schauen, ob der fertige Test als solches überhaupt hinreichend angenommen wird von den Leuten hier, bevor man irgendwas anpinned. Das wäre zumindest meine Ansicht als User.

hutzeputz

Wegen der Übersichtlichkeit würde hier in diesen Thread nur austesten und die Funktionsprüfung belassen. Die Tabelle und Rangliste der User im neuen Thread auflisten (den würde ich anpinnen). Wenn du fertig bist machen wir einfach einen neuen auf. Wie klingt das ?!

GrandAdmiralThrawn

Jo, das paßt. Die Ergebnisliste werde ich (wie schon beim x264er) bei mir selbst hosten, die Ergebnisse würden dann wieder in einem neu zu erstellenden Thread zu posten sein, so wie sonst auch. Wenn ich bereit bin, und alles hinreichend getestet ist, dann mach ich den neuen Thread halt einfach auf, und laß es dich wissen. Dann verbleibt dieser Thread hier ausschließlich für die Entwicklungsphase und später als "geschichtliche Referenz".

Das dauert eh alles noch.

GrandAdmiralThrawn

Jetzt ist es (leider?) doch passiert, x265 hat mit der neuen Version 2.4 einen Sprung nach vorne gemacht. Nicht nur, daß es jetzt das HDR10+ von Samsung mitimplementiert (was C++11 braucht, für den Benchmark komplett egal), nein, es hat auch revisionierte Lambdatabellen und einige Verbesserungen in psychovisueller Qualität und vor allem Speed. Eine schnelle Messung von meiner Seite mit identischen Settings unter XP x64 ergab für simplen 1080p Inhalt bei 2.5Mbps folgendes, framegenau gemessen an der exakt selben Stelle:

x265 2.3+2 (10b): 1.04 fps
x265 2.4+2 (10b): 1.17 fps

Damit wird es also wohl doch noch eine Aktualisierung von x265 geben. Obendrein habe ich die Buildskripte unter Windows für Visual Studio 2017, und Microsofts allerneuesten C/C++ Compiler angepaßt, der den saubersten und schnellsten Code bauen sollte. Faszinierendes Gimmick: Entgegen meiner bisherigen Annahmen kommt Visual Studio 2017 ohne weiteres mit einem v141_xp Platform Target daher, kann also ohne weiteres XP und XP x64 kompatiblen Code bauen, was gemäß meiner Tests auch ohne weiteres funktioniert.

Ggf. lag ich da in einigen meiner früher häufigen Anschuldigungen falsch und die Schuld für dumm eingestellte Platform Targets liegt doch nicht bei Microsoft, sondern bei diversen Entwicklern, die nicht wissen was ihr eigener Code eigentlich braucht und was nicht...

Grindhavoc

Wieso leider, mir ist gerade nicht ganz klar, welchen Einfluss es auf das Projekt an sich haben könnte.

GrandAdmiralThrawn

Der Einfluß ist der, daß bisherige Ergebnisse mit 2.3+23 nicht in die finale Liste kommen können. Das wäre möglich gewesen, sofern ich nicht mehr aktualisiere.

styvi

Halte ich für absolut verschmerzbar und sehe in dieser Phase wenig Grund, da nicht in der Buildphase
das Ding im möglichst aktuellen Zustand anzubieten.
Wenn es zudem noch auf XP 32bit* läuft, wär es für mich ein Grund mehr, das so fertigzumachen und die
größere Bandbreite an Systemen zu unterstützen, zu nutzen.
Es nicht zu tun wäre in meinen Augen Frevel und daher haste meinen Segen definitiv.
Da müsste nur noch ne zusätzliche Weiche bzgl. des Speichers bei (XP 32 max 3,25GB Ram)

*Falls ich das so richtig lese/interpretiere.

GrandAdmiralThrawn

Nein. 32-Bit wird und kann es gar nicht geben. x265 alloziert gleich Mal munter 8-10GB zum Start weg und wächst danach noch an, bis ca. 13GB. Und das ist schon eine massiv zusammengeschnittene Version, damit es überhaupt so weit runtergedrückt werden konnte, das war nicht so einfach. Ich erinnere: In der ursprünglichen Version so wie ich sie wollte fraß das Ding 30-32GB weg! Selbst der Decoder braucht bei dem Input schon 1GB extra oben drauf, und auch hier wurde schon stark auf niedrigen Verbrauch hin optimiert!

Daher, wiederholt:

Ein Betrieb auf 32-bit Systemen, egal ob Windows, Linux, UNIX oder BeOS ist technisch nicht lösbar und damit ausgeschlossen!

Wer auf XP 32-Bit (oder sonst einem 32-Bit System) einen Langzeit(stabilitäts)test sucht, ist beim x264 Benchmark gut aufgehoben! Der rennt auch unter 2000 und 9x noch.

styvi

Ah ok, d.h. wohl, man kann den Code bauen, aber BS bedingt funktionierts wegen derer Limits nicht.. oder?
Aber allein wegen des nicht unerheblichen Geschwindigkeitsunterschiedes würde ich es in aktueller Version
bevorzugen. Gerade im Bereich Software halte ich ich das für sinnig, da zum Release nicht am Alten Festzuhalten,
bedeutet ja keinen Wertverlust, - und im Hinblick auf die kommenden Jahre und viele Tests/Durchläufe und die geringe
Laufzeit der Systeme an sich würde ich da nach vorn schauen.
Dann schmeist man halt bei den bisherigen Systemen den Bench mal kurz neu an und gut isses.
Sind ja keine unter 500Mhz ~256MB-1GB Rechner wie beim X264, wo sich die Mühlen ewig lang abstrampeln und
maßlos Strom verballern..

GrandAdmiralThrawn

Den Code für einen 10-bit x265 Encoder zu bauen geht auf 32-Bit standardgemäß nicht (mehr), weil dieser Codepfad von den Entwicklern deaktiviert wurde. Grund ist, daß die hohe Bitness auch 1080p Encodes schon gefährden kann, weil auch da schon der RAM ausgehen kann. Man kann das im Sourcecode wieder aufdrehen, und dann tatsächlich einen 10-bit Encoder für 32-Bit kompilieren, aber es bringt nichts: Er wird beim Benchmark unter Garantie mit malloc() Fehler abstürzen, weil er einfach unmöglich genug Speicher haben wird.

Damit kannst dann 720p Zeug und so kodieren, oder (wenn die Einstellungen es zulassen) 1080p, aber 8K im Leben nie.

Das ewige Abstrampeln wird's aber hier auch geben bei den Lowest End Maschinen, Core 2 Duo oder so. Rennt sicher zig Tage. Zwecks der Gaudi teste ich das grade auf einem Core 2 Xeon mit in Summe 8 Kernen (2 Sockel, deswegen) auf 2.66GHz unter Linux, und es schaut so aus, als würde der da ungefähr 9 Stunden laufen. Eben mit dieser neuen, etwas flotteren Version 2.4.

Sind Yorkfields, also auch schon mit SSE4.1 Code im Einsatz.

4 Mal so lahm (ca. halt) bei 2.66GHz Core 2 Duo. Wennst jetzt so eine 1.6GHz oder 1.86GHz Möhre hast, dann fängt's doch schon an, ein kleines bißchen weh zu tun was die Laufzeit angeht. Es würde noch lahmer gehen: Gibt ja auch 64-Bit Netburst Xeons mit 16GB RAM und mehr. Also Potential für Schmerzen ist schon ein klein wenig da, wenn auch ned ganz so schlimm wie beim x264.

Grindhavoc

ja das die ersten Ergebnisse Testergebnisse sind und nicht in die finale Liste können ist absolut verschmerzbar.
(Könnten aber in einer eignen Liste, für die Vergleichbarkeit, dennoch beibehalten werden).

Hachja, das wird ein Spaß, freue mich schon auf die ersten AMD K8 CPUs, die den Benchmark erfolgreich beenden.
Wie lange das wohl dauern wird?

styvi

@ GAT Danke.
Allerdings kann man doch unter Linux mit 32bit PAE Kernel bis zu 64GB RAM nutzen,
sollte daher nicht der limitierende Faktor sein

Tweakstone

Zitat von styvi

@ GAT Danke.
Allerdings kann man doch unter Linux mit 32bit PAE Kernel bis zu 64GB RAM nutzen,
sollte daher nicht der limitierende Faktor sein

Trotzdem kannst du einem einzelnen Thread nicht mehr wie 2GB zuweisen also hilft dir das wenig

GrandAdmiralThrawn

bzw. einem einzelnen Prozeß. Ich habe das Gefühl man sollte einen PAE "Erklärthread" posten und pinnen lassen. Kaum ein Feature wird derart oft derart mißverstanden. Und in jedem einzelnen Thread immer wieder dasselbe zu posten bringts irgendwie ned so..

styvi

@ Tweaki
Ok, na denn. Wusste ich nicht, bislang nie ausprobiert oder gebraucht.

@ GAT - oder ne Seite mit guter Erklärung verlinken. Falls ich was find, füg ich es hier bei.

Verständlich, daß es Vollprofis, die ihr Brot damit verdienen, i-wann nervt, aber da ist
ein wenig Verständnis für Normaluser, die "nur" Anwender sind, angebracht.
Das Zusammenspiel von Hardware und Software was Memorymanagement angeht gehört mMn
eh zu den komplizierteren Bereichen an Rechnern. Ohne sich da intensiv mit zu beschäftigen
peilt man da kaum was OK, ich schweife.. besser hier wieder back2topic.