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).