Parallel Haskell: 2-year project to push real world use

[Christian Höner zu Siederdissen]

Hi,

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",
Christian

* 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.
> 
> Duncan
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100503/f48cbe47/attachment.bin