3.9.3 & testing

[Clint Whaley-2]

Guys,

I have released 3.9.3.  The main new thing is that I have incorporated both
Antoine's full testing scripts and the lapack testers into the package,
so that they can be invoked as trivially as the sanity tests are now.
I include a new section from INSTALL.txt explaining the new make targets below.

I believe this will make getting a new stable release out much easier.  I was
planning to backport the new Core2 & K10h kernels to 3.8, but then I had this
idea.  What I am hoping to do now instead is to see if I can improve the
ATLAS install on Windows and OS X, and then do a new stable release.
Having these testers should also be helpful for people wanting to use
developer releases for production code . . .

Here is the ChangeLog:
ATLAS 3.9.3 released 08/13/08, Changes from 3.9.2:
   * Added much more extensive testing capability:
     - make full_test  /  make scope_full_test
       + Added Antoine's testing scripts to ATLAS.  Just do a "make full_test"
         to run them ("make full_test_nh" to use nohup for remove connection).
     - make lapack_test[a,s,f]l_[ab,sb,fb,pt] / make scope_lapack_test_?l_??
       + Runs lapack testers linked against indicated lapack & BLAS
     - See INSTALL.txt/"EXTENDED ATLAS TESTING" for further details
   * Added several missing symbols from full LAPACK build
   * Fixed it so ?lamch are compiled wt no optimization.
   * Added ATLAS/src/blas/f77reference for ease of testing.  Made it so by
     default Make.inc's FBLASlib and BLASlib macros are set to this lib.
   * Fixed errors in arch default creation for LAPACK defaults
   * Changed test in LAPACK build Makefile to get around solaris shell
     incompatibility
   * Added architectural defaults for LAPACK QR tuning for:
     - AMD64K10h32SSE3 (first time 32-bit archdefs are given for this arch)
     - AMD64K10h64SSE3
     - PPCG564AltiVec
     - Core232SSE3
     - HAMMER64SSE3

Cheers,
Clint

***************************** EXTENDED ATLAS TESTING **************************
ATLAS has two extended testers beyond the sanity checks that can be
automatically invoked from the BLDdir.  These tests are longer running and
more complex to interpret than the sanity tests, and so not every user will
want to run them.  They are particularly recommended for installers who wish
to use a developer release for production code.

--------------------------------- full_test -----------------------------------
The first is a set of testing scripts written by Antoine Petitet, that
randomly generate testcases for a host of ATLAS's testers.  This testing
phase may take as long as two days to complete (and almost always takes
at least 4 hours).  To perform this long-running test, simply issue:
   make full_test
If you are logged into the host machine remotely, chances are good your
connection will go down before the install completes.  Therefore, there is
a second command that runs these scripts in the background with a no hangup
command (so the tests will continue even if your network connection dies):
   make full_test_nh
At the completion of the tests, the extensive output files will be searched
for errors (much as with the sanity tests), and the output sent to the screen.
If you have lost this screen of data, you can regenerate it with the command:
   make scope_full_test

Running these tests will create a directory BLDdir/bin/AtlasTest where the
tester resides, and your output files will be stored a $(ARCH) subdir.
If you want to rerun the testers from scratch (rather than just searching
old output), you can simply delete the entire BLDdir/bin/AtlasTest
directory tree, and do "make full_test" again.

----------------------------- lapack_test -------------------------------------
If you have installed the full LAPACK library, then you can run the standard
lapack testers as well.  The command you give is:
   make lapack_test_[a,s,f]l_[ab,sb,fb,pt]
The first choice (choose one of three) controls which LAPACK library macro is
used in the link for testing:

   _l    LINK FOR LAPACK       Make.inc MACRO
   ==    ===================   ==============
   a     ATLAS's LAPACK        $(LAPACKlib)
   s     system LAPACK         $(SLAPACKlib)
   f     F77 reference LAPACK  $(FLAPACKlib)

The second choice (choose one of three) controls which BLAS macros are
used in the link for testing:
  _b/pt  LINK FOR BLAS           Make.inc MACRO
  ====   =====================   =========================================
  ab     ATLAS BLAS              $(F77BLASlib) $(CBLASlib) $(ATLASlib)
  sb     system BLAS             $(BLASlib)
  fb     F77 reference BLAS      $(FBLASlib)
  pt     ATLAS' threaded BLAS    $(PTF77BLASlib) $(PTCBLASlib) $(ATLASlib)

Not all of these combinations will work without user modification of Make.inc.
You will need to fill in values for
   $(BLASlib)
   $(SLAPACKlib)
   $(FLAPACKlib)
if you want to run the lapack tester against these libraries.

Usually, you will want to test your newly install ATLAS LAPACK & BLAS:
   make lapack_test_al_ab

As before, once the testing is complete, you will get the output of a search
for errors though all output files, and you can search them again with:
   make scope_lapack_test_al_ab

Unfortunately, the lapack testers always show errors on almost all platforms.
So, how do you know if you have a real error?  Real errors will usually
have residuals in the 10^6 range, rather than O(1) (smaller residuals mean
less error).  If you are unsure, the best way is to contrast ATLAS with an
all-F77 install:
   make lapack_test_fl_fb
(To run this test, you will have to build a stock netlib LAPACK library,
and fill out Make.inc's FLAPACKlib macro appropriately.)  You can then see
how the errors reported by ATLAS stack up against the all-F77 version:
if they  are roughly the same, then you are usually OK.

All the lapack testers create a directory BLDdir/bin/LAPACK_TEST.  For
each test you run there will be a subdirectory
   LAOUT_[A,S,F]L_[AB,SB,FB,PT]
where all your output files will be located.  Additionally, the results
of the scope (search for error) will be stored in
   BLDdir/bin/LAPACK_TEST/SUMMARY_<lapack>_<blas>

Therefore, a typical round of testing might be:
   make lapack_test_al_ab
   make lapack_test_fl_fb
   # compare SUMMARY_al_ab with SUMMARY_fl_fb to check for error
   make lapack_test_al_pt
   # compare SUMMARY_al_pt with SUMMARY_fl_fb to check for error in parallel lib

If you had an error, you might want to be sure the error was in ATLAS's BLAS
and not lapack, so you could do "make lapack_test_fl_ab", and see if the
error went away.  If you filled in the GotoBLAS for the SLAPACKlib & BLASlib
macros, you could scope the error properties of Goto's BLAS and LAPACK.
Many system/vendor LAPACK/BLAS do not provide all of the routines required
to run the LAPACK testers, and some ATLAS testers call ATLAS internal
routines.  Therefore, the safest thing if you have missing symbol errors
when building system/vendor tests, is to use ATLAS to pick up any missing
symbols.  For instance, here is an example Make.inc output that makes all of
ATLAS testers work with the GotoBLAS on my Athlon-64 workstation:
   BLASlib = /opt/lib/libgoto_opteronp-r1.26.a \
             $(F77BLASlib) $(CBLASlib) $(ATLASlib)
   SLAPACKlib = /opt/lib/libgoto_opteronp-r1.26.a $(FLAPACKlib)

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel