Hi Philippe, Philippe Tillet <phil.til...@gmail.com> writes: > Unfortunately I won't be available until Tuesday for a meeting.
Well, then we should wait. I'd like to have a meeting before I go to Texas (a week on Sunday), but I think your input would be valuable. > Python and > CUDA-based libraries are widely used by the Machine Learning community. I > also want to push OpenCL forwards, but supporting CUDA through PyViennaCL > would be a very good thing to do, since a lot of researcher think that CUDA > is faster (or will at least want to compare). Yep -- it's definitely not off the agenda! Cheers, Toby > Philippe > > > 2014-06-26 18:57 GMT+02:00 Toby St Clere Smithe <m...@tsmithe.net>: > >> Karl Rupp <r...@iue.tuwien.ac.at> writes: >> > fine with me. My schedule is very much in flux in the next ~10 days or >> > so, so I might be unavailable on short notice. Rather than having one >> > big IRC meeting with all topics crushed together, I suggest we have a >> > couple of smaller topic-oriented meetings. To start out with, I suggest >> > two topics+dates: >> >> If it's inconvenient, I can wait! >> >> > * Friday, June 27, 18:00 UTC on PyViennaCL >> >> But, if not, this time is fine for me :) >> >> > We can also use VoIP-technology in addition to IRC to speed things up if >> > desired. Toby, do you have questions for Andreas on PyOpenCL or PyCUDA? >> >> I'm in contact with him regarding the best way to deal with padding of >> ViennaCL vectors / matrices. For my manual tests, I work with very small >> dimensions (to make it easy to spot errors), but of course these are >> padded out. So if I have a 3x3 matrix, I (say) really have a 128x128 >> matrix, with a lot of 0 entries. >> >> I have a convenience function which takes a matrix or vector to a >> PyOpenCL 'Array' object (which is just an array-like wrapper around an >> OpenCL buffer). Clearly, the underlying PyOpenCL buffer object should >> point to the whole 128x128 memory, but should I have the Array only >> expose the 3x3 matrix (like ViennaCL does), or the whole padded matrix? >> >> What I'm working on right now is having the Array work more like the >> ViennaCL matrix, so that if the user wants to print out the object (for >> example), they only get the non-padded entries. It's easy to get the >> whole buffer from an Array, and of course if the user wants to work with >> it in OpenCL, then they'll need to deal with the padding... So perhaps I >> should leave the padding visible when the user takes a ViennaCL object >> to a PyOpenCL one, to make it obvious? >> >> >> There are a couple of bits of API that need some more work. For >> >> instance, with regards to structured matrices, the Vandermonde matrix is >> >> missing (I had some API incompatibility with my current code which needs >> >> looking at), and there is some thinking to be done about operations >> >> involving two structured matrices; the logic for computing the result >> >> type needs work here. Bandwidth reduction is also missing, because I >> >> don't have a PyViennaCL wrapper type for the std::vector<std::map<T> > >> >> type used here (is generic sparse support on the agenda? Does it matter >> >> right now?). I also want to add support for casting between numeric >> >> types, as we were discussing earlier. By and large, however, the body of >> >> work here is done, and the remaining bits shouldn't take more than an >> >> afternoon. >> > >> > A summer student will soon extend FFT to the multi-backend case, which >> > should also make the structured matrices available for multiple >> > backends. As for the std::vector<std::map<T> > type: Are there any >> > standard sparse matrix formats used in Python/NumPy/etc.? Anything in >> > e.g. CSR format? I think it makes most sense to provide convenience >> > conversions for these and not worry about std::vector<std::map<T> >. >> >> Well, I want to spend some time investigating bringing the PyViennaCL >> and SciPy sparse types closer together. But of course PyViennaCL >> supports the ViennaCL compressed / coordinate / etc types right now. >> >> >> A similar situation obtains in the context of supporting multiple >> >> back-end platforms. I have implemented a generic Context object, and it >> >> is now possible to construct any PyViennaCL type in any given Context >> >> (for instance, in host memory, or on a specific OpenCL device with a >> >> given OpenCL queue). I'd like to pay my respects to Andreas for his work >> >> on PyOpenCL, which has made my life here fairly easy. Meaningful >> >> exceptions are raised if you try and execute an operation involving >> >> objects in different contexts. >> > >> > Perfect! Did you stumble over any problems in which the context isn't >> > used correctly? There may be some corner cases where this isn't handled >> > correctly, so please don't hesitate to report if you run into issues. >> >> Hmm. As far as I'm aware, the only failures I've seen so far have been >> my fault: for instance, if I try and do A+B with A and B having contexts >> on different devices or with different associated queues. I now test the >> vcl::ocl::context equality operator and throw an exception if I get >> false (or if A and B have different memory domains entirely, etc). >> >> >> My next job is to write a simple example involving a custom PyOpenCL >> >> kernel interacting with ViennaCL objects and operations, which I hope to >> >> have by the end of the week. Subsequently, I need to prepare some simple >> >> benchmarks and my paper for Texas. I had something to ask of Philippe in >> >> this respect, but I've forgotten what it was. Oh, well. >> > >> > The PyOpenCL<->PyViennaCL interaction would be a nice showcase for the >> > conference talk and also a nice example, as this is certainly of high >> > interest to many users. I recommend spending a bit of extra effort on >> > this: Polish this feature, set up some cool slides and a neat example. >> >> Indeed. What do you think would be a neat example? I wrote a very basic >> example to test that things were working -- just a simple kernel doing >> vector addition[1]. >> >> [1] >> https://github.com/viennacl/pyviennacl-dev/blob/platform-support/examples/simple-opencl-vector-sum.py >> >> > Let's reiterate on that after your conference trip. >> >> Sure. >> >> > This is most likely of interest once uBLAS is eliminated from the >> > ViennaCL core. For the time being, better stick with Boost.Python and >> > wait for libviennacl to mature. >> >> Fine. >> >> > Oh well, the CUDA issue. My latest discovery: CUDA 6 deprecates the >> > default -arch=sm_10, so if you call >> > $> nvcc myfile.cu >> > you will *by default* get a deprecation warning to stderr. This even >> > remains if you switch warnings off... >> >> :-/ >> >> > Sooner or later we should also be able to support PyCUDA, just because >> > there's such a large CUDA user base. I'm fine with not assigning high >> > priority to it because of the terrible packaging process. >> >> Yeah, I agree. But I also feel a little stubborn about it: I want to >> encourage prospective CUDA users to use OpenCL instead! Surely ViennaCL >> is a killer feature?... >> >> >> Cheers, >> >> Toby >> >> >> >> ------------------------------------------------------------------------------ >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> ViennaCL-devel mailing list >> ViennaCL-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/viennacl-devel >> > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > ViennaCL-devel mailing list > ViennaCL-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/viennacl-devel -- Toby St Clere Smithe http://tsmithe.net ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
