Re: More on binary packages and FFTW/ATLAS

[Paul Kienzle]

On Feb 20, 2004, at 2:32 PM, John W. Eaton wrote:

> On 19-Feb-2004, Dmitri A. Sergatskov <address@hidden> wrote:
>
> | Dirk Eddelbuettel wrote:
> | > On Thu, Feb 19, 2004 at 12:21:12PM -0600, Quentin Spencer wrote:
> |
> | >>optimizations, while the rest of the binary code is generic, but 
> ATLAS
> | >>does some compile-time optimizations. How has this been handled in 
> the
> | >>past for the other binary distributions (Debian, Windows, or OSX)?
> | >
> | >
> | > On Debian, Camm has put a lot of work in for architecture-specific 
> packages:
> | >
> |
> | What perhaps is more important is that he made ATLAS into shared 
> library.
> |
> | That is also how Matlab handles the situation (it shipped with few 
> pre-compiled
> | atlas.so libraries and does CPU detection on startup).
>
> We could do something similar, where Octave would not actually be
> linked with a Lapack or Blas library, but would dlopen them and look
> up functions as needed (or at startup, to fill in a table) and then
> call the linear algebra functions via pointers.  This way, it would be
> easy to switch from one linear algebra package to another, perhaps
> even at run time if you really wanted to do that.  Should we make a
> change like this?

I see this as more of an install time than a run time issue.
No need to complicate the code when the os runtime already
supports finding and loading dynamic libraries.

BTW, _every_ scientific application using lapack/blas can
benefit from atlas.  For every package to do the work of maintaining
separately compiled binaries for various os and architecture
combinations is silly.  Debian has the right solution --- it is the
job of the OS community to make atlas-lapack available and
keep it up to date, just like it is the job of the OS community to
make octave and octave-forge available and keep them up to
date.

Maybe an atlas-binaries project on source forge is what we
need for OSes such as Windows which do not have a community.
Then Octave, R, Scilab, scientific python, etc. can point their
users in that direction.

One caveat --- there is no way to override xerbla in a dll.  We
better be sure our code doesn't generate any errors!  I believe
most uses of xerbla in Octave are from other packages in libcruft
such as slatec, so this shouldn't be too difficult to do.

Paul Kienzle
address@hidden



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

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