On Wed, 2005-02-16 at 22:42 +0100, Sven Neumann wrote:
> Hi,
> I couldn't resist and changed the PixelProcessor to use a thread pool.
> Main motivation was to make progress callback work for the threaded
> case. So there's now a variant of pixel_regions_process_parallel()
> that takes progress function and data. This allows us to parallelize
> some of the slower core functions (like for example gradient blend).
> It would be interesting to know if this actually gives a noticeable
> speedup on SMP systems. Would be nice if one of you could give this
> some testing. Please try to do gradient blends (w/o adaptive
> supersampling!) on large images. Changing the number of processors in
> the preferences dialog allows you to switch between using the thread
> pool and the single-threaded code.

Here are some results for you:

Dual 2.5ghz g5 mac, mac os x 10.3.8
CVS gimp Changelog revision 1.10539

Linear Gradient blend on a 3000x3000 pixel image (Dithering on)
1 Processor:   7.98 seconds        1x
2 processors:  5.20 seconds        1.5x
3 processors:  5.23 seconds        1.5x

Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF)
1 processor:   3.89 seconds        1x
2 processors:  2.37 seconds        1.7x
3 processors   2.40 seconds        1.7x

Clearly the gradient code could use some tuning.  A linear blend
shouldn't take much more than 1/2 a second even with dithering.

The reason why the dithering case gets less of a speedup is because the
threads are fighting over the GRand state.  Each thread needs to have
it's own GRand state.

It looks like the threads are also fighting over gradient->last_visited.
My guess is that fixing this will get us much closer to the ideal 2x
speed up.

I don't see myself hacking on the gradient code in the near future so
anyone else should feel free...

Jay Cox

Gimp-developer mailing list

Reply via email to