4 ms·

There's actually quite a few of these kind of libraries floating around, although I'm not sure how many are still actively supported. Thrust: http://thrust.git

by scott_s 11y ago

There's actually quite a few of these kind of libraries floating around, although I'm not sure how many are still actively supported. Thrust: http://thrust.github.io/ http://thrust.github.io/ VexCL: http://ddemidov.github.io/vexcl/ http://ddemidov.github.io/vexcl/ Boost.Compute: http://boostorg.github.io/compute/ http://boostorg.github.io/compute/ The author of VexCL provided a comparison of them two years ago: http://stackoverflow.com/questions/20154179/differences-between-vexcl-thrust-and-boost-compute http://stackoverflow.com/questions/20154179/differences-betw...

oneofthose 11y ago
There is another library authored by me and some colleagues. It is called Aura: https://github.com/sschaetz/aura https://github.com/sschaetz/aura I blogged about these kinds of libraries here (overview): http://www.soa-world.de/echelon/2014/04/c-accelerator-libraries.html http://www.soa-world.de/echelon/2014/04/c-accelerator-librar... A new addition is welcome as we still have not found the perfect API for accelerator programming. EasyOpenCL seems very simple and easy to use but I feel like it is very restricted. For getting started with OpenCL development these days I would recommend PyOpenCL. Since everything is in Python, data can be generated easily, results can be plotted using well known Python tools which simplified debugging. Kernels developed in PyOpenCL can directly be copied to other APIs (raw OpenCL C API or some of the other C/C++ wrappers) and reused in production code.
- Polytonic 11y ago
  I think the problem with (most of?) these libraries is that they don't solve the fundamental problem, which is: the OpenCL API is awful to work with. Various strategies have been attempted, mainly involving some form of "wrap the C API in less verbose C++!"
lfowles 11y ago
pocl seems to be another: http://portablecl.org/ http://portablecl.org/
paulmd 11y ago
Thrust is for CUDA. But there's also the Bolt framework for OpenCL. EasyOpenCL sounds quite similar to these STL-style libraries.
ginko 11y ago
There is also SYCL[1], which is backed by Khronos (the standards body behind OpenCL, OpenGL, Vulkan and others) [1]https://www.khronos.org/sycl https://www.khronos.org/sycl
dragandj 11y ago
I must shamelessly plug my own ClojureCL library for doing this sort of programming from Clojure. http://clojurecl.uncomplicate.org http://clojurecl.uncomplicate.org

by scott_s 11y ago

oneofthose 11y ago

There is another library authored by me and some colleagues. It is called Aura: https://github.com/sschaetz/aura https://github.com/sschaetz/aura I blogged about these kinds of libraries here (overview): http://www.soa-world.de/echelon/2014/04/c-accelerator-libraries.html http://www.soa-world.de/echelon/2014/04/c-accelerator-librar... A new addition is welcome as we still have not found the perfect API for accelerator programming. EasyOpenCL seems very simple and easy to use but I feel like it is very restricted. For getting started with OpenCL development these days I would recommend PyOpenCL. Since everything is in Python, data can be generated easily, results can be plotted using well known Python tools which simplified debugging. Kernels developed in PyOpenCL can directly be copied to other APIs (raw OpenCL C API or some of the other C/C++ wrappers) and reused in production code.

Polytonic 11y ago
I think the problem with (most of?) these libraries is that they don't solve the fundamental problem, which is: the OpenCL API is awful to work with. Various strategies have been attempted, mainly involving some form of "wrap the C API in less verbose C++!"

lfowles 11y ago

pocl seems to be another: http://portablecl.org/ http://portablecl.org/

paulmd 11y ago

Thrust is for CUDA. But there's also the Bolt framework for OpenCL. EasyOpenCL sounds quite similar to these STL-style libraries.

ginko 11y ago

There is also SYCL[1], which is backed by Khronos (the standards body behind OpenCL, OpenGL, Vulkan and others) [1]https://www.khronos.org/sycl https://www.khronos.org/sycl

dragandj 11y ago

I must shamelessly plug my own ClojureCL library for doing this sort of programming from Clojure. http://clojurecl.uncomplicate.org http://clojurecl.uncomplicate.org