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

[Dennis Decoste]

Fellow Octavers --

 Was any sort of consensus / more definitive recommendation
 achieved, on how to use ATLAS libraries to replace Octave's
 BLAS and LAPACK?

 I noticed that the series of recent postings on this topic seems
 to have ended February 14th, with no apparent resolution, exactly ...

 The best result to date seemed to be:

On  9-Feb-2000, R Clint Whaley <address@hidden> wrote:
| >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.

 There seemed to still be some concern, though, that that didn't
 ensure getting all ATLAS's improvements, including:

>>For linking, the libraries are listed in the following order:
>>  liboctinterp.a liboctave.a $(SPECIAL_MATH_LIB) libcruft.a
>
>Ah, I missed this . . .
>
>>However, one problem with just using
>>
>>  liboctave.a libatlas.a libcruft.a
>>
>>is that you may not pick up all of the BLAS from libatlas.a that might
>>be used by libcruft.a, so really we need to omit all of the blas from
>>libcruft if we are linking with ATLAS, and then use either

 Also, the config patch by Steven G. Johnson
 [http://www.che.wisc.edu/octave/mailing-lists/octave-sources/2000/14]
 seems to only be for development version of Octave, and no followup
 discussion confirmed/denyed whether it suffered from the
 same problems as the above cited approaches.

 I think given the potential payoff, this issue should probably be
 pushed through to resolution ASAP.  I can help, although I'm not
 sure what the recommendation to date suggests.  Apparently, a
 restructuring of libcruft to separate out it's BLAS is required,
 to absolutely ensure that all libATLAS.a's BLAS stuff becomes used.
 Is that effort recognized by all now as absolutely necessary?

 Is such a restructuring of libcruft underway?  If not, is there
 a reasonable way to partition/delegate the work to make that
 happen (if so, I could help).  (For example, is any other
 active development happening with the libcruft src code, which
 would complicate such a restructuring effort?).

 Given that "even MATLAB" now can use a version of LAPACK,
 [http://www.che.wisc.edu/octave/mailing-lists/help-octave/2000/288,
 
http://www.mathworks.com/company/newsletter/clevescorner/winter2000.cleve.shtml]
 (which I'm installing to our local MATLAB, to allow new benchmarkings),
 pushing Octave to the next stage (ATLAS-optimized LAPACK)
 would also help maintain the significant historic "Octave edge".

-- Dennis

*  Dr. Dennis DeCoste  (Technical Group Leader, Senior MTS)         *
*  Machine Learning Systems Group, Artificial Intelligence          *
*  Jet Propulsion Laboratory / CalTech  address@hidden  *
*  http://www-aig.jpl.nasa.gov/home/decoste/                        *



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