I agree that a skype call will help. Are both of you available Friday?
thanks Fred 2011/5/11 Andreas Kloeckner <kloeck...@cims.nyu.edu>: > On Wed, 11 May 2011 13:53:41 -0400, James Bergstra <james.bergs...@gmail.com> > wrote: >> Another possibility is to start a new project that is technically >> distinct from PyCUDA and PyOpenCL, although certainly built with >> interoperability in mind. PyCUDA and PyOpenCL could be seen as >> lightweight wrappers around CUDA and OpenCL. Since neither of these >> standards has an n-dimensional tensor datatype, then it could be seen >> as a loss of focus to add one. > > Disagreed, given that > > a) they both already have one > and > b) almost everyone using them will be processing some sort of array > data. > >> At the same time, a standalone project could provide a datatype that is >> compatible with *both* CUDA and OpenCL. > > Again, disagreed--there are enough interface differences to make this > annoying to write, ranging from explicit-vs-implicit context, to > scheduling, to CL needing buffer+index where as CUDA is ok with just a > pointer. > > What I think *is* possible is for there to be some common > infrastructure--and that's exactly where I'm headed with this package > 'compyte' that you may have noticed. > > >> The datatype consists essentially of >> a float pointer and shape and stride info. Since host-allocated OpenCL >> buffers can be de-referenced from non-OpenCL code, and I understand that in >> some cases OpenCL-allocated buffers can be passed to CUDA routines (is this >> true?) > > (not as far as I know) > >> it would be nice if the data-type helped to gloss over these >> differences as much as possible. > > Agreed--the two types should be as similar as humanly possible, which is > perhaps technically feasible by deriving from the same base class. > >> So how about starting a new project with the datatype that Fred describes, >> with the small addition of like a 'context' pointer or something, and >> possibly a 'context_type' enum that says whether it was an OpenCL or a CUDA >> or a HOST pointer that is allocated. > > I'd like such a project--but I think it makes more sense to put this > into 'common' infrastructure rather than on top as a separate package. > >> The type can provide a python binding in C or python that supports numpy >> compatibility in cases where the data is stored in a way that is compatible >> with host-side pointers. > > Easily doable by implementing the PEP 3118 array interface. > >> The library can provide native C implementations of calls to CUBLAS, >> CUSPARSE, CUFFT, CURAND, and possibly some basic unary and binary >> arithmetic. > > I'm hesitant to glue CU* into the interface, but I support being able to > abstractly ask for these things. (As in, "FFT this array.") > > I think the main value proposition comes from implementing basic > arithmetic (with broadcasting, views, and strides) well, the FFT, > sparse, etc are just cherries on top. > >> This would essentially be a C package at first I think, and so >> operations that require any amount of code generation should be handled by >> higher level packages in different programming languages (e.g. python). >> >> This sounds a bit like a proposal to reimplement numpy > > It absolutely is--but numpy is simply not a GPU/CL-capable package, and > it won't easily grow to be one. > >> but the basics seem straightforward and in fact already done between >> Theano and PyCUDA. > > Right. (Famous last words.) > >> Also there's I think not the same pressure on the interface in Python >> to be good - downstream projects such as PyCUDA, Theano, and gnumpy >> can make the interface more or less pythonic. It's just a matter of >> refactoring. I don't know of another project that has done this. > > I guess our ideas about this aren't as different as I thought at > first--the fact that you say PyCUDA is 'downstream' of that seems to say > you're talking about the same type of 'common infrastructure' that I had > in mind. > > We could do a Skype conference to kick this off. > > Andreas > -- > Andreas Kloeckner > Room 1311 (Warren Weaver Hall), Courant Institute, NYU > http://www.cims.nyu.edu/~kloeckner/ > +1-401-648-0599 > _______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda
