[PyOpenCL] Cooperation between PyOpenCL / JavaCL (/ others) ?
olivier.chafik at gmail.com
Fri Feb 11 07:48:52 PST 2011
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")
#set( $myCollection = ["a","b","c"] )
#for( $item in $myCollection )
... and $variables can appear anywhere, possibly
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 :
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
What do you guys think about this ?
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) :
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) :
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
> 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
>> that limits us to StringTemplate  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.
>>  http://www.stringtemplate.org/
>>  http://mustache.github.com/
>>  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
> I didn't touch to the OpenCL kernel at all (just added a `#defineDATA_TYPE float` to
> scan_kernel.cl) :
> I wrote a literal translation of the scan.c C host code to Scala :
> Once I got this literal translation to work, I transformed the code into
> some more idiomatic Scala version :
> 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:
>> 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 :
> With the following locations for OpenCL code :
> JavaCL's util package :
> LibCL :
> JavaCL's demos :
> JavaCL's OpenGL demos :
> To make it easier to share our code, I've just setup a git repository :
> 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
> 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 !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PyOpenCL