[FFmpeg-devel] [PATCH] Runtime detection for the number of processors/cores
Wed May 21 22:07:48 CEST 2008
On Wed, 2008-05-21 at 11:24 +0100, M?ns Rullg?rd wrote:
> Philipp Meinen wrote:
> > Hello FFmpeg Team
> > The attached patch is an attempt to allow runtime detection for the
> > number of online processors/cores instead of having to specify the
> > number of threads. The idea is to type:
> > ffmpeg -threads 0 ....
> > to use as many threads as processors/cores are online.
> > I guess cmdutils.c/h is not the right file to place the new
> > detection function. To which file should this function belong?
> > Comments welcome :)
> This is the wrong way to go about it. The number of processors in the
> machine is not interesting, the number of processors we're running on
> is. On Linux, this information can be found from sched_get_affinity().
> Other systems have other methods.
This is a reasonable generic statement, but the nice thing about
FFmpeg's approach to multithreading is that it sort of self-schedules.
IOW, even if you create more (far more!) threads than you have actual
execution units (could be CPUs, could be cores or could even be
virtual threads -- think Hype-R-Threading) the only overhead is
at the start-up phase. Thus, using _sysconf(_SC_NPROCESSORS_ONLN)
seems quite reasonable of a compromise.
On a related note: I still don't quite understand why MPEG based
codecs don't allow for higher degree of parallelism. Unlike DV codec
which I've just tested on a nice Maramba box (2 CPUs, 16 cores,
128 execution units) and it scaled pretty much linearly to the
# of cores, the MPEG based ones just refused to go higher than 4.
More information about the ffmpeg-devel