
Chlorine: Dead Simple GPGPU - Polytonic
https://github.com/Polytonic/Chlorine
======
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...](http://developer.amd.com/tools-and-sdks/opencl-zone/opencl-
resources/introductory-tutorial-to-opencl/)

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](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](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).

------
feelix
This looks really interesting and extremely useful for a program of mine. Has
anyone tried this in OS X?

~~~
Polytonic
My primary platform is OSX, and Chlorine was written to target OSX first. It
is arguably the easiest to get started under OSX.

------
CyberDildonics
"Header only" but needs CMake?

~~~
tomjakubowski
You need CMake to run the in-tree examples and tests. That doesn't mean you
need CMake to use the library, which is in fact header-only.

