Hi all, 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) Details are below... Toby 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! 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 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 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? 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! 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? 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 Nice-to-have ============ + PyPy support for even more acceleration! ------------------------------------------------------------------------------ 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