Hi Karli, Karl Rupp <r...@iue.tuwien.ac.at> writes: >> 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
This one is a bit tricky, and as long as I'm using boost.python and boost.numpy, not that urgent (what's the burden of a couple more boost files in the external submodule on top of that?). I have been thinking about progressively changing the C++ parts of the wrapper away from boost.python (despite its elegant API!), and towards another method, perhaps by using libviennacl, perhaps Cython. But I think that's something that can happen gradually, and I'd rather work on features and fixes for now. > - Windows installer. Oh, yeah. That's really easy! It should be just 'python setup.py bdist_msi', and then you just need to build versions to match users' Python versions. So it should work already. I think. Did you get a chance to test out the Windows build? I'd like to release a PyViennaCL 1.0.1 with the build system change :) >> 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. Yeah, you're right. I'll cut it down to one week, and expand the misc. section by a week. I think it would be good, though, to get a couple of measurements done! >> 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) That's a good suggestion. In fact, I can put performance optimisation before the misc work, and then be free to adjust the relative timings for "general polishing work". >> 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. Great. I don't mind helping with any work on ViennaCL necessary because of my plans! >> 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 :-) You're right. I should take some inspiration from your blog post, and Andreas' various docs, which are excellent. I think an important point to bear in mind is that good documentation takes it slowly. >> Nice-to-have >> ============ >> >> + PyPy support for even more acceleration! > > Let's see how it goes... :-) Cheers, 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
