On Sun, 2005-02-20 at 23:52 +0000, Adam D. Moss wrote:
> Daniel Egger wrote:
> > I can force it to use both CPUs now, but even with
> > 200% utilization it is 2s slower to run this stupid
> > ubenchmark than on 1 CPU without threads.
> Just a vague guess, but the multiprocessor GIMP pixel
> work scheduler might* farm alternating tiles to alternating
> CPUs.  These are reasonably likely to have been allocated
> together and thus sit close together in memory, causing
> memory contention between CPUs.

I'm not sure what system the benchmark is being run on, but the cache
line size on a P4 is 128Byes (most other systems have smaller cache line
sizes).  A simple test to see if this is the problem would be to change
the tile allocation code to allocate an extra 128 bytes of memory per
tile.  See app/base/tile.c line 221

I think it is more likely that the problem is with sharing some other
data between processors (for example the gradient struct?)

I think it would be a good idea to get some timings from some other
operations also.  Perhaps painting with a large brush, or flattening a
complicated image.

Jay Cox

Gimp-developer mailing list

Reply via email to