Hi Andreas, thanks for your comments.
Andreas Kloeckner <li...@informa.tiker.net> writes: >> Features from SciPy / NumPy that would be useful (Week 3) >> ========================================================= >> >> + SciPy / NumPy convenience functions >> + Improved SciPy / NumPy integration >> - convenience functions >> - sparse matrix support >> >> + Need to look over where features provided are same, and whether API >> differences are warranted >> + dtype, result_type, norm, diag, etc >> + make classes provide compatible public attributes? >> + provide in-place /and/ copy functions .. >> >> + Convenience functions >> + eg scipy[.sparse] style solver / eigenvalue / etc interface > > Are you sure that duplicating numpy/scipy is worthwhile? I'd focus on > offering the functionality that they don't already offer. > > I had a 'make an UBlas-based numpy clone' project: > > http://git.tiker.net/pylinear.git > > It's only once you try to reimplement it that you start understanding > how much functionality really is in numpy. From fancy indexing, to > ufuncs, to... Duplicating it is hopeless and pointless, adding onto > it--not so much. I agree. It's a fine line to tread: my aim is to keep the API as familiar to new users as possible, with the assumption that new users will probably already have some familiarity with NumPy. So, all I'm trying to say here, I think, is that, where PyViennaCL exposes API that's similar in semantics to NumPy, it should expose that API in a similar way. That's not to say, of course, that I want to expose all of NumPy's API in a ViennaCL flavour, just that things should work as users expect :) >> + Allow operations on ndarrays >> + just convert to matrix / vector as appropriate > > This is powerful, if you can do it without having to copy storage. One > consideration here is also *returning* numpy arrays if the input > consisted of them. That's a good suggestion, thanks. And you're right about being careful about copies: of course, if someone for some reason does `pyviennacl.Mul(numpy_arrayA, numpy_arrayB)`, where the two arrays have 2-d shape, then either the computation should be performed on the CPU, or they should expect to incur some copying to a compute device. I haven't thought about what would be the best way to handle that kind of case, in the event that a user has a number of ViennaCL back-ends available. >> Platform support and integration >> ================================ >> >> Multi-platform support (Week 6 - 7) >> ----------------------------------- >> >> + enable CUDA, OpenMP back-ends >> + abstract back-end specific features / options into back-end >> specific submodules, which should be loaded at runtime >> >> + useful to specify the backend details on creation of a ViennaCL >> object (eg matrix) >> + for instance, say pyviennacl.Matrix(..., context = c) or suchlike >> + what about copying between back-ends? >> >> + how to define 'back-end'? >> := context? (could be OpenCL, or CUDA equiv.) >> := device? platform? >> >> + throw an exception if attempting to do an operation across >> back-ends? > > It's important that the backend (including device and CL command queue > choice) be made explicit somehow. Yep. >> + Want to take advantage of PyOpenCL's int_ptr to access ViennaCL >> objects in other (Py)OpenCL code and vice versa. >> >> + need to get the underlying OpenCL pointers out of ViennaCL -- >> and be able to pass them back in > > One thing to watch out for here is ownership semantics. If ViennaCL > insists on owning storage, then you may be forced to copy to preserve > correctness. This is something I will also have to be careful about -- thanks for reminding me beforehand! >> + where PyOpenCL is not available, provide compatible minimal >> surrogate classes >> + in this case, integration functionality is clearly unnecessary >> + don't want to depend on too many external bits, but also want to >> provide useful functionality! > > I see what you're trying to say here, but I'm not sure duplicating > PyOpenCL is worthwhile. Since PyViennaCL (in with-CL mode) and PyOpenCL > have the same dependencies and can be configured the same way, I'd > perhaps rely on setuptools to automatcially build PyOpenCL as a > dependency (again, only if CL mode is enabled). You're right. Since the deps are the same, it entirely makes sense just to do as you suggest. >> + convert between Matrix and pyopencl.array.Array types? > > Yes, you'd definitely want to do that. The array types are quite > flexible on who owns the storage (they're pure Python after all). Super. >> + "The functionality in the module pyopencl.elementwise contains >> tools to help generate kernels that evaluate multi-stage >> expressions on one or several operands in a single pass" >> -- http://documen.tician.de/pyopencl/algorithm.html >> + sounds familiar? This is what we do in ViennaCL! > > pyopencl.elementwise works by throwing a snippet of C at the API > though. It's a slight overlap in functionality, but not necessarily bad. Sure -- a bit of virtual cross-pollination always helps, too! >> Nice-to-have >> ============ >> >> + PyPy support for even more acceleration! > > Long-ish-term, maybe cffi (as a common CPython/pypy C foreign function > interface) is worth a look. A PyOpenCL branch exists that uses that: > > https://github.com/pyopencl/pyopencl/tree/cffi I had a look at cffi last year, and decided it was going to be a lot of work. As things evolve quite fast, and as libviennacl is developed, it's probably worth another look -- thanks. Best, Toby ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
