Threads and memory management

[Simon Marlow]

On 28/04/2009 17:25, Johannes Waldmann wrote:
> Thanks for your comments.
>
>
>>   Check whether it is GC-bound by using +RTS -sstderr.
>
> Well yes, it does a lot of GC (there's no way for the compiler
> to optimize away the list of primes) because that was the point
> of the example: to confirm (or disprove)
> that GC hurts parallelism (at the moment).
>
>
>    INIT  time    0.00s  (  0.00s elapsed)
>    MUT   time   13.23s  (  7.98s elapsed)
>    GC    time   14.12s  ( 14.11s elapsed)
>    EXIT  time    0.00s  (  0.00s elapsed)
>    Total time   27.35s  ( 22.09s elapsed)
>
>    %GC time      51.6%  (63.9% elapsed)
>
>
>> Try a recent HEAD snapshot if you can, or wait for 6.12.1.
>
> I did with 6.11.20090425 and it coredumps with  +RTS -N2  (on x86_64)

That's worrying, but I don't see a core dump here.  Here are my results:

GHC 6.11.20090429 -N1:

   INIT  time    0.00s  (  0.00s elapsed)
   MUT   time   13.52s  ( 13.64s elapsed)
   GC    time   21.25s  ( 21.23s elapsed)
   EXIT  time    0.00s  (  0.00s elapsed)
   Total time   34.76s  ( 34.87s elapsed)

GHC 6.11.20090429 -N2 -qg0 -qb:

   INIT  time    0.00s  (  0.00s elapsed)
   MUT   time   14.40s  (  7.21s elapsed)
   GC    time   18.35s  (  9.22s elapsed)
   EXIT  time    0.00s  (  0.00s elapsed)
   Total time   32.75s  ( 16.44s elapsed)

which, if I'm not mistaken, is super-linear speedup :-)

Don't forget the -qg0 -qb flags with HEAD, these flags usually give the 
best parallel GC performance at the moment.  For the release this might 
be the default, I still have to do some more experiments.

Cheers,
	Simon