Hi Frédéric,
On Thu, Jul 19, 2012 at 8:58 AM, Frédéric Bastien <[email protected]> wrote:
> How much useful it is to abstract between PyCUDA
> and PyOpenCL? Personnaly, I probably won't use that part, but I want
> to abstract between CUDA and OpenCL.
It was either that or to write almost identical libraries for PyCuda
and PyOpenCL. The user is by no means forced to use cluda context, it
is just a wrapper around PyCuda/PyOpenCL context that is passed to
computation classes. After that corresponding array classes and
synchronization functions from the target APIs can be used. But I
personally use this abstraction because I get better GPU performance
with CUDA, but I also need my programs to run on CPU with reasonable
speed (mostly, for debugging), and wor that OpenCL is preferable.
> I like the idea of making code generator that do transformation on the
> input before doing other computation. This is something I wanted
> Theano code generator to do, but I never got time to implement it.
> What the current parameter derive_s_from_lp and derive_lp_from_s mean?
These are two functions that are used to derive types. "s_from_lp"
means "stores from loads and parameters" (transformations can also
have scalar parameters, currently it can be seen in
test_matrixmul.py:test_preprocessing).
In the example the transformation is connected to "input pipeline",
i.e. to the input parameter "A". So it takes some values from new
external input parameters "A_re" and "A_im" (load=2) and combines them
into "A" (store=1). The derivation functions work in the following
situations:
1) When the object needs to derive types for the external signature
from its basis parameters, derive_lp_from_s() is called and supplied
with the type for "A", and expected to return types for "A_re" and
"A_im" (also for parameters, but there are none, so the empty list is
returned).
2) When the object needs to derive basis parameters from the arrays
supplied to prepare_for(), derive_s_from_lp() is called which performs
derivation in the other direction, producing data type for "A" from
data types of "A_re" and "A_im".
There are, in fact, four types of derivation functions. If we had a
transformation connected to the "output pipeline", we would need
derive_l_from_sp() and derive_sp_from_l().
Now that I think about it, "load" and "store" should probably be
called "input" and "output", it is less ambiguous :)
> Also the code section is not something I call readable... Is is only
> because I never used Mako? Andreas, I think you used mako, do you find
> this redable?
These are only one-liners, so, yes, they seem fine to me. Perhaps,
they would be more readable if I did not try to save on spacing, and
used some temporary variables? Also, do you find kernels (dummy.mako
and matrixmul.mako) hard to read too?
> I'm not sure that forcing people to use Mako is a good idea. Can we do
> without it?
The amount of Mako in the transformations can be reduced if I use
macros, for example, "LOAD1" instead of "${load.l1}". The latter was
chosen because I planned to add some error checking, which would be
less comprehensible with macros. It is much harder to avoid Mako for
non-trivial tasks though, like getting corresponding complex data type
for the real one, or providing support for multiplication of all
combinations of complex/real numbers. Is it really such an issue? It
is just Python code in curly braces, after all.
> I still think that we need to provide the user not just with a common
> gpu nd array object. We need to also provide fonctions on it. But I'm
> not sure how we should do this.
My project does not intersect with "general ndarray" idea at all. If
there was some general array class instead of cl.Array/GPUArray,
things would only make things easier for me. I just think that numpy
way of providing functions for arrays is not that good in GPU case, as
the overhead here is more significant, and should be made explicit and
manageable for the user.
_______________________________________________
PyCUDA mailing list
[email protected]
http://lists.tiker.net/listinfo/pycuda
