Re: lapack and blas
I should start by mentioning that Sue is orphaning the lapack packages.
One of these days I'll convince her to actually send mail to the wnpp
stating such.
Once she has officially orphaned them, I will send a note offering to
take them over.
On Tue, Sep 14, 1999 at 01:01:43PM -0400, Camm Maguire wrote:
> I'd like to package atlas before the upcoming release in November. As
> you may know, atlas tunes blas for your system automatically, with
> rather impressive results, turning the reference blas implementation
> essentially into an open source per-system optimized implementation.
> As I'm working on scalapack too, I'd like to get a blas library in
> shared, as well as in static form. (Using static libs in scalapack
> *really* wastes space). I've put together a BLAS package, and an
> atlas package, providing both shared and static libs. An idea is to
> also provide a script in atlas which would rebuild the blas library
> provided by the blas package with the newly optimized routines. That
> way, programs dynamically linked against libblas won't need to be
> recompiled to use atlas. To do this, of course, requires that the
> static library be built with -fPIC. Another idea is to use the
> alternatives system to allow on the fly switching between blas libs.
>
Are you aware that the current lapack packages contain both static and shared
libs(*)? The static libs are not compiled with -fPIC though. As I'm sure
you are aware, using -fPIC uses a register which can have a substantial(**)
hit on performance on register starved architectures like intel.
(*)As per Debian convention for packaging libraries, there are two
packages, lapack, containing the shared libs, and lapack-dev, containing the
static libs and headers.
(**)substantial is a rather subjective term. I've heard claims of only a
few percent difference up to a 30% hit for different cases. Unfortunately,
few actual numbers to back this up.
> What are your thoughts here? Assuming you are in general agreement
> with the above ideas, Here are the options as I see them, in ascending
> order of time required to accomplish:
>
> 1) Just don't include BLAS in lapack, and make a dependency on libblas
> in the control file.
>
It is my intention to separate blas from lapack. This is definitely the
right thing to do. lapack would depend on blas. It just needs to be decided
if the static blas library is compiled using -fPIC or not. The split packages
could be ready within two weeks.
> 2) Incorporate my Makefile to get shared and static blas libraries
> built with lapack. It might then be nice to make sure the reset of
> lapack uses the shared library.
>
> 3) Do 2), and then add the update-alternatives calls into postinst. I
> could help here if needed. Perhaps the reference implementation,
> whether in a separate package or part of lapack, could be
> libblas_ref, and the atlas one libblas_atlas, with appropriate
> links set to libblas. Since these libs are binary compatible, the
> soname of all libs should be libblas.so.x.
>
Perhaps a bit more discussion before a decision is reached. Do you have
any information on performance of
atlas modified static blas
vs.
atlas modified static blas compiled using -fPIC ?
How portable are the tuned libraries to other machines? For example, if the
atlas modified blas libraries are generated on a P133, how well would those
libs perform on a PII (with a much larger cache) compared to a set of
libraries tuned specifically for that configuration.
If they aren't very portable and -fPIC isn't a big hit, then we could
install atlas and use the postinst to automatically tune the users
machine. I believe this is what you suggested in your opening paragraph.
Can atlas fix an atlas modified version of blas? I'm thinking here of shipping
the blas package with an atlas modified library which could then be tuned
as per the previous paragraph if a user wishes. This would give an
(possibly) improved generic blas library while still allowing power users
to tune it for fastest performance on their machine.
If we have good answers to the above, the best course of action
should be clear.
> Thanks again! I hope you don't mind me cc'ing this note to the
> debian-beowulf mailing list, to solicit some additional feedback.
>
No problem. Since the blas routines are critical to many programs we need
to ship the fastest ones we can. More feedback is good.
Jay Treacy
Reply to: