[FFmpeg-devel] [PATCH] slicethread: Limit the automatic number of threads to 16

[Martin Storsjö]

On Tue, 6 Sep 2022, Lukas Fellechner wrote:

> There are really two separate issues here:
>
> 1. Running out of address space in 32-bit processes
>
> It probably makes sense to limit auto threads to 16, but it should only
> be done in 32-bit processes.

FWIW, this was my first approach, until Andreas pointed out that we have 
such caps for automatic numbers of threads already in all other places 
where we pick an automatic number of threads - including 
libavcodec/pthread_slice.c, where the limit already today is 16 threads.

Also FWIW, this patch was already pushed, after being OK'd by Andreas on 
irc.

> A 64-bit process should never run out of address space. We should not 
> cripple high end machines running 64-bit applications.
>
>
> Sidenotes about "it does not make sense to have more than 16 slices":


> On 8K video, when using 32 threads, each thread will process 256 lines
> or about 1MP (> FullHD!). Sure makes sense to me. But even for sw decoding
> 4K video, having more than 16 threads on a powerful machine makes sense.
>
> Intel's next desktop CPUs will have up to 24 physical cores. The
> proposed change would limit them to use only 16 cores, even on 64-bit.
>
>
> 2. Spawning too many threads when "auto" is used in multiple places
>
> This can indeed be an efficiency problem, although probably not major.
> Since usually only one part of the pipeline is active at any time,
> many of the threads will be sleeping, consuming very little resources.

For 32 bit processes running out of address space, yes, the issue is with 
"auto" being used in many places at once.

But in general, allowing arbitrarily high numbers of auto threads isn't 
beneficial - the optimal cap of threads depends a lot on the content at 
hand.

The system I'm testing on has 160 cores - and it's quite certain that 
doing slice threading with 160 slices doesn't make sense. Maybe the cap of 
16 is indeed too low - I don't mind raising it to 32 or something like 
that. Ideally, the auto mechanism would factor in the resolution of the 
content.

Just for arguments sake - here's the output from 'time ffmpeg ...' for a 
fairly straightforward transcode (decode, transpose, scale, encode), 1080p 
input 10bit, 720p output 8bit, with explicitly setting the number of 
threads ("ffmpeg -threads N -i input -threads N -filter_threads N 
output").

12:
real	0m25.079s
user	5m22.318s
sys	0m5.047s

16:
real	0m19.967s
user	6m3.607s
sys	0m9.112s

20:
real	0m20.853s
user	6m21.841s
sys	0m28.829s

24:
real	0m20.642s
user	6m28.022s
sys	1m1.262s

32:
real	0m29.785s
user	6m8.442s
sys	4m45.290s

64:
real	1m0.808s
user	6m31.065s
sys	40m44.598s

I'm not testing this with 160 threads for each stage, since 64 already was 
painfully slow - while you suggest that using threads==cores always should 
be preferred, regardless of the number of cores. The optimum here seems to 
be somewhere between 16 and 20.

Also, in these cases, the decoder and encoder both warn that "Application 
has requested N threads. Using a thread count greater than 16 is not 
recommended" (see libavcodec/pthread.c).

I can also test with only varying the -filter_threads parameter, while 
keeping the decoder and encoder threads fixed at 16:

16:
real	0m20.303s
user	6m5.425s
sys	0m12.954s

20:
real	0m20.862s
user	6m12.625s
sys	0m21.860s

24:
real	0m20.445s
user	6m20.734s
sys	0m21.111s

32:
real	0m21.216s
user	6m15.926s
sys	0m42.264s

64:
real	0m20.687s
user	6m39.544s
sys	0m59.204s

Not quite as dramatical in this case, but (on this particular test clip, 
mostly determined by the resolution) we still don't gain anything above 16 
threads. On a larger test clip, the optimum number of slice threads 
probably is a bit higher. But always using up to the number of cores isn't 
really healthy.

// Martin