Threads and memory management

[Simon Marlow]

On 25/04/2009 13:31, j.waldmann wrote:
> Here is some more data. It seems the behaviour depends on 32/64 bit arch?
>
> #######################################################
>
> waldmann at 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
>
> waldmann at master:~/tmp$ time ./Par +RTS -N1
> 496165411
> 496165411
>
> real    0m22.580s
> user    0m22.541s
> sys     0m0.040s
> waldmann at master:~/tmp$ time ./Par +RTS -N2
> 496165411
> 496165411
>
> real    0m21.259s
> user    0m26.678s
> sys     0m0.164s
>
> ########################################################
>
> waldmann at 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
>
> waldmann at box:~/tmp>  time ./Par +RTS -N1
> 496165411
> 496165411
>
> real    0m29.802s
> user    0m29.670s
> sys     0m0.028s
> waldmann at 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