What shall we do about ATLAS?
Dr. David Kirkby
ATLAS development has not stopped, but I understand from Clint (the main
developer), that he has other commitments which means he will spend less time on
ATLAS for a while. So there are not going to be any new stable release coming
out soon.
There are a few specific facts.
* The current version of ATLAS in Sage takes 8.5 hours to build on 't2' as it
has no tuning parameters for the Sun T2+ processors. The latest beta fixes that
and apparently will build in under an hour on 't2'. So an update should save
more than 7.5 hours when building Sage on 't2'. That should reduce the build
time of Sage on 't2' from around 27 hours to 19.5 hours.
* The ATLAS package in Sage has additional tuning parameters for 3 sorts of
processors. I've never managed to work out how to move them to a newer release,
so they might be lost if we changed to a new beta.
* The latest beta has lots of turning parameters for new processors, so should
build more quickly, and probably run faster too on many new processors. Less
CPUs would be classed as a generic 386. I suspect there is a good chance the 3
processors in Sage would all be in the updated ATLAS beta, but I don't know for
sure.
* The Sage package has quite a few hacks to get around problems. These may or
may not be necessary if ATLAS was updated. Integrating them might be difficult,
and probably difficult to test, as some require hardware/software combinations
that are quite rarely seen.
* I don't know if there are extensive doc tests in Sage for ATLAS, but a grep
of 'atlas' in the ptestlong.log file shows nothing with 'atlas' in the name,
which make me think there might not be. Clearly if we don't test ATLAS, it is
more difficult to know of any problems if an upgrade takes place.
I would generally be reluctant to use beta software, but in this case, the
problems with building ATLAS on 't2' are very severe.
Another option, that would solve the ATLAS problem on 't2' is that the ATLAS
package is expanded with some binaries for such processors. That would add 1.6
MB to the Sage package.
I've discussed this with William a bit off-list, and we agree that if a new
ATLAS package is made, it should go in an alpha0, so gets the longest test
duration. We would then have to sort out any problems.
Thoughts?
Dave
William Stein
I am personally all for updating to the beta version of ATLAS.
-- William
François Bissey
>
> I am personally all for updating to the beta version of ATLAS.
>
issues. The only reason we don't use 3.9.24 is that the person
who usually does the revbump is "away" atm.
Francois
Dr. David Kirkby
Do you have a package for this which you can share? Has the person who bumps it
up cleaned it up at all?
The installation system of ATLAS on Sage looks a bit messy, with a combination
of perl, python, sh and bash scripts. I'd like to clean it up, but I'm sure I'd
break something on some platform. Many are Itanium specific, but I don't have
access to any Itanium hardware myself.
Is SAGE_FAT_BINARY actually used by anyone?
Dave
François Bissey
> >>> Thoughts?
> >>
> >> I am personally all for updating to the beta version of ATLAS.
> >
> > We are currently using 3.9.23 in sage-on-gentoo without any
> > issues. The only reason we don't use 3.9.24 is that the person
> > who usually does the revbump is "away" atm.
> >
> > Francois
>
> Do you have a package for this which you can share? Has the person who
> bumps it up cleaned it up at all?
>
In sage-on-gentoo we exclusively use system packages. Everything now
is under the control of portage - the equivalent of rpm/deb. So I am
talking about ATLAS provided by the distro here.
> The installation system of ATLAS on Sage looks a bit messy, with a
> combination of perl, python, sh and bash scripts. I'd like to clean it up,
> but I'm sure I'd break something on some platform. Many are Itanium
> specific, but I don't have access to any Itanium hardware myself.
>
I could send you the ebuild which is really a building recipe of the same
kind as spkg-install.
> Is SAGE_FAT_BINARY actually used by anyone?
>
No idea.
Francois
Dr. David Kirkby
That might be useful. If its suitable for email posting, it would be worth
putting in the list. I think most of the code in spkg-install will probably not
be relevant to you, but I think spkg-install for atlas does need to be cleaned up.
>> Is SAGE_FAT_BINARY actually used by anyone?
>>
> No idea.
>
> Francois
>
Dave
William Stein
<david....@onetel.net> wrote:
YES. It is *extremely* important.
William
>
> Dave
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
cschwan
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sci-libs/blas-atlas/blas-atlas-3.9.23.ebuild?revision=1.1&view=markup
, which is the ebuild for 3.9.23 (there are newer ebuilds, but they
contain patches which most likely fail). If you are not used to
ebuilds, you should know the following points:
- ebuilds are bash scripts
- the variable ${FILESDIR} points (in this case) to
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sci-libs/blas-atlas/files
- the variable ${S} will point to the directory where the source is
unpacked
- ${D} points to destination
- the functions pkg_setup, src_unpack and so on are run (in this case)
in the order they appear in the ebuild