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

Hans Meine meine@informatik.uni-hamburg...
Fri Nov 9 13:39:59 CST 2007

On Freitag 09 November 2007, Travis E. Oliphant wrote:
> >  While this is
> > a good idea (also probably quite some work), the real thing bugging me is
> > that the above DOUBLE_add could (and should!) be called by the ufunc
> > framework in such a way that it is equally efficient for C and Fortran
> > arrays.
> Yes, that's what I was talking about.  There is actually a path through
> the ufunc code where this loop is called only once.  The requirement
> right now is that all the arrays are C-contiguous, but this should be
> changed to all arrays have the same contiguousness (and the output-array
> creation code changed to create Fortran-order arrays when the inputs are
> all Fortran-order).

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. :-)

> > BTW: What are the "void *func" in core/src/umathmodule.c.src arguments
> > for?  Shouldn't that be "void * /*func*/", since the parameters are
> > never used?
> Sure, it could be void * /* func*/
> You'll have to forgive my ignorance, but does that matter?   Are we
> using up a register or something by naming an unused argument?

No, but it triggers a compiler warning ("unused parameter foo", if warnings 
are enabled), which I even think to be useful.  At least in g++, but that 
obviously showed my ignorance of C, since gcc -W does not complain. ;-)
BTW: I am getting an interesting warning for 
numpy/core/src/scalartypes.inc.src:288 (empty 'if' body), which indeed looks 
suspicious.  The rest of the warnings can be neglected I AFAICS.

Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://projects.scipy.org/pipermail/numpy-discussion/attachments/20071109/cf7a66ae/attachment.bin 

More information about the Numpy-discussion mailing list