Hi Toby, > So I've been making some notes on stuff to propose / achieve for GSoC > 2014. There's quite a lot of stuff, but because I'm quite familiar with > the code now, I think it's plausible to get through pretty much all of > it, though there might be parts where the schedule looks a bit > tight. Any thoughts? Additions? Changes? > > At the moment, my proposed schedule outline looks like this: > > * Expose remaining ViennaCL mathematical API (Week 1 - 2) > * Features from SciPy / NumPy that would be useful (Week 3) > * Performance optimisation (Weeks 4 - 5) > * Multi-platform support (Week 6 - 7) > * PyOpenCL (+ PyCUDA) Integration (Weeks 8 - 9) > * Scheduler integration and linking (Weeks 10 - 11) > * Misc.: docs, tests, examples, binaries, marketing (Week 12)
The agenda looks good, yet it's certainly ambitious. I'd assign more time for the 'misc' part, since it's better to get a comprehensive, well-documented release out on time with less features rather than having to deal with a (potentially large) delay. Other suggestions worth considering: - Get rid of Boost.uBLAS to simplify (and speed up) installation/compilation - Windows installer. More comments below... > > Expose remaining ViennaCL mathematical API (Week 1 - 2) > ======================================================= > > + preconditioners > + in-place solvers > + QR factorisation > + structured matrices > + diag(), row(), column() > > + get scalar result type operations (norms, dot prod) working with > scheduler > + not clear whether the bug is in my code or ViennaCL here > + inner_prod with tie > + prod(A, B) where A is sparse and B is dense > > + implement tests along the way! Yes, that should be the first thing to start with. > 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 > > + Allow operations on ndarrays > + just convert to matrix / vector as appropriate Looks good. > Performance optimisation (Weeks 4 - 5) [ perhaps weeks 4 - 6 .. ] > ====================================== > > + PyViennaCL benchmarks > + vs equivalent operations in NumPy / SciPy, Theano.. > > + Profiling and optimising common code paths > > + More caching, as for the sparse matrices, but for dense matrices and > proxies > + for instance, instead of doing direct elementwise modifications, do > them in batch I suggest not to assign too much time to this. Sure, you should check that overheads from the Python wrapper don't get excessive, but for sufficiently large data it is always the ViennaCL part where time is spent. > 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? Good! > PyOpenCL (+ PyCUDA) Integration (Weeks 8 - 9) > --------------------------------------------- > > + 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 > > + 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! > > + convert between Matrix and pyopencl.array.Array types? > > + "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! Nice. you may want to start working on that a little earlier (e.g. work on this first before running performance optimizations) > Scheduler integration and linking (Weeks 10 - 11) > ------------------------------------------------- > > + users able to define a custom Node class > + useful for prototyping algorithm implementations! > + so: useful to expose an API similar to the underlying > ViennaCL structure so that prototypes can be ported > to the core without too much hassle > > + user-given class info determines dtypes, arguments and return type > > + class provides kernel (source, binary, whatever supported by > back-end) > + device-specific kernel support? > > + PyViennaCL registers custom Node with ViennaCL scheduler, > assigning the Node an ID > > + ViennaCL then has a mapping of (ID, custom operation) pairs > > + when the scheduler is called with the relevant ID, argument types > are checked and operation is scheduled for dispatch > + how is the return value created? > > + posible to harness the generator usefully? > + how to avoid temporaries in the expression tree, when using > custom nodes? > + while we can do metaprogramming in Python, the generator does > the metaprogramming in C++ > + how flexible is it? > + what source / metadata does it use? This will remove quite some pressure on the build system, because the time is then spent on building a shared libviennacl-library rather compiling lots of stuff within the PyViennaCL wrappers. It's good to schedule this towards the end of GSoC, since it will take some time until the ViennaCL side of things is ready. > Misc.: docs, tests, examples, binaries, marketing (Week 12) > =========================================================== > > + need to think of use case examples for the above > + eig tests > + Add __all__, so that docs are prettier > + Fix sphinx warnings > + Windows installers -- really easy to create! > + just setup.py bdist_msi Don't underestimate the efforts required here. Better to assign at least a second week. Documentation is so important, so it should get the necessary attention :-) > Nice-to-have > ============ > > + PyPy support for even more acceleration! Let's see how it goes... Best regards, Karli ------------------------------------------------------------------------------ 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
