Hi Toby, > I reiterate my call for an IRC meeting
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: * Friday, June 27, 18:00 UTC on PyViennaCL * Saturday, June 28, 14:00 UTC on the GUI 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'll post a brief status update about PyViennaCL 2014. 'brief' - nice :-) > Although I had exam season until 11th June, I've managed to catch up the > lost time. I have implemented in the C++ layer almost all the remaining > parts of the ViennaCL API, including preconditioners, QR and NM > factorisation, FFT, the mixed precision CG solver for OpenCL, and > structured matrices. The idiomatic Python layer for most of this is > almost ready. Excellent, great news! > 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> >. > 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. > 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. > After that, I will move on to integrating custom PyOpenCL kernels (as > user-provided pyviennacl.Node subclasses) and the scheduler, as > described in my proposal. Finally, there's improved NumPy / SciPy > compatibility, documentation, and tests to do. Let's reiterate on that after your conference trip. > As for nice-to-haves, I'm not sure right now if it's worth working on > Cython and libviennacl, because the Boost.Python solution is highly > functional, and fairly elegant. If Boost.Python begins to deteriorate, > and Cython's C++ support continues to improve, this will nonetheless be > worth returning to. 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. > Similarly, I'm not sure how much I'll be able to work on PyCUDA, which I > originally did envisage being a bigger part of the project. This is > because I won't be able to distribute CUDA binaries widely (since not > everyone has CUDA-supported hardware, and there is no free > implementation), because the CUDA build infrastructure is so parochial, > and because a number of the interesting parts of ViennaCL are > OpenCL-only. Nonetheless, I will spend some time investigating building > PyViennaCL with CUDA; but I probably won't prioritise it. We all should > concentrate on OpenCL. 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. Best regards, Karli ------------------------------------------------------------------------------ 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
