[Haskell-cafe] OpenCL target for DPH?

Manuel M T Chakravarty chak at cse.unsw.edu.au
Mon Dec 7 18:18:40 EST 2009


Marcus Daniels wrote,
> I'm wondering if anyone has looked at OpenCL as target for Data Parallel
> Haskell?  Specifically, having Haskell generate CL kernels, i.e. SIMD
> vector type aware C language backend, as opposed to just a Haskell
> language binding.

The short answer is that there is currently no plan to directly target OpenCL from DPH.  (That is the DPH team doesn't have any such plans, but if anybody else wants to give it a shot, the latest, bleeding edge DPH code is always available in the GHC HEAD repository.)

The long answer is that we are currently working on two separate data-parallel extensions for Haskell.

Data Parallel Haskell <http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell>
~~~~~~~~~~~~~~~~~~~~~
Here the focus is *expressiveness*.  In particular, we support arbitrarily deep, dynamic nesting of dataparallel computations with full support of higher-order functions (ie, parallel arrays of functions are fine).  However, to keep the work manageable, we only target multicore CPUs for the moment (using the multi-threading support in GHC's RTS).

Data.Array.Accelerate <http://www.cse.unsw.edu.au/~chak/project/accelerate/>
~~~~~~~~~~~~~~~~~~~~~
Here the focus is on targeting *exotic, high-performance hardware*.  We are currently working on a CUDA backend targeting CUDA-capable NVIDIA GPUs, but it shouldn't be too hard to re-target that to OpenCL.  Support for the Cell BE and FPGAs appears feasible, too (but we lack local expertise and hardware to write such backends ourselves).  However, to keep the work manageable, we only consider regular, multi-dimensional array codes encoded in an embedded DSL where functions are not first-class (ie, we use Haskell's first-class functions to implement the EDSL, but the embedded language is first-order).

Longer term future
~~~~~~~~~~~~~~~~~~
At some point, we would of course like to bring the above two projects together, but at the moment, each is already rather challenging just by itself.

Manuel



More information about the Haskell-Cafe mailing list