Subject: Re: Large CPU caches & NetBSD
To: None <netbsd-help@netbsd.org>
From: John Maier <johnam@kemper.org>
List: netbsd-help
Date: 04/12/2000 23:48:10
> > Depending on how much cache you had before will determine how much of
> > a change you see.  Going from no cache to a little cache can make a
> > very big difference but the effect tails off after a while, which you
> > probably knew already :-)

Cache depends a lot on how much real memory you have.

I.e. if you have:
up to 4 Megs of real memory, 64Kbyte cache is all you really need.
up to 8 Megs of real memory, 128Kbyte cache is all you really need.
up to 16 Megs of real memory, 256Kbyte cache is all you really need.
Notice to this point the memory to cache fairly linear.

If you run the 4meg machine without cache, the performance will drop by
(20-60%).  This number will vary according to processor, bus speed, memory,
etc. so an exact %tage is impossible to state.

If you run the 4meg machine at 128K instead of  64K, the increase in
performance will typically only be (8-10%). Again, this number will vary
according to processor, bus speed, memory, etc. so an exact %tage is
impossible to state.

Now, a bump up to 256K or higher will result in even less performance
increase.  What is happening is you are getting a lower cache to memory
ratio which means you approaching a point where the cache miss will be zero,
i.e. if cache size == real memory size, which is unreasonable.

up to 64 Megs of real memory, 512Kbyte cache is all you really need.

Why the jump to 64Megs @ 512K?  The assumption is, the need for memory is
not for bigger programs but for more data.  I know most will at first, that
the guys who thought this stuff up in the 80's didn't foresee the OSs of
today.  But unless the computer is a seriously heavy use multi-user system,
most code just sits in memory doing nothing!!!  So your memory usage at
these higher usage levels will have to be adjusted to meet your load.

Simple examples:

A friend, Paul, wrote a Rubics Cube solver.  The program code took little
space, but memory was exhausted from storing all of those states of the
cube!  His 128Meg machine would have gained little from additional cache.

Compilers don't typically benefit from larger caches due to the fairly tight
program loops.

Since cache memory typically is much higher in cost than real memory, most
of use contend with the 10 - .5% loss in performance.

You don't want all the theory and statistics on this stuff (and I don't want
to type it out) so go to your favorite University's EE section and crack
some books if you want to know more.

John A. Maier
johnam@kemper.org
Q; What's the first thing you know?
A: Old Jed's a millionaire!