RE: [Numpy-discussion] Optimizing Numpy

[Paul F. D. <pau...@ho...>]

The project page has a patch manager for contributions.

Please note that Travis is in the middle of a substantial reimplementation
and so I think nobody would want to do a lot of optimizing right now.

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of Pete
> Shinners
> Sent: Saturday, July 08, 2000 12:56 AM
> To: num...@so...
> Subject: [Numpy-discussion] Optimizing Numpy
>
>
> i've been throwing my hand and getting more speed out of
> numpy. i've birthed a little fruit from my efforts. my area
> of use is specifically with 2D arrays with image info.
>
> anyways, i've attached an 'arrayobject.c' file that is
> from the 15.3 release and optimized.
>
> in my test case the code ran about twice the speed of
> the original 15.3 release. i went and tested out other
> uses and found on a 20% speedup pretty consistent.
> (for example, i cranked the mandelbrot demo resolution
>  to 320 x 200 and removed the 'print' command and it
>  went from a runtime of 5.5 to 4.5)
>
> i'm not sure how people 'officially' make contributions
> to the code, but i hope this is easy enough to merge. i
> also hope this is accepted (or at least reviewed) for
> inclusion in the next release.
>
>
> optimizing further...
> i also plan on a few more optimizations. the least is going
> to be a 'C' version of 'arrayrange' and probably 'ones'. the
> current arrayrange is pretty slow (slower than the standard
> python 'range' in all my tests).
> the other optimization is a bit more drastic, and i'd like
> to hear feedback from more 'numpy experts' before making the
> change. in the file 'arraytypes.c' with all the arrays of conversion
> functions, i've found that the conversion routines are a little
> too 'elaborate'. these routines are only ever called from one line
> and the the two "increment/skip" arguments are always hardcoded one.
> there are two possible roads to speedup the conversion of array
> types.
> 1-- optimize all the conversion routines so they aren't so generic.
> this should be a pretty easy fix and should offer noticeable speed.
> 2-- do a better job of converting arrays. instead of creating a
> whole new array of the new type and simply copying that, create
> a conversion method that simply converts the data directly into
> the destination array. this would mean using all those conversion
> routines to their full power. this would offer more speed than
> the first option, but is also a lot more work
>
> well, what do people think? my initial thought is to make a
> quick python script to take 'arraytypes.c' and convert all the
> functions to be a quicker version.
>
>
> numpy is amazing, and i'm glad to get a chance to better it!
>
>