Difference between revisions of "Performance/Parallel"

From HaskellWiki
Jump to: navigation, search
Line 13: Line 13:
 
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
+
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).
 
results from our ICFP submission).
   
Line 19: Line 19:
   
 
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
 
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.