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

Wenn man meine eigenen Erfahrungen mit dem GMA950 und die diverser AMD Kaveri+ User heranzieht, dann spielen Speicherdurchsatz und Latenzen für die meisten CPU-orientierten Tasks kaum eine Rolle. Ich sage "die meisten", weil es nicht alle sind! Aber bislang kenne ich nur aus dem wissenschaftlichen Bereich Programme, die wirklich von scharfen Latenzen oder von besonders hohem Speicherdurchsatz profitieren. Und selbst da sind es nur SEHR wenige!

Mein Beispiel mit GMA950 und Kaveri hingegen bezieht sich mehr auf die GPU: Wennst einen integrierten Grafikchip hast, der den Systemspeicher mitbenutzt, dann kann die Auswirkung einer Verbesserung des Speicherinterfaces auf die Grafikleistung dramatisch sein! Wobei es hier sicher auch zu 98% auf Durchsatz ankommt und eher weniger auf Latenzen. Grade im Grafikbereich... Für CPU-Tasks wie x264 hingegen? Vernachlässigbar..

Hmm, hier scheint mir etwas nicht zu stimmen, wenn ich noch richtig sehe: Einen i7-2620QM scheint es nicht zu geben, nur einen i7-2720QM mit 2.2GHz. Einen i7-2620M gibt es, allerdings ist das ein Dual-Core Prozessor (1/2/4 statt 1/4/8).

Ich muß daher nochmals um ein kurzes Anstarten von CPU-Z o.ä. bitten, um die verbaute CPU eindeutig identifizieren zu können! Weil das einzige was auf den angegebenen Referenztakt und den Quadcorestatus passen würde, wäre ein Core i7-2960XM...

Danke.

Ist drin, und danke für die Info zu den Downloadlinks, werde Blacktron Mal per PM anschreiben. Derweil laß ich die Links noch stehen, ist ja viellleicht nur ein vorübergehender Serverausfall.

Meine 48GB sind manches Mal schon recht voll.

Mir ist jetzt auch ein neues Anwendungsgebiet eingefallen: Wenn man die Threadanzahl bei LZMA2 Kompression mit 64-Bit 7zip reduziert, dann sinkt auch der Speicherverbrauch. So kann man das Dedup Dictionary (=Indextabelle für Blockreferenzierung) auf 1536MB aufblasen. Mit 4 Threads sind's dann ca. 35GB RAM Maximalverbrauch. In dem Speicher baut er seine Deduplizierungs-Tabelle auf, um identische Datenblöcke zu erkennen und vorzuhalten. Mit vollen 12 Threads is das bei mir unmöglich, da will er 100GB RAM. Und bei maximalen 24 Threads gar 210GB RAM.

Ich hab ja meine ISOs und tlw. VM Images usw. mit 7zip gepresst, auch die ganze alte Software usw. Sehr große Files (DVD ISOs, BD ISOs) lassen sich durch's Aufblasen vom Dictionary noch stärker zusammenpressen, weil's Dictionary nicht so schnell voll ist - er kann also mehr Blöcke vorhalten und mehr Duplikate erkennen. Man kauft also quasi HDD Speicherplatz durch Einsatz von RAM! Nicht besonders effektiv, aber wenn der Speicher schon da is, kann man ihn auch benutzen.

Klar, mit 4 Threads komprimiert er halt etwas langsamer als mit 12, aber egal.

Najo, ein User aus den Weiten des Internets hat mir jetzt auch ein Resultat zukommen lassen, das pflanz ich Mal hier rein, damit ich on Topic bleibe:

Edit: Oder hast jetzt echt nur von VRAM gesprochen?

Leider is ja beim fertigen Binary nicht auszulesen, auf was die Variable X264_THREAD_MAX zur Buildtime in common\common.h gesetzt war, und ich habe auch weiterhin darin versagt, einen aktuellen Win64 Build zu fabrizieren (das liegt aber an mir, bzw. meinem Build Setup denke ich). Wir haben ja im ICQ drüber geredet. Nachdem das ein Problem zu sein scheint, das auch andere Software wie Prime betrifft, könnte es noch sein, daß es an der Art und Weise liegt, wie der logische CPU Count ermittelt wird.

Hast den 2016er Server jetzt mit UEFI/GPT installiert? Weil es gibt ja wie besprochen dokumentierte Fälle, wo ein CPU Count Query ans BIOS falsche Werte zurückliefert (eben Trunc auf 32, z.B. bei älteren Adobe AfterEffects Versionen). Ansonsten müßte man sich noch im C/C++ Code von x264 selber anschauen, um zu sehen wie der Count unter Windows ermittelt wird, und ob man da außer X264_THREAD_MAX noch etwas ändern muß. Soferns halt nicht wirklich am Windows Server selber liegt.

Man müßte eventuell noch mehr Software testen, aktuellen Cinebench z.B.? Nur um sicher zu sein, daß das Nutzungsproblem wirklich an Windows liegt, und nicht an schlecht/falsch programmierter Anwendungssoftware.