x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)

Na, das wird schon passen, war sicher nur, weil Mercurial fehlt. Wenn du den Bootstrapper ausgeführt hast, findet sich das bundled x265 Binary in ./bin/. Wennst also auf der Shell im Ordner bist, wo du die Skripte aufrufst, dann lautet der korrekte Aufruf wie folgt:

./bin/x265 --version

Habe dir das also falsch angesagt, sorry!

Aber meinen Verdacht, daß ein systemweites x265 in anderer Version zum Einsatz gekommen ist, ist damit ausgeräumt. Das Problem mit dem falschen Version Reporting kenne ich aus den frühen Testphasen. x265 nutzt dafür beim Kompilieren das Mercurial ("hg --version") Versionierungssystem. Eine Entscheidung seitens der Entwickler. Aber ich wollte es dem Nutzer nicht aufzwingen müssen, Mercurial zu installieren. Rennt ja auch ohne, nur die x265 Versionsnummer fehlt.

Wenn ich so drüber nachdenke.. So einen Schnitzer würden sich die Mint Distributoren niemals leisten, von daher hätte ich gleich gar nichts sagen sollen. Das paßt schon so! War nur ein wenig schockiert, weil die Kiste auf einmal so schnell ist!

Ich würde nur zu gerne wissen wieso... Aber leider haben mir die x265 Entwickler auch auf meine NUMA Frage (unter Windows) noch nicht geantwortet, da kommt wohl nichts mehr. Ich probier's einfach in ein paar Wochen nochmal.

Die Fallentscheidung ob der klassische oder der moderne Encoder benutzt wird ist für die Konsolenmeldung und die Nutzung der .exe dieselbe. Sprich: Es wird auf Basis der selben Variable entschieden, die aus der Kernelversion des Betriebssystems hergeleitet wird. Wenn er den klassischen Encoder nutzt, dann ist das auch visuell erkenntlich. Und solange die Kernelversion nicht 5.2 (XP x64) oder 6.0 (Vista) ist, sollte er immer den modernen nehmen. Server 2008 R2 ist ja 6.1, also Windows 7 Codebasis.

Normalerweise sollte er schon den modernen genommen haben. Ich habe Server 2008 (NT 6.0) und Server 2008 R2 (NT 6.1) aber nie gegeneinander getestet, nur Windows Vista und Windows 7.

Zudem: SO lahm ist der klassische Encoder auch wieder nicht, siehe meine Xeon X5690 und i7 980X CPUs.. Da sind vielleicht 20% um, aber nicht so eine Menge an Leistung wie bei Biolante..

Eisfuchs: Hast du noch die RESULTS.txt? Wenn ja, könntest die an deinen Post anhängen? Danke!

@Biolante: Swap ist Kernelsache. Und der Windows Kernel ist nicht so dämlich, Dinge zu swappen, die er nicht swappen muß. Wenn dein virtueller Speicher jetzt größer ist, so sollte das ebenfalls keine Auswirkungen haben. Fakt ist: Du hast einen riesen Haufen an RAM, weit mehr als für den Bench nötig! Das sollte also keinerlei Problem darstellen, auch dann nicht, wenn du einen Terabyte an Swap einrichtest, oder einen systemverwalteten (autogrow) Swap nutzt.

Klingt eher so als gäbe es unter Windows ein paar Skalierungsprobleme, aber Mal schaun... NUMA hast du ja nicht, der Faktor fiele schon Mal flach.

Na jedenfalls sollte der Swap da komplett egal sein..

Eisfuchs: Danke! Dann kann ich Mal eintragen gehen.

PS.: Wenn du einen Beitrag schreibst, hast unter dem Eingabefenster vier Tabs: Smileys, Settings, Attachments und Quotes. Bei Attachments kannst du Dateien anhängen.

Flott isser ja Mal ordentlich im x265er..

Eine Frage aber zu den Resultaten: Im UEFI hattest da immer 5GHz eingestellt, oder? Und der Downclock wurde von der CPU selbst ausgeführt, weil die AVX Register benutzt wurden? Weil wenn das so ist, dann trage ich 5GHz ein, "so wie vom User eingestellt".

Man kann nicht von jedem User erwarten, daß er dran denkt, daß seine CPU unter AVX Last runtertaktet, und alle Chips machen das ja auch ned. Und ich geh auch nicht bei jeder CPU extra nachschauen, ob die jetzt einen Downclock unter AVX Last vorgesehen hat oder ob nicht.

Von daher würde ich wohl vorschlagen, daß man einfach die fest eingestellte OC Frequenz angibt, selbst wenn der Chip das nicht hält. So wie bei Power Targets im Turbo und bei Thermal Targets erwarte ich dann einfach von den lesenden Nutzern, daß sie in der Lage sind, diese Ergebnisse korrekt zu interpretieren.

Ich will nur sichergehen, daß ich immer ein und den selben Wert in der Liste anführe, nicht bei User A die OC Vorgabe und dann bei User B den AVX Clock, weil ich halt nicht in jedem Fall genau nachgeforscht habe...

Oder hat jemand einen besseren Vorschlag (der ohne extra Arbeit auskommt)?

Jo, is schwer zu sagen. Vielleicht laß ich es einfach so und setze einen Link dazu auf deinen Post hier. Das wäre vorerst wahrscheinlich das schlauste.

Moderne CPU-Taktskalierungen sind echt verdammt noch Mal zu kompliziert geworden. Einer der sich heute Benchmarkergebnisse durchschaut muß ja wirklich schon viel Hintergrundwissen haben, um die Werte überhaupt noch einigermaßen interpretieren zu können...

Oook, das is aber schon verdammt nice, also verhält sich das neuere Windows deutlich anders? Wegen der Sockelanzahl?! Ich kapier ned ganz warum der Unterschied da so extrem sein soll, ab Windows 7 (und den entsprechenden Servern) sollte sich der Scheduler ähnlich gut verhalten, wenn man NUMA Mal beiseite läßt.

Momentan hab ich leider grad nur sehr wenig Zeit, aber ich klopf's heute noch in die Liste rein!