Hi all, I reiterate my call for an IRC meeting, but, following Namik's lead, I'll post a brief status update about PyViennaCL 2014.
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. 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 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. 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. 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. 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. 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. I think that's all from me. I do think a meeting would be worthwhile, and I would try not to repeat myself at one! Best regards, Toby -- 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
