Well, that was the theory, anyway :) 
The practice shows that the handwritten library supports 100% the latest 
OpenCL version, while a couple of automatically generated libraries (Jogamp 
JOCL, JavaCL) support only old versions, and even that support is not 
complete. And it is written in standard C that other people can understand, 
instead of using obscure and poorly documented experimental code generators.
Additional + for JOCL.org is that it is much faster, which may or may not 
be important for particular use cases, but certainly does not hurt :)
Moreover, JOCL.org is a low level library, which is in my opinion a much 
better choice for higher-level libraries like ClojureCL, because it maps 
almost 1:1 to the OpenCL standard.

Now, I do not have anything against JNA: it might be an excellent choice 
when you need to connect to a native library and do not have time and 
resources to write a separate JNI layer. But, for a kind of a system 
library like OpenCL, I think writing tuned JNI calls pays off, since OpenCL 
does not change often.

On Tuesday, June 16, 2015 at 12:35:06 AM UTC+2, Karsten Schmidt wrote:
>
> Thanks for clarifying this, Dragan! I'm v.interested in OCL2.0, but 
> alas have to wait on OSX :( I also didn't know about Jogamp JOCL being 
> stale - I knew the previous maintainer left, but there seems to be 
> some activity (would be a shame too, if not...). To be honest, I don't 
> think the JNA route is causing a noticeable slowdown compared to JNI 
> though, at least not in my use cases where the number of OCL native 
> calls is rather low... I also thought the idea of using Jogamp's 
> Gluegen layer was that their JOCL version could be much more 
> up-to-date than handwritten wrappers. Having said this, the last time 
> I seriously worked w/ JOCL is over a year ago and when I started my 
> SimpleCL Clojure lib in 2013 it seemed the best way forward, now maybe 
> not anymore... 
>
> On 14 June 2015 at 19:46, Dragan Djuric <drag...@gmail.com <javascript:>> 
> wrote: 
> > Just to clarify: JOCL.org also does not demand jumping extra hoops for 
> OSX: 
> > their previous version (0.1.9) comes with OSX binaries and works out of 
> the 
> > box. It is only a question of time when the author is going to receive 
> the 
> > binaries and put the in the distribution jar in maven central 
> repository. 
> > The build is make or CMake and should work out of the box... 
> > 
> > On Sunday, June 14, 2015 at 8:24:06 PM UTC+2, Karsten Schmidt wrote: 
> >> 
> >> Hi Dragan, this looks great & will check it out ASAP! Just one 
> >> question about your OSX note - for http://thi.ng/simplecl (also based 
> >> on JOCL) I didn't have to jump through extra hoops for OSX, since JOCL 
> >> also includes all mac binaries... All I needed to do was set 
> >> :native-preset to empty 
> >> (https://github.com/thi-ng/simplecl/blob/master/project.clj#L14) 
> >> 
> >> I haven't tried running your examples yet, but just wondering how 
> >> you're dealing with native deps to not be able to support OSX out of 
> >> the box... 
> >> 
> >> Thanks, K. 
> >> 
> >> On 14 June 2015 at 17:04, Dragan Djuric <drag...@gmail.com> wrote: 
> >> > I am pleased to announce a first public release of new OpenCL 2.0 
> >> > Clojure 
> >> > library - ClojureCL 
> >> > 
> >> > Very detailed documentation at http://clojurecl.uncomplicate.org and 
> API 
> >> > at 
> >> > http://clojurecl.uncomplicate.org/codox/ 
> >> > 
> >> > Lots of learning examples - follows the example code of OpenCL in 
> Action 
> >> > book, and is compatible with other OpenCL literature. 
> >> > 
> >> > Uses fast hand-written JNI bindings (jocl.org). 
> >> > 
> >> > ClojureCL is a Clojure library for High performance parallel 
> computing 
> >> > (including GPGPU) with OpenCL 2.0, which supports: 
> >> > 
> >> > * GPUs from AMD, nVidia, Intel; 
> >> > * CPUs from Intel, AMD, ARM etc; 
> >> > * Computing accelerators and embedded devices (Intel Xeon Phi, 
> >> > Parallella, 
> >> > etc.). 
> >> > 
> >> > Call for help: 
> >> > Everything you need for Linux and Windows is in Clojars. If you know 
> >> > your 
> >> > way around gcc on OS X and you are willing to help providing the 
> binary 
> >> > builds for those (or other) systems, please contact me. 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Clojure" group. 
> >> > To post to this group, send email to clo...@googlegroups.com 
> >> > Note that posts from new members are moderated - please be patient 
> with 
> >> > your 
> >> > first post. 
> >> > To unsubscribe from this group, send email to 
> >> > clojure+u...@googlegroups.com 
> >> > For more options, visit this group at 
> >> > http://groups.google.com/group/clojure?hl=en 
> >> > --- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups 
> >> > "Clojure" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> > an 
> >> > email to clojure+u...@googlegroups.com. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> 
> >> -- 
> >> Karsten Schmidt 
> >> http://postspectacular.com | http://thi.ng | http://toxiclibs.org 
>
>
>
> -- 
> Karsten Schmidt 
> http://postspectacular.com | http://thi.ng | http://toxiclibs.org 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to