123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779 |
- # to unbundle, sh this file (in an empty directory)
- echo RATIONALE 1>&2
- sed >RATIONALE <<'//GO.SYSIN DD RATIONALE' 's/^-//'
- -
- -
- - Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules
- -
- - [published in SIGPLAN Notices 23,8 (Aug. 1988), 49-62]
- -
- -
- - Reinhold P. Weicker
- - Siemens AG, E STE 35
- - [now: Siemens AG, AUT E 51]
- - Postfach 3220
- - D-8520 Erlangen
- - Germany (West)
- -
- -
- -
- -
- -1. Why a Version 2 of Dhrystone?
- -
- -The Dhrystone benchmark program [1] has become a popular benchmark for
- -CPU/compiler performance measurement, in particular in the area of
- -minicomputers, workstations, PC's and microprocesors. It apparently satisfies
- -a need for an easy-to-use integer benchmark; it gives a first performance
- -indication which is more meaningful than MIPS numbers which, in their literal
- -meaning (million instructions per second), cannot be used across different
- -instruction sets (e.g. RISC vs. CISC). With the increasing use of the
- -benchmark, it seems necessary to reconsider the benchmark and to check whether
- -it can still fulfill this function. Version 2 of Dhrystone is the result of
- -such a re-evaluation, it has been made for two reasons:
- -
- -o Dhrystone has been published in Ada [1], and Versions in Ada, Pascal and C
- - have been distributed by Reinhold Weicker via floppy disk. However, the
- - version that was used most often for benchmarking has been the version made
- - by Rick Richardson by another translation from the Ada version into the C
- - programming language, this has been the version distributed via the UNIX
- - network Usenet [2].
- -
- - There is an obvious need for a common C version of Dhrystone, since C is at
- - present the most popular system programming language for the class of
- - systems (microcomputers, minicomputers, workstations) where Dhrystone is
- - used most. There should be, as far as possible, only one C version of
- - Dhrystone such that results can be compared without restrictions. In the
- - past, the C versions distributed by Rick Richardson (Version 1.1) and by
- - Reinhold Weicker had small (though not significant) differences.
- -
- - Together with the new C version, the Ada and Pascal versions have been
- - updated as well.
- -
- -o As far as it is possible without changes to the Dhrystone statistics,
- - optimizing compilers should be prevented from removing significant
- - statements. It has turned out in the past that optimizing compilers
- - suppressed code generation for too many statements (by "dead code removal"
- - or "dead variable elimination"). This has lead to the danger that
- - benchmarking results obtained by a naive application of Dhrystone - without
- - inspection of the code that was generated - could become meaningless.
- -
- -The overall policiy for version 2 has been that the distribution of
- -statements, operand types and operand locality described in [1] should remain
- -unchanged as much as possible. (Very few changes were necessary; their impact
- -should be negligible.) Also, the order of statements should remain unchanged.
- -Although I am aware of some critical remarks on the benchmark - I agree with
- -several of them - and know some suggestions for improvement, I didn't want to
- -change the benchmark into something different from what has become known as
- -"Dhrystone"; the confusion generated by such a change would probably outweight
- -the benefits. If I were to write a new benchmark program, I wouldn't give it
- -the name "Dhrystone" since this denotes the program published in [1].
- -However, I do recognize the need for a larger number of representative
- -programs that can be used as benchmarks; users should always be encouraged to
- -use more than just one benchmark.
- -
- -The new versions (version 2.1 for C, Pascal and Ada) will be distributed as
- -widely as possible. (Version 2.1 differs from version 2.0 distributed via the
- -UNIX Network Usenet in March 1988 only in a few corrections for minor
- -deficiencies found by users of version 2.0.) Readers who want to use the
- -benchmark for their own measurements can obtain a copy in machine-readable
- -form on floppy disk (MS-DOS or XENIX format) from the author.
- -
- -
- -2. Overall Characteristics of Version 2
- -
- -In general, version 2 follows - in the parts that are significant for
- -performance measurement, i.e. within the measurement loop - the published
- -(Ada) version and the C versions previously distributed. Where the versions
- -distributed by Rick Richardson [2] and Reinhold Weicker have been different,
- -it follows the version distributed by Reinhold Weicker. (However, the
- -differences have been so small that their impact on execution time in all
- -likelihood has been negligible.) The initialization and UNIX instrumentation
- -part - which had been omitted in [1] - follows mostly the ideas of Rick
- -Richardson [2]. However, any changes in the initialization part and in the
- -printing of the result have no impact on performance measurement since they
- -are outside the measaurement loop. As a concession to older compilers, names
- -have been made unique within the first 8 characters for the C version.
- -
- -The original publication of Dhrystone did not contain any statements for time
- -measurement since they are necessarily system-dependent. However, it turned
- -out that it is not enough just to inclose the main procedure of Dhrystone in a
- -loop and to measure the execution time. If the variables that are computed
- -are not used somehow, there is the danger that the compiler considers them as
- -"dead variables" and suppresses code generation for a part of the statements.
- -Therefore in version 2 all variables of "main" are printed at the end of the
- -program. This also permits some plausibility control for correct execution of
- -the benchmark.
- -
- -At several places in the benchmark, code has been added, but only in branches
- -that are not executed. The intention is that optimizing compilers should be
- -prevented from moving code out of the measurement loop, or from removing code
- -altogether. Statements that are executed have been changed in very few places
- -only. In these cases, only the role of some operands has been changed, and it
- -was made sure that the numbers defining the "Dhrystone distribution"
- -(distribution of statements, operand types and locality) still hold as much as
- -possible. Except for sophisticated optimizing compilers, execution times for
- -version 2.1 should be the same as for previous versions.
- -
- -Because of the self-imposed limitation that the order and distribution of the
- -executed statements should not be changed, there are still cases where
- -optimizing compilers may not generate code for some statements. To a certain
- -degree, this is unavoidable for small synthetic benchmarks. Users of the
- -benchmark are advised to check code listings whether code is generated for all
- -statements of Dhrystone.
- -
- -Contrary to the suggestion in the published paper and its realization in the
- -versions previously distributed, no attempt has been made to subtract the time
- -for the measurement loop overhead. (This calculation has proven difficult to
- -implement in a correct way, and its omission makes the program simpler.)
- -However, since the loop check is now part of the benchmark, this does have an
- -impact - though a very minor one - on the distribution statistics which have
- -been updated for this version.
- -
- -
- -3. Discussion of Individual Changes
- -
- -In this section, all changes are described that affect the measurement loop
- -and that are not just renamings of variables. All remarks refer to the C
- -version; the other language versions have been updated similarly.
- -
- -In addition to adding the measurement loop and the printout statements,
- -changes have been made at the following places:
- -
- -o In procedure "main", three statements have been added in the non-executed
- - "then" part of the statement
- -
- - if (Enum_Loc == Func_1 (Ch_Index, 'C'))
- -
- - they are
- -
- - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
- - Int_2_Loc = Run_Index;
- - Int_Glob = Run_Index;
- -
- - The string assignment prevents movement of the preceding assignment to
- - Str_2_Loc (5'th statement of "main") out of the measurement loop (This
- - probably will not happen for the C version, but it did happen with another
- - language and compiler.) The assignment to Int_2_Loc prevents value
- - propagation for Int_2_Loc, and the assignment to Int_Glob makes the value of
- - Int_Glob possibly dependent from the value of Run_Index.
- -
- -o In the three arithmetic computations at the end of the measurement loop in
- - "main ", the role of some variables has been exchanged, to prevent the
- - division from just cancelling out the multiplication as it was in [1]. A
- - very smart compiler might have recognized this and suppressed code
- - generation for the division.
- -
- -o For Proc_2, no code has been changed, but the values of the actual parameter
- - have changed due to changes in "main".
- -
- -o In Proc_4, the second assignment has been changed from
- -
- - Bool_Loc = Bool_Loc | Bool_Glob;
- -
- - to
- -
- - Bool_Glob = Bool_Loc | Bool_Glob;
- -
- - It now assigns a value to a global variable instead of a local variable
- - (Bool_Loc); Bool_Loc would be a "dead variable" which is not used
- - afterwards.
- -
- -o In Func_1, the statement
- -
- - Ch_1_Glob = Ch_1_Loc;
- -
- - was added in the non-executed "else" part of the "if" statement, to prevent
- - the suppression of code generation for the assignment to Ch_1_Loc.
- -
- -o In Func_2, the second character comparison statement has been changed to
- -
- - if (Ch_Loc == 'R')
- -
- - ('R' instead of 'X') because a comparison with 'X' is implied in the
- - preceding "if" statement.
- -
- - Also in Func_2, the statement
- -
- - Int_Glob = Int_Loc;
- -
- - has been added in the non-executed part of the last "if" statement, in order
- - to prevent Int_Loc from becoming a dead variable.
- -
- -o In Func_3, a non-executed "else" part has been added to the "if" statement.
- - While the program would not be incorrect without this "else" part, it is
- - considered bad programming practice if a function can be left without a
- - return value.
- -
- - To compensate for this change, the (non-executed) "else" part in the "if"
- - statement of Proc_3 was removed.
- -
- -The distribution statistics have been changed only by the addition of the
- -measurement loop iteration (1 additional statement, 4 additional local integer
- -operands) and by the change in Proc_4 (one operand changed from local to
- -global). The distribution statistics in the comment headers have been updated
- -accordingly.
- -
- -
- -4. String Operations
- -
- -The string operations (string assignment and string comparison) have not been
- -changed, to keep the program consistent with the original version.
- -
- -There has been some concern that the string operations are over-represented in
- -the program, and that execution time is dominated by these operations. This
- -was true in particular when optimizing compilers removed too much code in the
- -main part of the program, this should have been mitigated in version 2.
- -
- -It should be noted that this is a language-dependent issue: Dhrystone was
- -first published in Ada, and with Ada or Pascal semantics, the time spent in
- -the string operations is, at least in all implementations known to me,
- -considerably smaller. In Ada and Pascal, assignment and comparison of strings
- -are operators defined in the language, and the upper bounds of the strings
- -occuring in Dhrystone are part of the type information known at compilation
- -time. The compilers can therefore generate efficient inline code. In C,
- -string assignemt and comparisons are not part of the language, so the string
- -operations must be expressed in terms of the C library functions "strcpy" and
- -"strcmp". (ANSI C allows an implementation to use inline code for these
- -functions.) In addition to the overhead caused by additional function calls,
- -these functions are defined for null-terminated strings where the length of
- -the strings is not known at compilation time; the function has to check every
- -byte for the termination condition (the null byte).
- -
- -Obviously, a C library which includes efficiently coded "strcpy" and "strcmp"
- -functions helps to obtain good Dhrystone results. However, I don't think that
- -this is unfair since string functions do occur quite frequently in real
- -programs (editors, command interpreters, etc.). If the strings functions are
- -implemented efficiently, this helps real programs as well as benchmark
- -programs.
- -
- -I admit that the string comparison in Dhrystone terminates later (after
- -scanning 20 characters) than most string comparisons in real programs. For
- -consistency with the original benchmark, I didn't change the program despite
- -this weakness.
- -
- -
- -5. Intended Use of Dhrystone
- -
- -When Dhrystone is used, the following "ground rules" apply:
- -
- -o Separate compilation (Ada and C versions)
- -
- - As mentioned in [1], Dhrystone was written to reflect actual programming
- - practice in systems programming. The division into several compilation
- - units (5 in the Ada version, 2 in the C version) is intended, as is the
- - distribution of inter-module and intra-module subprogram calls. Although on
- - many systems there will be no difference in execution time to a Dhrystone
- - version where all compilation units are merged into one file, the rule is
- - that separate compilation should be used. The intention is that real
- - programming practice, where programs consist of several independently
- - compiled units, should be reflected. This also has implies that the
- - compiler, while compiling one unit, has no information about the use of
- - variables, register allocation etc. occuring in other compilation units.
- - Although in real life compilation units will probably be larger, the
- - intention is that these effects of separate compilation are modeled in
- - Dhrystone.
- -
- - A few language systems have post-linkage optimization available (e.g., final
- - register allocation is performed after linkage). This is a borderline case:
- - Post-linkage optimization involves additional program preparation time
- - (although not as much as compilation in one unit) which may prevent its
- - general use in practical programming. I think that since it defeats the
- - intentions given above, it should not be used for Dhrystone.
- -
- - Unfortunately, ISO/ANSI Pascal does not contain language features for
- - separate compilation. Although most commercial Pascal compilers provide
- - separate compilation in some way, we cannot use it for Dhrystone since such
- - a version would not be portable. Therefore, no attempt has been made to
- - provide a Pascal version with several compilation units.
- -
- -o No procedure merging
- -
- - Although Dhrystone contains some very short procedures where execution would
- - benefit from procedure merging (inlining, macro expansion of procedures),
- - procedure merging is not to be used. The reason is that the percentage of
- - procedure and function calls is part of the "Dhrystone distribution" of
- - statements contained in [1]. This restriction does not hold for the string
- - functions of the C version since ANSI C allows an implementation to use
- - inline code for these functions.
- -
- -o Other optimizations are allowed, but they should be indicated
- -
- - It is often hard to draw an exact line between "normal code generation" and
- - "optimization" in compilers: Some compilers perform operations by default
- - that are invoked in other compilers only when optimization is explicitly
- - requested. Also, we cannot avoid that in benchmarking people try to achieve
- - results that look as good as possible. Therefore, optimizations performed
- - by compilers - other than those listed above - are not forbidden when
- - Dhrystone execution times are measured. Dhrystone is not intended to be
- - non-optimizable but is intended to be similarly optimizable as normal
- - programs. For example, there are several places in Dhrystone where
- - performance benefits from optimizations like common subexpression
- - elimination, value propagation etc., but normal programs usually also
- - benefit from these optimizations. Therefore, no effort was made to
- - artificially prevent such optimizations. However, measurement reports
- - should indicate which compiler optimization levels have been used, and
- - reporting results with different levels of compiler optimization for the
- - same hardware is encouraged.
- -
- -o Default results are those without "register" declarations (C version)
- -
- - When Dhrystone results are quoted without additional qualification, they
- - should be understood as results obtained without use of the "register"
- - attribute. Good compilers should be able to make good use of registers even
- - without explicit register declarations ([3], p. 193).
- -
- -Of course, for experimental purposes, post-linkage optimization, procedure
- -merging and/or compilation in one unit can be done to determine their effects.
- -However, Dhrystone numbers obtained under these conditions should be
- -explicitly marked as such; "normal" Dhrystone results should be understood as
- -results obtained following the ground rules listed above.
- -
- -In any case, for serious performance evaluation, users are advised to ask for
- -code listings and to check them carefully. In this way, when results for
- -different systems are compared, the reader can get a feeling how much
- -performance difference is due to compiler optimization and how much is due to
- -hardware speed.
- -
- -
- -6. Acknowledgements
- -
- -The C version 2.1 of Dhrystone has been developed in cooperation with Rick
- -Richardson (Tinton Falls, NJ), it incorporates many ideas from the "Version
- -1.1" distributed previously by him over the UNIX network Usenet. Through his
- -activity with Usenet, Rick Richardson has made a very valuable contribution to
- -the dissemination of the benchmark. I also thank Chaim Benedelac (National
- -Semiconductor), David Ditzel (SUN), Earl Killian and John Mashey (MIPS), Alan
- -Smith and Rafael Saavedra-Barrera (UC at Berkeley) for their help with
- -comments on earlier versions of the benchmark.
- -
- -
- -7. Bibliography
- -
- -[1]
- - Reinhold P. Weicker: Dhrystone: A Synthetic Systems Programming Benchmark.
- - Communications of the ACM 27, 10 (Oct. 1984), 1013-1030
- -
- -[2]
- - Rick Richardson: Dhrystone 1.1 Benchmark Summary (and Program Text)
- - Informal Distribution via "Usenet", Last Version Known to me: Sept. 21,
- - 1987
- -
- -[3]
- - Brian W. Kernighan and Dennis M. Ritchie: The C Programming Language.
- - Prentice-Hall, Englewood Cliffs (NJ) 1978
- -
- //GO.SYSIN DD RATIONALE
- echo README_C 1>&2
- sed >README_C <<'//GO.SYSIN DD README_C' 's/^-//'
- -This "shar" file contains the documentation for the
- -electronic mail distribution of the Dhrystone benchmark (C version 2.1);
- -a companion "shar" file contains the source code.
- -(Because of mail length restrictions for some mailers, I have
- -split the distribution in two parts.)
- -
- -For versions in other languages, see the other "shar" files.
- -
- -Files containing the C version (*.h: Header File, *.c: C Modules)
- -
- - dhry.h
- - dhry_1.c
- - dhry_2.c
- -
- -The file RATIONALE contains the article
- -
- - "Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules"
- -
- -which has been published, together with the C source code (Version 2.0),
- -in SIGPLAN Notices vol. 23, no. 8 (Aug. 1988), pp. 49-62.
- -This article explains all changes that have been made for Version 2,
- -compared with the version of the original publication
- -in Communications of the ACM vol. 27, no. 10 (Oct. 1984), pp. 1013-1030.
- -It also contains "ground rules" for benchmarking with Dhrystone
- -which should be followed by everyone who uses the program and publishes
- -Dhrystone results.
- -
- -Compared with the Version 2.0 published in SIGPLAN Notices, Version 2.1
- -contains a few corrections that have been made after Version 2.0 was
- -distriobuted over the UNIX network Usenet. These small differences between
- -Version 2.0 and 2.1 should not affect execution time measurements.
- -For those who want to compare the exact contents of both versions,
- -the file "dhry_c.dif" contains the differences between the two versions,
- -as generated by a file comparison of the corresponding files with the
- -UNIX utility "diff".
- -
- -The file VARIATIONS contains the article
- -
- - "Understanding Variations in Dhrystone Performance"
- -
- -which has been published in Microprocessor Report, May 1989
- -(Editor: M. Slater), pp. 16-17. It describes the points that users
- -should know if C Dhrystone results are compared.
- -
- -Recipients of this shar file who perform measurements are asked
- -to send measurement results to the author and/or to Rick Richardson.
- -Rick Richardson publishes regularly Dhrystone results on the UNIX network
- -Usenet. For submissions of results to him (preferably by electronic mail,
- -see address in the program header), he has provided a form which is contained
- -in the file "submit.frm".
- -
- -
- -The following files are contained in other "shar" files:
- -
- -Files containing the Ada version (*.s: Specifications, *.b: Bodies):
- -
- - d_global.s
- - d_main.b
- - d_pack_1.b
- - d_pack_1.s
- - d_pack_2.b
- - d_pack_2.s
- -
- -File containing the Pascal version:
- -
- - dhry.p
- -
- -
- -February 22, 1990
- -
- - Reinhold P. Weicker
- - Siemens AG, AUT E 51
- - Postfach 3220
- - D-8520 Erlangen
- - Germany (West)
- -
- - Phone: [xxx-49]-9131-7-20330 (8-17 Central European Time)
- - UUCP: ..!mcsun!unido!estevax!weicker
- //GO.SYSIN DD README_C
- echo VARIATIONS 1>&2
- sed >VARIATIONS <<'//GO.SYSIN DD VARIATIONS' 's/^-//'
- -
- - Understanding Variations in Dhrystone Performance
- -
- -
- -
- - By Reinhold P. Weicker, Siemens AG, AUT E 51, Erlangen
- -
- -
- -
- - April 1989
- -
- -
- - This article has appeared in:
- -
- -
- - Microprocessor Report, May 1989 (Editor: M. Slater), pp. 16-17
- -
- -
- -
- -
- -Microprocessor manufacturers tend to credit all the performance measured by
- -benchmarks to the speed of their processors, they often don't even mention the
- -programming language and compiler used. In their detailed documents, usually
- -called "performance brief" or "performance report," they usually do give more
- -details. However, these details are often lost in the press releases and other
- -marketing statements. For serious performance evaluation, it is necessary to
- -study the code generated by the various compilers.
- -
- -Dhrystone was originally published in Ada (Communications of the ACM, Oct.
- -1984). However, since good Ada compilers were rare at this time and, together
- -with UNIX, C became more and more popular, the C version of Dhrystone is the
- -one now mainly used in industry. There are "official" versions 2.1 for Ada,
- -Pascal, and C, which are as close together as the languages' semantic
- -differences permit.
- -
- -Dhrystone contains two statements where the programming language and its
- -translation play a major part in the execution time measured by the benchmark:
- -
- - o String assignment (in procedure Proc_0 / main)
- - o String comparison (in function Func_2)
- -
- -In Ada and Pascal, strings are arrays of characters where the length of the
- -string is part of the type information known at compile time. In C, strings
- -are also arrays of characters, but there are no operators defined in the
- -language for assignment and comparison of strings. Instead, functions
- -"strcpy" and "strcmp" are used. These functions are defined for strings of
- -arbitrary length, and make use of the fact that strings in C have to end with
- -a terminating null byte. For general-purpose calls to these functions, the
- -implementor can assume nothing about the length and the alignment of the
- -strings involved.
- -
- -The C version of Dhrystone spends a relatively large amount of time in these
- -two functions. Some time ago, I made measurements on a VAX 11/785 with the
- -Berkeley UNIX (4.2) compilers (often-used compilers, but certainly not the
- -most advanced). In the C version, 23% of the time was spent in the string
- -functions; in the Pascal version, only 10%. On good RISC machines (where less
- -time is spent in the procedure calling sequence than on a VAX) and with better
- -optimizing compilers, the percentage is higher; MIPS has reported 34% for an
- -R3000. Because of this effect, Pascal and Ada Dhrystone results are usually
- -better than C results (except when the optimization quality of the C compiler
- -is considerably better than that of the other compilers).
- -
- -Several people have noted that the string operations are over-represented in
- -Dhrystone, mainly because the strings occurring in Dhrystone are longer than
- -average strings. I admit that this is true, and have said so in my SIGPLAN
- -Notices paper (Aug. 1988); however, I didn't want to generate confusion by
- -changing the string lengths from version 1 to version 2.
- -
- -Even if they are somewhat over-represented in Dhrystone, string operations are
- -frequent enough that it makes sense to implement them in the most efficient
- -way possible, not only for benchmarking purposes. This means that they can
- -and should be written in assembly language code. ANSI C also explicitly allows
- -the strings functions to be implemented as macros, i.e. by inline code.
- -
- -There is also a third way to speed up the "strcpy" statement in Dhrystone: For
- -this particular "strcpy" statement, the source of the assignment is a string
- -constant. Therefore, in contrast to calls to "strcpy" in the general case, the
- -compiler knows the length and alignment of the strings involved at compile
- -time and can generate code in the same efficient way as a Pascal compiler
- -(word instructions instead of byte instructions).
- -
- -This is not allowed in the case of the "strcmp" call: Here, the addresses are
- -formal procedure parameters, and no assumptions can be made about the length
- -or alignment of the strings. Any such assumptions would indicate an incorrect
- -implementation. They might work for Dhrystone, where the strings are in fact
- -word-aligned with typical compilers, but other programs would deliver
- -incorrect results.
- -
- -So, for an apple-to-apple comparison between processors, and not between
- -several possible (legal or illegal) degrees of compiler optimization, one
- -should check that the systems are comparable with respect to the following
- -three points:
- -
- - (1) String functions in assembly language vs. in C
- -
- - Frequently used functions such as the string functions can and should be
- - written in assembly language, and all serious C language systems known
- - to me do this. (I list this point for completeness only.) Note that
- - processors with an instruction that checks a word for a null byte (such
- - as AMD's 29000 and Intel's 80960) have an advantage here. (This
- - advantage decreases relatively if optimization (3) is applied.) Due to
- - the length of the strings involved in Dhrystone, this advantage may be
- - considered too high in perspective, but it is certainly legal to use
- - such instructions - after all, these situations are what they were
- - invented for.
- -
- - (2) String function code inline vs. as library functions.
- -
- - ANSI C has created a new situation, compared with the older
- - Kernighan/Ritchie C. In the original C, the definition of the string
- - function was not part of the language. Now it is, and inlining is
- - explicitly allowed. I probably should have stated more clearly in my
- - SIGPLAN Notices paper that the rule "No procedure inlining for
- - Dhrystone" referred to the user level procedures only and not to the
- - library routines.
- -
- - (3) Fixed-length and alignment assumptions for the strings
- -
- - Compilers should be allowed to optimize in these cases if (and only if)
- - it is safe to do so. For Dhrystone, this is the "strcpy" statement, but
- - not the "strcmp" statement (unless, of course, the "strcmp" code
- - explicitly checks the alignment at execution time and branches
- - accordingly). A "Dhrystone switch" for the compiler that causes the
- - generation of code that may not work under certain circumstances is
- - certainly inappropriate for comparisons. It has been reported in Usenet
- - that some C compilers provide such a compiler option; since I don't have
- - access to all C compilers involved, I cannot verify this.
- -
- - If the fixed-length and word-alignment assumption can be used, a wide
- - bus that permits fast multi-word load instructions certainly does help;
- - however, this fact by itself should not make a really big difference.
- -
- -A check of these points - something that is necessary for a thorough
- -evaluation and comparison of the Dhrystone performance claims - requires
- -object code listings as well as listings for the string functions (strcpy,
- -strcmp) that are possibly called by the program.
- -
- -I don't pretend that Dhrystone is a perfect tool to measure the integer
- -performance of microprocessors. The more it is used and discussed, the more I
- -myself learn about aspects that I hadn't noticed yet when I wrote the program.
- -And of course, the very success of a benchmark program is a danger in that
- -people may tune their compilers and/or hardware to it, and with this action
- -make it less useful.
- -
- -Whetstone and Linpack have their critical points also: The Whetstone rating
- -depends heavily on the speed of the mathematical functions (sine, sqrt, ...),
- -and Linpack is sensitive to data alignment for some cache configurations.
- -
- -Introduction of a standard set of public domain benchmark software (something
- -the SPEC effort attempts) is certainly a worthwhile thing. In the meantime,
- -people will continue to use whatever is available and widely distributed, and
- -Dhrystone ratings are probably still better than MIPS ratings if these are -
- -as often in industry - based on no reproducible derivation. However, any
- -serious performance evaluation requires more than just a comparison of raw
- -numbers; one has to make sure that the numbers have been obtained in a
- -comparable way.
- -
- //GO.SYSIN DD VARIATIONS
- echo dhry.h 1>&2
- sed >dhry.h <<'//GO.SYSIN DD dhry.h' 's/^-//'
- -/*
- - ****************************************************************************
- - *
- - * "DHRYSTONE" Benchmark Program
- - * -----------------------------
- - *
- - * Version: C, Version 2.1
- - *
- - * File: dhry.h (part 1 of 3)
- - *
- - * Date: May 25, 1988
- - *
- - * Author: Reinhold P. Weicker
- - * Siemens AG, AUT E 51
- - * Postfach 3220
- - * 8520 Erlangen
- - * Germany (West)
- - * Phone: [+49]-9131-7-20330
- - * (8-17 Central European Time)
- - * Usenet: ..!mcsun!unido!estevax!weicker
- - *
- - * Original Version (in Ada) published in
- - * "Communications of the ACM" vol. 27., no. 10 (Oct. 1984),
- - * pp. 1013 - 1030, together with the statistics
- - * on which the distribution of statements etc. is based.
- - *
- - * In this C version, the following C library functions are used:
- - * - strcpy, strcmp (inside the measurement loop)
- - * - printf, scanf (outside the measurement loop)
- - * In addition, Berkeley UNIX system calls "times ()" or "time ()"
- - * are used for execution time measurement. For measurements
- - * on other systems, these calls have to be changed.
- - *
- - * Collection of Results:
- - * Reinhold Weicker (address see above) and
- - *
- - * Rick Richardson
- - * PC Research. Inc.
- - * 94 Apple Orchard Drive
- - * Tinton Falls, NJ 07724
- - * Phone: (201) 389-8963 (9-17 EST)
- - * Usenet: ...!uunet!pcrat!rick
- - *
- - * Please send results to Rick Richardson and/or Reinhold Weicker.
- - * Complete information should be given on hardware and software used.
- - * Hardware information includes: Machine type, CPU, type and size
- - * of caches; for microprocessors: clock frequency, memory speed
- - * (number of wait states).
- - * Software information includes: Compiler (and runtime library)
- - * manufacturer and version, compilation switches, OS version.
- - * The Operating System version may give an indication about the
- - * compiler; Dhrystone itself performs no OS calls in the measurement loop.
- - *
- - * The complete output generated by the program should be mailed
- - * such that at least some checks for correctness can be made.
- - *
- - ***************************************************************************
- - *
- - * History: This version C/2.1 has been made for two reasons:
- - *
- - * 1) There is an obvious need for a common C version of
- - * Dhrystone, since C is at present the most popular system
- - * programming language for the class of processors
- - * (microcomputers, minicomputers) where Dhrystone is used most.
- - * There should be, as far as possible, only one C version of
- - * Dhrystone such that results can be compared without
- - * restrictions. In the past, the C versions distributed
- - * by Rick Richardson (Version 1.1) and by Reinhold Weicker
- - * had small (though not significant) differences.
- - *
- - * 2) As far as it is possible without changes to the Dhrystone
- - * statistics, optimizing compilers should be prevented from
- - * removing significant statements.
- - *
- - * This C version has been developed in cooperation with
- - * Rick Richardson (Tinton Falls, NJ), it incorporates many
- - * ideas from the "Version 1.1" distributed previously by
- - * him over the UNIX network Usenet.
- - * I also thank Chaim Benedelac (National Semiconductor),
- - * David Ditzel (SUN), Earl Killian and John Mashey (MIPS),
- - * Alan Smith and Rafael Saavedra-Barrera (UC at Berkeley)
- - * for their help with comments on earlier versions of the
- - * benchmark.
- - *
- - * Changes: In the initialization part, this version follows mostly
- - * Rick Richardson's version distributed via Usenet, not the
- - * version distributed earlier via floppy disk by Reinhold Weicker.
- - * As a concession to older compilers, names have been made
- - * unique within the first 8 characters.
- - * Inside the measurement loop, this version follows the
- - * version previously distributed by Reinhold Weicker.
- - *
- - * At several places in the benchmark, code has been added,
- - * but within the measurement loop only in branches that
- - * are not executed. The intention is that optimizing compilers
- - * should be prevented from moving code out of the measurement
- - * loop, or from removing code altogether. Since the statements
- - * that are executed within the measurement loop have NOT been
- - * changed, the numbers defining the "Dhrystone distribution"
- - * (distribution of statements, operand types and locality)
- - * still hold. Except for sophisticated optimizing compilers,
- - * execution times for this version should be the same as
- - * for previous versions.
- - *
- - * Since it has proven difficult to subtract the time for the
- - * measurement loop overhead in a correct way, the loop check
- - * has been made a part of the benchmark. This does have
- - * an impact - though a very minor one - on the distribution
- - * statistics which have been updated for this version.
- - *
- - * All changes within the measurement loop are described
- - * and discussed in the companion paper "Rationale for
- - * Dhrystone version 2".
- - *
- - * Because of the self-imposed limitation that the order and
- - * distribution of the executed statements should not be
- - * changed, there are still cases where optimizing compilers
- - * may not generate code for some statements. To a certain
- - * degree, this is unavoidable for small synthetic benchmarks.
- - * Users of the benchmark are advised to check code listings
- - * whether code is generated for all statements of Dhrystone.
- - *
- - * Version 2.1 is identical to version 2.0 distributed via
- - * the UNIX network Usenet in March 1988 except that it corrects
- - * some minor deficiencies that were found by users of version 2.0.
- - * The only change within the measurement loop is that a
- - * non-executed "else" part was added to the "if" statement in
- - * Func_3, and a non-executed "else" part removed from Proc_3.
- - *
- - ***************************************************************************
- - *
- - * Defines: The following "Defines" are possible:
- - * -DREG=register (default: Not defined)
- - * As an approximation to what an average C programmer
- - * might do, the "register" storage class is applied
- - * (if enabled by -DREG=register)
- - * - for local variables, if they are used (dynamically)
- - * five or more times
- - * - for parameters if they are used (dynamically)
- - * six or more times
- - * Note that an optimal "register" strategy is
- - * compiler-dependent, and that "register" declarations
- - * do not necessarily lead to faster execution.
- - * -DNOSTRUCTASSIGN (default: Not defined)
- - * Define if the C compiler does not support
- - * assignment of structures.
- - * -DNOENUMS (default: Not defined)
- - * Define if the C compiler does not support
- - * enumeration types.
- - * -DTIMES (default)
- - * -DTIME
- - * The "times" function of UNIX (returning process times)
- - * or the "time" function (returning wallclock time)
- - * is used for measurement.
- - * For single user machines, "time ()" is adequate. For
- - * multi-user machines where you cannot get single-user
- - * access, use the "times ()" function. If you have
- - * neither, use a stopwatch in the dead of night.
- - * "printf"s are provided marking the points "Start Timer"
- - * and "Stop Timer". DO NOT use the UNIX "time(1)"
- - * command, as this will measure the total time to
- - * run this program, which will (erroneously) include
- - * the time to allocate storage (malloc) and to perform
- - * the initialization.
- - * -DHZ=nnn
- - * In Berkeley UNIX, the function "times" returns process
- - * time in 1/HZ seconds, with HZ = 60 for most systems.
- - * CHECK YOUR SYSTEM DESCRIPTION BEFORE YOU JUST APPLY
- - * A VALUE.
- - *
- - ***************************************************************************
- - *
- - * Compilation model and measurement (IMPORTANT):
- - *
- - * This C version of Dhrystone consists of three files:
- - * - dhry.h (this file, containing global definitions and comments)
- - * - dhry_1.c (containing the code corresponding to Ada package Pack_1)
- - * - dhry_2.c (containing the code corresponding to Ada package Pack_2)
- - *
- - * The following "ground rules" apply for measurements:
- - * - Separate compilation
- - * - No procedure merging
- - * - Otherwise, compiler optimizations are allowed but should be indicated
- - * - Default results are those without register declarations
- - * See the companion paper "Rationale for Dhrystone Version 2" for a more
- - * detailed discussion of these ground rules.
- - *
- - * For 16-Bit processors (e.g. 80186, 80286), times for all compilation
- - * models ("small", "medium", "large" etc.) should be given if possible,
- - * together with a definition of these models for the compiler system used.
- - *
- - **************************************************************************
- - *
- - * Dhrystone (C version) statistics:
- - *
- - * [Comment from the first distribution, updated for version 2.
- - * Note that because of language differences, the numbers are slightly
- - * different from the Ada version.]
- - *
- - * The following program contains statements of a high level programming
- - * language (here: C) in a distribution considered representative:
- - *
- - * assignments 52 (51.0 %)
- - * control statements 33 (32.4 %)
- - * procedure, function calls 17 (16.7 %)
- - *
- - * 103 statements are dynamically executed. The program is balanced with
- - * respect to the three aspects:
- - *
- - * - statement type
- - * - operand type
- - * - operand locality
- - * operand global, local, parameter, or constant.
- - *
- - * The combination of these three aspects is balanced only approximately.
- - *
- - * 1. Statement Type:
- - * ----------------- number
- - *
- - * V1 = V2 9
- - * (incl. V1 = F(..)
- - * V = Constant 12
- - * Assignment, 7
- - * with array element
- - * Assignment, 6
- - * with record component
- - * --
- - * 34 34
- - *
- - * X = Y +|-|"&&"|"|" Z 5
- - * X = Y +|-|"==" Constant 6
- - * X = X +|- 1 3
- - * X = Y *|/ Z 2
- - * X = Expression, 1
- - * two operators
- - * X = Expression, 1
- - * three operators
- - * --
- - * 18 18
- - *
- - * if .... 14
- - * with "else" 7
- - * without "else" 7
- - * executed 3
- - * not executed 4
- - * for ... 7 | counted every time
- - * while ... 4 | the loop condition
- - * do ... while 1 | is evaluated
- - * switch ... 1
- - * break 1
- - * declaration with 1
- - * initialization
- - * --
- - * 34 34
- - *
- - * P (...) procedure call 11
- - * user procedure 10
- - * library procedure 1
- - * X = F (...)
- - * function call 6
- - * user function 5
- - * library function 1
- - * --
- - * 17 17
- - * ---
- - * 103
- - *
- - * The average number of parameters in procedure or function calls
- - * is 1.82 (not counting the function values as implicit parameters).
- - *
- - *
- - * 2. Operators
- - * ------------
- - * number approximate
- - * percentage
- - *
- - * Arithmetic 32 50.8
- - *
- - * + 21 33.3
- - * - 7 11.1
- - * * 3 4.8
- - * / (int div) 1 1.6
- - *
- - * Comparison 27 42.8
- - *
- - * == 9 14.3
- - * /= 4 6.3
- - * > 1 1.6
- - * < 3 4.8
- - * >= 1 1.6
- - * <= 9 14.3
- - *
- - * Logic 4 6.3
- - *
- - * && (AND-THEN) 1 1.6
- - * | (OR) 1 1.6
- - * ! (NOT) 2 3.2
- - *
- - * -- -----
- - * 63 100.1
- - *
- - *
- - * 3. Operand Type (counted once per operand reference):
- - * ---------------
- - * number approximate
- - * percentage
- - *
- - * Integer 175 72.3 %
- - * Character 45 18.6 %
- - * Pointer 12 5.0 %
- - * String30 6 2.5 %
- - * Array 2 0.8 %
- - * Record 2 0.8 %
- - * --- -------
- - * 242 100.0 %
- - *
- - * When there is an access path leading to the final operand (e.g. a record
- - * component), only the final data type on the access path is counted.
- - *
- - *
- - * 4. Operand Locality:
- - * -------------------
- - * number approximate
- - * percentage
- - *
- - * local variable 114 47.1 %
- - * global variable 22 9.1 %
- - * parameter 45 18.6 %
- - * value 23 9.5 %
- - * reference 22 9.1 %
- - * function result 6 2.5 %
- - * constant 55 22.7 %
- - * --- -------
- - * 242 100.0 %
- - *
- - *
- - * The program does not compute anything meaningful, but it is syntactically
- - * and semantically correct. All variables have a value assigned to them
- - * before they are used as a source operand.
- - *
- - * There has been no explicit effort to account for the effects of a
- - * cache, or to balance the use of long or short displacements for code or
- - * data.
- - *
- - ***************************************************************************
- - */
- -
- -/* Compiler and system dependent definitions: */
- -
- -#ifndef TIME
- -#define TIMES
- -#endif
- - /* Use times(2) time function unless */
- - /* explicitly defined otherwise */
- -
- -#ifdef TIMES
- -#include <sys/types.h>
- -#include <sys/times.h>
- - /* for "times" */
- -#endif
- -
- -#define Mic_secs_Per_Second 1000000.0
- - /* Berkeley UNIX C returns process times in seconds/HZ */
- -
- -#ifdef NOSTRUCTASSIGN
- -#define structassign(d, s) memcpy(&(d), &(s), sizeof(d))
- -#else
- -#define structassign(d, s) d = s
- -#endif
- -
- -#ifdef NOENUM
- -#define Ident_1 0
- -#define Ident_2 1
- -#define Ident_3 2
- -#define Ident_4 3
- -#define Ident_5 4
- - typedef int Enumeration;
- -#else
- - typedef enum {Ident_1, Ident_2, Ident_3, Ident_4, Ident_5}
- - Enumeration;
- -#endif
- - /* for boolean and enumeration types in Ada, Pascal */
- -
- -/* General definitions: */
- -
- -#include <stdio.h>
- - /* for strcpy, strcmp */
- -
- -#define Null 0
- - /* Value of a Null pointer */
- -#define true 1
- -#define false 0
- -
- -typedef int One_Thirty;
- -typedef int One_Fifty;
- -typedef char Capital_Letter;
- -typedef int Boolean;
- -typedef char Str_30 [31];
- -typedef int Arr_1_Dim [50];
- -typedef int Arr_2_Dim [50] [50];
- -
- -typedef struct record
- - {
- - struct record *Ptr_Comp;
- - Enumeration Discr;
- - union {
- - struct {
- - Enumeration Enum_Comp;
- - int Int_Comp;
- - char Str_Comp [31];
- - } var_1;
- - struct {
- - Enumeration E_Comp_2;
- - char Str_2_Comp [31];
- - } var_2;
- - struct {
- - char Ch_1_Comp;
- - char Ch_2_Comp;
- - } var_3;
- - } variant;
- - } Rec_Type, *Rec_Pointer;
- -
- -
- //GO.SYSIN DD dhry.h
- echo dhry_1.c 1>&2
- sed >dhry_1.c <<'//GO.SYSIN DD dhry_1.c' 's/^-//'
- -/*
- - ****************************************************************************
- - *
- - * "DHRYSTONE" Benchmark Program
- - * -----------------------------
- - *
- - * Version: C, Version 2.1
- - *
- - * File: dhry_1.c (part 2 of 3)
- - *
- - * Date: May 25, 1988
- - *
- - * Author: Reinhold P. Weicker
- - *
- - ****************************************************************************
- - */
- -
- -#include "dhry.h"
- -
- -/* Global Variables: */
- -
- -Rec_Pointer Ptr_Glob,
- - Next_Ptr_Glob;
- -int Int_Glob;
- -Boolean Bool_Glob;
- -char Ch_1_Glob,
- - Ch_2_Glob;
- -int Arr_1_Glob [50];
- -int Arr_2_Glob [50] [50];
- -
- -extern char *malloc ();
- -Enumeration Func_1 ();
- - /* forward declaration necessary since Enumeration may not simply be int */
- -
- -#ifndef REG
- - Boolean Reg = false;
- -#define REG
- - /* REG becomes defined as empty */
- - /* i.e. no register variables */
- -#else
- - Boolean Reg = true;
- -#endif
- -
- -/* variables for time measurement: */
- -
- -#ifdef TIMES
- -struct tms time_info;
- -extern int times ();
- - /* see library function "times" */
- -#define Too_Small_Time 120
- - /* Measurements should last at least about 2 seconds */
- -#endif
- -#ifdef TIME
- -extern long time();
- - /* see library function "time" */
- -#define Too_Small_Time 2
- - /* Measurements should last at least 2 seconds */
- -#endif
- -
- -long Begin_Time,
- - End_Time,
- - User_Time;
- -float Microseconds,
- - Dhrystones_Per_Second;
- -
- -/* end of variables for time measurement */
- -
- -
- -main ()
- -/*****/
- -
- - /* main program, corresponds to procedures */
- - /* Main and Proc_0 in the Ada version */
- -{
- - One_Fifty Int_1_Loc;
- - REG One_Fifty Int_2_Loc;
- - One_Fifty Int_3_Loc;
- - REG char Ch_Index;
- - Enumeration Enum_Loc;
- - Str_30 Str_1_Loc;
- - Str_30 Str_2_Loc;
- - REG int Run_Index;
- - REG int Number_Of_Runs;
- -
- - /* Initializations */
- -
- - Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
- - Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
- -
- - Ptr_Glob->Ptr_Comp = Next_Ptr_Glob;
- - Ptr_Glob->Discr = Ident_1;
- - Ptr_Glob->variant.var_1.Enum_Comp = Ident_3;
- - Ptr_Glob->variant.var_1.Int_Comp = 40;
- - strcpy (Ptr_Glob->variant.var_1.Str_Comp,
- - "DHRYSTONE PROGRAM, SOME STRING");
- - strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
- -
- - Arr_2_Glob [8][7] = 10;
- - /* Was missing in published program. Without this statement, */
- - /* Arr_2_Glob [8][7] would have an undefined value. */
- - /* Warning: With 16-Bit processors and Number_Of_Runs > 32000, */
- - /* overflow may occur for this array element. */
- -
- - printf ("\n");
- - printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
- - printf ("\n");
- - if (Reg)
- - {
- - printf ("Program compiled with 'register' attribute\n");
- - printf ("\n");
- - }
- - else
- - {
- - printf ("Program compiled without 'register' attribute\n");
- - printf ("\n");
- - }
- - printf ("Please give the number of runs through the benchmark: ");
- - {
- - int n;
- - scanf ("%d", &n);
- - Number_Of_Runs = n;
- - }
- - printf ("\n");
- -
- - printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);
- -
- - /***************/
- - /* Start timer */
- - /***************/
- -
- -#ifdef TIMES
- - times (&time_info);
- - Begin_Time = (long) time_info.tms_utime;
- -#endif
- -#ifdef TIME
- - Begin_Time = time ( (long *) 0);
- -#endif
- -
- - for (Run_Index = 1; Run_Index <= Number_Of_Runs; ++Run_Index)
- - {
- -
- - Proc_5();
- - Proc_4();
- - /* Ch_1_Glob == 'A', Ch_2_Glob == 'B', Bool_Glob == true */
- - Int_1_Loc = 2;
- - Int_2_Loc = 3;
- - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 2'ND STRING");
- - Enum_Loc = Ident_2;
- - Bool_Glob = ! Func_2 (Str_1_Loc, Str_2_Loc);
- - /* Bool_Glob == 1 */
- - while (Int_1_Loc < Int_2_Loc) /* loop body executed once */
- - {
- - Int_3_Loc = 5 * Int_1_Loc - Int_2_Loc;
- - /* Int_3_Loc == 7 */
- - Proc_7 (Int_1_Loc, Int_2_Loc, &Int_3_Loc);
- - /* Int_3_Loc == 7 */
- - Int_1_Loc += 1;
- - } /* while */
- - /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
- - Proc_8 (Arr_1_Glob, Arr_2_Glob, Int_1_Loc, Int_3_Loc);
- - /* Int_Glob == 5 */
- - Proc_1 (Ptr_Glob);
- - for (Ch_Index = 'A'; Ch_Index <= Ch_2_Glob; ++Ch_Index)
- - /* loop body executed twice */
- - {
- - if (Enum_Loc == Func_1 (Ch_Index, 'C'))
- - /* then, not executed */
- - {
- - Proc_6 (Ident_1, &Enum_Loc);
- - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
- - Int_2_Loc = Run_Index;
- - Int_Glob = Run_Index;
- - }
- - }
- - /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
- - Int_2_Loc = Int_2_Loc * Int_1_Loc;
- - Int_1_Loc = Int_2_Loc / Int_3_Loc;
- - Int_2_Loc = 7 * (Int_2_Loc - Int_3_Loc) - Int_1_Loc;
- - /* Int_1_Loc == 1, Int_2_Loc == 13, Int_3_Loc == 7 */
- - Proc_2 (&Int_1_Loc);
- - /* Int_1_Loc == 5 */
- -
- - } /* loop "for Run_Index" */
- -
- - /**************/
- - /* Stop timer */
- - /**************/
- -
- -#ifdef TIMES
- - times (&time_info);
- - End_Time = (long) time_info.tms_utime;
- -#endif
- -#ifdef TIME
- - End_Time = time ( (long *) 0);
- -#endif
- -
- - printf ("Execution ends\n");
- - printf ("\n");
- - printf ("Final values of the variables used in the benchmark:\n");
- - printf ("\n");
- - printf ("Int_Glob: %d\n", Int_Glob);
- - printf (" should be: %d\n", 5);
- - printf ("Bool_Glob: %d\n", Bool_Glob);
- - printf (" should be: %d\n", 1);
- - printf ("Ch_1_Glob: %c\n", Ch_1_Glob);
- - printf (" should be: %c\n", 'A');
- - printf ("Ch_2_Glob: %c\n", Ch_2_Glob);
- - printf (" should be: %c\n", 'B');
- - printf ("Arr_1_Glob[8]: %d\n", Arr_1_Glob[8]);
- - printf (" should be: %d\n", 7);
- - printf ("Arr_2_Glob[8][7]: %d\n", Arr_2_Glob[8][7]);
- - printf (" should be: Number_Of_Runs + 10\n");
- - printf ("Ptr_Glob->\n");
- - printf (" Ptr_Comp: %d\n", (int) Ptr_Glob->Ptr_Comp);
- - printf (" should be: (implementation-dependent)\n");
- - printf (" Discr: %d\n", Ptr_Glob->Discr);
- - printf (" should be: %d\n", 0);
- - printf (" Enum_Comp: %d\n", Ptr_Glob->variant.var_1.Enum_Comp);
- - printf (" should be: %d\n", 2);
- - printf (" Int_Comp: %d\n", Ptr_Glob->variant.var_1.Int_Comp);
- - printf (" should be: %d\n", 17);
- - printf (" Str_Comp: %s\n", Ptr_Glob->variant.var_1.Str_Comp);
- - printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
- - printf ("Next_Ptr_Glob->\n");
- - printf (" Ptr_Comp: %d\n", (int) Next_Ptr_Glob->Ptr_Comp);
- - printf (" should be: (implementation-dependent), same as above\n");
- - printf (" Discr: %d\n", Next_Ptr_Glob->Discr);
- - printf (" should be: %d\n", 0);
- - printf (" Enum_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Enum_Comp);
- - printf (" should be: %d\n", 1);
- - printf (" Int_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Int_Comp);
- - printf (" should be: %d\n", 18);
- - printf (" Str_Comp: %s\n",
- - Next_Ptr_Glob->variant.var_1.Str_Comp);
- - printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
- - printf ("Int_1_Loc: %d\n", Int_1_Loc);
- - printf (" should be: %d\n", 5);
- - printf ("Int_2_Loc: %d\n", Int_2_Loc);
- - printf (" should be: %d\n", 13);
- - printf ("Int_3_Loc: %d\n", Int_3_Loc);
- - printf (" should be: %d\n", 7);
- - printf ("Enum_Loc: %d\n", Enum_Loc);
- - printf (" should be: %d\n", 1);
- - printf ("Str_1_Loc: %s\n", Str_1_Loc);
- - printf (" should be: DHRYSTONE PROGRAM, 1'ST STRING\n");
- - printf ("Str_2_Loc: %s\n", Str_2_Loc);
- - printf (" should be: DHRYSTONE PROGRAM, 2'ND STRING\n");
- - printf ("\n");
- -
- - User_Time = End_Time - Begin_Time;
- -
- - if (User_Time < Too_Small_Time)
- - {
- - printf ("Measured time too small to obtain meaningful results\n");
- - printf ("Please increase number of runs\n");
- - printf ("\n");
- - }
- - else
- - {
- -#ifdef TIME
- - Microseconds = (float) User_Time * Mic_secs_Per_Second
- - / (float) Number_Of_Runs;
- - Dhrystones_Per_Second = (float) Number_Of_Runs / (float) User_Time;
- -#else
- - Microseconds = (float) User_Time * Mic_secs_Per_Second
- - / ((float) HZ * ((float) Number_Of_Runs));
- - Dhrystones_Per_Second = ((float) HZ * (float) Number_Of_Runs)
- - / (float) User_Time;
- -#endif
- - printf ("Microseconds for one run through Dhrystone: ");
- - printf ("%6.1f \n", Microseconds);
- - printf ("Dhrystones per Second: ");
- - printf ("%6.1f \n", Dhrystones_Per_Second);
- - printf ("\n");
- - }
- -
- -}
- -
- -
- -Proc_1 (Ptr_Val_Par)
- -/******************/
- -
- -REG Rec_Pointer Ptr_Val_Par;
- - /* executed once */
- -{
- - REG Rec_Pointer Next_Record = Ptr_Val_Par->Ptr_Comp;
- - /* == Ptr_Glob_Next */
- - /* Local variable, initialized with Ptr_Val_Par->Ptr_Comp, */
- - /* corresponds to "rename" in Ada, "with" in Pascal */
- -
- - structassign (*Ptr_Val_Par->Ptr_Comp, *Ptr_Glob);
- - Ptr_Val_Par->variant.var_1.Int_Comp = 5;
- - Next_Record->variant.var_1.Int_Comp
- - = Ptr_Val_Par->variant.var_1.Int_Comp;
- - Next_Record->Ptr_Comp = Ptr_Val_Par->Ptr_Comp;
- - Proc_3 (&Next_Record->Ptr_Comp);
- - /* Ptr_Val_Par->Ptr_Comp->Ptr_Comp
- - == Ptr_Glob->Ptr_Comp */
- - if (Next_Record->Discr == Ident_1)
- - /* then, executed */
- - {
- - Next_Record->variant.var_1.Int_Comp = 6;
- - Proc_6 (Ptr_Val_Par->variant.var_1.Enum_Comp,
- - &Next_Record->variant.var_1.Enum_Comp);
- - Next_Record->Ptr_Comp = Ptr_Glob->Ptr_Comp;
- - Proc_7 (Next_Record->variant.var_1.Int_Comp, 10,
- - &Next_Record->variant.var_1.Int_Comp);
- - }
- - else /* not executed */
- - structassign (*Ptr_Val_Par, *Ptr_Val_Par->Ptr_Comp);
- -} /* Proc_1 */
- -
- -
- -Proc_2 (Int_Par_Ref)
- -/******************/
- - /* executed once */
- - /* *Int_Par_Ref == 1, becomes 4 */
- -
- -One_Fifty *Int_Par_Ref;
- -{
- - One_Fifty Int_Loc;
- - Enumeration Enum_Loc;
- -
- - Int_Loc = *Int_Par_Ref + 10;
- - do /* executed once */
- - if (Ch_1_Glob == 'A')
- - /* then, executed */
- - {
- - Int_Loc -= 1;
- - *Int_Par_Ref = Int_Loc - Int_Glob;
- - Enum_Loc = Ident_1;
- - } /* if */
- - while (Enum_Loc != Ident_1); /* true */
- -} /* Proc_2 */
- -
- -
- -Proc_3 (Ptr_Ref_Par)
- -/******************/
- - /* executed once */
- - /* Ptr_Ref_Par becomes Ptr_Glob */
- -
- -Rec_Pointer *Ptr_Ref_Par;
- -
- -{
- - if (Ptr_Glob != Null)
- - /* then, executed */
- - *Ptr_Ref_Par = Ptr_Glob->Ptr_Comp;
- - Proc_7 (10, Int_Glob, &Ptr_Glob->variant.var_1.Int_Comp);
- -} /* Proc_3 */
- -
- -
- -Proc_4 () /* without parameters */
- -/*******/
- - /* executed once */
- -{
- - Boolean Bool_Loc;
- -
- - Bool_Loc = Ch_1_Glob == 'A';
- - Bool_Glob = Bool_Loc | Bool_Glob;
- - Ch_2_Glob = 'B';
- -} /* Proc_4 */
- -
- -
- -Proc_5 () /* without parameters */
- -/*******/
- - /* executed once */
- -{
- - Ch_1_Glob = 'A';
- - Bool_Glob = false;
- -} /* Proc_5 */
- -
- -
- - /* Procedure for the assignment of structures, */
- - /* if the C compiler doesn't support this feature */
- -#ifdef NOSTRUCTASSIGN
- -memcpy (d, s, l)
- -register char *d;
- -register char *s;
- -register int l;
- -{
- - while (l--) *d++ = *s++;
- -}
- -#endif
- -
- -
- //GO.SYSIN DD dhry_1.c
- echo dhry_2.c 1>&2
- sed >dhry_2.c <<'//GO.SYSIN DD dhry_2.c' 's/^-//'
- -/*
- - ****************************************************************************
- - *
- - * "DHRYSTONE" Benchmark Program
- - * -----------------------------
- - *
- - * Version: C, Version 2.1
- - *
- - * File: dhry_2.c (part 3 of 3)
- - *
- - * Date: May 25, 1988
- - *
- - * Author: Reinhold P. Weicker
- - *
- - ****************************************************************************
- - */
- -
- -#include "dhry.h"
- -
- -#ifndef REG
- -#define REG
- - /* REG becomes defined as empty */
- - /* i.e. no register variables */
- -#endif
- -
- -extern int Int_Glob;
- -extern char Ch_1_Glob;
- -
- -
- -Proc_6 (Enum_Val_Par, Enum_Ref_Par)
- -/*********************************/
- - /* executed once */
- - /* Enum_Val_Par == Ident_3, Enum_Ref_Par becomes Ident_2 */
- -
- -Enumeration Enum_Val_Par;
- -Enumeration *Enum_Ref_Par;
- -{
- - *Enum_Ref_Par = Enum_Val_Par;
- - if (! Func_3 (Enum_Val_Par))
- - /* then, not executed */
- - *Enum_Ref_Par = Ident_4;
- - switch (Enum_Val_Par)
- - {
- - case Ident_1:
- - *Enum_Ref_Par = Ident_1;
- - break;
- - case Ident_2:
- - if (Int_Glob > 100)
- - /* then */
- - *Enum_Ref_Par = Ident_1;
- - else *Enum_Ref_Par = Ident_4;
- - break;
- - case Ident_3: /* executed */
- - *Enum_Ref_Par = Ident_2;
- - break;
- - case Ident_4: break;
- - case Ident_5:
- - *Enum_Ref_Par = Ident_3;
- - break;
- - } /* switch */
- -} /* Proc_6 */
- -
- -
- -Proc_7 (Int_1_Par_Val, Int_2_Par_Val, Int_Par_Ref)
- -/**********************************************/
- - /* executed three times */
- - /* first call: Int_1_Par_Val == 2, Int_2_Par_Val == 3, */
- - /* Int_Par_Ref becomes 7 */
- - /* second call: Int_1_Par_Val == 10, Int_2_Par_Val == 5, */
- - /* Int_Par_Ref becomes 17 */
- - /* third call: Int_1_Par_Val == 6, Int_2_Par_Val == 10, */
- - /* Int_Par_Ref becomes 18 */
- -One_Fifty Int_1_Par_Val;
- -One_Fifty Int_2_Par_Val;
- -One_Fifty *Int_Par_Ref;
- -{
- - One_Fifty Int_Loc;
- -
- - Int_Loc = Int_1_Par_Val + 2;
- - *Int_Par_Ref = Int_2_Par_Val + Int_Loc;
- -} /* Proc_7 */
- -
- -
- -Proc_8 (Arr_1_Par_Ref, Arr_2_Par_Ref, Int_1_Par_Val, Int_2_Par_Val)
- -/*********************************************************************/
- - /* executed once */
- - /* Int_Par_Val_1 == 3 */
- - /* Int_Par_Val_2 == 7 */
- -Arr_1_Dim Arr_1_Par_Ref;
- -Arr_2_Dim Arr_2_Par_Ref;
- -int Int_1_Par_Val;
- -int Int_2_Par_Val;
- -{
- - REG One_Fifty Int_Index;
- - REG One_Fifty Int_Loc;
- -
- - Int_Loc = Int_1_Par_Val + 5;
- - Arr_1_Par_Ref [Int_Loc] = Int_2_Par_Val;
- - Arr_1_Par_Ref [Int_Loc+1] = Arr_1_Par_Ref [Int_Loc];
- - Arr_1_Par_Ref [Int_Loc+30] = Int_Loc;
- - for (Int_Index = Int_Loc; Int_Index <= Int_Loc+1; ++Int_Index)
- - Arr_2_Par_Ref [Int_Loc] [Int_Index] = Int_Loc;
- - Arr_2_Par_Ref [Int_Loc] [Int_Loc-1] += 1;
- - Arr_2_Par_Ref [Int_Loc+20] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
- - Int_Glob = 5;
- -} /* Proc_8 */
- -
- -
- -Enumeration Func_1 (Ch_1_Par_Val, Ch_2_Par_Val)
- -/*************************************************/
- - /* executed three times */
- - /* first call: Ch_1_Par_Val == 'H', Ch_2_Par_Val == 'R' */
- - /* second call: Ch_1_Par_Val == 'A', Ch_2_Par_Val == 'C' */
- - /* third call: Ch_1_Par_Val == 'B', Ch_2_Par_Val == 'C' */
- -
- -Capital_Letter Ch_1_Par_Val;
- -Capital_Letter Ch_2_Par_Val;
- -{
- - Capital_Letter Ch_1_Loc;
- - Capital_Letter Ch_2_Loc;
- -
- - Ch_1_Loc = Ch_1_Par_Val;
- - Ch_2_Loc = Ch_1_Loc;
- - if (Ch_2_Loc != Ch_2_Par_Val)
- - /* then, executed */
- - return (Ident_1);
- - else /* not executed */
- - {
- - Ch_1_Glob = Ch_1_Loc;
- - return (Ident_2);
- - }
- -} /* Func_1 */
- -
- -
- -Boolean Func_2 (Str_1_Par_Ref, Str_2_Par_Ref)
- -/*************************************************/
- - /* executed once */
- - /* Str_1_Par_Ref == "DHRYSTONE PROGRAM, 1'ST STRING" */
- - /* Str_2_Par_Ref == "DHRYSTONE PROGRAM, 2'ND STRING" */
- -
- -Str_30 Str_1_Par_Ref;
- -Str_30 Str_2_Par_Ref;
- -{
- - REG One_Thirty Int_Loc;
- - Capital_Letter Ch_Loc;
- -
- - Int_Loc = 2;
- - while (Int_Loc <= 2) /* loop body executed once */
- - if (Func_1 (Str_1_Par_Ref[Int_Loc],
- - Str_2_Par_Ref[Int_Loc+1]) == Ident_1)
- - /* then, executed */
- - {
- - Ch_Loc = 'A';
- - Int_Loc += 1;
- - } /* if, while */
- - if (Ch_Loc >= 'W' && Ch_Loc < 'Z')
- - /* then, not executed */
- - Int_Loc = 7;
- - if (Ch_Loc == 'R')
- - /* then, not executed */
- - return (true);
- - else /* executed */
- - {
- - if (strcmp (Str_1_Par_Ref, Str_2_Par_Ref) > 0)
- - /* then, not executed */
- - {
- - Int_Loc += 7;
- - Int_Glob = Int_Loc;
- - return (true);
- - }
- - else /* executed */
- - return (false);
- - } /* if Ch_Loc */
- -} /* Func_2 */
- -
- -
- -Boolean Func_3 (Enum_Par_Val)
- -/***************************/
- - /* executed once */
- - /* Enum_Par_Val == Ident_3 */
- -Enumeration Enum_Par_Val;
- -{
- - Enumeration Enum_Loc;
- -
- - Enum_Loc = Enum_Par_Val;
- - if (Enum_Loc == Ident_3)
- - /* then, executed */
- - return (true);
- - else /* not executed */
- - return (false);
- -} /* Func_3 */
- -
- //GO.SYSIN DD dhry_2.c
- echo dhry_c.dif 1>&2
- sed >dhry_c.dif <<'//GO.SYSIN DD dhry_c.dif' 's/^-//'
- -7c7
- -< * Version: C, Version 2.1
- ----
- -> * Version: C, Version 2.0
- -9c9
- -< * File: dhry.h (part 1 of 3)
- ----
- -> * File: dhry_global.h (part 1 of 3)
- -11c11
- -< * Date: May 25, 1988
- ----
- -> * Date: March 3, 1988
- -30c30
- -< * In addition, Berkeley UNIX system calls "times ()" or "time ()"
- ----
- -> * In addition, UNIX system calls "times ()" or "time ()"
- -44c44
- -< * Please send results to Rick Richardson and/or Reinhold Weicker.
- ----
- -> * Please send results to Reinhold Weicker and/or Rick Richardson.
- -59c59
- -< * History: This version C/2.1 has been made for two reasons:
- ----
- -> * History: This version C/2.0 has been made for two reasons:
- -123,129d122
- -< * Version 2.1 is identical to version 2.0 distributed via
- -< * the UNIX network Usenet in March 1988 except that it corrects
- -< * some minor deficiencies that were found by users of version 2.0.
- -< * The only change within the measurement loop is that a
- -< * non-executed "else" part was added to the "if" statement in
- -< * Func_3, and a non-executed "else" part removed from Proc_3.
- -< *
- -165,167c158,160
- -< * -DHZ=nnn
- -< * In Berkeley UNIX, the function "times" returns process
- -< * time in 1/HZ seconds, with HZ = 60 for most systems.
- ----
- -> * -DHZ=nnn (default: 60)
- -> * The function "times" returns process times in
- -> * 1/HZ seconds, with HZ = 60 for most systems.
- -169c162
- -< * A VALUE.
- ----
- -> * THE DEFAULT VALUE.
- -176,178c169,171
- -< * - dhry.h (this file, containing global definitions and comments)
- -< * - dhry_1.c (containing the code corresponding to Ada package Pack_1)
- -< * - dhry_2.c (containing the code corresponding to Ada package Pack_2)
- ----
- -> * - dhry_global.h (this file, containing global definitions and comments)
- -> * - dhry_pack_1.c (containing the code corresponding to Ada package Pack_1)
- -> * - dhry_pack_2.c (containing the code corresponding to Ada package Pack_2)
- -350a344
- -> #ifndef TIMES
- -353,354c347,354
- -< /* Use times(2) time function unless */
- -< /* explicitly defined otherwise */
- ----
- -> #endif
- -> /* Use "times" function for measurement */
- -> /* unless explicitly defined otherwise */
- -> #ifndef HZ
- -> #define HZ 60
- -> #endif
- -> /* Use HZ = 60 for "times" function */
- -> /* unless explicitly defined otherwise */
- -363c363
- -< /* Berkeley UNIX C returns process times in seconds/HZ */
- ----
- -> /* UNIX C returns process times in seconds/HZ */
- -7c7
- -< * Version: C, Version 2.1
- ----
- -> * Version: C, Version 2.0
- -9c9
- -< * File: dhry_1.c (part 2 of 3)
- ----
- -> * File: dhry_pack_1.c (part 2 of 3)
- -11c11
- -< * Date: May 25, 1988
- ----
- -> * Date: March 3, 1988
- -18c18
- -< #include "dhry.h"
- ----
- -> #include "dhry_global.h"
- -50,51d49
- -< #define Too_Small_Time 120
- -< /* Measurements should last at least about 2 seconds */
- -55a54,55
- -> #endif
- ->
- -58d57
- -< #endif
- -73a73
- ->
- -84a85
- ->
- -99,100c100,102
- -< /* Was missing in published program. Without this statement, */
- -< /* Arr_2_Glob [8][7] would have an undefined value. */
- ----
- -> /* Was missing in published program. Without this */
- -> /* initialization, Arr_2_Glob [8][7] would have an */
- -> /* undefined value. */
- -105c107
- -< printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
- ----
- -> printf ("Dhrystone Benchmark, Version 2.0 (Language: C)\n");
- -281c283
- -< /******************/
- ----
- -> /**********************/
- -338c340
- -< /******************/
- ----
- -> /**********************/
- -347a350,351
- -> else /* not executed */
- -> Int_Glob = 100;
- -349a354
- ->
- -7c7
- -< * Version: C, Version 2.1
- ----
- -> * Version: C, Version 2.0
- -9c9
- -< * File: dhry_2.c (part 3 of 3)
- ----
- -> * File: dhry_pack_2.c (part 3 of 3)
- -11c11
- -< * Date: May 25, 1988
- ----
- -> * Date: March 3, 1988
- -18c18
- -< #include "dhry.h"
- ----
- -> #include "dhry_global.h"
- -189,190d188
- -< else /* not executed */
- -< return (false);
- //GO.SYSIN DD dhry_c.dif
- echo submit.frm 1>&2
- sed >submit.frm <<'//GO.SYSIN DD submit.frm' 's/^-//'
- -DHRYSTONE 2.1 BENCHMARK REPORTING FORM
- -MANUF:
- -MODEL:
- -PROC:
- -CLOCK:
- -OS:
- -OVERSION:
- -COMPILER:
- -CVERSION:
- -OPTIONS:
- -NOREG:
- -REG:
- -NOTES:
- -DATE:
- -SUBMITTER:
- -CODESIZE:
- -MAILTO: uunet!pcrat!dry2
- //GO.SYSIN DD submit.frm
|