Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!ll-xn!ames!ubvax!weitek!mahar
From: mahar@weitek.UUCP
Newsgroups: comp.arch
Subject: Re: Dhrystone 2.1
Keywords: integer benchmark
Message-ID: <391@attila.weitek.UUCP>
Date: 12 Jul 88 17:25:00 GMT
References: <517@pcrat.UUCP> <2294@sugar.UUCP>
Reply-To: mahar@attila.UUCP (Mike Mahar)
Organization: WEITEK Corporation, Sunnyvale, CA
Lines: 33

I've noticed that the way people use the Dhrystone benchmark is very different
than the initial intent.  It was supposed to be used to evaluate computer
architectures.  Instead, it is used to evaluate C compilers.  In the RISC
world, this makes a certain sense.  Given the following rule of thumb.
    For a given RISC architecture, 
	Vax780mips = .7 * Clock in Mhz

A 10Mhz RISC is about 7 VAX780 mips.  This is true for Mips Co., 88000, 29000,
and Weitek XL8000.  This doesn't seem to hold true for SPARC.  That machine
seems to be between 5 & 6 VAX780 mips.

Given this the Dhrystone benchmark is used to evaluate compilers for the
various RISC processors.  A very good optimizing compiler will eliminate
all the code in Dhrystone except the calls to times.  This would give the
result of a divide by zero exception since the two calls to times would
take place in less than a 60th of a second.  None of the compilers are doing
that yet but they are making great strides is optimizing the code for
Dhrystone.  For example.  The string copy can be done a word at a time if
the strings are guaranteed to be word aligned.  Since the string copys in
Dhrystone are of constants to local arrays, the compiler can guarantee that
the strings are aligned and even do the string copy in-line. 
There is a divide in every iteration that can be eliminated.  Clever compilers
can get rid of the divide.  High speed string compares can be written that
compare a word at a time.  These three tricks alone can almost double the
Dhrystone rating of a machine.  Fast string copy and compare are usefull
library routines but they don't account for 30% of a typical program's time.
The divide optimization would be part of a general strength reduction and
could be more useful but I don't know how much more usefull.

				Mike Mahar
-- 
	Mike Mahar
	UUCP: {turtlevax, cae780}!weitek!mahar