Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!philapd!ssp2!pb
From: pb@idca.tds.PHILIPS.nl (Peter Brouwer)
Newsgroups: comp.unix.i386
Subject: Re: Cache performance on 386 boards running Unix
Message-ID: <530@ssp2.idca.tds.philips.nl>
Date: 30 Oct 89 10:04:30 GMT
References: <919@umigw.MIAMI.EDU> <416@ssp2.idca.tds.philips.nl> <1480@crdos1.crd.ge.COM>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 32

In article <1480@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <416@ssp2.idca.tds.philips.nl>, pb@idca.tds.PHILIPS.nl (Peter Brouwer) writes:
>|  This depends on the size/working set of your applications you use.
>|  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. 
>
>  Micro caches don't work in 4k pages, so what has this to do with
>anything? I suspect you're thinking of mainframe cache which may work
>in larger chunks. 4, 16, and 32 byte cache chunks are mentioned by
>manufacturers, I think someone used 64 bytes, but I haven't got the
>name.
>
I must admit I did not know this. From the discussions uptill now I understand
the cache contains a 32 bits address and 32 bit data.
Does this means that it can contain 1K memory references.
If this is the case and you have an application which uses for instance an
memory array > 1K and does lots of accesses in it , will result in a low
cache hit ratio.
Is a correct assumtion?







-- 
Peter Brouwer,                # Philips Telecommunications and Data Systems,
NET  : pb@idca.tds.philips.nl # Department SSP-P9000 Building V2,
UUCP : ....!mcvax!philapd!pb  # P.O.Box 245, 7300AE Apeldoorn, The Netherlands.
PHONE:ext [+31] [0]55 432523, # Never underestimate the power of human stupidity