[Haskell-cafe] ANNOUNCE: parallel-2.0.0.0

[Edward Kmett]

I love the new Eval Applicative!

Out of idle curiosity, can parListN be generalized to parTraverseN similar
to how parList was generalized to parTraverse? Similarly, parListChunk?

-Edward Kmett

On Wed, Nov 18, 2009 at 9:21 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> 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<http://www.haskell.org/%7Esimonmar/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<http://www.macs.hw.ac.uk/%7Edsg/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<http://www.haskell.org/%7Esimonmar/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 at .  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.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20091118/0a85a32a/attachment.html