Difference between revisions of "Performance/Parallel"
DonStewart (talk | contribs) |
DonStewart (talk | contribs) |
||
Line 12: | Line 12: | ||
GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, based on various factors, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html |
GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, based on various factors, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html |
||
+ | |||
+ | > GHC 6.10.2 contains some slightly bogus heuristics about when to turn on the parallel GC, and it just so happens that 8 processors tips it over the point where the parallel GC is enabled for young-generation collections. In 6.10.2 the parallel GC really didn't help most of the time, but it has undergone a lot of tuning since then, and in the HEAD things are much better (see the |
||
+ | results from our ICFP submission). |
||
+ | |||
+ | === Disabling parallel GC === |
||
+ | |||
+ | In the meantime you might get somewhere by disabling parallel GC altogether (+RTS -g1), but as the results in our paper show, sometimes the parallel GC is essential for retaining locality in parallel |
||
+ | |||
== Sparks == |
== Sparks == |
Revision as of 18:12, 27 April 2009
Tips and tricks for better multicore parallel performance from your Haskell.
Which GHC version to use
The recommended version of GHC for parallel programming at the moment (Apr 2009) is GHC 6.12 (aka the HEAD branch of GHC), which has had extensive tuning.
Affinity
Parallel GC
Using n-1 cores
GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, based on various factors, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html
> GHC 6.10.2 contains some slightly bogus heuristics about when to turn on the parallel GC, and it just so happens that 8 processors tips it over the point where the parallel GC is enabled for young-generation collections. In 6.10.2 the parallel GC really didn't help most of the time, but it has undergone a lot of tuning since then, and in the HEAD things are much better (see the results from our ICFP submission).
Disabling parallel GC
In the meantime you might get somewhere by disabling parallel GC altogether (+RTS -g1), but as the results in our paper show, sometimes the parallel GC is essential for retaining locality in parallel
Sparks
Data Parallel Arrays
Tool Support
Tools for parallel performance tuning:
- ThreadScope
- GHC (HEAD 2009) supports a visual post-mortem analysis, and a graphical tool "ThreadScope" has been developed by Satnam Singh and others.