Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

Abgelehnt - Die Varianz ist zu groß. Swap wird immer einen Einfluß haben, der gerade auf Windows Systemen nur sehr schwer nachvollziehbar ist, daher würde das eine nicht nachvollziehbare Streuung auslösen. Ich geh sicher nicht bei jedem User extra nachschauen welche Disks er im System hat! Dann kommen noch ggf. vorhandene, ebenfalls nicht oder nur schwerst nachvollziehbare Faktoren dazu, wie R-M-W bei SSDs oder Fragmentierung bei HDDs.

Ich sag's jetzt noch Mal ganz klar und deutlich => 8GB sind kategorisch ausgeschlossen, das diskutiere ich nicht!

Für Maschinen darüber wird es wie schon beim x264 Bench eine klare, transparente und einheitliche Grenze geben. Ob das jetzt 16GB oder 32GB sind, sie wird in jedem Fall für alle Systeme gleich sein. Alles andere wäre eine fehlgeleitete Verkomplizierung und eine potentielle Verfälschung der Ergebnisse, die in ihrem Ausmaß nicht abzuschätzen ist.

KISS Prinzip! (Das ich eh schon nicht ganz befolge)

Was durch den Rost fällt, kann man immer noch als blaues Ergebnis einschicken (Blau wie beim x264 Bench als Signal für das Unterschreiten der Mindestanforderungen).

Hm, schade... Wobei, kriegt man das durch manuelle Konfiguration nicht ans Laufen? Die meisten 1.35V Module sind ohnehin für 1.5V auch zugelassen, wennst da einfach alles auf 1.6V stellst oder so?! Falls möglich halt.

Hmm, rein aus Neugierde: Welches Brett issn das? Is ja normal ned so schwer daß sowas rennt.

Und: So schnell grillst keinen IMC... Es gibt schon Grenzen, an die man sich auch für kurze Betriebsdauern nicht ranwagen sollte, aber die liegen weiter oben.

Mh, ok. Das issn seltsames Gemisch, vielleicht klappts nicht, weil sich dann zwei unterschiedliche Module auf einem Quadchannel zusammentun müssen? Quasi 4 Stück von den Samsung und einmal 3 Corsair mit'm letzten Samsung, vielleicht liegt da der Hund begraben? Aber keine Ahnung, ich kenn nur die Vorgängerbretter aus zweiter Hand, also die X58 Teile.

Ich bin unterdies Mal mutig und versuche zur Abwechslung die Komponenten auf SunOS 5.11 / Oracle Solaris 11.3 zu portieren (Also nicht gleich das Skript, nur die Software). Schaun ob das geht. Linux und FreeBSD / OpenBSD UNIX werden wohl kaum mehr Probleme machen. MacOS X muß ich mir auch noch anschaun..

Die Anleitung kann ich niemals so veröffentlichen wie sie ist, es braucht direkt eine Vergewaltigung des Solaris Systems, damit das hinhaut. Diese Wahnsinnigen liefern nur einen 32-Bit GCC auf dem OS aus. Das und VIELES andere machen den Bau SO häßlich und grausam, das is echt kaum packbar. Aber ich wußte es ja.

Wer sich mit Oracle Solaris einläßt, stirbt langsam!

Mh, die "unknown" Lines sollte ich noch aus'm Report wegfiltern, die sind für gar nichts. Und die Disks und Grakas muß ich eigentlich auch ned wissen... Mal schaun dann, ob ich das wegbekomme.

Übrigens, laut Thomsen (ham vorher im ICQ geredet) war die Auslastung der 40 Threads sehr gut. Schaut soweit Mal ok aus, was das angeht.

Zweigleisigkeit wird es in der Finalversion keine geben, und die 8K sind schlicht nötig, um genug Threads rausquetschen zu können. Je höher die Auflösung steigt, desto besser läßt sich das Transcoding nämlich parallelisieren.

Die Kunst wird darin bestehen, den Test unter 16GB zu drücken, für alles darunter sehe ich eigentlich keinen echten Grund. Wer hat in einer modernen 64-Bit Maschine noch 8GB RAM? Ich meine, vielleicht gibt's sowas ja noch, Core 2 oder Athlon64 oder so, aber für ein Projekt das sehr stark zukunftsorientiert sein soll, sehe ich keinen Grund von der 8K Plattform auf z.B. 4K herunterzusteigen. Das gefährdet die zukünftige Skalierbarkeit auf Manycore.

Und zweigleisig will ich es auf keinen Fall haben, das wird mir ein zu hoher administrativer Aufwand. Für Systeme mit geringerem RAM würde ich daher auf das ältere x264 Projekt verweisen wollen.

Denn: Eine Maschine mit 8GB oder weniger hat wahrscheinlich auch keine irre Kern- & Thread-Anzahl. Also muß es nicht unbedingt der superfette x265 Bench sein, dann nimmt man halt x264, den würge ich eh nicht ab, sondern pflege ihn weiter.

Allerdings habe ich die 16GB sehr wohl am Radar, denn 32GB sind tatsächlich ein starker Verhinderungsgrund. Vor allem: Auf Systemen mit sehr vielen Threads durchbricht der Benchmark die 32GB sogar. Grund ist, daß dann erhöhte Parallelisierung zum Einsatz kommt, die nochmal mehr RAM kostet. Aber da muß ich halt noch tweaken.

Die Kunst wird darin bestehen, den Speicherverbrauch zu drücken, ohne dabei die Parallelisierung zu gefährden. Das ist möglich - ich muß nur von meinem hohen Roß namens YUV 4:4:4 und 16 B-Frames runtersteigen. Das geht - es ist nur bitter, weil der Einsatz von YUV 4:2:0 Chroma Subsampling eigentlich eine ziemlich rückständige Sache ist. Aber najo.

Das wird dann wohl vor der Beta trotzdem noch passieren, sonst finden sich nur wenige Server und sehr große Workstations im Test wieder, und das für eine lange Zeit. Werde demnächst Mal ein YUV 4:2:0 Quellfile erzeugen, in 10b. Dann werde ich Mal ernste Versuche damit anstellen, die 16GB zu unterschreiten.

Diese Tests sind dann aber zeitaufwendig. Wird also etwas dauern. 16GB wäre eine schöne, vertretbare Mittellinie für die finalen Systemanforderungen finde ich. Mit 32GB habe ich einfach ein bissl Bauchweh...

Edit: So, grade Remote auf die Linux Workstation verbunden, die das Crunchen erledigt, da steckt mein guter alter i7 980X drin mit 48GB RAM. Eine neue Quelle wird erzeugt, für's Anvisieren von 16GB RAM-Verbrauch, und zwar wie folgt, aus TIFF => YUV Upsample => H.265/HEVC Encode, das kann schön über's WE laufen: