Re: Multiprocessing and y4mdenoise

On 5/26/09, Steven Boswell II <[email protected]> wrote:
> The other method involves a few internal worker-threads for the remaining big bottleneck that I haven't otherwise solved -- the flood-filling of pixel-group matches.  The problem here is how to coordinate the worker-threads with the main threads.  Experience with multi-threaded programming tells me that mutexes are WAY too slow to be used this much -- if I try to use several hundred thousand mutex locks/unlocks within a single frame, I'll just beat the operating system to death.

Mutexes only hop into the kernel if they have to sleep.  Calling
usleep/nanosleep will always hop into the kernel.  If you have to hop
into the kernel, you've already lost.

I assume "the other method" involves pipelining the problem, so each
thread processes the data in a way that the next thread can digest.
Probably the simplest mechanism is to use a pipe to signify
completions to the next thread, but take advantage of the shared
memory architecture of threads to transfer the real data.

I STRONGLY suggest you do not use sleep in the threads.  You'll never
sleep for the right amount of time -- it will vary by processor, and
depends on what tasks the processor is good at.  Use conditionals or
pipes to sleep until there is data to process, and try to make it so
data is processed in large enough chunks that you aren't signalling
from thread to thread too often.
-- 
        Scott

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects