[jzwinck]

I haven't used OpenCL before. This library seemed sort of reasonable but I had some questions about whether it was really that much better than the native OpenCL API. So I found an OpenCL "hello world" program here: http://developer.amd.com/tools-and-sdks/opencl-zone/opencl-r...

Holy crap. The "kernel" code is basically the same, but the native API setup code (which that tutorial even calls "boiler plate") is insane, starting with the fact that the source code for the CL on-device program has to be passed as a string. There is no API to pass a filename--only a string containing the entire program source!

[dragandj]

On the other hand, if you don't mind using other languages for the host code, there are a number of libraries in Java, Python, etc. that make it much simpler and more feature-complete than this library.

Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.

The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.

[Polytonic]

>On the other hand, if you don't mind using other languages for the host code, there are a number of libraries in Java, Python, etc. that make it much simpler and more feature-complete than this library.

What features would you consider to be missing?

>Major problem with many of those libraries, including this one, is that, while they help you with hello world, they cripple the real-world functionality. All this low-level stuff that is there in the standard usually has its use. Of course it could and should be simpler, but most of those wrapper libraries guess too much and make many optimizations inaccessible or very hard to achieve.

Of course, though I wouldn't say cripple. With abstraction comes an associated performance cost. Chlorine is intended to reduce the barrier to entry. It's one of those "do things that don't scale" ideas. It hides some of the boilerplate from you, and is meant to help you quickly validate your ideas. If you need more fine-grained control over memory allocation, execution order, etc., you can always turn to the C/C++ API for performance, and it shouldn't be too difficult to port.

>The library that I wrote for Clojure (and Java), ClojureCL (http://clojurecl.uncomplicate.org) even supports OpenCL 2.0 (which is usually not supported in other libraries), while still allowing you all sorts of low-level performance optimizations accessible in the native C API, and is (in my opinion) rather simple to use compared to other libraries, and requires little boilerplate.

My goal is to make GPU programming more accessible, so it's always good to see competition! Anyway, Chlorine is OpenCL 1.1/1.2 only, mainly because OSX is not OpenCL 2.0 compatible (knowing Apple, it may never be).

[anon4]

OpenCL always reminds me of "implementing the for keyword as a class in Java"... Yes, you can get pretty much the same semantics, but the code gets awfully unwieldy.

Compare to the CUDA alternative where a lot of this is implemented as extensions to C++ in nVidia's nvcc http://www.computer-graphics.se/hello-world-for-cuda.html

[cesnja]

OpenCL bootstrap sure is complex, but there are many possible configurations. I think this library is too simple right now. As soon as you need to optimize host code, you need to rewrite it with default API. On the other hand, I'd love to use this, if there were more options available.

[Polytonic]

The idea is to be super simple and easy to pick up. I'd rather spend my day to day time working on interesting problems, rather than slapping together boilerplate. Hence, my goal is to make it very easy to get started. When you need the performance, you can always reach for the C++ or C API.

>I'd love to use this, if there were more options available.

Did you have anything specific in mind? I'd be happy to add features.

[bainsfather]

"There is no API to pass a filename"

Use:

convertToString(filename, sourceStr);

and pass sourceStr.

You are right about how much boilerplate there is - though you can hide it a bit with helper fns and a few macros.