On 26/06/2012 00:42, Ryan Newton wrote:
However, the parallel GC will be a problem if one or more of your
cores is being used by other process(es) on the machine. In that
case, the GC synchronisation will stall and performance will go down
the drain. You can often see this on a ThreadScope profile as a big
delay during GC while the other cores wait for the delayed core.
Make sure your machine is quiet and/or use one fewer cores than
the total available. It's not usually a good idea to use
hyperthreaded cores either.
Does it ever help to set the number of GC threads greater than
numCapabilities to over-partition the GC work? The idea would be to
enable some load balancing in the face of perturbation from external
load on the machine...
It looks like GHC 6.10 had a "-g" flag for this that.... later went away?
The GC threads map one-to-one onto mutator threads now (since 6.12).
This change was crucial for performance, before that we hardly ever got
any speedup from parallel GC because there was no guarantee of locality.
I don't think it would help to have more threads. The load-balancing is
already done with work-stealing, it isn't statically partitioned.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
