On 25/04/2009 13:31, j.waldmann wrote:
Here is some more data. It seems the behaviour depends on 32/64 bit arch?
#######################################################
waldm...@master:~/tmp$ uname -a
Linux master 2.6.18-6-amd64 #1 SMP Fri Dec 12 05:49:32 UTC 2008 x86_64
GNU/Linux
waldm...@master:~/tmp$ time ./Par +RTS -N1
496165411
496165411
real 0m22.580s
user 0m22.541s
sys 0m0.040s
waldm...@master:~/tmp$ time ./Par +RTS -N2
496165411
496165411
real 0m21.259s
user 0m26.678s
sys 0m0.164s
########################################################
waldm...@box:~/tmp> uname -a
Linux box 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386
GNU/Linux
waldm...@box:~/tmp> time ./Par +RTS -N1
496165411
496165411
real 0m29.802s
user 0m29.670s
sys 0m0.028s
waldm...@box:~/tmp> time ./Par +RTS -N2
496165411
496165411
real 0m11.219s
user 0m14.917s
sys 0m0.164s
This is a very strange result: the user time should not *decrease*, but
rather should stay the same or increase a bit when adding cores. If
your program is GC-bound, then using a 32-bit build will improve
performance, simply because it is shoveling half as much memory around.
Check whether it is GC-bound by using +RTS -sstderr.
Anyway, the current situation is that with GHC 6.10.2 there are a lot of
performance quirks and bottlenecks with respect to parallel programs,
some of which have been squashed in HEAD. Try a recent HEAD snapshot if
you can, or wait for 6.12.1.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
