On Wed, 2005-02-16 at 22:42 +0100, Sven Neumann wrote:
> 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
I don't see myself hacking on the gradient code in the near future so
anyone else should feel free...
Gimp-developer mailing list