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 [EMAIL PROTECTED] _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
