1 |
On Saturday 25 June 2011 13:41:11 Frank Peters wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Believe it or not, at the very beginning, Linux/GNU had some math problems. |
5 |
> In particular, it would do somewhat poorly on various floating point tests |
6 |
> that are available on-line. Because I do mathematical work on my machine, |
7 |
> I used to regularly evaluate my software using these tests. |
8 |
> |
9 |
> However, for the past several years Linux/GNU has gotten nearly perfect |
10 |
> scores on these same tests and it seemed that glibc and/or gcc had finally |
11 |
> gotten the math code right. As a result of this, I stopped my regular |
12 |
> evaluations of the software. |
13 |
> |
14 |
> Just recently I decided to run these tests again. I expected to see the |
15 |
> same nearly perfect scores but, to my surprise, a failure occurred in the |
16 |
> area of complex number operations. This may not be a very serious failure, |
17 |
> but it was not present during prior tests and thus it should not be present |
18 |
> now. |
19 |
> |
20 |
> Possibly a fault has crept in somewhere either in glibc or gcc. Because |
21 |
> I had stopped my regular testing I can't relate the failure to any specific |
22 |
> version change of either package. |
23 |
> |
24 |
> I need to request a verification from any Gentoo users. All that needs to |
25 |
> be done is run a straightforward software test. |
26 |
> |
27 |
> The software is called UCBTEST and is described at http://www.netlib.org/fp/ |
28 |
> |
29 |
> The source code, however, is ancient Unix (1995) code and must be patched. |
30 |
> I have created a patched tarball that can run on recent Linux. This file |
31 |
> is attached as ucbtest.tar.bz2 |
32 |
> |
33 |
> If one is accustomed to modern GUI software, this code is a mess, but it is |
34 |
> rather straightforward to implement. Here are the steps: |
35 |
> |
36 |
> 1) Create a directory somewhere, e.g. /tmp/fp-test |
37 |
> |
38 |
> 2) Unpack the tarball into this directory. |
39 |
> |
40 |
> 3) Change into the /tmp/fp-test directory |
41 |
> |
42 |
> 4) Modify the ucbREADME/linux.sh file as follows: |
43 |
> |
44 |
> Line 10 -- specify a full path for the results directory -- all test results |
45 |
> will be stored here -- e.g. /tmp/fp-test-results |
46 |
> |
47 |
> Line 11 -- specify the full path to the Unix time program -- ucbtest won't |
48 |
> run without time -- for Gentoo just "emerge time" and the path will be |
49 |
> "/usr/bin/time" |
50 |
> |
51 |
> Line 17 -- specify the full path to the test directory -- same as in step #1 |
52 |
> |
53 |
> Line 36 -- enter your CFLAGS here |
54 |
> |
55 |
> That's it as far as configuration. Now, from the top directory of the |
56 |
> source just execute: |
57 |
> |
58 |
> ucbREADME/linux.sh |
59 |
> |
60 |
> The code will take several minutes to compile, execute, and complete. While |
61 |
> the test is running it will spit out its progress to stdout. Upon |
62 |
> completion a brief summary is given: |
63 |
> |
64 |
> UCBFAIL indicates problems! |
65 |
> /tmp/fp-test-results/ccos_DP.output: ucbtest UCBFAIL in COS(X) at line 444 |
66 |
> for generic /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL in cabsd |
67 |
> at line 701 for double /tmp/fp-test-results/clib_DP.output: ucbtest UCBFAIL |
68 |
> in powd at line 701 for double /tmp/fp-test-results/clib_DP.output:UCBFAIL |
69 |
> clib_DP.output , 25 out of 25 tests completed |
70 |
> /tmp/fp-test-results/csin_DP.output: ucbtest UCBFAIL in SIN(X) at line 444 |
71 |
> for generic |
72 |
> |
73 |
> only 11 out of 14 show UCBPASS! |
74 |
> |
75 |
> |
76 |
> There are expected failures in the trigonometric tests since trigonometric |
77 |
> performance is not specified in IEEE754/854. The failure in powd (double |
78 |
> power function) is also expected. But everything else should have passed. |
79 |
> |
80 |
> In my case, the new failure occurs in the cabsd test, which is the absolute |
81 |
> value for complex numbers. I have never seen this error previously and |
82 |
> it may possibly indicate some problem with either glibc or gcc. |
83 |
> |
84 |
> The results directory is also a mess (someone should really clean this code |
85 |
> up). In the results directory (see step #4) all detailed test results are |
86 |
> contained in the *.output files. |
87 |
> |
88 |
> Anyway, if anyone wants to try this test, the steps have been outlined. |
89 |
> In spite of the messiness, the procedure is really quite simple, and the |
90 |
> ucbtest is a very good test of floating point performance. |
91 |
> |
92 |
> Frank Peters |
93 |
|
94 |
btw, have you tried ekopath? The compiler entered portage shortly after its |
95 |
open sourcing? Maybe it is more correct. According to some it is faster than |
96 |
gcc when it comes to math heavy workloads. |
97 |
-- |
98 |
#163933 |