![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to nroff.in CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / sys / nfs / TEST / unix-tests / general|
Return to nroff.in CVS log | Up to [CSRG BSD Unix] / 43BSDReno / sys / nfs / TEST / unix-tests / general |
1.1 root 1: .DA
2: .ds RF Company Confidential
3: .ds LF Sun Microsystems
4: .nr PS 12
5: .nr VS 14
6: .ps 12
7: .vs 14
8: .TL
9: Fortran Benchmarks from General Electric
10: .AU
11: Evan Adams
12: .LP
13: Walter Sawka from the New York office sent a memo
14: on June 21, 1983 detailing fortran performance.
15: It included the source and results to three fortran
16: benchmarks.
17: .LP
18: I ran the benchmarks on the following configurations:
19: .TS
20: center;
21: l l l l.
22: CPU Unix Fortran Memory
23: .sp 4p
24: Sun 1 Version 7 SVS 1 Meg
25: Sun 1.5 Sun 0.4 Berkeley 2 Meg
26: Sun 2 Sun 0.3 Berkeley 2 Meg
27: Sun 2 Sun 0.3 Berkeley/Optimizer 2 Meg
28: VAX 750 4.1cBSD Berkeley/Optimizer 4 Meg
29: .TE
30: .LP
31: The benchmarks are:
32: .IP 1)
33: Matrix inversion of double precision values.
34: .IP 2)
35: A bubble sort of integers.
36: .IP 3)
37: A prime number generator.
38: .LP
39: .TS
40: center;
41: c|c|c s|c s|
42: c|c|c s|c s|
43: c|c|c s|c s|
44: c|c|c s|c s|
45: |l|n|n|n|n|n|.
46: _ _ _ _ _
47: .sp 4p
48: Matrix Inversion Bubble Sort Prime Numbers
49: .sp 4p
50: _ _ _ _ _
51: .sp 4p
52: Dimension Number of Elements Highest N
53: .sp 4p
54: _ _ _ _ _ _
55: .sp 4p
56: Configuration 50 1000 2000 10000 50000
57: .sp 4p
58: =
59: .sp 3p
60: Version 7 91.7 23.1 88.9 24.3 180.1
61: .sp 3p
62: _
63: .sp 3p
64: Sun 1.5 74.9 29.0 112.7 49.0/28.5\(dg 290.3/188.6\(dg
65: .sp 3p
66: _
67: .sp 3p
68: Sun 2 60.5 22.8 88.0 39.1/22.7\(dg 231.4/150.6\(dg
69: .sp 3p
70: _
71: .sp 3p
72: Sun 2 (OPT) 55.9 15.8 59.9 38.3/22.7\(dg 227.6/150.6\(dg
73: .sp 3p
74: _
75: .sp 3p
76: Apollo 68000 61 30 122 19 164
77: .sp 3p
78: _
79: .sp 3p
80: Apollo DN300 51 25 94 16 130
81: .sp 3p
82: _
83: .sp 3p
84: Apollo (PE) 28 22 88 14 127
85: .sp 3p
86: _
87: .sp 3p
88: VAX (OPT) 19.3 12.1 46.4 14.5 87.2
89: .sp 3p
90: _
91: .TE
92: .LP
93: \(dg using a single precision square root function
94: .LP
95: All times are in seconds.
96: The times for the Apollo machines are from Walt's memo.
97: His memo claims the times are elapsed (wall clock) time.
98: This seems silly since most of the programs prompt for some information.
99: The times for V7 and 4.2 are user time as given by the /bin/time command.
100: The Apollo is a 68000 at 10Mhz,
101: the Apollo DN300 is a 68010 at 10MHz, and
102: the Apollo (PE) is a 68000 at 10Mhz with the performance enhancement option.
103: .LP
104: The Apollo numbers for the prime number generator
105: with a highest N of 10000 look suspect.
106: I find it difficult to believe that the Apollo (PE)
107: beat the VAX in this benchmark while it was
108: consistently beaten badly in the other benchmarks.
109: .LP
110: Berkeley fortran fared poorly in the prime number generator.
111: This program makes many calls to the square root function.
112: The square root function is part of the math library and is written
113: in C.
114: To take the square root of a single precision number
115: it is converted to doubled precision and passed to sqrt().
116: A double precision square root is calculated and returned where
117: it is promptly converted to single precision.
118: Approximately 75% of the execution time was spent in sqrt() and its
119: descendants.
120: .LP
121: I wrote a single precision sqrt() routine in
122: fortran and the prime number generator ran 43% faster on
123: the Sun 2.
124: .LP
125: The fortran optimizer mainly improves array references within
126: inner loops.
127: The bubble sort improves by 30%; the prime number generator
128: does not change at all.
129: .LP
130: It should also be noted that the system times on the 4.2 systems were
131: 2 to 7 times greater than the system times for the version 7 system.
132: On version 7, the system time averaged 2.4% of the user time.
133: On the Sun 2, the system time averaged 8.2% of the user time.
134: .SH
135: Conclusions
136: .LP
137: The same object code ran on the Sun 1.5 and the Sun 2.
138: The Sun 2 execution times averaged 20.6% less than the Sun 1.5.
139: There was speculation that the Sun 2 performance would improve
140: by as much as 30% as compared to Sun 1.5.
141: Some people may be disappointed by these numbers.
142: .LP
143: The Sun 2 with the fortran optimizer beats the best Apollo
144: time by 28% for the sorting program.
145: I believe that the Apollo performance enhancement option includes
146: hardware floating point.
147: Still, the Sun 2 is 9% slower than the Apollo DN300 on the matrix
148: inversion program and a factor of two slower on the prime number
149: generator.
150: Taking into account the double precision/single precision problem
151: for the prime number generator, the Sun 2 is 13% slower
152: than the Apollo DN300.
153: .LP
154: The fortran optimizer is still in a developement stage and
155: is not very reliable yet.
156: It is not ready for release!
157: .SH
158: Future
159: .LP
160: The benchmark numbers give us a reflection of where
161: we are at today.
162: The ultimate goal is
163: .IP 1)
164: A Sun 2 CPU,
165: .IP 2)
166: Unix 4.2BSD (not 4.1c),
167: .IP 3)
168: the SKY floating point board,
169: .IP 4)
170: the fortran optimizer,
171: .IP 5)
172: a single precision and double precision math library, and
173: .IP 6)
174: an improved fortran I/O library.
175: .LP
176: Development is in progress for everything but the libraries.
177: It is conjecture, but with each of these components in place
178: we should beat Apollo consistently.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.