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!ulysses!ucbvax!works
From: rdt@HOUXK.UUCP
Newsgroups: mod.computers.workstations
Subject: Re: Benchmarking and the 68020 Cache
Message-ID: <8603061402.AA09310@ulysses.UUCP>
Date: Thu, 6-Mar-86 09:02:03 EST
Article-I.D.: ulysses.8603061402.AA09310
Posted: Thu Mar  6 09:02:03 1986
Date-Received: Sun, 9-Mar-86 05:15:13 EST
References: <8601241531.AA21587@uc
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31
Approved: works@red.rutgers.edu


i am sorry. you are not saying anything of substance.  any cache is
unstable if it's working set exceeds the size of the cache.
apparently this is the case for your whetstone application.

the instruction cache can provide from 0 to 20 percent improvement to
the overall execution rate. the lower bound occurs for 'large working
sets' of code, while the upper bound occurs for 'small working sets'
of code.

for example, 64KB of cache will do absolutely NOTHING for inline code
without loops. There is nothing UNSTABLE about the hardware that
causes it to provide 0 percent speedup. The algorithm may also have
nothing wrong with it.  the 2 simply are not a good match; other
applications do get benifit from a code cache. typically search and
sort routines see alot of benifit. bitblt typically fits inside the
020 cache.

the message is that if you want better performance from your cache,
you had better fine tune your algorithm. if you can't (or don't want
to) then take your lumps.

as for "nearly identical code" behaving totally differently I suggest
that your definition of nearly identical is flawed.  Apparently it
means alot to the hardware, your scope is too global to understand
ways around the problem.

i hope that this has been helpful. 

richard
att info sys.