[Numpy-discussion] Unnecessarily bad performance of elementwise operators with Fortran-arrays
meine at informatik.uni-hamburg.de
Sat Nov 10 10:26:43 EST 2007
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:
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
> 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.
/ / ANS ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the NumPy-Discussion