[Insight-users] Data Parallelization

[Luis Ibanez]

Hi Ron,


Your item (b) describes better the ITK pipeline.

The implementation of the pipeline is made in
such a way to make this possible. However case (b)
may only happen in the ideal case in which all the
filters downstream are pixel-wise, henceforth fully
parallelizable.

In practice, the pipeline negotiates filter by
filter how to stream data. If a streaming filter
is followed by a non-streaming one, the negotiation
will result in case (a).

For example, if you connnect the GradientMagnitude
RecursiveGaussianFilter (GMRG) at the output of the
Sigmoid filter. The Sigmoid can still run in several
threads but it will have to collectall the image
pieces and synchronize the thread endings before
passing its output to the GMRG filter. This, due to
the fact that the GMRG requires the full data of the
image to be available before it can start computing.

To summarize, in practice a mix of (a) and (b) will
happen in different sections of the pipeline, depending
on the type of filters that you put together.



    Luis


------------------------------------------
Ron Inbar wrote:
> Hi Luis,
> 
> Thanks a lot for your answer!
> 
> I have one more question, though (in fact I have more than one, but I'll ask
> them one at a time): When multithreading is enabled for a particular filter
> F (using F->SetNumberOfThreads( N ) ) which of the following better
> describes what takes place:
> 
> (a) The Input is updated; the RequestedRegion is partitioned into N pieces;
> N threads are spawned; each thread generates its piece of the output; the
> filter waits for all threads to finish; the next filter downstream (if there
> is one) begins to execute.
> 
> (b) The RequestedRegion is partitioned into N pieces; N threads are spawned;
> each thread updates its input and executes; the filter waits for all threads
> to finish, and then the next filter downstream executes.
> 
> To make the point clearer: method (a) splits execution for one filter at a
> time, but the pipeline as a whole still executes serially (i.e., each filter
> has to finish executing before the one downstream can begin), while method
> (b) splits execution all the way upstream from F (i.e., the section of the
> pipeline upstream from F will be executed in each of the N threads
> independently).
> 
> Method (b) is probably more efficient (because there's less thread
> synchronization), but more difficult to implement.
> 
> Thanks in advance,
> 
> Ron
> 
>