help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ATLAS and octave


From: R Clint Whaley
Subject: Re: ATLAS and octave
Date: Wed, 9 Feb 2000 14:11:23 -0500

>Here is all I did to build a copy of Octave that uses ATLAS:
>
>  1. build ATLAS
>
>  2. merge all four of the libraries that the ATLAS build creates into
>     a single libatlas.a and install it in /some/dir.
>
>  3. relink Octave by running
>
>       make SPECIAL_MATH_LIB=/some/dir/libatlas.a
>
>That seems to be all that is needed.

That will get you ATLAS's BLAS, but I don't think it will get you ATLAS's
LU or Cholesky.  The BLAS represent the lion's share of performance, but
for these two routines, the difference can still be quite large.  To give you
an idea, I show MFLOPS for LAPACK (using optimal blocking factor) versus ATLAS's
LU and Cholesky for several problem sizes, on a 266Mhz Pentium II and a 600Mhz 
Athlon:

           N     LAPACK   ATLAS
PII266   100         63      81
PII266   500        122     148
PII266  1000        141     165
Ath600   100        248     278
Ath600   500        347     482
Ath600  1000        370     542

If you want to get this performance win on top of the BLAS win you are already
seeing, you'll need to have ATLAS's liblapack.a override that in libcruft.
This is a little more complex than with the BLAS since ATLAS does not provide
a full LAPACK.  It is designed to overwrite a previously installed LAPACK for
user's wanting a full library.  Anyway, if you are interested, we can find
an appropriate way to do this . . .

>Would it be possible to modify the ATLAS makefiles to just build a
>libatlas.a?  Then Octave could simply have
>
>  AC_CHECK_LIB(atlas, ATL_xerbla)
>
>in the configure script, and set SPECIAL_MATH_LIB accordingly.

You can do this with the present ATLAS.  ATLAS's configure creates a
Make.<arch> make include file.  If you edit this, and change:

#  ---------------------
#  Libraries to be built
#  ---------------------
   ATLASlib = $(LIBdir)/libatlas.a
   RBLASlib = $(LIBdir)/libatlas.a
   CBLASlib = $(LIBdir)/libcblas.a
   F77BLASlib = $(LIBdir)/libf77blas.a
   TESTlib = $(LIBdir)/libtstatlas.a
   TBLASlib = $(LIBdir)/libatlas_pt.a
   LAPACKlib = $(LIBdir)/liblapack.a
to:
#  ---------------------
#  Libraries to be built
#  ---------------------
   ATLASlib = $(LIBdir)/libatlas.a
   RBLASlib = $(LIBdir)/libatlas.a
   CBLASlib = $(ATLASlib)
   F77BLASlib = $(ATLASlib)
   TESTlib = $(LIBdir)/libtstatlas.a
   TBLASlib = $(LIBdir)/libatlas_pt.a
   LAPACKlib = $(ATLASlib)

Everything will be built into one library.  However, I still think it best
if you keep lapack split out, for the aforementioned reasons.  The BLAS
libraries were originaly split up in order for us to do some tricks with
our pthreads, but then we wound up not releasing the pthreads this time,
leaving a few users confused as to why our interface routines are seperate
from our main library . . .

Cheers,
Clint



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]