[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
QUERY: what is status/recommendations for Octave + ATLAS compilation
From: |
Dennis Decoste |
Subject: |
QUERY: what is status/recommendations for Octave + ATLAS compilation |
Date: |
Tue, 07 Mar 2000 10:19:44 -0800 |
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
-----------------------------------------------------------------------
- QUERY: what is status/recommendations for Octave + ATLAS compilation,
Dennis Decoste <=