[SciPy-dev] adding LAPACK and BLAS to the source code

eric jones eric at enthought.com
Mon Jun 24 09:53:42 CDT 2002


> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Travis Oliphant
> Sent: Sunday, June 23, 2002 9:05 PM
> To: scipy-dev at scipy.net
> Subject: Re: [SciPy-dev] adding LAPACK and BLAS to the source code
> 
> On Sun, 2002-06-23 at 13:45, eric jones wrote:
> > Hey group,
> >
> > Apologies if you get this twice -- we had a mail list hiccup earlier
> > this week, and I don't think this went out correctly.
> >
> >
> > We just had the unpleasant experience of getting SciPy to build on
the
> > Sun architecture.  In the end, it didn't prove that hard -- it was
all
> > the mis-steps that were painful.  Most of SciPy builds without a
hitch
> > -- it is only the LAPACK and BLAS stuff that causes major problems.
> >
> 
> I had thought it would be easier to get optimized LAPACK and BLAS with
> Sun systems.
> 
> > The issue is that many LAPACK's are built with vendor specific
compilers
> > instead of g77, so getting the correct libraries to link in when
> > compiling with distutils is a major headache.  And, once the link
works,
> > the headaches continue with chasing down random seg-faults that
appear
> > to come from incompatible library ABI issues.
> 
> Ah, this is the problem with using those.

Well, really, I'm not sure that its the C ABI.  I would have thought
(and do think) that gcc is compatible with the native compiler ABI.  I'm
more suspicious about g77 and f77 library incompatibilities/clashes,
especially with IO routines.  This is all speculations because we never
chased down the real problems -- it just took to long.

> 
> >
> > We worked with ATLAS for a while, but finally backed off to working
with
> > just the standard LAPACK and BLAS.
> 
> Why did ATLAS not work?

One time it was name mangling issues, another Fortran compiler issues.
The deal is that making "mistakes" in the build process is extremely
high.  If the created library has to incorrect name mangling, or the
wrong fortran compiler setting, or whatever, you don't find out until 5
hours later (on Sun).  

> 
> 
> > The result was a pain free build
> > because gcc and g77 were used all the way through.  I expect
building
> > everything with the Sun compilers would also go fairly smoothly
using
> > this approach.  It seems like most of the questions we get on
building
> > SciPy have to do with ATLAS and linear algebra.  On windows and
Linux,
> > we about have this problem licked.  But its still difficult on
platforms
> > with multiple compilers.  So, I am planning to put LAPACK and BLAS
into
> > the SciPy CVS so that they are built with the same compiler as the
rest
> > of SciPy and no longer have to be built separately.
> 
> Won't this result in slow code on those machines?

The resulting code was actually pretty fast.  There was a factor of 5-10
improvement over Numeric's linear algebra stuff.

I'm sure it is still quite a bit slower than ATLAS, but in many cases,
just getting the capability is much more important than having the
ultimate in speed.

> 
> > This will increase
> > the repository size substantially (LAPACK is big), but has little
other
> > side effects.  We'll set up the building of LAPACK and BLAS so that
they
> > are optional -- if you have ATLAS or other LAPACK libraries you'd
like
> > to use, you can specify them in the site.cfg package -- or at least
> > specify that system_info should search for them.  This search will
be
> > turned off by default, however, so that incompatible
lapack/blas/atlas
> > libraries are not found.
> >
> 
> It seems like in CVS the default should be to use the optimized LAPACK
> given that this is the default most of the developers would want to
> use.   Is the site.cfg file managed by CVS?  If so, then our constant
> changes to this file will undoubtedly result in checking in a version
> that searches by default.

I think this will probably work fine on Linux since gcc is the main tool
here, and compatibility issues are much less likely to crop up.  Perhaps
a nm check on the found ATLAS library to find out if the libraries
symbols match what SciPy expects would be a good idea though.

Another question on Linux that is likely to become more and more
important is whether gcc 3.x compiled libraries are compatible with gcc
2.9x ibraries?

Outside of the Linux and Windows worlds, defaulting to optimized
libraries has problems.  On Sun, all the libraries existed (ATLAS,
vendor supplied blas, lapack were all in /usr/lib), and were detected by
the SciPy, but none of these libraries would work because of the
mentioned issues.  So, having SciPy automatically detect and choose
these optimized libraries is problematic on non-Linux Unix platforms.

> 
> It would seem that a check for certain machines and a subsequent
turning
> off of that option would be better.

That sounds fine to me -- if Linux choose optimized by default.  If
other Unix, choose LAPACK/BLAS by default.

eric




More information about the Scipy-dev mailing list