![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Hi all, I think this is a nifty bit of trivia. After getting my nifty Apple Dual G5, I finally got around to doing a test I had wanted to do for a while. The Numeric package uses LAPACK for the Linear Algebra stuff. For OS-X there are two binary versions available for easy install: One linked against the default, non-optimized version of BLAS (from Jack Jansen's PackMan database) One linked against the Apple Supplied vec-lib as the BLAS. (From Bob Ippolito's PackMan database (http://undefined.org/python/pimp/) To compare performance, I wrote a little script that generates a random matrix and vector: A, b, and solves the equation: Ax = b for x N = 1000 a = RandomArray.uniform(-1000, 1000, (N,N) ) b = RandomArray.uniform(-1000, 1000, (N,) ) start = time.clock() x = solve_linear_equations(a,b) print "It took %f seconds to solve a %iX%isystem"%( time.clock()-start, N, N) And here are the results: With the non-optimized version: It took 3.410000 seconds to solve a 1000X1000 system It took 28.260000 seconds to solve a 2000X2000 system With vec-Lib: It took 0.360000 seconds to solve a 1000X1000 system It took 2.580000 seconds to solve a 2000X2000 system for a speed increase of over 10 times! Wow! Thanks Bob, for providing that package. I'd be interested to see similar tests on other platforms, I haven't gotten around to figuring out how to use a native BLAS on my Linux box. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/f43c8615de52864c7f2f3ad5d67ee137.jpg?s=120&d=mm&r=g)
At least at a debian box you can install native ATLAS libraries and they come with blas and lapack. For example if a search for atlas3 packages I find the following atlas packages available: atlas3-base atlas3-3dnow atlas3-sse atlas3-sse2 Best Paulo -- Paulo José da Silva e Silva Professor Assistente do Dep. de Ciência da Computação (Assistant Professor of the Computer Science Dept.) Universidade de São Paulo - Brazil e-mail: rsilva@ime.usp.br Web: http://www.ime.usp.br/~rsilva Teoria é o que não entendemos o (Theory is something we don't) suficiente para chamar de prática. (understand well enough to call) (practice)
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 11:57, Chris Barker wrote:
One linked against the Apple Supplied vec-lib as the BLAS. (From Bob Ippolito's PackMan database (http://undefined.org/python/pimp/)
Well, I'm a sucker for trying to increase performance :-) . AMD's Web site recommends ATLAS as the best source for an Athlon-optimized BLAS. I happen to have ATLAS installed, and the time for Chris Barker's test went from 4.95 seconds to 0.91 seconds on a dual-Athlon MP 2200+ system. To build numarray 1.0 with this setup, I had to modify addons.py a bit, both to use LAPACK and ATLAS and because ATLAS was built here with the Absoft Fortran compiler version 8.2 (I haven't tried g77). Is anyone interested in this? -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 13:00, Perry Greenfield wrote:
Well, I guess we are :-) Let us know what you had to do to get it to work.
This is so Absoft-specific that I'm not sure how much it helps others, but here goes: I built LAPACK after modifing the make.inc.LINUX file to set the compiler and linker to /opt/absoft/bin/f77 instead of to g77, and the compile flags to "-O3 -YNO_CDEC". I ran "make config" in the ATLAS directory and told the setup that /opt/absoft/bin/f77 was my Fortran compiler, then did "make install arch=", then followed the scipy.org instructions to combine LAPACK with the one from ATLAS. Finally, I applied the attached patch to addons.py in the numarray directory. Interestingly, the example program runs in 1.43 seconds on a 2.26GHz P4 with the default numarray install (as opposed to 4.95 seconds on the Athlon). I haven't built ATLAS on this platform yet to find how much of an improvement I get. I suppose something similar would work with g77, replacing the Absoft libraries with g2c, but I haven't tried it. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
An addition to my previous post: I also had to do a "setenv USE_LAPACK" in the shell before "python setup.py build" in the numarray directory. [Admin question: I'm not seeing my own posts to this list, even though I'm supposed to according to my Sourceforge preferences.]
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
HI all, I decided I want to try to get this working on my gentoo linux box. I started by emerging the gentoo atlas package. Now I've gone into the Numeric setup.py, and have gotten confused. These seem to be the relevant lines (unchanged from how they came with Numeric 23.3): # delete all but the first one in this list if using your own LAPACK/BLAS sourcelist = [os.path.join('Src', 'lapack_litemodule.c'), # os.path.join('Src', 'blas_lite.c'), # os.path.join('Src', 'f2c_lite.c'), # os.path.join('Src', 'zlapack_lite.c'), # os.path.join('Src', 'dlapack_lite.c') That's all well and good, except that they are all deleted except the first one. And it looks like I don't want that one either. ] # set these to use your own BLAS; library_dirs_list = ['/usr/lib/atlas'] libraries_list = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c'] # if you also set `use_dotblas` (see below), you'll need: # ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c'] This also seems to be set already. I don't have a '/usr/lib/atlas', so I set: library_dirs_list = [] All the libraries in libraries_list are in /usr/lib/ include_dirs = ['/usr/include/atlas'] # You may need to set this to find cblas.h cblas.h is in : /usr/include/, so I set this to: include_dirs = [] Now everything compiled and installed just fine, but when I try to use it, I get: File "/usr/lib/python2.3/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: dynamic module does not define init function (initlapack_lite) SO I tried adding sourcelist = [os.path.join('Src', 'lapack_litemodule.c')] back in. Now I can build and install, but get: Traceback (most recent call last): File "./TestBlas.py", line 4, in ? from LinearAlgebra import * File "/usr/lib/python2.3/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: /usr/lib/python2.3/site-packages/Numeric/lapack_lite.so: undefined symbol: dgesdd_ Now I'm stuck. -CHB -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
By the way, I get these same errors when compiling with the setup.py unchanged from how it's distributed with Numeric 23.3
So some thing's weird. Stephen Walton wrote:
one has to merge an LAPACK library built separately with the one generated by ATLAS to get a 'complete' LAPACK.
I'll try this, but it's odd that it didn't give an error when compiling or linking. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 15:22, Chris Barker wrote:
(I neglected to CC the list on my response to Chris, but basically wrote that changes similar to the ones I used for numarray worked in Numeric). Since Numeric and numarray are building shared libraries, undefined external references don't show up until you actually import the Python package represented by the shared libraries. I noticed this in my experiments as well. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Stephen Walton wrote:
OK. I did an "emerge lapack" and got lapack installed, then re-build Numeric, and now it works. What's odd is that before I installed lapack all the libs were there, including liblapack. Anyway it works, so I'm happy. One note, however: The setup.py delivered with 23.3 seems to be set up to use a native lapack by default. Will it work on a system that doesn't have one? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 15:36, Chris Barker wrote:
The setup.py delivered with 23.3 seems to be set up to use a native lapack by default. Will it work on a system that doesn't have one?
No. On my system it fails with a complaint about not finding -llapack, since my ATLAS and LAPACK libraries are in /usr/local/lib/atlas, and the 23.3 setup.py looks in /usr/lib/atlas. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/5c85708f2eed0869671a7d303ca55b85.jpg?s=120&d=mm&r=g)
On Thu, Jul 29, 2004 at 03:36:58PM -0700, Chris Barker wrote:
Atlas might have installed a liblapack, with the (few) functions that it overrides with faster ones. It's by no means a complete LAPACK installation. Have a look at the difference in library sizes; a full LAPACK is a few megs; Atlas's routines are a few hundred K. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
David M. Cooke wrote:
OK, I'm really confused now. I got it working, but it seems to have virtually identical performance to the Numeric-supplied lapack-lite. I'm guessing that the LAPACK package I emerged does NOT use the atlas BLAS. if the atlas liblapack doesn't have all of lapack, how in the world are you supposed to use it? I have no idea how I would get the linker to get what it can from the atlas lapack, and the rest from another one. Has anyone done this on Gentoo? If not how about another linux distro, I don't have to use portage for this after all. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Fri, 30 Jul 2004 09:28:35 -0700 "Chris Barker" <Chris.Barker@noaa.gov> wrote:
I am making my own ATLAS rpms and basically I am doing the following (starting from the ATLAS source directory, with the LAPACK unpacked inside it): # build lapack # Note added right now: this assumes that the LAPACK/make.inc has been patched (cd LAPACK; make lapacklib) # configuration: leave the blank lines in the 'here' document # Note added right now: this is dependent on your CPU architecture if [ $(hostname)=="zombie" ] ; then make config <<EOF 023 y y y y 0 y EOF # build atlas make install arch=Linux_P4SSE2_2 # make an atlas enhanced lapack library # Note added right now: this is explained in the ATLAS (or SciPy docs) cd lib/Linux_P4SSE2_2 mkdir tmp cd tmp ar x ../liblapack.a cp ../../../LAPACK/lapack.a ../liblapack.a ar r ../liblapack.a *.o cd .. rm -rf tmp fi That is all -- Gerard
![](https://secure.gravatar.com/avatar/c6e87f3cd4874c0d84477d5a503aec89.jpg?s=120&d=mm&r=g)
I recently did this under Gentoo. It seems that the atlas package doesn't build a complete lapack, which is necessary. Instead I emerged the newer blas-atlas and lapack-atlas packages. These build a complete lapack library with atlas optimizations. They are however masked with ~x86 so you have to add the following to your /etc/portage/package.keywords: app-sci/lapack-atlas ~x86 app-sci/blas-atlas ~x86 app-sci/blas-config ~x86 app-sci/lapack-config ~x86 blas-config and lapack-config are packages that are needed by the other ones. They can be used to switch between reference lapack or atlas optimized libraries (if you install lapack-reference and blas-reference) For more information see Gentoo bug #30453 Hope this helps, Mats On Friday 30 July 2004 18.28, Chris Barker wrote:
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Hi folks, I've got a project that uses Numeric arrays a fair bit. Unfortunately, I have a fair number of users that would like to be able to use it without Numeric (frankly I don't get it. It's a wxPython widget, and once you've installed wxPython, Numeric should not be a show stopper, but whatever). I though one way to accommodate this was to create a pure python Numeric-lite package, that contained the functionality need for my app, and was written in pure python. A side benefit of this is that it would be an easy way to see how much a performance gain Numeric gives me. Frankly, I don't really care that much, I like using Numeric operations for the syntactical advantages, aside from performance issues. Anyway, I recall a while back a couple folks did some testing with Psyco and a pure-python implementation of a small fraction of Numeric functionality. I'd love to see that code if it's still around. Or if any of you has done something similar, I'd love to see that too. -thanks, Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Chris Barker wrote:
Hi Chris, That was probably me. Your message prompted me to take a look at that code for the first time in a long time and it is indeed a *small* fraction of Numeric functionality. That being said your welcome to try and do something useful with it. I'll go ahead and send you the file in private email to avoid cluttering the list. If anyone else wants a copy let me know. -tim
-thanks, Chris
![](https://secure.gravatar.com/avatar/f43c8615de52864c7f2f3ad5d67ee137.jpg?s=120&d=mm&r=g)
Hello, I have took some time today to do some benchmark on different uses of lapack in an Athlon Thunderbird 1.2Gz. Here it goes: ------ Vanilla numarray It took 9.970000 seconds to solve a 1000X1000system numarray vanilla blas and lapack It took 7.010000 seconds to solve a 1000X1000system numarray atlas blas and vanilla lapack It took 1.050000 seconds to solve a 1000X1000system numarray atlas blas and lapack It took 0.760000 seconds to solve a 1000X1000system ------ One nice touch is that matlab takes 1.3s to solve a system of the same size with the notation A\b. Hence numarray is actually faster than matlab to solve linear system :-) I know, probably there is a way to make matlab use the faster atlas library... Paulo -- Paulo José da Silva e Silva Professor Assistente do Dep. de Ciência da Computação (Assistant Professor of the Computer Science Dept.) Universidade de São Paulo - Brazil e-mail: rsilva@ime.usp.br Web: http://www.ime.usp.br/~rsilva Teoria é o que não entendemos o (Theory is something we don't) suficiente para chamar de prática. (understand well enough to call) (practice)
![](https://secure.gravatar.com/avatar/f43c8615de52864c7f2f3ad5d67ee137.jpg?s=120&d=mm&r=g)
At least at a debian box you can install native ATLAS libraries and they come with blas and lapack. For example if a search for atlas3 packages I find the following atlas packages available: atlas3-base atlas3-3dnow atlas3-sse atlas3-sse2 Best Paulo -- Paulo José da Silva e Silva Professor Assistente do Dep. de Ciência da Computação (Assistant Professor of the Computer Science Dept.) Universidade de São Paulo - Brazil e-mail: rsilva@ime.usp.br Web: http://www.ime.usp.br/~rsilva Teoria é o que não entendemos o (Theory is something we don't) suficiente para chamar de prática. (understand well enough to call) (practice)
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 11:57, Chris Barker wrote:
One linked against the Apple Supplied vec-lib as the BLAS. (From Bob Ippolito's PackMan database (http://undefined.org/python/pimp/)
Well, I'm a sucker for trying to increase performance :-) . AMD's Web site recommends ATLAS as the best source for an Athlon-optimized BLAS. I happen to have ATLAS installed, and the time for Chris Barker's test went from 4.95 seconds to 0.91 seconds on a dual-Athlon MP 2200+ system. To build numarray 1.0 with this setup, I had to modify addons.py a bit, both to use LAPACK and ATLAS and because ATLAS was built here with the Absoft Fortran compiler version 8.2 (I haven't tried g77). Is anyone interested in this? -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 13:00, Perry Greenfield wrote:
Well, I guess we are :-) Let us know what you had to do to get it to work.
This is so Absoft-specific that I'm not sure how much it helps others, but here goes: I built LAPACK after modifing the make.inc.LINUX file to set the compiler and linker to /opt/absoft/bin/f77 instead of to g77, and the compile flags to "-O3 -YNO_CDEC". I ran "make config" in the ATLAS directory and told the setup that /opt/absoft/bin/f77 was my Fortran compiler, then did "make install arch=", then followed the scipy.org instructions to combine LAPACK with the one from ATLAS. Finally, I applied the attached patch to addons.py in the numarray directory. Interestingly, the example program runs in 1.43 seconds on a 2.26GHz P4 with the default numarray install (as opposed to 4.95 seconds on the Athlon). I haven't built ATLAS on this platform yet to find how much of an improvement I get. I suppose something similar would work with g77, replacing the Absoft libraries with g2c, but I haven't tried it. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
An addition to my previous post: I also had to do a "setenv USE_LAPACK" in the shell before "python setup.py build" in the numarray directory. [Admin question: I'm not seeing my own posts to this list, even though I'm supposed to according to my Sourceforge preferences.]
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
HI all, I decided I want to try to get this working on my gentoo linux box. I started by emerging the gentoo atlas package. Now I've gone into the Numeric setup.py, and have gotten confused. These seem to be the relevant lines (unchanged from how they came with Numeric 23.3): # delete all but the first one in this list if using your own LAPACK/BLAS sourcelist = [os.path.join('Src', 'lapack_litemodule.c'), # os.path.join('Src', 'blas_lite.c'), # os.path.join('Src', 'f2c_lite.c'), # os.path.join('Src', 'zlapack_lite.c'), # os.path.join('Src', 'dlapack_lite.c') That's all well and good, except that they are all deleted except the first one. And it looks like I don't want that one either. ] # set these to use your own BLAS; library_dirs_list = ['/usr/lib/atlas'] libraries_list = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c'] # if you also set `use_dotblas` (see below), you'll need: # ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c'] This also seems to be set already. I don't have a '/usr/lib/atlas', so I set: library_dirs_list = [] All the libraries in libraries_list are in /usr/lib/ include_dirs = ['/usr/include/atlas'] # You may need to set this to find cblas.h cblas.h is in : /usr/include/, so I set this to: include_dirs = [] Now everything compiled and installed just fine, but when I try to use it, I get: File "/usr/lib/python2.3/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: dynamic module does not define init function (initlapack_lite) SO I tried adding sourcelist = [os.path.join('Src', 'lapack_litemodule.c')] back in. Now I can build and install, but get: Traceback (most recent call last): File "./TestBlas.py", line 4, in ? from LinearAlgebra import * File "/usr/lib/python2.3/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: /usr/lib/python2.3/site-packages/Numeric/lapack_lite.so: undefined symbol: dgesdd_ Now I'm stuck. -CHB -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
By the way, I get these same errors when compiling with the setup.py unchanged from how it's distributed with Numeric 23.3
So some thing's weird. Stephen Walton wrote:
one has to merge an LAPACK library built separately with the one generated by ATLAS to get a 'complete' LAPACK.
I'll try this, but it's odd that it didn't give an error when compiling or linking. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 15:22, Chris Barker wrote:
(I neglected to CC the list on my response to Chris, but basically wrote that changes similar to the ones I used for numarray worked in Numeric). Since Numeric and numarray are building shared libraries, undefined external references don't show up until you actually import the Python package represented by the shared libraries. I noticed this in my experiments as well. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Stephen Walton wrote:
OK. I did an "emerge lapack" and got lapack installed, then re-build Numeric, and now it works. What's odd is that before I installed lapack all the libs were there, including liblapack. Anyway it works, so I'm happy. One note, however: The setup.py delivered with 23.3 seems to be set up to use a native lapack by default. Will it work on a system that doesn't have one? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/80473ff660f57aa7f90affadd2240008.jpg?s=120&d=mm&r=g)
On Thu, 2004-07-29 at 15:36, Chris Barker wrote:
The setup.py delivered with 23.3 seems to be set up to use a native lapack by default. Will it work on a system that doesn't have one?
No. On my system it fails with a complaint about not finding -llapack, since my ATLAS and LAPACK libraries are in /usr/local/lib/atlas, and the 23.3 setup.py looks in /usr/lib/atlas. -- Stephen Walton <stephen.walton@csun.edu> Dept. of Physics & Astronomy, Cal State Northridge
![](https://secure.gravatar.com/avatar/5c85708f2eed0869671a7d303ca55b85.jpg?s=120&d=mm&r=g)
On Thu, Jul 29, 2004 at 03:36:58PM -0700, Chris Barker wrote:
Atlas might have installed a liblapack, with the (few) functions that it overrides with faster ones. It's by no means a complete LAPACK installation. Have a look at the difference in library sizes; a full LAPACK is a few megs; Atlas's routines are a few hundred K. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
David M. Cooke wrote:
OK, I'm really confused now. I got it working, but it seems to have virtually identical performance to the Numeric-supplied lapack-lite. I'm guessing that the LAPACK package I emerged does NOT use the atlas BLAS. if the atlas liblapack doesn't have all of lapack, how in the world are you supposed to use it? I have no idea how I would get the linker to get what it can from the atlas lapack, and the rest from another one. Has anyone done this on Gentoo? If not how about another linux distro, I don't have to use portage for this after all. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Fri, 30 Jul 2004 09:28:35 -0700 "Chris Barker" <Chris.Barker@noaa.gov> wrote:
I am making my own ATLAS rpms and basically I am doing the following (starting from the ATLAS source directory, with the LAPACK unpacked inside it): # build lapack # Note added right now: this assumes that the LAPACK/make.inc has been patched (cd LAPACK; make lapacklib) # configuration: leave the blank lines in the 'here' document # Note added right now: this is dependent on your CPU architecture if [ $(hostname)=="zombie" ] ; then make config <<EOF 023 y y y y 0 y EOF # build atlas make install arch=Linux_P4SSE2_2 # make an atlas enhanced lapack library # Note added right now: this is explained in the ATLAS (or SciPy docs) cd lib/Linux_P4SSE2_2 mkdir tmp cd tmp ar x ../liblapack.a cp ../../../LAPACK/lapack.a ../liblapack.a ar r ../liblapack.a *.o cd .. rm -rf tmp fi That is all -- Gerard
![](https://secure.gravatar.com/avatar/c6e87f3cd4874c0d84477d5a503aec89.jpg?s=120&d=mm&r=g)
I recently did this under Gentoo. It seems that the atlas package doesn't build a complete lapack, which is necessary. Instead I emerged the newer blas-atlas and lapack-atlas packages. These build a complete lapack library with atlas optimizations. They are however masked with ~x86 so you have to add the following to your /etc/portage/package.keywords: app-sci/lapack-atlas ~x86 app-sci/blas-atlas ~x86 app-sci/blas-config ~x86 app-sci/lapack-config ~x86 blas-config and lapack-config are packages that are needed by the other ones. They can be used to switch between reference lapack or atlas optimized libraries (if you install lapack-reference and blas-reference) For more information see Gentoo bug #30453 Hope this helps, Mats On Friday 30 July 2004 18.28, Chris Barker wrote:
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Hi folks, I've got a project that uses Numeric arrays a fair bit. Unfortunately, I have a fair number of users that would like to be able to use it without Numeric (frankly I don't get it. It's a wxPython widget, and once you've installed wxPython, Numeric should not be a show stopper, but whatever). I though one way to accommodate this was to create a pure python Numeric-lite package, that contained the functionality need for my app, and was written in pure python. A side benefit of this is that it would be an easy way to see how much a performance gain Numeric gives me. Frankly, I don't really care that much, I like using Numeric operations for the syntactical advantages, aside from performance issues. Anyway, I recall a while back a couple folks did some testing with Psyco and a pure-python implementation of a small fraction of Numeric functionality. I'd love to see that code if it's still around. Or if any of you has done something similar, I'd love to see that too. -thanks, Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Chris Barker wrote:
Hi Chris, That was probably me. Your message prompted me to take a look at that code for the first time in a long time and it is indeed a *small* fraction of Numeric functionality. That being said your welcome to try and do something useful with it. I'll go ahead and send you the file in private email to avoid cluttering the list. If anyone else wants a copy let me know. -tim
-thanks, Chris
![](https://secure.gravatar.com/avatar/f43c8615de52864c7f2f3ad5d67ee137.jpg?s=120&d=mm&r=g)
Hello, I have took some time today to do some benchmark on different uses of lapack in an Athlon Thunderbird 1.2Gz. Here it goes: ------ Vanilla numarray It took 9.970000 seconds to solve a 1000X1000system numarray vanilla blas and lapack It took 7.010000 seconds to solve a 1000X1000system numarray atlas blas and vanilla lapack It took 1.050000 seconds to solve a 1000X1000system numarray atlas blas and lapack It took 0.760000 seconds to solve a 1000X1000system ------ One nice touch is that matlab takes 1.3s to solve a system of the same size with the notation A\b. Hence numarray is actually faster than matlab to solve linear system :-) I know, probably there is a way to make matlab use the faster atlas library... Paulo -- Paulo José da Silva e Silva Professor Assistente do Dep. de Ciência da Computação (Assistant Professor of the Computer Science Dept.) Universidade de São Paulo - Brazil e-mail: rsilva@ime.usp.br Web: http://www.ime.usp.br/~rsilva Teoria é o que não entendemos o (Theory is something we don't) suficiente para chamar de prática. (understand well enough to call) (practice)
participants (8)
-
Chris Barker
-
David M. Cooke
-
Gerard Vermeulen
-
Mats Klingberg
-
Paulo J. S. Silva
-
Perry Greenfield
-
Stephen Walton
-
Tim Hochberg