On 27.02.2005, at 01:04, Sven Neumann wrote:
I have eliminated last_visited from the gradient struct. Instead the caller of gimp_gradient_get_color_at() may now do the same optimization without any caching in the gradient itself. I very much doubt that this makes any difference though. Perhaps if you would benchmark a gradient blend with a lot of segments. But in the general case it's just a few of them, very often even only a single one.
Now that this race condition is eliminated I might look into adding hooks to the pixel-processor to allow initialisation of per-thread data, like for example a GRand.
Your change dramatically changed the picture.
Instead of:
Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor: 7.5 s 2 processors: 9.6 s 4 processors: 9.6 s
Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor: 3.0 s 2 processors: 2.5 s 4 processors: 2.5 s
I now get: Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor: 7.2 s 2 processors: 8.9 s
Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor: 2.5 s 2 processors: 1.5 s
However dithering on is still loosing quite a bit on this SMP machine....
Servus,
Daniel
Attachment:
PGP.sig
Description: This is a digitally signed message part
