Hi, >> As long as you're a student, you're eligible to apply for GSoC. ;-) >> However, I don't give any guarantees, your application will be treated >> equally. You certainly have an advantage with respect to how things >> work, but no other student should be excluded upfront. > > It would definitely be great to be able to finish what I've started!
A preliminary list of ideas is available here: http://www.iue.tuwien.ac.at/cse/index.php/gsoc/2014.html I think about adding an OpenMP tuning project, since more and more users seem to get in touch with it. > I was thinking about another nice-to-have feature. I'd quite like to > make it possible (if it is in fact possible..) to play with prototyping > implementations of other algorithms for ViennaCL in PyViennaCl using > PyOpenCL and PyCUDA; for instance (just picking a recently discussed > example) to implement using PyOpenCL a cl_program for sparse matrix > multiplication, and be able to use the resultant buffer like any other > PyViennaCL matrix object. I don't know if it would be worthwhile to hook > into the generator or scheduler at this point. One thing that will be certainly of interest for a bunch of people is the ability to provide custom matrix-vector products for the iterative solvers ("matrix-free implementations"). Andreas Kloeckner is also looking forward to provide any help needed. Hooking this into the scheduler is possible to some degree, at least for the common applications of an operator to a vector or matrix. > Just personally, I'd quite like this functionality, because I do find > rapid development easier in Python than C++, and I would like to play > with implementing matrix algorithms at some point in the future. Python *is* more suitable for rapid prototyping than C++. You will quickly find that for rapid prototyping it is important to have broad support for all basic operations (including elementwise operations, etc.), so this should have highest priority. We should be careful with implementing additional algorithms in PyViennaCL for anything other than tutorial purposes, because then we would quickly end up maintaining multiple versions of the same functionality. > Yes; I'll need to investigate this. At the moment, I quite enjoy the > object-oriented nature of ViennaCL, and there are parts of PyViennaCL > which are inelegantly not-OOP. So I'd probably want to think about which > way is going to be most elegant overall. > > Presumably, the C++ API isn't going to disappear? The object-oriented nature will not disappear. Even if the core is going to be a shared (C-)library for ViennaCL 2.0.0, it will still have the same spirit of the current C++ API. Actually, I expect that ViennaCL 2.0.0 will still have a (more lightweight) C++ layer on top of the shared library, so it's API won't change much. Best regards, Karli ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
