[PyOpenCL] Cooperation between PyOpenCL / JavaCL (/ others) ?

Fri Feb 11 07:48:52 PST 2011

Hi all,

Follow-up on the Java/Python-compatible template engine choice issue : I've
played with StringTemplate a bit and my head hurts...
I particularly miss the flexibility and concision of Velocity, where a
simple loop can look like :

#if ($myVar == "int")
...
#else
...
#end

#set( $myCollection = ["a","b","c"] )

#for( $item in $myCollection )
...
#end

... and $variables can appear anywhere, possibly
${escaped}WhenIt'sAmbiguous.

I might be wrong, but it seems that to perform a loop with StringTemplate
you need to define a template for the loop content, which makes it hard to
write self-contained template files (need host code that defines the
templates that should be used in the loops). The StringTemplate introduction
(http://www.antlr.org/wiki/display/ST/Introduction) makes it clear that ST
follows a "logic-less" dogma, but I feel this is far from our pragmatic
needs (logic-less technologies make sense for presentation layers, where
designers are involved, but here we're generating code).

Good news is there's a Python port of Velocity called Airspeed, which should
allow for 100% compatible templates to be written for Java and Python :
http://dev.sanityinc.com/airspeed/

I think it would make a lot of sense to use Velocity / Airspeed as a
template engine, provided that you find that the Python API is decent / fast
enough...
What do you guys think about this ?

Cheers
--
zOlive
http://ochafik.com

PS: here are some Velocity templates that I use with success in BridJ (I
defined $primitives to be a collection of metadata on primitive types, which
lets me generate dozens of methods with ease) :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/Runtime/BridJ/src/main/velocity/org/bridj/Pointer.java

I also use Velocity to generate C programs (e.g. to multiply automated
tests) and it plays well with the C preprocessor (which we can also leverage
in OpenCL) :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/Runtime/BridJ/src/test/velocity/org/bridj/CallTest.cpp

2011/2/5 Olivier Chafik <olivier.chafik at gmail.com>

> Hi Andreas,
>
> 2011/1/30 <lists at informa.tiker.net>
>
> First of all, sorry for the long delay in replying, and thanks for your
>> message.
>
>
> Ugh, sorry for the even longer reply... Was busy releasing the latest
> versions of JavaCL and ScalaCL and with my real-life job at the same time...
> Anyway, thanks for your reply !
>
>
>> Also, please note that I have cc'd the pyopencl mailing list--I
>> hope that's ok with you.
>>
>
> Sure, hi all :-)
>
>
>> A collaboration like this certainly sounds like a good idea.
>>
>> If we insist that such a collaboration centers around shared code, that
>> would depend on a common templating technology.
>>
>
> Hehe, I'm open to any kind of collaboration, it's just the first one that
> came to my mind... Let other proposals flow ;-)
>
>
>> According to
>>
>> https://secure.wikimedia.org/wikipedia/en/wiki/Template_engine_(web)
>>
>> that limits us to StringTemplate [1] and Mustache [2,3]. If you know any
>> other candiates, please point them out. Unfortunately, Mustache makes
>> many things that are simple in Mako (such as unrolling a loop based on a
>> count) rather difficult because of the absence of actual logic,
>> StringTemplate less so.
>>
>> [1] http://www.stringtemplate.org/
>> [2] http://mustache.github.com/
>> [3] http://mustache.github.com/mustache.5.html
>>
>>
> Seems like StringTemplate could be a winner, then.
> So far I've only used Velocity, I'll try experimenting with StringTemplate
> to see if there are annoying limitations or not.
>
>
>> In any case, since potentially significant bits of (non-shared) host
>> code need to be written for each (shared) kernel, I think that explicit
>> kernel code sharing might be a bit too heavy-handed, and that we can
>> probably get by with occasional mutual 'manual' stealing.
>>
>
> I'm okay for mutual manual stealing, but I don't think it would be that
> hard to share the exact same OpenCL code between different bindings.
>
> For instance I've just ported some Apple code that does parallel prefix sum
> :
>
> http://developer.apple.com/library/mac/#samplecode/OpenCL_Parallel_Prefix_Sum_Example/Introduction/Intro.html
>
> I didn't touch to the OpenCL kernel at all (just added a `#defineDATA_TYPE float` to
> scan_kernel.cl) :
>
> http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/resources/scalacl/impl/scan_kernel.cl
>
> I wrote a literal translation of the scan.c C host code to Scala :
>
> http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/scala/scalacl/impl/ApplePrefixSum.scala
>
> Once I got this literal translation to work, I transformed the code into
> some more idiomatic Scala version :
>
> http://code.google.com/p/nativelibs4java/source/browse/branches/OpenCL-BridJ/libraries/OpenCL/ScalaCL2/src/main/scala/scalacl/impl/GroupedPrefixSum.scala
>
> Even though the resulting host code looks rather different from the
> original C version, the OpenCL kernel is strictly the same.
> I could be wrong, but I believe the same could be hold true of all the
> OpenCL kernel we could write, especially with a common template system :-)
>
>
>
>> All of pyopencl's code will show up in this directory:
>> http://git.tiker.net/pyopencl.git/tree/HEAD:/pyopencl
>>
>> If you can point us to a permanent place where your code is availble,
>> then I'd say a mutually beneficial future of theft is assured. :)
>>
>
> Sure, JavaCL's source repository is here :
>
> http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL
>
> With the following locations for OpenCL code :
>
> JavaCL's util package :
>
> http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/JavaCL/src/main/opencl/com/nativelibs4java/opencl/util/
>
> LibCL :
>
> http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/LibCL/src/main/resources/LibCL/
>
> JavaCL's demos :
>
> http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/Demos/src/main/opencl/com/nativelibs4java/opencl/demos/
>
> JavaCL's OpenGL demos :
>
> http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/OpenGLDemos/src/main/opencl/com/nativelibs4java/opencl/demos
>
>
> To make it easier to share our code, I've just setup a git repository :
> https://github.com/ochafik/LibCL
>
> I'm not good with git, but I believe you'll have no problem forking /
> contributing from there and merge the changes to our respective repositories
> if needed :-)
> Ideally we could all put our (reusable) OpenCL code there, whether it fits
> into the 'LibCL' principle (kind of a new libc) or it is more specific demo
> code.
> Then the other library wouldn't have to adapt immediately / use immediately
> that code, but a direct link to the host code's implementation in the kernel
> source code might make it easier.
>
> Looking forward to reading from you guys !
> Cheers
> --
> zOlive
> http://ochafik.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tiker.net/pipermail/pyopencl/attachments/20110211/9e2bba1b/attachment-0001.html>