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

Also jetzt bin ich überrascht... die gleiche CPU wie ich kurz davor, noch dazu gleich hoch getaktet.

Nein, nicht das Ergebnis ist es, das mich überrascht, sondern nur der Umstand, daß du kurz nach mir die gleiche CPU auf'm gleichen Takt in's Rennen geschickt hast.

Der Selbstbau hat nur relativ wenig Einfluß. Das hatte ich damals noch getestet, als ich das Ding initial gebaut hatte. Grund dafür ist, daß diese Software Optimierungen nicht nur für deine Host-CPU baut, sondern mittels zur Laufzeit aktivierbarer Codepfade für viele verschiedene CPUs. Selbst eine auf einem Pentium 4 gebaute Version kann also die ganzen Gimmicks eines Haswell Kerns wie etwa AVX nutzen, (fast) ganz so als hättest du direkt am Haswell kompiliert. Die C/C++ Optimierungen sind kaum relevant, weil der meiste leistungshungrige Code in Assembly vorliegt, zumindest auf den modernen x86 CPUs.

Den meisten Einfluß hat die Verwendung einer neueren Version des Encoders. Bis vor wenigen Jahren hat da noch richtig viel Leistungsoptimierung stattgefunden, kontinuierlich. Erst jetzt sind wir in einer Phase angelangt, wo dahingehend nicht mehr viel weitergeht.

Die Auswirkungen davon kann man mittels --asm Parameter zur Laufzeit testen. Gebaut werden nämlich immer der C/C++ und der ganze Assemblycode. Man kann einzelne Codepfade selektiv deaktivieren. Man könnte also z.B. AVX oder SSE4.2 ausschalten. Dann läuft für diese Teile statt dessen der Code, den dein C/C++ Compiler ausgespuckt hat, oder es läuft ein anderer Assemblypfad (z.B. SSE2 statt SSE4.1) für gewisse Dinge. Mit --no-asm lassen sich alle Assemblypfade abdrehen, dann rennt das reine C/C++ Kompilat. Von den Entwicklern werden Versionen, die von Haus aus nur auf Basis von C/C++ gebaut werden dann "crippled Build" genannt.

LTO habe ich (soweit ich mich entsinne) nie verwendet. Habe auch nicht genau nachgelesen, was das genau tut, sollte ich vielleicht noch tun.

Ist drin! Das war der Auftakt...

Ich verstehe dein Ergebnis nicht ganz. 71 Minuten sollten es nicht sein, da hätte sich das Ding mit meinem Gulftown Hexcore angelegt. Wenn es 71 Stunden waren, paßt was bei der Angabe von Minuten, Sekunden und Millisekunden nicht?! Da fehlt eine Zahl zwischendrin. Sekunden oder Minuten...

Da bist gut im unteren 80stel der regulären Ergebnisse angelangt, meine Glückwünsche!

Ist drin, danke für die prompte Richtigstellung!

*rülps*

Wenn's bei dir so wenig RAM hat, isses eh irgendein ARM SoC, der sowieso keine Gültigkeit bekommt?

Reg. ECC ist in der Regel ein Problem, allerdings hängt das auch von der Plattform ab, eventuell sogar von der Verdrahtung des Mainboards und dem BIOS? Das ECC ist egal, das stimmt. Aber DDR3 mit Registerpuffern habe ich einige Male mit dem X58 Chipsatz auf zwei ASUS Boards getestet, mit dem Ergebnis das alles instabil war, inkl. Freezes und fehlschlagender POSTs ohne nicht den Speicher einmal durchzutauschen. Manchmal lief es 2-3 Wochen, dann wieder Freeze. Andere Leute mit Mainboards anderer Hersteller haben berichtet, daß ihre Systeme gar nicht damit booten. Dann gibt es aber auch "eigentlich nicht Reg. fähige" Bretter mit neueren Chipsätzen, wo solcher RAM läuft.

Bei SDR-SDRAM DIMMs mit 168 Pins war auch noch die Keyposition anders, wenn ich mich recht entsinne. Da konntest Reg. ECC SDRAM also - soweit ich weiß - mechanisch gar nicht in ein normales Mainboard für unbuffered SDRAM stecken. Bei SODIMMs kann ich dazu nichts sagen. Hängt dann auch davon ab, ob der Chipsatz die zusätzlichen Ranks des Reg. Speichers nutzen kann...

Man muß es wohl einfach ausprobieren.

Und: Vor dem Problem steht man manchmal halt. Auf dem 486er konnte ich ja auch kein valides Ergebnis erzielen.

Und #2: Wenn du von einer USV sprichst, bekomme ich schon Angstgefühle hier, das muß wohl ein ziemlich grausam lahmes System sein.