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 <marlo...@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...@. 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe