Hey Karsten, You obviously have a lot more energy and patience to throw at this problem than me :-) - I am lazy and looking for a quick fix...
I thought I would post my findings here and resuscitate this thread in case anyone had anything to add... Here's what I have found - There are a number of potential approaches to mapping a pure clojure function over a sequence in parallel on a GPU : - rootbeer : https://github.com/pcpratts/rootbeer1 I've played with this a little - you write a class that implements a Kernel interface, compile and pack it and all its dependencies into a jar and run the rootbeer compiler on it. This generates code for the cuda compiler, which then compiles this to something that will run on your nvidia gpu. Rootbeer also provides all the knowhow to upload the data and code to your gpu, choreograph the parallel running of the kernel instances and download the results back into your program. I have run the test (pure java) successfully, but this is a long way (IMHO) from being able to run even my simplest clojure Kernel. - aparapi : http://code.google.com/p/aparapi/ I haven't looked at this so closely, but it seems to be a similar. but more mature project targetting OpenCL and initiated by AMD - I should go back and spend more time on it... - llvm : http://llvm.org/ This is interesting because nvidia have just integrated their cuda project with llvm and opensourced it (http://nvidianews.nvidia.com/Releases/NVIDIA-Contributes-CUDA-Compiler-to-Open-Source-Community-7d0.aspx). There is also a related project vmkit (http://vmkit.llvm.org/) which provides vm abstractions and a jvm (j3) built on top. With a little reading into these technologies, i was able to imagine a mechanism whereby I could use a mixture of various llvm frontends and backends to reach my goal - it would need a lot work though... - java8 closures - http://jdk8.java.net/lambda/ I'd heard about java8 closures, but had not paid them much attention - why would i want to write closures in a horribly tortuous syntax when i could write them clearly and simply in LISP? What I was missing was Project Sumatra (http://openjdk.java.net/projects/sumatra/) - which, as far as I can make out, is a fresh attempt, with more substantial and varied backing, to annotate likely parallelisation candidate closures for the jit compiler to pick up and spit out native gpu code :-) which is then run gpu rather than cpu side... It looks like the closure part of the equation will make java8, but the gpu bit is unlikely to and will either come out as an update or wait for java9. So, I thought i would d/l the java8/closures preview and see if it would run clojure and try playing with j8 closures in clojure! just to see how closely aligned clojure and j8 closure support was and what it would take to map one to the other.... Disappointment - java.lang.VerifyError: (class: clojure/lang/ASeq, method: count signature: ()J) Expecting to find long on stack - on loading clojure - I tried recompiling 1.4 on my j8 - wouldn't compile - I tried recompiling it on j7 and loading that into j8 - same issue - so I am calling it a night, but thought i would share before switching off... who knows - someone out there my be thinking the same thoughts... Jules -- 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
