Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!jqj
From: jqj@cornell.UUCP (J Q Johnson)
Newsgroups: net.arch
Subject: Re: 11/08/85 Dhrystone Benchmark Results
Message-ID: <643@cornell.UUCP>
Date: Tue, 12-Nov-85 07:27:05 EST
Article-I.D.: cornell.643
Posted: Tue Nov 12 07:27:05 1985
Date-Received: Wed, 13-Nov-85 08:03:39 EST
References: <1129@hou2h.UUCP>
Reply-To: jqj@cornell.UUCP (J Q Johnson)
Distribution: net.arch
Organization: Cornell Univ. CS Dept.
Lines: 14

Although I remain unconvinced about the validity of Dhrystone benchmarks as
a useful measure of system througput, I applaud Richardson's well presented
discussion of what benchmarks like this do and don't mean.  One major question
that remains in my mind with respect to Dhrystone benchmarks is the effect
of cache.  Has anyone looked at Dhrystone benchmarks with this in mind?
How much does a typical cache architecture (say a 4K 2-way associative
cache, or the onboard cache on a 68020) effect Dhrystone performance?

Dhrystone is a small program, and as a result may have a quite atypical
performance profile even if its balance of instruction types is typical.
Cache performance is one source of such variation.  Another might be the
fact that typical Dhrystone implementations exist in a single file.  Some
compilers (e.g. Tartan C), treat this as an opportunity to optimize
subroutine calling conventions (using JSR instead of CALLS on a VAX).