DhrystoneDoc.tioga
Created by Neil Gunther, December 10, 1986 2:11:25 pm PST
Last Edited by: Neil Gunther December 16, 1986 7:38:55 pm PST
Russ Atkinson (RRA) December 16, 1986 1:17:16 am PST
CedarDhrystone
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
CedarDhrystone
-- and MesaDhrystone and InlineDhrystone
Neil Gunther
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: CedarDhrystone is a translation of the popular Dhrystone benchmark written in ADA by Reinhold P. Weicker, CACM 27, No 10, 1984 p. 1013 ff. It exercises the integer operation performance of the processor. The concomitant floating-point benchmark is available in CedarWhetstone. Straight Mesa and Inline versions are also available.
Created by: Neil Gunther
Maintained by: Neil Gunther <Gunther.pa>
Keywords: Arithmetic, Benchmark
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. The Dhrystone Benchmark
The original program (see Dhrystone.ada in Benchmarks.df) contains statements expressed in a high-level programming language, ADA, in a distribution considered representative, VIZ.
Assignments   53%
Control statements   32%
Procedure calls   15%
100 statements are dynamically executed. The program is balanced with respect to the three aspects:
- statement type
- operand type (for simple data types)
- operand access
operand global, local, parameter, or constant.
The combination of these three aspects is balanced only approximately.
The program does not compute anything meaningful, but it is syntactically and semantically correct. No explicit floating-point operations are invoked (see CedarWhetstoneDoc.tioga).
A table of values (expressed as Dhystones = Dhystone/second) for different hardware, exercised by various C compilers (see Dhrystone.c in Benchmarks.df), can be found in DhrystoneTable.tioga.
2. The Cedar Implementation
An effort has been made to preserve the intent behind the original ADA version of the benchmark and not to write a piece of supercharged Cedar code.
The salient Cedar modifications to the original code are:
1. RecordType is not written as a variant record. Variant records are safe storage antagonists. This change eliminates some discrimination cost, but increases copying cost (since the record becomes larger).
2. REFs are used instead of pointers. Since a few AssignRefs are performed in the inner loop, this has some performance degradation (about 15%).
3. OUT parameters are replaced by returns, and IN/OUT parameters are replaced by paired argument and return variables. Probably no performance effect here.
4. Cedar system stuff has been inserted to register with the commander and to use the high-precision timer. No effect on performance, but the numbers are a little more accurate.
The timing granularity is chosen to be seconds in the original benchmark for 16-bit processors and is the one chosen for this Cedar implementation. This could easily be reworked to use Pulses for greater accuracy. The recommended number of iterations is 50,000.
There are three versions of the benchmark.
CedarDhrystone: uses REFs and always has bounds checking
MesaDhrystone: uses LONG POINTERs and may have bounds checking (dpending on the compilation options).
InlineDhrystone: same as MesaDhrystone but has the inner testing procedures declared to be INLINE. May also be compiled without bounds checking.
Dorado Dhrystones
  1  2  3  4
Cedar 3310 3370 —— ——
Mesa 3770 3850 4110 4260
Inline 5450 5640 6230 6350
1, 3: normal priority (± 50)
2, 4: high priority (± 10)
3, 4: bounds & NIL checking disabled
This estimate indicates that the Cedar version on a Dorado is about the same as the C version on a Sun 3 without register optimizations (3333 reported). The Mesa version is nearly as fast as the Sun 3 with register optimizations (4166 best reported), and the Inline version is significantly faster.
3. Executing the Benchmark in Cedar
% CedarDhrystone
will commence execution automatically. All timing is performed internally. In the interest of consistency, no other significant programs should be running at the time the benchmark is performed. The WatchTool is excluded from this caveat since it only consumes about 2% of the cpu.
% FastCedarDhrystone
runs the benchmark as a high priority process. Similar commands run MesaDhrystone and InlineDhrystone. The stored versions of the programs are compiled with bounds checking.