[Numpy-discussion] Unnecessarily bad performance of elementwise operators with Fortran-arrays

[Hans Meine]

On Samstag 10 November 2007, David Cournapeau wrote:
> > After some measurements, I must say that even the slower Fortran variant
> > is competitive (read: faster ;-) ), compared with our very flexible
> > dynamic functors used in the current interactive VIGRA.  IOW: Good job.
> > :-)
>
> I am not suprised at all: although I've seen many times people saying
> that C++ can provide good abstractions without cost, this is not my
> experience, at least with g++.

Oh, I tried to prevent this misunderstanding; this is about the interactive 
VIGRA.  Here, we have a functor grammar parser which composes functors 
(objects with virtual methods etc.) according to the syntax tree, in order to 
compute complex operations in one go.  In case you're interested in our API, 
here's the relevant part of a mini tutorial I wrote lately:
http://kogs-www.informatik.uni-hamburg.de/~meine/vigra_interactive/#processing-each-pixel

This is not to be confused with  STL-like C++ functors; i.e. in the normal C++ 
VIGRA we use functors a lot, and our experience is very positive.  E.g. our 
copyImage which gets two 2D source iterators (upper left, lower right), a 
source accessor (which may perform additional conversions or pull pixel 
components from different sources together), and a destination iterator + 
accessor has exactly the speed of a memcpy when standard (pass-through) 
accessors are used.  (In fact, it was slightly faster, but most probably 
within measurement uncertainty.)

> Whatever the method/library used (blitz, the ones in boost, etc...).

I like boost a lot, but I think in some places it may stress compilers too 
much.  OTOH, my experience is that compilation takes ages, but the resulting 
code is quite fast.  But that may depend on the (part of) library you're 
talking about.

> I am really convinced that C++ 
> provides the bad abstraction for numerical works (and the fundamental
> design decision of C++ to avoid extending the language to implement
> things in libraries instead is flawed, at least for numerical works).

I cannot follow you here, but I think there's not much point having yet 
another "which language is best" discussion, especially not when it becomes 
off-topic.  I just wanted to tell you that my above statement is not an 
example that "C++ can [not] provide abstractions without cost".  The same 
statement in C++ would be much faster than NumPy, but it's comparing apples 
and oranges (C++ vs. Python).  I just compared our Python extension module 
with NumPy, and both use a very different approach (cf. the above link).

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20071110/cd619d3d/attachment.sig>