Cache performance on 386 boards running Unix
Dick Dunn
rcd at ico.isc.com
Fri Oct 27 13:18:00 AEST 1989
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.
More information about the Comp.unix.i386
mailing list