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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
