[SciPy-dev] Progress with linalg2
eric at scipy.org
Sat Mar 2 17:27:12 CST 2002
This looks great on several accounts. First congrats on the speed of your f2py
interfaces. I've wondered in the past if what your doing is generally appicable
and efficient, and your proving that it is. Good work.
Second, it is nice to see to see a speed improvement on the linalg solve. Call
me greedy, but I was actually expecting more -- I thought I remembered factors
of 2-10 when comparing ATLAS to standard LAPACK on my machine. Perhaps this is
because of the processor types. As I remember ATLAS runs faster on PIII than
PII because of the SSE instruction set, and it really comes into its own on a P4
with the SSE2 instruction set. I'll be interested to see time comparisons for
those machines, and also compared to Matlab, Octave, C, and other common tools.
One other thing. Sorry I haven't had more time to put into this part of the
linalg section of the project. I haven't managed to make time for it as I had
hoped, and you've picked up the slack wonderfully. Thanks.
I'll run tests this evening and report how they do on my PIII-850 laptop on W2K.
thanks for all your good work,
----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>
To: <scipy-dev at scipy.org>
Sent: Saturday, March 02, 2002 12:28 PM
Subject: [SciPy-dev] Progress with linalg2
> I am working again with linalg2 and I have made some progress with it.
> I have almost finished testing solve() function, other functions will
> get out faster hopefully.
> Here are some timing results that compare the corresponding functions of
> scipy and Numeric:
> Solving system of linear equations
> | continuous | non-continuous
> size | scipy | Numeric | scipy | Numeric
> 20 | 1.11 | 1.70 | 1.10 | 1.85 (secs for 2000 calls)
> 100 | 1.65 | 3.02 | 1.68 | 4.47 (secs for 300 calls)
> 500 | 1.73 | 2.14 | 1.78 | 2.33 (secs for 4 calls)
> 1000 | 5.60 | 6.23 | 5.59 | 7.03 (secs for 2 calls)
> 1) `Numeric' refers to using LinearAlgebra.solve_linear_equations().
> 2) `scipy' refers to using scipy.linalg.solve().
> 3) `size' is the number of equations.
> 4) Both continuous and non-continuous arrays were used in the tests.
> 5) Both Numeric and scipy use the same LAPACK routine dgesv from
> 6) The tests were run on PII-400MHz, 160MB RAM, Debian Woody
> with gcc-2.95.4, Python 2.2, Numeric 20.3, f2py-2.13.175-1218.
> 1) The corresponding Scipy function is faster in all tests.
> The difference gets smaller for larger tasks but it does not vanish.
> 2) Since both Scipy and Numeric functions use the same LAPACK
> routine, then these tests actually measure the efficency of the interfaces
> to LAPACK routines. In the Scipy case the interfaces are generated by
> f2py and in the Numeric case by a man. These results show that it makes
> sense to use automatically generated extension modules: one can always
> tune the code generator for producing a better code while hand-written
> extension modules will hardly get tuned in practice.
> 3) Note that there is almost no difference whether the input array to f2py
> generated extension module is contiguous or non-contiguous, these
> cases are efficently handled by the interface. While using the Numeric
> interface, the difference is quite noticable.
> Note also that in order to run these tests, one has to have
> f2py-2.13.175-1218 (in f2py CVS) or later because earlier versions of f2py
> leak memory. Here is how I run the tests (remember to cvs update):
> cd linalg2
> python setup_linalg.py build --build-platlib=.
> python tests/test_basic.py
> Scipy-dev mailing list
> Scipy-dev at scipy.net
More information about the Scipy-dev