Re: Limit of 4 threads in the VfW GUI

Michael Militzer <[email protected]> Mon, 29 Nov 2010 13:03:15 +0100
Newsgroups gmane.comp.video.xvid.devel
Message-ID <[email protected]>
Hi,

well, maybe you could indeed provoke a crash with "way too many" threads.
But that shouldn't be an issue yet with a bit more than 4 threads.

The problem is rather that xvidcore doesn't scale well for many threads. So
using many threads doesn't necessarily make things faster, especially not
with low vertical input resolution.

The threading algorithm in xvidcore has a "warm-up" and a "fade-out" phase
so to say, where the threads do not all run fully in parallel. So there are
interdependencies between the threads, which cause waiting and syncing
phases with other threads. This overhead becomes bigger with increasing
number of threads, so that the benefits from launching more threads also
becomes smaller and smaller.

Further, only the ME and RD-opt code is multi-threaded in xvidcore. The
write-out of the final bitstream for a frame is still serialized (as is
the bitstream itself). So with more threads and faster ME and R-D analysis,
the bitstream writing will gain more impact relatively. This also limits
the scalability of xvidcore over many threads.

The limit of "4" in VfW is there because xvidcore scales quite well to this
number of threads. Increasing it to say "8" will likely yield a further
speed-up for HD input video but it will not nearly be double the speed
(because of the additional sync and wait overhead). So you might overall get
a better performance when running xvidcore with just the "4" threads (which
still scale ok) and use your remaining CPU to run some other common tasks
in parallel, like audio encoding, image prefiltering or decoding of your
input video (which should often be compressed also). Therefore, the VfW
limit of "4" threads seemed like a good compromise.

If you want to use many threads effectively for xvid encoding, have a look
at xvid_encraw. The xvid_encraw program can combine the xvidcore threading
algorithm with multi-threading at the app-level and scales rather well to
e.g. 8 threads.

Best regards,
Michael


Quoting Marcin Jaworski <[email protected]>:

> Greetings.
>
> The VfW GUI limits the number of threads to 4
> (xvidcore/vfw/src/config.c, line 1478), but the core library has no such
> limitation. I know that the vertical resolution of the input effectively
> limits the number of threads that can be used, but is there a reason for
> hardcoding the limit in VfW to just 4? SysKin once warned about using
> "way too many" threads. Can >4 be too many for the algorithm to handle
> (can it cause crashes etc.)?
>
> Best regards,
> Marcin Jaworski
> _______________________________________________
> Xvid-devel mailing list
> [email protected]
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>