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
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
Attached Files:
-
ucbtest.tar.bz2 (508 KB)