Cache performance on 386 boards running Unix

[Dick Dunn]

pb at idca.tds.PHILIPS.nl (Peter Brouwer) writes:
> ... angel at flipper.miami.edu (angel li) writes:
> >Does anyone know the performance difference of 386 boards with a cache
> >against boards without a cache, both running Unix?...
> This depends on the size/working set of your applications you use.

It depends on the working set--data and code both, although separate I and
D caches help a lot even with large amounts of data because the code is
still likely to have good locality even if the data defeats the caching.

> Most caches are 64k = 16 pages. So if you have large applications with
> a working set ( number of pages it used during execution ) the cache is'nt
> a great help. 

No.  (I've never seen a page-oriented cache--refill would be nasty!)  The
normal organization caches a small amount of memory (~ 4 - 8 bytes) per
cell, so the relevant question is not at page granularity.  It is rare for
a computation-intensive program to have a large amount of active code at any
given time--in fact, somewhat the opposite, because "computation intensive"
often means a few small loops.

Also, remember that the 386 presents physical addresses, so cache flushes
don't have to happen very often.  (Don't confuse a cache flush with a TLB
flush.)

Some informal experiments we've done suggest that a decent cache does a lot.
For example, a cached 25-MHz machine is easily twice as fast as an uncached
16-MHz even though the processor is only about 50% faster.

Keep in mind that this is CPU speed.  Look at your processing mix; if
you're I/O bound, there are still secondary reasons that a cache can help
but it's not such a big deal.
-- 
Dick Dunn     rcd at ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.