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

Alles drin!

Hast zufällig noch den Namen der Maschine selber (ThinkCentre Modell, oder was das genau ist)?

Wenn nicht, trag' ich's mit dem Mainboardbezeichner so ein.

Edit: Wurde mir per IRC nachgereicht, Ergebnisse sind jetzt drin.

Zitat von Pineapple

ffms [error]: could not create index

is that normal

Wie CryptonNite schon sagt, das ist normal. Ist nicht direkt hübsch, aber najo. Erklärung: x264 wurde sowohl mit Support für ffms (ffmpeg-source) wie auch lavf (libavformat) kompiliert, um die Eingabedatei zu dekodieren / einzulesen. Die Decoder werden der Reihe nach selektiert, ffms kommt zuerst. Wenn ffms fehlschlägt (so wie hier), übernimmt lavf transparent und ohne weitere Meldung. Ich hätte das ganz zu Anfang fixen sollen, aber nachdem draus kein echter Schaden entsteht, habe ich einfach so gelassen.

As CryptonNite said, this is expected. It ain't exactly pretty, but yeah. Explanation: x264 is compiled with both ffms (ffmpeg-source) and lavf (libavformat) support for decoding / reading the input file. They are selected in order, ffms first. When ffms fails (like here), lavf takes over silently and transparenty. I should've fixed that early on, but since there is no actual harm, I just left it as-is.

Er sollte nicht nochmals starten. Was du da siehst is sehr wahrscheinlich nur Transcodingpass #2/2. Der Benchmark kodiert in einem 2-Pass Verfahren mit deterministischer Laufzeit und Dateigröße. Also er kodiert einmal um die Statistikdaten zur Bitratenbestimmung zu generieren, und dann ein zweites Mal um die finale Ausgabevideodatei zu erzeugen. Wenn Pass 2 komplett ist, ist der Benchmark durch und zeigt die Laufzeit auf dem Kommandozeilenterminal an.

Für Neueinsteiger ist der Ablauf nicht direkt logisch, ich weiß... das ganze Teil war nicht direkt gut geplant, und nie dafür gedacht, soviel Zuspruch zu finden wie es dann hat.

Edit: Ah, übrigens, willkommen im Forum und danke für die Teilnahme!

It shouldn't start again. What you're looking at is very likely just transcoding pass #2/2. The benchmark encodes in a 2-pass way with deterministic runtime and file size. So it encodes everything once to generate its statistics files for bitrate determination, and then in does the second encoding run to produce the final output video file. Once pass 2 has completed, the benchmark is done showing its runtime on the command line terminal.

It's not the smoothest process for new users, I know... this whole thing wasn't overly well-planned, and was never meant to gain as much traction as it has.

Edit: Ah, anyway, welcome to the forum and thank you for your participation!

Nur Stesstests zu fahren ist auch ok. Der Benchmark wurde ursprünglich mehr für Stabilitätstests gebaut als für's Benchen. Das war mehr ein Nebenprodukt. Frühe Tests haben gezeigt, daß x264 manche grenzstabile PCs sogar schneller crashen kann als der Intel Burntest oder linX. Das machte die Sache für den Zweck brauchbar.

Ich möchte aber darauf hinweisen, daß der x265 Benchmark eher Hardcore ist. Selbst mit moderner Hardware wird es mehrere Stunden dauern bis der durch ist, siehe die x265 Benchmark [Ergebnisliste]. Man sollte auch 12-16GiB RAM haben, je nach Anzahl der logischen Kerne. Wenn man nur stresstestet, kann man das Ding natürlich einfach jederzeit abbrechen.

Just stress-testing is fine as well. This benchmark was originally built more for testing hardware than for actual benchmarking, which was more of a byproduct. Early tests had shown that x264 can crash borderline-stable PCs even faster than Intel Burntest /or linX in some cases, which made the whole thing worthwile.

Please understand that our x265 benchmark is pretty hardcore though. Even with very modern hardware, it will take several hours to complete, see the x265 benchmark [results list]. And you should have 12-16GiB of RAM for it as well, depending on logical core count. If you're just stress-testing you can just abort the whole thing at any given time of course.

Naja, der i7 990X ist eher selten, und sauteuer war er auch. Wir würden nicht Mal den i7 980X haben, wenn's nicht mein eigener Chip wär, den ich dann später in meine (immer noch laufende) Linux Workstation auf der Arbeit gesteckt habe. Wie auch immer, CPUs die noch nicht in den Listen erfaßt sind heiße ich immer willkommen!

Well, the i7 990X is kinda rare, and it was pretty expensive too. We wouldn't even have an i7 980X, if it wasn't for my own chip, which I later plugged into my (still running) Linux workstation at work. Anyway, I always welcome processors that aren't on the lists yet!

Sollte nichts mit den Caches zu tun haben? Ob die CPU 48GiB RAM addressieren kann, hängt vom Adressbus ab. Und alle i7 Chips sind PAE-fähig (990X eingeschlossen), was zumindest einen 36-bit Adressbus bedingt. Damit können wir 2³⁶ Elemente (=Bytes im Falle von x86_64 Speicheradressierung) ansprechen. Das bedeutet 64GiB adressierbaren Speichers. Also ja, jeder S1366 Core i7 kann 48GiB Speicher adressieren, sogar der allererste i7 920. Man muß nur sicherstellen, daß man 2-Rank Module mit 8 ICs pro Seite benutzt. Das bedeutete dann 512MiB pro IC. 8GiB pro Modul. Ja keine 1-Rank Module mit nur 8 ICs in Summe nehmen, weil man dabei die Speicherdichtelimitierung des IMCs in der CPU sprengen würde! 512MiB pro IC sind das Maximum, so wie 2 Ranks das Maximum pro Modul darstellen.

In grauer Theorie könnte ein Westmere Xeon Chip mit einem 40-bit Adressbus sogar 1TiB Speicher pro Sockel ansprechen (was den Weg zu 96GiB mit einem Xeon auf X58 ebnen würde), aber leider ist das unerreichbar, aufgrund von Speicherdichte-, Rank- und Registered-Limitierungen. Zumindest nicht auf dem X58.

Shouldn't have anything to do with the caches? Whether the CPU can address 48GiB of RAM depends on the address bus. And all i7 chips are PAE-capable (990X included), which also means that all of them feature at least a 36-bit address bus. With that, we can address 2³⁶ elements (=bytes in case of x86_64 memory addressing). That translates to 64GiB of addressable memory. So yes, any S1366 Core i7 can address 48GiB of RAM, even the very first i7 920. Just make sure to use 2-rank modules with 8 ICs per side. That would mean 512MiB per IC. 8GiB per module. Do not use 1-rank modules with just 8 ICs total, or you'll exceed the IC density limits of the IMC in that chip! 512MiB per IC is the maximum, as is 2 ranks per module.

In grey theory, a Westmere Xeon chip with a 40-bit address bus could address 1TiB of RAM per socket (paving the way to using 96GiB of RAM with a Xeon on X58), but unfortunately, this cannot be reached due to IC density, rank and registered memory requirements. At least not on X58.

Dieser Benchmark profitiert nur geringfügig von Speichertakt. Er frißt zwar ein bißchen RAM, aber die effektive Transferrate von CPU zu RAM ist niedrig. Er ist sehr rechenintensiv, aber nicht speicherdurchsatzintensiv. Schnellerer RAM hilft also nicht viel, eine schnellere CPU hingegen schon. Ist beim viel schwereren x265 Benchmark ähnlich. Also er rennt schon schneller, aber der Unterschied ist eher vernachlässigbar.

Was die Caches angeht, war mir kein Unterschied zwischen dem i7 980X und dem i7 990X bewußt. Soweit ich weiß haben beide Chips das selbe Smart Cache Setup (wie auch der Xeon X5680, X5690, ...). Hast du einen Link, wo ich mich zu dem Thema informieren kann?

Was Speicherübertaktung angeht: Ich mach's nicht. Ich habe keine Anwendungen, die exzessiv von mehr Speicherbandbreite profitieren würden. Ich bin da noch auf 48GiB DDR3/1333 8-8-8-24-2T. Ich brauche zwar viel RAM, aber keinen superschnellen.

95% von meinem Workload entfallen auf ffmpeg+x264/x265 Videotranscoding. Ein paar Prozent auf Audiotranscoding und ein paar Prozent auf Bildverarbeitung (Filter, Resize, etc.). Ah, und ≤1% entfallen auf Spiele, vielleicht halt. Das isses.

RAM clock speed does not benefit this specific benchmark much. While it consumes a bit of RAM, effective transfer rates from CPU to RAM are low. It's very computation-heavy, but non memory-transfer-heavy. So faster RAM won't help much, but a faster CPU will. It's pretty similar with the much heavier x265 benchmark. I mean, it'll run faster, but the difference is rather negligible.

As for the caches, no, I wasn't aware of any differences between the i7 980X and the i7 990X. According to my information, both chips have the exact same Smart Cache setup (same with the Xeon X5680, X5690, ...). Do you have a link where I can read up on that?

And as for the memory overclocking: I don't do it. I don't have any applications which would profit excessively from more memory bandwidth. I'm on 48GiB of DDR3/1333 8-8-8-24-2T. I do need a lot of RAM, but not superfast one.

95% of my workload is ffmpeg+x264/x265 video transcoding. A few percent are audio transcoding, and a few percent are image processing (like filters, resize, etc.). Oh and ≤1% are games, maybe. That's it.