Re: [gentoo-amd64] Possible Math Problem - Request For Verification

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

On Saturday 25 June 2011 13:41:11 Frank Peters wrote:
> Hello,
> 
> Believe it or not, at the very beginning, Linux/GNU had some math problems.
> In particular, it would do somewhat poorly on various floating point tests
> that are available on-line.  Because I do mathematical work on my machine,
> I used to regularly evaluate my software using these tests.
> 
> However, for the past several years Linux/GNU has gotten nearly perfect
> scores on these same tests and it seemed that glibc and/or gcc had finally
> gotten the math code right.  As a result of this, I stopped my regular
> evaluations of the software.
> 
> Just recently I decided to run these tests again.  I expected to see the
> same nearly perfect scores but, to my surprise, a failure occurred in the
> area of complex number operations.  This may not be a very serious failure,
> but it was not present during prior tests and thus it should not be present
> now.
> 
> Possibly a fault has crept in somewhere either in glibc or gcc.  Because
> I had stopped my regular testing I can't relate the failure to any specific
> version change of either package.
> 
> I need to request a verification from any Gentoo users.  All that needs to
> be done is run a straightforward software test.
> 
> The software is called UCBTEST and is described at http://www.netlib.org/fp/
> 
> The source code, however, is ancient Unix (1995) code and must be patched.
> I have created a patched tarball that can run on recent Linux.  This file
> is attached as ucbtest.tar.bz2
> 
> If one is accustomed to modern GUI software, this code is a mess, but it is
> rather straightforward to implement.  Here are the steps:
> 
> 1) Create a directory somewhere, e.g. /tmp/fp-test
> 
> 2) Unpack the tarball into this directory.
> 
> 3) Change into the /tmp/fp-test directory
> 
> 4) Modify the ucbREADME/linux.sh file as follows:
> 
> Line 10 -- specify a full path for the results directory -- all test results
> will be stored here -- e.g. /tmp/fp-test-results
> 
> Line 11 -- specify the full path to the Unix time program -- ucbtest won't
> run without time -- for Gentoo just "emerge time" and the path will be
> "/usr/bin/time"
> 
> Line 17 -- specify the full path to the test directory -- same as in step #1
> 
> Line 36 -- enter your CFLAGS here
> 
> That's it as far as configuration.  Now, from the top directory of the
> source just execute:
> 
> ucbREADME/linux.sh
> 
> The code will take several minutes to compile, execute, and complete.  While
> the test is running it will spit out its progress to stdout.  Upon
> completion a brief summary is given:
> 
> UCBFAIL indicates problems!
> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444
> for generic /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd
> at line 701 for double /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL
> in powd at line 701 for double /tmp/fp-test-results/clib_DP.output:UCBFAIL
> clib_DP.output , 25 out of 25 tests completed
> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444
> for generic
> 
> only 11 out of 14 show UCBPASS!
> 
> 
> There are expected failures in the trigonometric tests since trigonometric
> performance is not specified in IEEE754/854.  The failure in powd (double
> power function) is also expected.  But everything else should have passed.
> 
> In my case, the new failure occurs in the cabsd test, which is the absolute
> value for complex numbers.  I have never seen this error previously and
> it may possibly indicate some problem with either glibc or gcc.
> 
> The results directory is also a mess (someone should really clean this code
> up). In the results directory (see step #4) all detailed test results are
> contained in the *.output files.
> 
> Anyway, if anyone wants to try this test, the steps have been outlined.
> In spite of the messiness, the procedure is really quite simple, and the
> ucbtest is a very good test of floating point performance.
> 
> Frank Peters

btw, have you tried ekopath? The compiler entered portage shortly after its 
open sourcing? Maybe it is more correct. According to some it is faster than 
gcc when it comes to math heavy workloads.
-- 
#163933