Dhrystone howto

This Page serves as a guide for running Dhrystone benchmark on arm machines: Go back to Main Project Page

About Dhrystone

From Wikipedia, the free encyclopedia

Dhrystone is a synthetic computing benchmark program developed in 1984 by Reinhold P. Weicker intended to be representative of system (integer) programming. The Dhrystone grew to become representative of general processor (CPU) performance. Later the CPU89 benchmark suite from the Standard Performance Evaluation Corporation, today known as the "SPECint" suite was introduced, but SPEC programs are quite expensive whereas Dhrystone is free, therefore Dhrystone remains popular.

The name "Dhrystone" is a pun on a different benchmark algorithm called Whetstone.

With Dhrystone, Weicker gathered meta-data from a broad range of software, including programs written in FORTRAN, PL/1, SAL, ALGOL 68, and Pascal. He then characterized these programs in terms of various common constructs: procedure calls, pointer indirections, assignments, etc. From this he wrote the Dhrystone benchmark to correspond to a representative mix. Dhrystone was published in Ada, with the C version for Unix developed by Rick Richardson ("version 1.1") greatly contributing to its popularity.

The Dhrystone benchmark contains no floating point operations, thus the name is a pun on the then-popular Whetstone benchmark for floating point operations. The output from the benchmark is the number of Dhrystones per second (the number of iterations of the main code loop per second).

Both Whetstone and Dhrystone are synthetic benchmarks, meaning that they are simple programs that are carefully designed to statistically mimic the processor usage of some common set of programs. Whetstone, developed in 1972, originally strove to mimic typical Algol 60 programs based on measurements from 1970, but eventually became most popular in its Fortran version, reflecting the highly numerical orientation of computing in the 1960s.

Dhrystone Fundamentals

From ARM White Paper

Dhrystone has a number of attributes that have led to it being widely used in the past as a measure of CPU performance. Foremost, Dhrystone is compact, widely available in the public domain, and simple to run. Significantly, there are no lengthy certification processes to go through before citing Dhrystone figures. Dhrystone compares the performance of the processor under benchmark to that of a reference machine. This is an advantage over quoting ‘straight’ MIPS numbers since using a reference machine effectively compensates for differences in the richness of competing instruction sets. For example, literal comparison of the ‘millions of instructions per second’ numbers for a RISC architecture and a CISC architecture is not meaningful.

The industry has adopted the VAX 11/780 as the reference 1 MIP machine. The VAX 11/780 achieves 1757 Dhrystones per second. The Dhrystone figure is calculated by measuring the number of Dhrystones per second for the system, and dividing that by 1757. So "80 MIPS" means "80 Dhrystone VAX MIPS", which means 80 times faster than a VAX 11/780. A DMIPS/MHz rating takes this normalization process one step further, enabling comparison of processor performance at different clock rates. For all of these reasons, in the past, Dhrystone has been a widely quoted benchmark figure. In theory, Dhrystone should provide a basis for the comparison of processor performances.

However, some of the apparent advantages of Dhrystone are also significant weaknesses of the benchmark. Dhrystone numbers actually reflect the performance of the C compiler and libraries, probably more so than the performance of the processor itself. Also, lack of independent certification means that customers are dependent on processor vendors to quote accurate and meaningful Dhrystone data.

Dhrystone Characteristics

Strengths

• Written in C language Code (Allows code portability)
• Small in size (An easy to understand program)
• Single easy to report score (DMIPS which uses a reference VAX MIPS)
• Potentially useful for 8 and 16-bit microcontroller benchmark

Weaknesses

• Cannot hope to mimic the breadth of applications encountered by a processor-based system
• Dhrystone only measures a few mathematical and basic operations
• Does not measure multiply- accumulate, floating-point, SIMD, or any other type of operations
• Dhrystone’s execution is largely spent in standard C library functions, such as strcmp(),strcpy(), and memcpy(). Compiler vendors generally provide these libraries that are typically optimized and hand-written in assembly language. While you may think you are benchmarking a processor, you are really benchmarking are the compiler writer’s optimizations of the C library functions for a particular platform

Installation

1. Obtaining the Source Code

One of the most important defects in Dhrystone is that it is often unclear what version is being quoted. Furthermore, since there are no "disclosure rules" or independent certification of scores, companies and individuals are free to state, or not state, anything.

The following package is "one of the reliable Dhrystone 2.1" package online. Due to its non proprietary nature, individuals and companies modified their own versions of Dhrystone resulting in various alterations of the source code.

Dhrystone-2.1.tar.gz

2. Extract the file

Extract the tarball using the command:

tar xvf dhrystone-2.1.tar.gz -C destination_directory/

There will be a total of 19 files once extracted. Move to the directory where the extracted files are.

3. Edit the Makefile Move

Project Leader(s)

Name(s) of primary people working on the project. If you want to join a project as leader, discuss with other leaders first. Include links to personal pages within wiki

Project Contributor(s)

Name(s) of people casually working on the project, or who have contributed significant help. Include links to personal pages within wiki

NOTE: only Project Leader(s) should add names here. You can’t add your own name to the Contributor list.

Project Details

Provides more depth than the Project Description. This is the place for technical discussions, project specs, or other details. If this gets very long, you might consider breaking this part into multiple pages and linking to them.

Project Plan

Goals for each release:

• 0.1
• 0.2
• 0.3

Project News

This is where your regular updates will go. In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc.

Put detailed technical information into the Project Details page (i.e., update it as you go), and save this section for news about participation in the project.