On Sat, 24 Dec 2011 12:48:37 +0100, Martin Kempf <martin.kempf(a)gmail.com> wrote:
Am 23.12.2011 12:54, schrieb Andreas Kloeckner:
> Hi Martin,
> first of all, sorry for taking so long to reply to this. I had a busy
> end of the (US) semester, with teaching, projects and all.
no problem, thanks for the answer! Meanwhile I have read more on this
topic and it helped me understanding your clarifications. But there are
still some points I am curious about:
> Now onward to the usefulness of both of these packages in conjunction
> with PyCUDA. cgen can be useful if more 'textual' ways of generating
> code don't work for your specific application. That said, I have found
> that textual generation is sufficient in very many settings, and only
> very few types of codegen require the flexibility that cgen offers. (but
> those do exist!)
Is the example on loopy found in this paper  a case where the
flexibiliy of cgen is needed? Where can I find more information on
That's loopy as of two prototypes ago. I'll release the current version
of loopy as soon as I submit the article that goes with it.
> However, I've made the experience using cgen when it
> isn't required ends up resulting in odd-looking code that's harder to
> maintain than necessary. I am still using cgen in my projects (loopy,
> yet to be announced, being the most recent one)--I'm just more judicious
> about its use.
> codepy (in its compile-link variety) can also be used with PyCUDA. Bryan
> Catanzaro has done this in Copperhead, where he uses codepy to drive
> nvcc to compile host-side (!) Python extension modules that execute CUDA
> code. This removes much of PyCUDA from the picture, as now you're using
> the CUDA run-time interface, rather than the driver interface.
Is this achieved by using the CudaModule of CodePy, combined with the
Correct. Bryan contributed that code.
It is an interesting topic I came accros as it is the topic of my
seminar  at the university of applied sciences in Rapperswil,
Great! Good luck with your seminar talk.