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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
