Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!nsc!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.arch
Subject: Re: 11/08/85 Dhrystone Benchmark Results
Message-ID: <2228@amdahl.UUCP>
Date: Wed, 13-Nov-85 19:25:23 EST
Article-I.D.: amdahl.2228
Posted: Wed Nov 13 19:25:23 1985
Date-Received: Fri, 15-Nov-85 05:06:52 EST
References: <1129@hou2h.UUCP> <643@cornell.UUCP>
Distribution: net.arch
Organization: Amdahl Corp, Sunnyvale CA
Lines: 18

> ...One major question that remains in my mind with respect to Dhrystone
> benchmarks is the effect of cache...
> 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 locality for instruction fetch is certainly pretty good for
Dhrystone.  However, this kind of locality is typical for many
user applications, as Dhrystone is represented to be.  Operand locality
is much worse, again the usual situation.  While there are always
exceptions, this kind of pattern is typical in the data that we collect
for applications (not supervisory code).  Based on the well-known
S/370-type machines in the list (470, 580, 3083, 4341) the results track
real experience surprisingly well.  In our experience, it is supervisory
code that really shows the differences in cache performance to extremes.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]