Parallel Haskell: 2-year project to push real world use
Christian Höner zu Siederdissen
choener at tbi.univie.ac.at
Mon May 3 19:21:48 EDT 2010
on that topic, consider this (rather trivial) array:
a = array (1,10) [ (i,f i) | i <-[1..10]] where
f 1 = 1
f 2 = 1
f i = a!(i-1) + a!(i-2)
(aah, school ;)
Right now, I am abusing vector in ST by doing this:
a <- new
a' <- freeze a
forM_ [3..10] $ \i -> do
write a (a'!(i-1) + a!(i-2))
Let's say I wanted to do something like this in dph (or repa), does that
work? We are actually using this for RNA folding algorithms that are at
least O(n^3) time. For some of the more advanced stuff, it would be
really nice if we could "just" parallelize.
To summarise: I need arrays that allow in-place updates.
Otherwise, most libraries that do heavy stuff (O(n^3) or worse) are
using vector right now. On a single core, it performs really great --
even compared to C-code that has been optimized a lot.
Thanks and "Viele Gruesse",
* Duncan Coutts <duncan.coutts at googlemail.com> [30.04.2010 17:11]:
> On Fri, 2010-04-30 at 10:25 -0400, Tyson Whitehead wrote:
> > On April 30, 2010 06:32:55 Duncan Coutts wrote:
> > > In the last few years GHC has gained impressive support for parallel
> > > programming on commodity multi-core systems. In addition to traditional
> > > threads and shared variables, it supports pure parallelism, software
> > > transactional memory (STM), and data parallelism. With much of this
> > > research and development complete, and more on the way, the next stage
> > > is to get the technology into more widespread use.
> > Does this mean DPH is ready for abuse?
> This project is about pushing the practical use of the parallel
> techniques that are already mature, rather than about pushing research
> projects along further.
> So this project is not really about DPH. On the other hand it's possible
> someone might be able to make more immediate use of the dense, regular
> parallel arrays which has been a recent spinoff of the DPH project. They
> have the advantage of being considerably easier to implement, but much
> less expressive than the full sparse, nested parallel arrays.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100503/f48cbe47/attachment.bin
More information about the Glasgow-haskell-users