Sympow needs to disable fused-multiply-add and should create datafiles

[jdemeyer]

See #11226 and ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48823.

For sympow, we need to use the compiler option -ffp-contract=on or -mno-fused-madd (if the compiler supports it).

Sympow should also create its datafiles, see #5155.

spkg: ​http://boxen.math.washington.edu/home/jdemeyer/spkg/sympow-1.018.1.p10.spkg

[jdemeyer]

Not reported upstream because upstream project is dead (we should probably have this as an option in the "Upstream" field).

[jdemeyer]

Tested on Core2, pentium4, ia64 with fairly recent versions of gcc.

[Snark]

sympow-1.018.1.p10.spkg compiles on my ARM box.

[leif]

With GCC versions prior to 4.6, you might have to specify e.g. -fno-fused-madd instead on some platforms, so you could also check whether that's supported and use it in case it is.

[Although it's not immediately clear to me whether that's desirable at all; with (fused) multiply-accumulate, the results are more accurate than without. They'll of course frequently differ slightly from what you get with strict IEEE 754 compliance.]

spkg-install should use $MAKE instead of make.

$SAGE_LOCAL should be quoted in the generated script.

There are a few typos in the comments, e.g. "default mode of operation" and "precision" (instead of "precion").

[leif]

P.S.:

Linux silius 2.6.32.46-0.3-ppc64 #1 SMP 2011-09-29 17:49:31 +0200 ppc64 ppc64 ppc64 GNU/Linux
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.4.6/configure -v --prefix=/home/leif/local/silius/ --program-suffix=-4.4.6 --enable-languages=c,c++,fortran --enable-plugins --enable-lto --enable-gold --enable-version-specific-runtime-libs --with-cpu=power7 --with-tune=power7 --with-gmp=/home/leif/local/silius/ --with-mpfr=/home/leif/local/silius/ --with-mpc=/home/leif/local/silius/
Thread model: posix
gcc version 4.4.6 (GCC) 
****************************************************
patching file Configure
patching file generate.c
patching file fpu.c
The double precision of your FPU is 105 bits.
The Quad Double library used by SYMPOW assumes IEEE-754 double precision
numbers with exactly 53 bits in the mantissa (64 bits in total).

Unfortunately, we currently have no workaround for your system.
Running SYMPOW will surely fail. Please report this problem to
sage-devel (http://groups.google.com/group/sage-devel),
mentioning in particular your operating system, processor type
and compiler version (run gcc --version).

[leif]

With -mno-fused-add, it builds. (I get "The double precision of your FPU is 53 bits.")

[leif]

Replying to leif:

With GCC versions prior to 4.6, you might have to specify e.g. -fno-fused-madd [...]

Note that it's of course -m, not -f.

[leif]

FWIW, both with the p9 (with -O3, and without -mno-fused-madd, which is AFAIK the default) and with the p10 (with -mno-fused-madd) all (long) tests in

sage/lfunctions/sympow.py

pass. So you should probably change your check to detect whether the doubles are 64-bit / have a 53-bit mantissa.

Only the optional ones fail (differently); one has to compute extra data (with PARI/GP) for these anyway. With the p10 I get:

sage -t -long -optional "devel/sage/sage/lfunctions/sympow.py"
**********************************************************************
File ".../sage/lfunctions/sympow.py", line 127:
    sage: a = sympow.L(EllipticCurve('11a'), 2, 16); a   # optional
Expected:
    '1.057599244590958E+00'
Got:
    '-4.967915042710588E+11'
**********************************************************************
File ".../sage/lfunctions/sympow.py", line 129:
    sage: RR(a)                    # optional -- requires precomputations
Expected:
    1.05759924459096
Got:
    -4.96791504271059e11
**********************************************************************
1 items had failures:
   2 of   5 in __main__.example_4
***Test Failed*** 2 failures.
For whitespace errors, see the file /home/leif/.sage//tmp/sympow_52568.py
	 [12.7 s]

Fairly loud noise... :-)

(Might be that the data in the "manually" computed file is just wrong.)

[leif]

Replying to leif:

FWIW, both with the p9 (with -O3, and without -mno-fused-madd, which is AFAIK the default) and with the p10 (with -mno-fused-madd) all (long) tests in

sage/lfunctions/sympow.py

pass. So you should probably change your check to detect whether the doubles are 64-bit / have a 53-bit mantissa.

With the p9 (and with -mfused-add):

$ time env SAGE_TEST_ITER=20 ./sage -tp 1 -long devel/sage/sage/lfunctions/sympow.py 
Testing that Sage starts...
Yes, Sage starts.
Global iterations: 1
File iterations: 20
No long cached timings exist; will create for successful files.
Doctesting 1 file using 1 thread
sage -t -long devel/sage/sage/lfunctions/sympow.py
         [10.2 s]
 
----------------------------------------------------------------------
All tests passed!
Timings have been updated.
Total time for all tests: 232.1 seconds

real    3m54.484s
user    3m39.864s
sys     0m11.631s

With the p10:

$ time env SAGE_TEST_ITER=20 ./sage -tp 1 -long devel/sage/sage/lfunctions/sympow.py 
Testing that Sage starts...
Yes, Sage starts.
Global iterations: 1
File iterations: 20
Using long cached timings to run longest doctests first.
Doctesting 1 file using 1 thread
sage -t -long devel/sage/sage/lfunctions/sympow.py
         [11.4 s]
 
----------------------------------------------------------------------
All tests passed!
Timings have been updated.
Total time for all tests: 238.5 seconds

real    4m0.566s
user    3m44.169s
sys     0m11.777s

(Both packages compiled with -O3 -march=power7 -mtune=power7.)

[jdemeyer]

Replying to leif:

With GCC versions prior to 4.6, you might have to specify e.g. -fno-fused-madd instead on some platforms, so you could also check whether that's supported and use it in case it is.

Good point, I will add that flag.

[Although it's not immediately clear to me whether that's desirable at all; with (fused) multiply-accumulate, the results are more accurate than without. They'll of course frequently differ slightly from what you get with strict IEEE 754 compliance.]

This is certainly desirable. SYMPOW really requires strict IEEE-754 compliance, anything more precise is bad.

[jdemeyer]

Replying to leif:

FWIW, both with the p9 (with -O3, and without -mno-fused-madd, which is AFAIK the default) and with the p10 (with -mno-fused-madd) all (long) tests in

sage/lfunctions/sympow.py

pass.

The fact that all tests pass, does not necessarily mean that SYMPOW is operating correctly. It has been shown that SYMPOW sometimes computes incorrect results when fused-madd is used. I agree, this was with gcc 4.6.0 on ia64, not gcc 4.4.6 on powerpc, but still...

[jdemeyer]

Diff for the new Sympow spkg, for review only

[jdemeyer]

New spkg, builds correctly on silius, both with gcc 4.6.1 and with gcc 4.3.4. Needs review.