I've just uploaded parallel-2.0.0.0 to Hackage. If you're using
Strategies at all, I'd advise updating to this version of the parallel
package. It's not completely API compatible, but if you're just using
the supplied Strategies such as parList, the changes should be
relatively minor.
The Haddock docs include a full description of the changes, reproduced
below. Haddock docs are also here, until Hackage catches up:
http://www.haskell.org/~simonmar/parallel/index.html
The Strategy-using programs I've tried so far go faster. Enjoy!
Cheers,
Simon
---------------------------------------------------------------------
Version 1.x
The original Strategies design is described in
<http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html>
and the code was written by
Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al.
Version 2.x
Later, during work on the shared-memory implementation of
parallelism in GHC, we discovered that the original formulation of
Strategies had some problems, in particular it lead to space leaks
and difficulties expressing speculative parallelism. Details are in
the paper \"Runtime Support for Multicore Haskell\"
<http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf>.
This module has been rewritten in version 2. The main change is to
the 'Strategy a' type synonym, which was previously @a -> Done@ and
is now @a -> a...@. This change helps to fix the space leak described
in \"Runtime Support for Multicore Haskell\". The problem is that
the runtime will currently retain the memory referenced by all
sparks, until they are evaluated. Hence, we must arrange to
evaluate all the sparks eventually, just in case they aren't
evaluated in parallel, so that they don't cause a space leak. This
is why we must return a \"new\" value after applying a 'Strategy',
so that the application can evaluate each spark created by the
'Strategy'.
The simple rule is this: you /must/ use the result of applying
a 'Strategy' if the strategy creates parallel sparks, and you
should probably discard the the original value. If you don't
do this, currently it may result in a space leak. In the
future (GHC 6.14), it will probably result in lost parallelism
instead, as we plan to change GHC so that unreferenced sparks
are discarded rather than retained (we can't make this change
until most code is switched over to this new version of
Strategies, because code using the old verison of Strategies
would be broken by the change in policy).
The other changes in version 2.x are:
* Strategies can now be defined using a convenient Applicative
type Eval. e.g. parList s = unEval $ traverse (Par . s)
* 'parList' has been generalised to 'parTraverse', which works on
any 'Traversable' type.
* 'parList' and 'parBuffer' have versions specialised to 'rwhnf',
and there are transformation rules that automatically translate
e.g. @parList rwnhf@ into a call to the optimised version.
* 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@
package instead. Note that since the 'Strategy' type changed, 'rnf'
is no longer a 'Strategy': use 'rdeepseq' instead.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
