Re: QUERY: what is status/recommendations for Octave + ATLAS compilation

[Steven G. Johnson]

JWE wrote:
>As I see it, ATLAS will definitely be available in some future version
>of Octave.  The only question is whether it should be optional.  I'm
>leaning toward making it the default.  If it is the default, then the
>question is how to modify the Octave distribution to accomodate that.
>Since ATLAS doesn't provide everything from LAPACK that Octave needs,
>it makes the installation a bit strange.  The current scheme of
>building the LAPACK library and then building ATLAS and overwriting
>parts of the LAPACK library seems a bit awkward to me.

I think that bundling ATLAS with Octave would not be such a good idea,
because ATLAS can take a very long time (hours) to build (due to its
self-optimization scripts, etcetera), especially on new machines for which
it doesn't have hard-coded parameters, and also because its build process
is not completely automated (it asks you to answer a certain number of
questions about your machine, compiler flags, and so on...you would have to
fork ATLAS's development to try to deal with these things automatically).

Basically, if someone can afford the time and effort to compile ATLAS from
scratch, then they are probably a person who doesn't mind downloading it
separately and installing it first.

On the other hand, I agree that people who don't care quite so much about
performance will want to just untar it, compile it, and go.  For those
people, you should continue to package a default BLAS and LAPACK with
Octave, that get used if they are not found on the system.

As for the ATLAS/LAPACK interactions, I think the key thing here is that
it's just an option for really diligent users; the vast majority of the
performance gains from ATLAS will come just from using its optimized BLAS.
The weirdness comes because ATLAS provides replacements for one or two
LAPACK routines, in addition to its optimized BLAS, and one *must* build
these directly into the LAPACK library because of the way compilers resolve
dependency information.  So, either (1) the user can just forget about the
ATLAS LAPACK routines (and just use the optimized BLAS), or (2) people who
really care can build/install LAPACK and add the ATLAS routines.  There
really isn't any way around (2) if one wants to to use the ATLAS LAPACK
routines, unless you're willing to build your own completely mutant version
of LAPACK that fuses ATLAS and LAPACK.

I just don't think that this is something that Octave should worry
about--leave it up to the user, and the ATLAS/LAPACK developers, to figure
out how to build the fastest libraries.  Octave should just provide the
option of linking with the fastest/latest libraries if the user provides
them.

Steven

PS. I think you'd be surprised at how many people won't mind downloading
and installing a couple of other libraries first.  Also, using optional
existing BLAS/LAPACK libraries would help push e.g. Linux distributions
into including BLAS and LAPACK libraries by default, which would be a good
thing.




-----------------------------------------------------------------------
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
-----------------------------------------------------------------------