Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!bellcore!petrus!sabre!zeta!epsilon!gamma!ulysses!cbosgd!ucbvax!works From: jrp@SUNA.PSG.NPL.CO.UK Newsgroups: mod.computers.workstations Subject: Re: Benchmarking and the 68020 Cache Message-ID: <1000.510399685@suna> Date: Wed, 5-Mar-86 04:41:25 EST Article-I.D.: suna.1000.510399685 Posted: Wed Mar 5 04:41:25 1986 Date-Received: Thu, 6-Mar-86 22:03:57 EST References: <8601241531.AA21587@ucbvax.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: nplppvs!baw@seismo.CSS.GOV, baw , baw Organization: National Physical Laboratory,Teddington,UK. Lines: 13 Approved: works@red.rutgers.edu Dear David, I found your note on the 68020 cache most interesting. Similar experiments on other machines have given a much smaller difference between 'identical' encodings of Whetstone. Hence I conclude: The 68020 cache is 'unstable' and hence all measurements of performance on that machine are susceptable to at least a 20% uncertainity. I do not see how ordinary high level language code can avoid the problem of the cache that you have located - just increasing the size of the benchmark is unlikely to help. yours, Brian Wichmann