Update ATLAS to stable version 3.10.1

[vbraun]

The new atlas release now builds netlib lapack itself, so the lapack tarball is now included in the ATLAS spkg.

• Updated to newest upstream source, various patches are no longer required
• SAGE_ATLAS_LIB=path now searches in path/libatlas.so instead of path/lib/libatlas.so so it works for people with atlas in /lib64, too.
• Threading is now enabled by default
• Flush before os.system (ATLAS: flush output before os.system() #13210)

Upstream has made some attempt at changing the layout of the shared libraries, which is now different from the static libraries. The atlas spkg contains a stub autoconf/libtools project that unpacks the static libraries and repacks them into equivalent shared libraries.

By default, ATLAS will now try twice to get timings and fail immediately if throttling is enabled. If auto-tuning fails build with SAGE_ATLAS_ARCH=fast, and if that fails with SAGE_ATLAS_ARCH=base. On x86, the fast and base targets are the new ATLAS generic targets x86SSE3 and x86SSE2/x86x87.

There is an upstream problem where compilation sometimes crashes during xextract because of a buffer overflow due to small fixed-sized buffers for filenames.

Updated spkg:

1. http://boxen.math.washington.edu/home/jpflori/spkg/atlas-3.10.1.p0.spkg.

Apply

1. attachment: 10508_root.patch to the SAGE_ROOT repository
2. attachment: trac_10508_doctest.rebased.patch and attachment: trac_10508_update_atlas_docs.rebased.patch to the Sage repository.
3. attachment: 10508_scripts.patch to local/bin.

Remove the lapack and blas packages.

Depends on #13160
Depends on #13395
Depends on #13392
Depends on #13416
Depends on #12994
Depends on #9906
Depends on #12883
Depends on #13123
Depends on #13415
Depends on #14344
Depends on #14465
Depends on #12832
Depends on #14617

Upstream: Reported upstream. No feedback yet.

CC: @dimpase @kiwifb @nexttime @kcrisman

Component: packages: standard

Keywords: ATLAS spkg

Author: Volker Braun, Jeroen Demeyer, Jean-Pierre Flori

Reviewer: Benjamin Jones, Karl-Dieter Crisman, Dmitrii Pasechnik, Georg Weber, François Bissey, John Palmieri, Volker Braun

Merged: sage-5.10.beta5

Issue created by migration from https://trac.sagemath.org/ticket/10508

[vbraun]

comment:1

Note that you cannot just use sage -f atlas-3.9.32.spkg to update atlas only. Many other spkgs use blas/lapack and must be rebuilt. The easiest way is to do a separate Sage installation...

The cvxopt spkg needs to be updated to link correctly with this atlas release, see #10509.

[dimpase]

comment:3

Does it mean that LAPACK spkg can be removed, too?

[vbraun]

comment:4

Yes, the lapack spkg can be removed.

I'm still trying to debug some issues with linbox...

[kiwifb]

comment:5

BLAS can also be removed if we go with this. f2c which was used before we got ATLAS to provide cblas by f2c-ing the BLAS
package should also be removed (I think it listed in scipy's dependency only).

[dimpase]

comment:6

on 32-bit x86 Linux (Debian squeeze) I get the following, when trying to install the spkg (applied the patches to a pristine Sage 4.6.1.alpha3):

...
make -j1 libatlas.so libptf77blas.so libf77blas.so \
                libptcblas.so libcblas.so liblapack.so
make[3]: Entering directory `/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/lib'
ld -melf_i386 -shared -soname /usr/local/src/sage/sage-4.6.1.alpha3/local/lib/libatlas.so -o libatlas.so \
           -rpath-link /usr/local/src/sage/sage-4.6.1.alpha3/local/lib \
           --whole-archive libatlas.a --no-whole-archive -lc -lm
make[3]: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'.  Stop.
make[3]: Leaving directory `/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/at
las-3.9.32/ATLAS-build/lib'
make[2]: *** [ptshared] Error 2
make[2]: Leaving directory `/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/at
las-3.9.32/ATLAS-build/lib'
Configuration:
    SAGE_LOCAL: /usr/local/src/sage/sage-4.6.1.alpha3/local
    linker_Solaris?: False
    PPC?: False
    SPKG_DIR: /usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32
    linker_GNU?: True
    ld: GNU
    system: Linux
    Darwin?: False
    machine: i686
    fortran: gfortran
    Solaris?: False
    fortran_g95?: False
    bits: 32bit
    CYGWIN?: False
    SPARC?: False
    fortran_GNU?: True
    FreeBSD?: False
    32bit?: True
    Linux?: True
    64bit?: False
    Intel?: False
    processor: 

[dimpase]

comment:7

Replying to @dimpase:

on 32-bit x86 Linux (Debian squeeze) I get the following, when trying to install the spkg (applied the patches to a pristine Sage 4.6.1.alpha3):

complete install.log is here:
http://boxen.math.washington.edu/home/dima/tmp/install-alt3.9.log.gz

[vbraun]

comment:8

Hi Dima,

I think the problem is

make[6]: Entering directory `/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/tune/sysinfo'
gcc -c -DL2SIZE=4194304 -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/include -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/../src//include -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/../src//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_CoreDuo -DATL_CPUMHZ=800 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632  -fomit-frame-pointer -O3 -mfpmath=387 -fPIC -m32 /usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/../src//tune/sysinfo/findNT.c
gcc -DL2SIZE=4194304 -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/include -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/../src//include -I/usr/local/src/sage/sage-4.6.1.alpha3/spkg/build/atlas-3.9.32/ATLAS-build/../src//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_CoreDuo -DATL_CPUMHZ=800 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632  -fomit-frame-pointer -O3 -mfpmath=387 -fPIC -m32 -o xfindNT findNT.o ATL_walltime.o -lm
/usr/lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make[6]: *** [xfindNT] Error 1

This fails because ATL_NCPU is not set. Do you have a single-core processor? I guess the threaded libraries are not built in that case.

[dimpase]

comment:9

Replying to @vbraun:

This fails because ATL_NCPU is not set. Do you have a single-core processor? I guess the threaded libraries are not built in that case.

yes, it's single-core. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)

[vbraun]

comment:10

I changed the spkg-install to make only single-threaded shared libraries if necessary. Should work now.

For simplicity, I made spkgs for cvxopts and sage_scripts. So you need to add

http://www.stp.dias.ie/~vbraun/Sage/spkg/atlas-3.9.32.spkg
http://www.stp.dias.ie/~vbraun/Sage/spkg/cvxopt-1.1.3.p0.spkg
http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.1.alpha3.p0.spkg

to $SAGE_ROOT/spkg/standard and then

• replace spkg/install with the attached version (Note that sage_scripts overwrites this file during installation, aargh)
• replace spkg/standard/deps with the attached version.

I'm still having doctest errors with linbox...

[dimpase]

comment:11

Replying to @vbraun:

I changed the spkg-install to make only single-threaded shared libraries if necessary. Should work now.

It builds OK, but then testlong gives quite a bit of failures:

The following tests failed:
        sage -t  -long -force_lib "devel/sage/doc/en/bordeaux_2008/elliptic_curves.rst"
        sage -t  -long -force_lib "devel/sage/sage/modular/modsym/space.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modsym/tests.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modsym/subspace.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modsym/ambient.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modform/space.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modform/element.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/modform/ambient.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/hecke/submodule.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/abvar/abvar.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/abvar/torsion_subgroup.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/abvar/cuspidal_subgroup.py"
        sage -t  -long -force_lib "devel/sage/sage/modular/abvar/finite_subgroup.py"
        sage -t  -long -force_lib "devel/sage/sage/matrix/matrix_integer_dense.pyx"
        sage -t  -long -force_lib "devel/sage/sage/matrix/matrix_integer_dense_hnf.py"
        sage -t  -long -force_lib "devel/sage/sage/rings/qqbar.py"
        sage -t  -long -force_lib "devel/sage/sage/finance/time_series.pyx"
        sage -t  -long -force_lib "devel/sage/sage/schemes/elliptic_curves/padic_lseries.py"
        sage -t  -long -force_lib "devel/sage/sage/schemes/elliptic_curves/ell_modular_symbols.py"
        sage -t  -long -force_lib "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
        sage -t  -long -force_lib "devel/sage/sage/schemes/elliptic_curves/sha_tate.py"
Total time for all tests: 30045.4 seconds

I do not know how many of them are Atlas related, though.
The log is here: http://boxen.math.washington.edu/home/dima/tmp/testlong-atl3.9.log

[kiwifb]

comment:12

A lot of it is probably related. Was this a build from scratch?
linbox calls seem to be particularly affected, there are a lot of failures in that
path:
sage.matrix.matrix_integer_dense.Matrix_integer_dense._charpoly_linbox
stuff going through:
sage.matrix.matrix_rational_dense.Matrix_rational_dense.right_kernel
is also affected and that smells like atlas at work too.

I must say we have observed a number of failures related to ATLAS-3.9.23 in
sage-on-gentoo:
https://github.com/cschwan/sage-on-gentoo/issues#issue/3
you have failure there too but not due to iml/ATLAS as far as I can see.
https://github.com/cschwan/sage-on-gentoo/issues#issue/6
more subtle.
I see you have the failure with devel/sage/sage/finance/time_series.pyx
you may want to look the comment I wrote about it in the section
"known test failures for Sage on Gentoo":
https://github.com/cschwan/sage-on-gentoo/wiki/Known-test-failures
note that sage-on-gentoo can use (c)blas-reference, ATLAS or gsl-cblas or some combinations - in fact amd and intel libraries could in principle be used but
no one I know has tried.
http://www.gentoo.org/proj/en/science/blas-lapack.xml

Not sure about the SIGFPE, it could come from a result rounded to 0 or the like.

[dimpase]

comment:13

Replying to @kiwifb:

A lot of it is probably related. Was this a build from scratch?

yes, it's a build from scratch, on the same machine (old Pentium M) as already discussed above.

linbox calls seem to be particularly affected, there are a lot of failures in that
path:

I wonder if these are Atlas bugs, or Linbox bugs...

One should try an OSX build.

[kiwifb]

comment:14

why OS X in particular? I could do that but not before the 5th of January, when
my university reopens. Ok I could do it before that but I'll enjoy the break a
little bit more :)

[dimpase]

comment:15

Replying to @kiwifb:

why OS X in particular? I could do that but not before the 5th of January, when
my university reopens. Ok I could do it before that but I'll enjoy the break a
little bit more :)

