[Top][All Lists]

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

Re: More on binary packages and FFTW/ATLAS

From: Paul Kienzle
Subject: Re: More on binary packages and FFTW/ATLAS
Date: Fri, 20 Feb 2004 18:53:32 -0500

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

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

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

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

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