[SciPy-dev] Progress with linalg2
eric
eric at scipy.org
Sun Mar 3 05:35:02 CST 2002
Hey Pearu,
3 things:
1. My atlas is missing some routines that you have in generic_clapack.pyf.
Specifically:
clapack_xgetri
clapack_xpotri
clapack_xlauum
clapack_xtrtri
where x stands for the various types. Are these in your ATLAS? I have a
fairly recent version, but perhaps I need to upgrade?
2. I get segfaults when trying to run the tests. It looks like they happen
for both C and Fortran (I commented out contiguous cases to test Fortran).
Do you think this is a windows specific issue? I am using the latest
f2py CVS.
3. I like your _measure tests. I've long been wishing we had some set of
benchmarks that we could test with something like:
>>> import scipy
>>> scipy.benchmark()
This is a nice step in that direction.
eric
----- 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
>
> Hi,
>
> 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)
>
> Notes:
> 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
> ATLAS-3.3.13.
> 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.
>
> Conclusions:
> 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
>
> Regards,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>
More information about the Scipy-dev
mailing list