linux-mips-fnet
[Top] [All Lists]

Re: r10000 boards

To: linux-mips
Subject: Re: r10000 boards
From: Dom Sweetman <dom@algor.co.uk>
Date: Wed, 2 Apr 1997 09:05:20 +0100 (BST)
In-reply-to: <9704020557.AA19244@scimitar.dolphinics.no>
References: <Pine.LNX.3.95.960401194650.11590A-100000@ravage.labs.gmu.edu> <9704020557.AA19244@scimitar.dolphinics.no>
> > > A good RAM interface is a much more effective mean to accelerate
> > > a system than caches especially when you have an application
> > > that has a working set that exceeds the cache size.

>From first principles, CPU performance is determined by:

o How fast the core is when it gets everything from cache;
o What proportion of CPU cycles miss in the cache (almost the same as
  the cache miss rate);
o How long the CPU waits on a cache miss (cache miss penalty).

We spent most of last year working with the Vr4300 CPU (133MHz MIPS
R4x00 with a 32-bit bus).  In a decent system, running an average
program, it's stalled waiting for memory 60% of the time.  If you
could drop in a 266MHz core, your program would run only 25% faster.
In this CPU, the cache/memory system is limiting performance.

The cache miss rate goes down with bigger or cleverer caches.  But
off-chip or very large or very clever primary caches slow the CPU
clock down, so people invented secondary cache.  To be useful,
secondary cache has to be a lot bigger than primary cache and a lot
faster than main memory.

The R4000PC had a big brother (the R4000SC) with a separate secondary
cache bus.  The R4000PC could only have a secondary cache by sharing
the system bus, but that means a secondary cache would run at 'system
bus speed' and would probably not be enough faster than main memory to
be really worthwhile.  The Magnum's designers aimed for reducing the
cache miss penalty... and missed.

The cache miss penalty goes down with simpler or more tightly
integrated memory systems, because it's more affected by memory
*latency* (how long you wait until the first word) than *bandwidth*
(how fast the data comes once it starts, or sometimes how fast the
data comes "on average").

Ralf is right; RISC and PC systems, 1990-97 style, have tended to
ignore main memory latency and use secondary caches as palliatives.
Regular EDO DRAMs have 60ns access time (latency) at the DRAM pins,
but that typically turns into 180ns as seen by the CPU.  That's just
bad, wasteful design.

But once you've got a 200MHz CPU even the best memory system will
benefit from a secondary cache in front of it - so long as the CPU
interface allows it to run fast enough.  

Don't get me started on the MIPS system interface...

Dominic Sweetman
dom@algor.co.uk


<Prev in Thread] Current Thread [Next in Thread>