Indeed quadruple precision is very very slow.
I will raise the timeout, thanks for pointing out the problem.
The output of your double tests is fine. We know some LAPACK testing are
failing to pass the threshold.
Now comparing your output, you have some differences but they are all minors.
Your LAPACK quadruple precision is ready to be used!
On Oct 3, 2011, at 12:15 AM, Alan W. Irwin wrote:
On 2011-09-29 14:40-0700 Alan W. Irwin wrote:
export FFLAGS="-O3 -fPIC -ffixed-line-length-132"
mkdir -p build_double_dir
cmake ../lapack-3.3.1_double_complex >& cmake.out
make VERBOSE=1 -j4 >& make.out
ctest >& ctest_double.out
export FFLAGS="-O3 -fPIC -fdefault-real-8 -ffixed-line-length-132"
As in the default precision case, the cmake and make steps completed
without any warning or error messages, but the ctest stage took 6000
seconds with 9 tests taking more than 100 seconds each and two of
those 9 timing out at 1500 seconds (!) On the other hand, many of the
test results completed in times comparable to the corresponding
default test times. (See the attached ctest_quadruple.out results).
So I think this approach for implementing a quadruple-precision
lapack/blas might be close to success.
Actually, the fundamental issue is that on this Intel 64-bit hardware
(uname -a identifies it as
Linux raven 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64
gfortran quadruple precision is implemented with software rather than
hardware so all the quadruple-precision tests consume roughly 100
times the cpu time of the corresponding double-precision tests. This
slowdown caused timeouts on two of the tests. If I specify a much
longer timeout limit and the verbose option to get detailed test
ctest --verbose --timeout 36000
then the 128-bit floating point and 256-bit complex tests all pass
in roughly 2 hours on this hardware.
However, "pass" is defined as a certain fraction of the tests
succeeding, and the verbose results (attached as
ctest_double_verbose.out and ctest_quadruple_verbose.out) show some
individual test failures in detail for both the double and
Could somebody take a look at those detailed test results to see if
there is anything of particular concern or have I achieved a pretty
high quality (albeit ~100 times slower than the corresponding
64-bit/128-bit float/complex results because of hardware limitations)
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
Lapack mailing list