[x264-devel] Varying of PSNR as a function of thread count

[Harald Alvestrand]

Thanks for the responses!
Yes, the CPU was hyperthreaded (6 physical 12 logical cores).

Interestingly, for a small-size video (416x240), there was speedup up to
6 threads (indicating real-CPU limiting); with a large-size video
(2560x1600), there was some speedup right up to 13 threads (indicating
that something else was the limiting factor).

My conclusions so far seem to be:

- If I have plenty of (wall-clock) time, use --threads 1, since that
gives the best PSNR result

- If I am short of (wall-clock) time, use --threads <number of CPUs> (or
let it be auto-set), since that makes the encode finish the fastest.

Seems about right?


Den 21. april 2015 09:38, skrev Loren Merritt:
> On Mon, 20 Apr 2015, Harald Alvestrand wrote:
> 
>> (I also observed that the measured CPU time with --threads 1 on my
>> system is 6.7 seconds, while all configurations with multiple threads
>> come in above 8.1 seconds, with all configurations above 6 threads
>> taking 11 CPU-seconds. Is this also as expected?)
> 
> This is expected *if* you have a hyperthreaded CPU.
> Two hyperthreads on the same core counts as 200% CPU usage, but only gets
> about 25% more work done per wallclock-second than a single thread.
> Plus, most recent CPUs adjust their clockrate depending on how many
> cores you're using in order to limit heat.
> Unless you can eliminate these confounders (e.g. by turning them off in
> the BIOS), you just can't compare "CPU-seconds" between two workloads
> with different thread counts.
> 
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>