[Haskell-cafe] ANN: OpenCL 1.0.1.3 package

[Jason Dagit]

On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal <dybber at dybber.dk> wrote:
> On 3 October 2011 12:56, Luis Cabellos <cabellos at ifca.unican.es> wrote:
>> Hello, all.
>> I want to show you the OpenCL package. I have done this using Jeff Heard
>> OpenCLRaw package, but I create a new one due the lack of updates of the
>> former.
>> # Where to get it
>> * Hackage page (http://hackage.haskell.org/package/OpenCL)
>> * Repository (https://github.com/zhensydow/opencl)
>> * Bugs (https://github.com/zhensydow/opencl/issues)
>> * Examples (https://github.com/zhensydow/opencl/tree/master/examples).
>> # Things:
>> * I write it's high-level binding to OpenCL libraries, but only because I
>> added more types to hide most of the alloc/free of the API, and hide the
>> enums using c2hs enums.
>> * The worst problem of the OpenCLRaw is the bad types it use, I learn to fix
>> 32/64 bits issues with c2hs, and test it on linux machines.
>> * Tested on Linux + NVidia only.
>> * Jason Dagit is helping with Windows, OSX testing in own fork, also the
>> call-conv fork in github has changes to work on Windows
>> Please, Consider it's on experimental status but it works, I need lots of
>> feedbacks for detect posible errors,
>> Thanks,
>
> Hi everyone
>
> I just found this thread today, as I don't read Haskell-cafe that
> often (too bad, I know). I have been working on a set of OpenCL
> bindings for the last months myself, which I'm using to implement an
> OpenCL backend to the Data.Array.Accelerate library. The work is done
> at the HIPERFIT research center, Uni. Copenhagen.
>
> My bindings are even further from the naming conventions of the OpenCL
> library, but I really can't see the problem with that. People which
> are used to programming OpenCL from C/C++ might have to learn how the
> naming conventions of the Haskell library are, but they only need to
> do this once.

I think it's important to distinguish between being a new API and
being a faithful binding to an established API.  In reality it ends up
as a continuum because an exact one to one mapping is not possible
between idiomatic C and idiomatic Haskell.  If someone is renaming
things or changing the API when not strictly necessary then I would
say person is making a new API based on the the old API.  My desire is
to have a binding which is faithful to the C API and then letting
people build new abstractions on top of that.

> When the mapping between the old and the new naming
> conventions are learned, they will benefit from having a more clean
> interface for all future times. (No Haskell hacker should have a
> problem with a steep learning curve.)

I have to disagree here, based largely on my experience with learning
other Haskell bindings (for example OpenGL, which I knew from C).  If
I were to twist your words I could use this to say that we should make
Haskell hard to learn.  I doubt that's what you meant but it seems
dangerously close to me.

Probably we have very different goals.  You want to make a nice
OpenCL-based API for parallel programming and I want a binding that
matches the OpenCL api very closely, but not to the point of using Ptr
() in many places.

> It is somewhat troubling that we now have five different interfaces to
> OpenCL (that I know of), and I think we should join efforts and make
> one library that is as stable as possible. The five libraries are:

I agree that having so many implementations of the binding is odd.  I
wonder if it's because they cater to different needs.  In the case of
OpenCLRaw we could reasonably remove it from the list because it's
unmaintained and incomplete.

And yes, it would be nice to merge efforts.

Jason