Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rochester.UUCP Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!rochester!crowl From: crowl@rochester.UUCP (Lawrence Crowl) Newsgroups: net.arch Subject: Re: 11/08/85 Dhrystone Benchmark Results Message-ID: <13143@rochester.UUCP> Date: Thu, 14-Nov-85 12:41:19 EST Article-I.D.: rocheste.13143 Posted: Thu Nov 14 12:41:19 1985 Date-Received: Fri, 15-Nov-85 05:44:40 EST References: <1129@hou2h.UUCP> <643@cornell.UUCP> Reply-To: crowl@rochester.UUCP (Lawrence Crowl) Distribution: net.arch Organization: U. of Rochester, CS Dept. Lines: 29 In article <643@cornell.UUCP> jqj@cornell.UUCP (J Q Johnson) writes: >.... 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? >.... The Dhrystone benchmark originated in: Reinhold P. Weicker Dhrystone: A Synthetic Systems Programming Benchmark Communications of the ACM Volume 27, Number 10, Pages 1013-1030, October 1984 In the article, the benchmark is timed for only one run. This eliminates the effect of cache on multiple runs, but not for the single run, which is as it should be. Multiple runs will skew the results heavily towards machines with a cache. Multiple runs are a timing convenience and are not in the spirit of a 'systems' benchmark because systems programs usually do not exibit this behavior. This convenience is acceptable for machines without ANY cache, but it is not acceptable for machines with a cache. Therefore, do not accept the results of a multiple run timing on machines with a cache. Insist that the benchmarker get out a logic analyzer and time a single run. I know this is a major hassle, but it is the only comparable result. I suggest you read the article if you intend to use the results. -- Lawrence Crowl 716-275-5766 University of Rochester Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627