On Tue, 19 Sep 2006, Troy Dawson wrote:

> Howdy,
> I'm getting our first batch of scientific programs into S.L. 4.4.
> Right now, I'm just getting in the ones that were in the contrib area.
> R and numpy

<snip>
> I couldn't get atlas to install, or any programs that depend on it, so it's 
> looking like it won't make it in this release.

ATLAS is a strange beast in that building it for a given cpu type is easy 
enough on that cpu (it will generally auto-detect everything it needs), 
but I've yet to manage to convince it to build for any different cpu (e.g. 
build for pentium-III on a P4 etc).  Actually differences between versions 
of CPUs (e.g. cache-sizes etc) mean that one can't be sure that the tuning 
isn't slightly different for different versions of the P4 anyway.

Apparently the Debian dpkg for ATLAS does the magic but their patch looked 
hideously complex...

Since the whole point of ATLAS is that it is supposed to be 'tuned' to the 
cpu there isn't *much* point in building it in a generic way except 
perhaps to fill dependencies.

I'd be tempted to just make a srpm which builds/tunes itself for the 
platform it gets installed on but atlas takes so long to build (at least 
on older machines!) that this would be a major pain.

Since ATLAS is really only providing replacement/faster BLAS code anything 
wanting/depending on ATLAS should really only need any BLAS (though using 
a faster one is clearly better).  Maybe the standard BLAS libraries should 
end up as links to whatever *best* BLAS is available (if that is 
possible).

If you have a lot of identical machines (e.g. a cluster or similar) then 
building ATLAS for those is easy enough...  Last time I rebuilt ATLAS I 
ended up with 5 different sets of libraries though at least some of those 
(e.g. Pentium-II) may not be something I'll worry about next time :-)

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/