Dhrystone

The Dhrystone benchmark was designed to test performance factors important in non numeric systems programming (operating systems, compilers, wordprocessors, etc.):

• it contains no floating point operations;
• a considerable percentage of time is spent in string functions making the test very dependent upon the way such operations are performed (e.g. by in-line code, routines written in assembly language, etc.) making it susceptible to manufacturers 'tweaking' of critical routines;
• it contains hardly any tight loops so in the case of very small caches the majority of instruction accesses are will be misses; however, the situation changes radically as soon as the cache reaches a critical size and can hold the main measurement loop;
• only a small amount of global data is manipulated (as opposed to Whetstone).

There are two versions of the Dhrystone benchmark. A depreated version 1.1 contained some 'dead code' which could be removed by optimising compilers. Version 2.1 corrected this and should be the version used in practice (and is the one that is in the uClinux distribution). Some manufacturers, however, still quote the (better) results of Version 1.1 so care must be taken when comparing Dhrystone performance figures to check which version was used.

If Dhrystone data is used for comparison purposes, it is important that the conditions of the benchmark are well understood, including:

1. Which Dhrystone version was used? (We use Dhrystone version 2.1)
2. Which Dhrystone source code was used (ANSI, unmodified K&R)? (we used the unmodified Unmodified K&R)
3. How many compilation modules were used (one merged or two separate modules)? (We use the original unmodified two separate modules)
4. Which inlining settings are applied? (See results)
5. Which C libraries are used? (We use uClibc included in the toolchain)
6. Which tool chain (compiler version, options, linker) was used? (We use gcc 4.x)
7. What is the CPU’s clock speed? (See results)

These questions were borrowed from a White paper Richard York wrote.

Some people still occasionally ask for Dhrystone MIPS data, and so we will continue to provide these numbers. However, we do not recommend that Dhrystone results be used as part of any embedded processor evaluation exercise, due to its many known deficiencies. Where we provides a Dhrystone figure, it will be based on its standard tool suite under the conditions outlined above, and will therefore be 100% publicly and independently reproducible.

These results were taken on the processor, with Drystone compiled as a Linux application.

rgetz@pinky:~/blackfin1/uClinux-dist/user/dhrystone> bfin-uclinux-gcc --version
bfin-uclinux-gcc (ADI-trunk/svn-3648) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rgetz@pinky:~/blackfin/uclinux-dist/user/dhrystone> bfin-linux-uclibc-gcc -O3 -DNO_PROTOTYPES=1 -c -o dhry_1.o dhry_1.c
rgetz@pinky:~/blackfin/uclinux-dist/user/dhrystone> bfin-linux-uclibc-gcc -O3 -DNO_PROTOTYPES=1 -c -o dhry_2.o dhry_2.c
rgetz@pinky:~/blackfin/uclinux-dist/user/dhrystone> bfin-linux-uclibc-gcc -O3 -DNO_PROTOTYPES=1  dhry_1.o dhry_2.o -o  dhrystone
rgetz@pinky:~/blackfin/uclinux-dist/user/dhrystone> rcp ./dhrystone root@192.168.0.8:/dhrystone

root:/> cat /proc/cpuinfo
processor       : 0
vendor_id       : Analog Devices
cpu family      : 0x27c8000
model name      : ADSP-BF537 600(MHz CCLK) 120(MHz SCLK)
stepping        : 2
cpu MHz         : 600.000/120.000
bogomips        : 1196.03
Calibration     : 598016000 loops
cache size      : 16 KB(L1 icache) 32 KB(L1 dcache-wb) 0 KB(L2 cache)
dbank-A/B       : cache/cache
icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way
board name      : ADDS-BF537-STAMP
board memory    : 65536 kB (0x00000000 -> 0x04000000)
kernel memory   : 57336 kB (0x00001000 -> 0x037ff000)

root:~> ./dhrystone_O0

Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled without 'register' attribute

Please give the number of runs through the benchmark: 10000000

Execution starts, 10000000 runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:            5
        should be:   5
Bool_Glob:           1
        should be:   1
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       7
        should be:   7
Arr_2_Glob[8][7]:    10000010
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:          3707284
        should be:   (implementation-dependent)
  Discr:             0
        should be:   0
  Enum_Comp:         2
        should be:   2
  Int_Comp:          17
        should be:   17
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:          3707284
        should be:   (implementation-dependent), same as above
  Discr:             0
        should be:   0
  Enum_Comp:         1
        should be:   1
  Int_Comp:          18
        should be:   18
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           5
        should be:   5
Int_2_Loc:           13
        should be:   13
Int_3_Loc:           7
        should be:   7
Enum_Loc:            1
        should be:   1
Str_1_Loc:           DHRYSTONE PROGRAM, 1'ST STRING
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           DHRYSTONE PROGRAM, 2'ND STRING
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

Microseconds for one run through Dhrystone:    3.0
Dhrystones per Second:                      336021.5

All these tests were taken with the same processor (BF537 0.2, running at 500MHz CCLK, 120 MHz SCLK), just varying the compiler optimization settings. 10000000 (Ten Million) iterations are used to obtain accurate results.

“Benchmarking without analysis is as useless as analysis without benchmarking.” - Richard P. Gabriel, Performance and Evaluation of Lisp Systems, 1985

We can see that applications, like Dhrystone, which fit completely in cache, are only effected by a little bit by changing SCLK rates.

Before we can look at detailed analysis, some basic gcc flags must be understood:

-static

On systems that support dynamic linking, this prevents linking with the shared libraries, and includes the library functions in the application.

-O0

Do not optimize.

-Os

Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version

-O1

Turns on the following optimization flags: -fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers -floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time -fmerge-constants

-O2

turns on all optimization flags specified by -O1. It also turns on the following optimization flags: -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm -fexpensive-optimizations-fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks -freorder-functions -falign-functions -falign-jumps -falign-loops -falign-labels -ftree-vrp -ftree-pre

-O3

Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options.

-fomit-frame-pointer

Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions.

-ffunction-sections

-fdata-sections

Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section's name in the output file.

-gc-sections

Linker Flag to enable garbage collection of unused input sections. Used in combination with -ffunction-sections and -fdata-sections can make applications smaller.

Over 99.7% of the processor is spent running dhrystone.