how to figure out how many threads x264 used?

[plonk420]

i'm assuming build doesn't matter, though i'm running 1139, currently.

[LoRd_MuldeR]

By default x264 uses exactly one thread. If you specify "--threads auto" (aka "--threads 0"), it will use 3/2 * <number of cores> threads.

And if you specify "--threads n", it will use n threads....

[plonk420]

oh, answered my own question:

x264 - core 67 r1139M 1024283 - H.264/MPEG-4 AVC codec - Copyleft 2003-2009 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x133 me=tesa subme=9 psy_rd=1.0:0.0 mixed_ref=1 me_range=32 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-2 threads=4 nr=0 decimate=0 mbaff=0 bframes=8 b_pyramid=0 b_adapt=2 b_bias=0 direct=1 wpredb=1 keyint=250 keyint_min=25 scenecut=40 rc=2pass bitrate=300 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

i could have SWORN i've seen threads=0 before...

and it would appear it rounds down or does int(cores*3/2) when one has an X3

[roozhou]

CTRL+ALT+DEL, it is shown in your task manager

[LoRd_MuldeR]

and it would appear it rounds down or does int(cores*3/2) when one has an X3

The code is as follows:

if( h->param.i_threads == 0 )
h->param.i_threads = x264_cpu_num_processors() * 3/2;

And you are right: 3 * 3 / 2 will result in 4, as both arguments of the division are "int" type. To get it rounded to 5, one would need to do it like this:

if( h->param.i_threads == 0 )
h->param.i_threads = round(x264_cpu_num_processors() * 3 / 2.0f);

[kemuri-_9]

To get it rounded to 5, one would need to do it like this:
if( h->param.i_threads == 0 )
h->param.i_threads = round(x264_cpu_num_processors() * 3 / 2.0f);

and that also would cause 1 thread to round up to 2,
which is sub-optimal, so the rounding down case was chosen instead.

[plonk420]

i was going to do more testing on it (lower res, 1080p), but i got a bit drunk/distracted;

my 4 thread (cores = 0) vs 5 thread test gave this result:

pass 1: .89 FPS
pass 2: .97 FPS

5 threads:

pass 1: 1.00 FPS
pass 2: 1.08 FPS

i'm assuming it doesn't warrant enough to change UI settings..

program --pass 2 --bitrate 4000 --stats ".stats" --level 4.1 --ref 5 --mixed-refs --no-fast-pskip --bframes 5 --b-adapt 2 --weightb --deblock -1:-1 --subme 9 --trellis 2 --partitions all --8x8dct --me tesa --merange 32 --threads 5 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"

X3 710, jacked up mix of (speeds of) 4 1gb sticks of DDR2

note: i left prime95/seventeenorbust running... (so if it seems slower than it should be)

note2: also, source was less than optimal; 1000 frames of 576i source of The IT Crowd (lanczos4resized to 720p); i should have started with a 1080p source and scaled down...

[roozhou]

(cores + 2) seems better than (cores * 3 / 2) for me.

[Sagekilla]

That defeats the purpose of cores * 3 / 2 though. The point is that, when running n threads, one or more of those threads may have finished stopped working and must wait for the other thread to finish. Alternatively, you can have n * 1.5 threads, so that after a thread (or group of threads) stops working, another thread / group can wake up and continue doing work.

[roozhou]

That defeats the purpose of cores * 3 / 2 though. The point is that, when running n threads, one or more of those threads may have finished stopped working and must wait for the other thread to finish. Alternatively, you can have n * 1.5 threads, so that after a thread (or group of threads) stops working, another thread / group can wake up and continue doing work.

x264 is not that perfect as you wish.
On my E8400 --threads 4 is faster than --threads 3

[Sagekilla]

I never said it was perfect, nor did I imply it was perfect. I said that using the default method of threads * 1.5 is more optimal than threads + 2. For low core counts, that method works fine. But if you have something like 16 cores, it'd probably be more efficient to use 20+ threads rather than 16 or 18.

[roozhou]

I never said it was perfect, nor did I imply it was perfect. I said that using the default method of threads * 1.5 is more optimal than threads + 2. For low core counts, that method works fine. But if you have something like 16 cores, it'd probably be more efficient to use 20+ threads rather than 16 or 18.

Can we find out a more optimal formula for number of threads?

[plonk420]

you may contribute your tests if you so wish!

[Sagekilla]

@Roozhou: I'd love to but the biggest problem is being able to accurately test from 1 core up to N cores. Let N be some ridiculous number like 24 (!) for arguments sake. If we have access to 24 cores, as well as the ability to specify how many cores are active, we should be able to find an optimal scaling formula for threads vs cores.

Another issue is the fact that frame type decision is still single threaded. So do we look at just b-adapt mode 1, 2, both, or all including off?


At this point, this probably belongs in it's own thread for finding an optimal scaling formula that works all the way up to many-core systems. It should be nothing but trial and error but we need to get results from multiple cores as well.

[roozhou]

Another issue is the fact that frame type decision is still single threaded. So do we look at just b-adapt mode 1, 2, both, or all including off?


We should make formulas for each b-adapt mode

[Patrick Bateman]

x264 is not that perfect as you wish.
On my E8400 --threads 4 is faster than --threads 3

Ditto. I tested 1,2,3,4,6,8 threads on my E8400 (OC'd to 3.60) and in speed it went 8>6>4>3>2>1. But the speed advantage with 6 and 8 was so minimal. Also, I saw it was hurting SSIM values and bitrate was falling so I figured it probably isn't a good idea to have too many threads.