[XviD-devel] mulithread rework

[Con Kolivas]

On Thu, 24 Apr 2008 01:02:57 Edouard Gomez wrote:
> Quoting Con Kolivas <kernel at kolivas.org>:
> > Converting it to strict locking has the effect of performing at
> > virtually the same rate of frame encoding, but with much less CPU
> > usage.
>
> Did you just remove the "spinlocking" around the sched_yield or did
> you turn that wait code to pthread_condition stuff ?

Semaphore counts. Very light weight. No spinning and very fast.

>
> Yesterday i wrote an email from home proposing the use of a thread pool
> but the email didn't get through the mailing list agent.

It did.
>
> Because as I see it, the current thread implementation is suboptimal
> because threads are waiting actively on single tasks (next above block is
> completed). With a thread pool and a task queue, it is then possible to
> queue up more tasks and then let the consumers start picking from it.
>
> > So are there any other potential gains? There are minor improvements
> > to actual FPS encoded if all the threads are generated in advance and
> > not generated/destroyed on each frame being encoded because thread
> > creation is not exactly instantaneous, and allows CPU balancing to
> > move them around in advance rather than always starting on the same
> > CPU as the parent process. However, even this does not amount to much
> > improvement (I can't give you a firm figure but eyeballing the FPS was
> > not impressive).
>
> Yeah that was my idea with the threadpools, thread creation cost is
> reduced to a minimum.
>
> If it can help you investigate the threading pool + task queue, i have some
> free code online that can serve as a good starting point.
>
> See:
> http://ed.gomez.free.fr/vrac/threadpool.c
> http://ed.gomez.free.fr/vrac/threadpool.h
>
> The API is quite easy to understand, but be aware that the flush operation
> doesn't sync on thread task completion, it just makes sure the task queue
> is empty before returning. It's a 5min exercice (left to the reader) to add
> a sync on tasks completion instead.

I already said I tried thread pools (see eyeballing comment). They're 
unimpressive in their performance gains. The way work is currently divided up 
is simply not that scalable. This is not limited by the locking/threading 
model (which is what I originally thought). Changing the threading and 
locking model reduces cpu cost but does not improve the throughput.The work 
needs to be divided up differently or else nothing can make it scale any 
more.

-- 
-ck