DPH and CUDA status

[Manuel M T Chakravarty]

Felipe Lessa:
> On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote:
>> Hello Felipe,
>> 
>> I copied this email to Sean Lee & Manuel M T Chakravarty as they
>> worked on Haskell+CUDA, maybe they can comment on the current status?
>> 
>> Here's their paper...
>> GPU Kernels as Data-Parallel Array Computations in Haskell
>> http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf
> 
> As far as I could look for on Hackage and on Chakravarty's web
> site the code from the paper isn't released.  So now he has DPH,
> Data.Array.Accelerate and GPU monad for array processing :).

It's really only two things, as the GPU monad from the cited paper has been superseded by Data.Array.Accelerate — ie, the latter is a revision of the former.  So, the code from the cited paper will eventually be released as a CUDA backend for D.A.Accelerate.

> I wonder if he has any plans of gluing things?

Our intention is to bring the two together eventually, but at the moment, each project on its own is already rather challenging.  As far as

  http://hackage.haskell.org/trac/summer-of-code/ticket/1537

is concerned, I think it is a huge amount of work, well beyond what even a group GSoC project could achieve, especially as it is not just an implementation project, but requires a large amount of research.  Things may get a bit easier with the recently announced Fermi architecture, but I don't think that is going to change the picture fundamentally.

I would suggest that any GSoC project in this space should be based on D.A.Accelerate (rather than DPH), simply because the code base is much smaller and more accessible.  There is not much point in writing a CUDA backend, as we already have a partially working one that we are going to release in due course.  However, I repeatedly had people asking for an OpenCL backend.  So, there appears to be some demand for that (and it's the right thing to do, given that CUDA is tied to a single company).  An OpenCL backend for D.A.Accelerate also appears to be in the scope of what a good coder can achieve in the timeframe of a GSoC project.  (To be precise, I think, a good coder can implement a working backend in that timeframe, but it will probably require more work to generate well optimised code.)

Manuel