>> I think this would be very very useful. But it seems reinventing the
>> wheel to implement the actual vector math. It is not that trivial. Just
>> as one exmaple: sometimes intermediate buffers are faster so you need to
>> have a heuristic to decide that.
>> Why not using a C++ template library for that? One could use Blitz++ but
>> I think Eigen (eigen.tuxfamily.org <http://eigen.tuxfamily.org>) is
>> newer and significant faster (e.g. automatically uses SSE). Since
>> everything is in a include files no external libary requirement is added.
>
> Thanks for pitching in; that's some very interesting thoughts!
>
> Here's my immediate reaction:
> - We should avoid reinventing the wheel at all costs. Heuristics for
> intermediate buffers in Cython is probably a no-go.
I also agree. Getting the basic algorithm working wouldn't be too big
a deal, but that is not being familiar with cython's internals and
abstracting the problem away.
However, I'm realizing that getting such a thing to play nicely in all
the corner cases is tricky.
> - Still, relying explicitly on one specific C++ library makes me uneasy
> - So perhaps what is needed here is some kind of plugin system.
>From the above arguments, I'm inclined to think that optional,
plugin-based optimization is probably the way to go.
It seems there are two reasons for not including something like eigen
or blitz++ in cython natively; first, license issues (a BSD version of
Blitz++ is included in scipy, but eigen does seem nicer and handling
matrices is super), and second it raises the compiler requirement from
that of CPython to C++.
I'm not familiar with how cython does optimizations, but the way I'd
imagine an ideal system to work would be something like this:
1. Plugins are registered somehow with hooks determining which node
types in the AST they are run on.
2. Plugins take such a node and return a modified node (or the same)
plus some other info (such as new headers to include or a new function
to stick somewhere).
Such plugin optimizers would be enabled using something like
"cython.enablePlugin('myplugin.py')" or "with
cython.plugin('myplugin.py'):" Then, when cython is run, the plugin
is loaded if it's found and a warning is printed if it's not. (This,
of course, brings the requirement that such plugins don't change the
ultimate behavior.)
In addition, if such a system were in place, you could have dummy
"optimizing" plugins that did nothing but warn about code that could
be better written, such as A[0][1] vs A[0,1].
Now as I mentioned, I'm speaking out of ignorance about how cython
actually works in this regard. It seems to me, though, that if
something like this was in place, expressions like the example I gave
previously could be detected and replaced with a block of code that
implemented the operation in eigen.
I am convinced that something like this would be a better way to go in
the long run. In 99% of the cases, I think that those who care about
the extra speed would likely be willing to deal with the extra effort
of another dependency and compiling in c++.
> Getting the basics working (just unoptimized, "what you would have
> written in C") is more trivial, and would get us up fast and allow
> operation without an external library.
> Then, if there was a good protocol for it, one would ideally be able to
> easily add support for other backends as well. (Which would all be
> required to have the same result, they would just differ in
> implementation detail.)
> On one hand, one shouldn't over-design, while on the other hand, a
> vector math library is a fairly sophisticated thing and one could argue
> that those should be made swappable if possible.
I think a plugin system like the one previously described is the way
to go. Fully swappable is probably not the answer; you'll easily run
into corner cases that kill things. For instance, blitz++ breaks if
the types of index arguments are not "int" (e.g. unsigned long) due to
how it implements the templates. But a plugin system should handle
all this.
>> A) There's a clash with existing semantics to be resolved. For instance
>> if you have a NumPy "matrix" instance, then * does matrix multiplication
>> instead, and just implementing this now would break code.
>>
>> http://wiki.cython.org/enhancements/buffersyntax
>> http://thread.gmane.org/gmane.comp.python.numeric.general/28439
>>
>> contains my thoughts on how this could be resolved. I'll use this syntax
>> below.
>>
Ah, yes, I hadn't seen that earlier or
http://trac.cython.org/cython_trac/ticket/178. That makes sense -- I
should have done a bit more searching before jumping in on this :-/.
I've been quite busy lately, so I didn't really follow that thread.
>> I think this could solved by allowing to define custom mapping of
>> operators/methods of python types/classes to C functions. With that one
>> could define that for Numpy ndarray the element wise multiplication is
>> used and for NumPy matrix the matrix multiplication is used. And both
>> could be translated into calls of Eigen or some other vector library.
>>
>> This would allow to directly transform normal NumPy, which tries to
>> avoid using loops, into highly optimized C with SSE without any
>> intermediate buffers.
>
> Well, if you write
>
> def f(np.ndarray[int] arr):
> print arr * arr
>
> f(np.matrix(...)) # subclass, so allowed
>
> then the Python version of that would be np.dot but the Cython version
> np.multiply.
>
> The problem is that we really need to know the behaviour compile-time.
> Should we disallow subclasses when a buffer is declared perhaps?
With a plugin optimization system, it seems that one could handle this
with flags in the AST nodes; e.g. one saying it is exactly of type
ndarray. Then the optimizer would reject if the flags were not good.
Of course more cases (such as matrix) could be handled after the
initial, conservative cases were working.
Just my 2 cents. I'm still willing to help out on this, though I'd
need more mentoring.
--Hoyt
++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ [email protected]
++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
