numarray speed question

[grv575]

cookedm+news at physics.mcmaster.ca (David M. Cooke) wrote in message news:<qnkr7qluxuy.fsf at arbutus.physics.mcmaster.ca>...
> Well, numarray probably isn't faster for this case (adding a scalar to
> a vector). In fact, the relevant numarray code looks like this:
> 
> static int add_Float64_vector_scalar(long niter, long ninargs, long noutargs, vo
> id **buffers, long *bsizes) {
>     long i;
>     Float64 *tin1     = (Float64 *) buffers[0];
>     Float64 tscalar   = *(Float64 *) buffers[1];
>     Float64 *tout    = (Float64 *) buffers[2];
>     
>     for (i=0; i<niter; i++, tin1++, tout++) {
>         *tout = *tin1 + tscalar;
>     }
>  return 0;
> }

OK good.  So doing it in C isn't really that much of a headache when
it comes to optimization.

> What you *do* get with numarray is:
> 
> 1) transparent handling of byteswapped, misaligned, discontiguous,
>    type-mismatched data (say, from a memory-mapped file generated on a
>    system with a different byte order as single-precision instead of
>    double-precision).

Heh.  Try timing the example I gave (a += 5) using byteswapped vs.
byteswap().  It's fairly fast to do the byteswap.  If you go the
interpretation way (byteswapped) then all subsequent array operations
are at least an order of magnitude slower (5 million elements test
example).

> 2) ease-of-use. That two lines of python code above is _it_ (except
>    for an 'import numarray' statement). Your C code isn't anywhere
>    nearly complete enough to use. You would need to add routines to
>    read the file, etc.

Can't argue here.

> 3) interactive use. You can do all this in the Python command line. If
>    you want to multiply instead of add, an up-arrow and some editing
>    will do that. With C, you'd have to recompile.

As much as I hate the .edu push for interpreted languages like lisp
and ml, having a python interpreter to test code out real quickly
before it goes into the source script is real nice.

> If you need the best possible speed (after doing it in numarray and
> finding it isn't fast enough), you can write an extension module to
> do that bit in C, or look into scipy.weave for inlining C code, or into
> f2py for linking Fortran code to Python.

Well re speed what really bothers me is the slowness in which numarray
is improving in this area.  If I have to take 1000 FFT's over 32
element arrays, then it's useless.  I'll have to install both numarray
and numeric :/