Hi Frédéric, On Fri, 22 Apr 2011 08:35:03 -0400, Frédéric Bastien <no...@nouiz.org> wrote: > Thanks for yours modification. Here is some questions/comments: > > I'm not sure I understand the idea in the to_gpu() function that put > the same stride on the GpuArray as on the host, but we copy the data > to make it c contiguous before we transfer it. That way the stride in > the GpuArray won't represent what is on the gpu. In that case, I think > we should put the stride as the contiguous version of the data. That > way the stride on the GpuArray represent what is on the gpu, not the > original strides.
I disagree. As long as the host data is contiguous (C or Fortran, or in principle any other way), a straight copy is the fastest and most logical thing to do, IMO. > When I talked about having a strided GpuArray, I was thinking about > having a new object with a different attribute name for the gpudata > attribute. The goal is to make it not compatible with current code > without modification. Are you talking about package code or user code? As far as user code is concerned, the new code accepts the same arrays that the old code did, and it doesn't change semantics on any one. Thus no need to switch to a different type, IMO. In general, nothing generates non-contiguous GPU arrays for now. > The reason is that the current code don't check > stride and will give wrong answer if it receive a strided GpuArray. I > would have preferred an error raised. A simple change to the code to > work correctly with strided data would be to call a function that make > the data c contiguous and use that. A longer fix would be to use the > stride information in the gpu code. Until we have proper stride support, I agree that the code should throw an error on non-contiguouity. I'll put that in. > For example, your current code generator for elemwise will simply > ignore the stride information. I'm sure there is other code in pycuda > and outside that need modification to won't return a wrong result > silently. Right--but as I said above, as long as you don't start throwing around non-contiguous arrays, the semantics change is somewhere between non-existent and benign. I'd much prefer a slow upgrade of the existing infrastructure to support strides, rather than having a 'dumb' and a 'smart' array type. > There will be a small workshop at the beginning of May on gpu > computing for machine learning and I will try to make a proposition > there and to get feed back from people there(Nicolas Pinto will attend > it). There is not only the stride question that need to be answered. > When I have something written, I will send it to you as you seam > interested. Great--please do keep me (and the lists!) in the loop, and if possible, consider that similar changes are needed in PyOpenCL and PyCUDA. > I think we can compare the current python gpu base array object as > before numpy exit. i.e. There is many variable that are not directly > compatible, but very close. I disagree--GPUArray was explicitly conceived as a numpy array workalike, and it'll slowly grow to get closer to that goal. Andreas
pgpXgGPFkJpKV.pgp
Description: PGP signature
_______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda
