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.