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