On Mon, Feb 21, 2005 at 09:14:13AM +0100, Tino Schwarze <[EMAIL PROTECTED]>
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
This is unlikely, as the gimp has no say in the physical layout of the memory
it gets from the kernel.
Also, interleaving should not have much of an effect, as the blocks are
large, so there will be no thrashing between cpus (if hyperthreading is in
use, then interleaving would actually be slightly better due to limited
cache associativity).
It's more likely that gimp is doing something wrong currently, with respect
to locking or sth. similar.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
