From eca1e7e7becd3d444be45850031e3fa35bccd55d Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Tue, 15 Sep 2009 08:34:31 +0000 Subject: [PATCH] Update the "Hints for using SMP parallelism" section In particular, remove the claim that the GC is single-threaded! --- docs/users_guide/using.xml | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/users_guide/using.xml b/docs/users_guide/using.xml index 06b9ccc..af7950c 100644 --- a/docs/users_guide/using.xml +++ b/docs/users_guide/using.xml @@ -2002,19 +2002,20 @@ f "2" = 2 whether your program got faster by using more CPUs or not. If the user time is greater than the elapsed time, then the program used more than one CPU. You should - also run the program without -N for comparison. - - GHC's parallelism support is new and experimental. It may make your - program go faster, or it might slow it down - either way, we'd be - interested to hear from you. - - One significant limitation with the current implementation is that - the garbage collector is still single-threaded, and all execution must - stop when GC takes place. This can be a significant bottleneck in a - parallel program, especially if your program does a lot of GC. If this - happens to you, then try reducing the cost of GC by tweaking the GC - settings (): enlarging the heap or the - allocation area size is a good start. + also run the program without -N for + comparison. + + The output of +RTS -s tells you how + many “sparks” were created and executed during the + run of the program (see ), which + will give you an idea how well your par + annotations are working. + + GHC's parallelism support has improved in 6.12.1 as a + result of much experimentation and tuning in the runtime + system. We'd still be interested to hear how well it works + for you, and we're also interested in collecting parallel + programs to add to our benchmarking suite. -- 1.7.10.4