[SciPy-dev] Linalg2 benchmarks

pearu at scipy.org pearu at scipy.org
Fri Apr 5 09:01:21 CST 2002

On 4 Apr 2002, Jochen Küpper wrote:

> Travis showed really impressive numbers for linal2.  Here is what I
> get -- less impressive, still ok?

Yes, it is still ok.

> I don't know what the problem is, but it looks as scipy scales worse
> than Numeric?

I don't understand how can you conclude that but if scipy and Numeric
use the same ATLAS (the Jochen case) then:

1) for n->oo, where n is the size of the problem, there would be no
difference in speeds as the hard computation is done by the same ATLAS

2) for n fixed but repeating the computation for c times, then for c->oo
you would find that scipy is 2-3 times faster that Numeric. This speed up
is gained only because of the f2py generated interface between Python and
the ATLAS routines that scipy uses.

BUT, if Numeric is linked with its lapack_lite (the Travis case), then
you will have huge speedups (approx. 10 times) mainly because scipy
uses highly optimized ATLAS routines.

So, I don't find these testing results strange as you commented.

What I find surprising is that there is very small difference in
the results for contiguous and non-contiguous input data. This shows that
memory copy is a really cheap operation and one should not worry too much
if the input data is non-contiguous, at least, if you have plenty of
memory in your computer.

More surprising is that sometimes with non-contiguous input data the
calculation is actually faster(!) and not slower as I would expect. I have
no explanation for this one.


More information about the Scipy-dev mailing list