Lines Matching refs:to
15 satisfies a need for an easy-to-use integer benchmark; it gives a first
19 With the increasing use of the benchmark, it seems necessary to
20 reconsider the benchmark and to check whether it can still fulfill this
43 o As far as it is possible without changes to the Dhrystone statistics,
47 removal" or "dead variable elimination"). This has lead to the
58 know some suggestions for improvement, I didn't want to change the
61 outweight the benefits. If I were to write a new benchmark program, I
65 always be encouraged to use more than just one benchmark.
71 Readers who want to use the benchmark for their own measurements can
87 outside the measaurement loop. As a concession to older compilers,
93 However, it turned out that it is not enough just to inclose the main
94 procedure of Dhrystone in a loop and to measure the execution time. If
117 benchmarks. Users of the benchmark are advised to check code listings
120 Contrary to the suggestion in the published paper and its realization
121 in the versions previously distributed, no attempt has been made to
123 has proven difficult to implement in a correct way, and its omission
131 loop and that are not just renamings of variables. All remarks refer to
134 In addition to adding the measurement loop and the printout statements,
145 to Str_2_Loc (5'th statement of "main") out of the measurement loop
147 with another language and compiler.) The assignment to Int_2_Loc
148 prevents value propagation for Int_2_Loc, and the assignment to
153 loop in "main ", the role of some variables has been exchanged, to
159 parameter have changed due to changes in "main".
163 to
165 It now assigns a value to a global variable instead of a local
171 was added in the non-executed "else" part of the "if" statement, to
172 prevent the suppression of code generation for the assignment to
176 to
184 in order to prevent Int_Loc from becoming a dead variable.
186 o In Func_3, a non-executed "else" part has been added to the "if"
197 changed from local to global). The distribution statistics in the
202 not been changed, to keep the program consistent with the original
214 known to me, considerably smaller. In Ada and Pascal, assignment and
221 (ANSI C allows an implementation to use inline code for these
222 functions.) In addition to the overhead caused by additional function
225 function has to check every byte for the termination condition (the
229 "strcmp" functions helps to obtain good Dhrystone results. However, I
245 As mentioned in [1], Dhrystone was written to reflect actual
250 difference in execution time to a Dhrystone version where all
273 attempt has been made to provide a Pascal version with several
280 expansion of procedures), procedure merging is not to be used. The
284 since ANSI C allows an implementation to use inline code for these
291 It is often hard to draw an exact line between "normal code
295 benchmarking people try to achieve results that look as good as
298 times are measured. Dhrystone is not intended to be non-optimizable
299 but is intended to be similarly optimizable as normal programs. For
303 these optimizations. Therefore, no effort was made to artificially
313 "register" attribute. Good compilers should be able to make good use
318 procedure merging and/or compilation in one unit can be done to
324 In any case, for serious performance evaluation, users are advised to
325 ask for code listings and to check them carefully. In this way, when
327 feeling how much performance difference is due to compiler optimization
328 and how much is due to hardware speed.
335 very valuable contribution to the dissemination of the benchmark. I
349 Informal Distribution via "Usenet", Last Version Known to me: Sept.