Or does OSX remain disabled for Atlas, i.e. it's not built?

[kiwifb]

comment:16

Replying to @dimpase:

Replying to @kiwifb:

why OS X in particular? I could do that but not before the 5th of January, when
my university reopens. Ok I could do it before that but I'll enjoy the break a
little bit more :)

Or does OSX remain disabled for Atlas, i.e. it's not built?

I had forgotten about that. I checked the spkg and ATLAS is not built on
cygwin and OS X. So it makes sense.

[vbraun]

comment:17

I get the same doctest errors. Most of them are linbox related. The SIGFPE is from converting a NAN into a GMP integer, but I haven't gotten to the root of the NAN yet. In trying to debug this I've noticed that there are a bunch of valgrind warnings in the linbox code path we are using. I've asked some more specific questions on the linbox-use mailinglist:

https://groups.google.com/d/topic/linbox-use/N3QNNOQuTAc/discussion

But so far no final conclusion.

[kiwifb]

comment:18

Replying to @dimpase:

Replying to @vbraun:

This fails because ATL_NCPU is not set. Do you have a single-core processor? I guess the threaded libraries are not built in that case.

yes, it's single-core. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)

I notice you say it is a Pentium M, yet ATLAS is compiling things
with the assumption that it is a coreduo:
-DATL_ARCH_CoreDuo -DATL_CPUMHZ=800 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632
I am guessing the speed is right but the rest is not. Was your successful build
using these parameters? I had in one instance a non-working ATLAS because the
cpu type was misdetected (wanted to use sse3 when it didn't have them). The build
was curiously successful but the library was unusable.

[dimpase]

comment:19

Replying to @kiwifb:

Replying to @dimpase:

Replying to @vbraun:

This fails because ATL_NCPU is not set. Do you have a single-core processor? I guess the threaded libraries are not built in that case.

yes, it's single-core. An old Pentium M. (Atlas 3.8 spkg does not build on it, at all)

I notice you say it is a Pentium M, yet ATLAS is compiling things
with the assumption that it is a coreduo:
-DATL_ARCH_CoreDuo -DATL_CPUMHZ=800 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632
I am guessing the speed is right but the rest is not. Was your successful build
using these parameters? I had in one instance a non-working ATLAS because the
cpu type was misdetected (wanted to use sse3 when it didn't have them). The build
was curiously successful but the library was unusable.

The processor is Pentium M
Banias 1.1GHz, http://ark.intel.com/Product.aspx?id=27600
(according to GotoBlas installation procedure :-))

The Atlas built is not totally useless, it works for many doctests.
By the way, 3.8 also thinks it's a CoreDuo. And it works. I saw somewhere a note that it's OK.

[kiwifb]

comment:20

Replying to @vbraun:

I get the same doctest errors. Most of them are linbox related. The SIGFPE is from converting a NAN into a GMP integer, but I haven't gotten to the root of the NAN yet. In trying to debug this I've noticed that there are a bunch of valgrind warnings in the linbox code path we are using. I've asked some more specific questions on the linbox-use mailinglist:

https://groups.google.com/d/topic/linbox-use/N3QNNOQuTAc/discussion

But so far no final conclusion.

Converting a NAN into a GMP integer is exactly what was happening in cschwan/sage-on-gentoo#3 and it didn't happen when using gslcblas. I will do a full build of sage-on-gentoo with 3.9.40 (or 41) and see if I can see anything.

[kiwifb]

comment:21

Yuck, still got problems leading to linbox, I got the ones leading to iml too. Note that using another cblas like gslcblas/openblas/reference(netlib) all these problems disappear which seem to indicate that there is something going on in ATLAS itself or that all the others gets it wrong (I realise that on a stock sage you may have trouble compiling iml with anything else than ATLAS, it requires some patching to the configure script to be able to do so).

[TimDumol]

comment:22

It may be worth noting that new released are available for both stable and development:

Stable
Unstable

[kiwifb]

comment:23

I have 3.9.41 now, the only difference was it compiled faster because there was tuning for my cpu. But we could investigate 3.8.4.
Thanks for pointing it is out, some of us (me at least) didn't think it would ever happen. We may have a stable ATLAS supporting newer CPUs at last, and it looks like I could test it quickly.

[kiwifb]

comment:24

OK 3.8.4 doesn't suffer from any of the drawbacks that are apparent in 3.9.23+.

The big drawback is that it doesn't build lapack nicely on its own, provided we point to the sources like the latest 3.9.xx do. That means spkg-install would need a little bit more work.

Opinions?

[vbraun]

comment:25

Can we keep this ticket focused on the development version of atlas and discuss the stable ATLAS on #10226? I updated the spkg on the latter ticket to the new stable ATLAS release.

[kiwifb]

comment:26

Sure. My current opinion and that's something I am pushing to sage-on-gentoo users is to avoid ATLAS 3.9.xx for the time being. It is possible that ATLAS-3.9.xx is doing something permissible that iml and linbox are not ready to catch. My line of thought is that I remember that some algorithm in iml takes the inverse of a result returned by cblas. If the result is 0 instead of a small value we may have our NaN, more likely some result from ATLAS is a NaN.

[jpflori]

comment:524

I tried that and it does not give any details (except that ir says that it did not find ATLAS).
Looking at configure, it searches for cblas.h that our ATLAS spkg does not install.

[jhpalmieri]

comment:525

config.log for iml with its original ./configure file (or at least with the appropriate line in spkg-install commented out). Note, by the way, that there is a "new" version of iml, 1.0.3, dating from 2008. I haven't tried using that one instead, but I don't expect it to help.

Does all of this mean that iml is completely untested in the Sage library?

[jpflori]

comment:526

Putting the header from /src/include/cblas.h in /local/lib fixes the problem.

I guess leif was lucky because he had a system-wide cblas.h?
And in previous Sage versions we must have gotten one from the reference BLAS?

And the IML install script looks quite messy...

[sagetrac-Koen]

comment:527

In the Atlas spkg-install script, there is a function configure_atlas_library
which does not specify --incdir to the configure of Atlas. That is why the header files of Atlas are not installed in sage 5.10.rc1.

[kiwifb]

comment:528

Depends what you mean by untested. There are various problems with iml. I use 1.0.3 in sage-on-gentoo but the fix we have for BLAS detection is not applicable to the sage spkg. The install script is messy because there is quite some cruft in the source and patching will require running autotools on it. IML is definitely used in the sage library and it is at least indirectly called in some doctest.

[jpflori]

comment:529

I'd also say we don't call ATLAS's Makefile install target.
Volker crafted an autotools stub to pack shared libraries and we install from there.

The easiest solution is to call ATLAS Makefile install target.
That will install headers (maybe requiring the incdir option) and static libraries which IMHO is a good idea.

[jhpalmieri]

comment:530

I've created #14699 to discuss this issue with iml and ATLAS. We should move the discussion there.

[nexttime]

comment:531

Putting the header from /src/include/cblas.h in /local/lib fixes the problem.

I guess leif was lucky because he had a system-wide cblas.h?

Of course I have it, as does sage.math (which I had checked, also for system-wide libs). I guess John was actually testing on boxen.math, which does not have it.

And the IML install script looks quite messy...

The whole [s]package is a mess, see #748.

[kiwifb]

comment:532

Replying to @nexttime:

Putting the header from /src/include/cblas.h in /local/lib fixes the problem.

I guess leif was lucky because he had a system-wide cblas.h?

Of course I have it, as does sage.math (which I had checked, also for system-wide libs). I guess John was actually testing on boxen.math, which does not have it.

And the IML install script looks quite messy...

The whole [s]package is a mess, see #748.

Ticket on which I meant to work for more than a year :(

[sagetrac-Koen]

comment:533

jpflori, the static libraries are already installed for me (this is done through an shutil.copy in configure_atlas_library). I'm unsure if the header files should be copied in a similar way, or if giving an extra option to configure will be enough.

[jdemeyer]

comment:534

Reverting this ticket: #14753.

[jdemeyer]

Changed merged from sage-5.10.beta5 to none

[jdemeyer]

Merged: sage-5.10.beta5

[jdemeyer]

comment:536

Keeping "merged in" information for future reference, we should not change this ticket further.

[jdemeyer]

comment:537

Upgrading ATLAS (again) is now #14754.