Hey Karl,
Karl Rupp <r...@iue.tuwien.ac.at> writes:
>> 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.
Yep, and I'll get in touch with him as soon as I have something to show!
I need to do a fair bit of design thinking first (and Philippe is right
about waiting to see how similar functionality arises in core ViennaCL),
which I'll put into my GSoC proposal under the scope of 'improving the
PyViennaCL Python wrapper'.
>> 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.
Oh, definitely. I would keep the API as close as sensibly possible to
the equivalent functionality exposed in C++, to encourage users to push
as much as possible down the stack.
>> 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.
OK. I'll exercise my judgement, and use what seems most appropriate :)
Best wishes,
Toby
------------------------------------------------------------------------------
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
