Xref: utzoo comp.arch:8828 comp.sys.intel:769
Path: utzoo!attcan!uunet!lll-winken!vette!brooks
From: brooks@vette.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 Multiprocessing
Message-ID: <22090@lll-winken.LLNL.GOV>
Date: 18 Mar 89 00:26:09 GMT
References: <496@ircam.UUCP>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: brooks@maddog.llnl.gov (Eugene Brooks)
Followup-To: comp.arch
Organization: Lawrence Livermore National Laboratory
Lines: 26

In article <496@ircam.UUCP> elind@ircam.ircam.fr (Eric Lindemann) writes:
>In <21876@lll-winken.LLNL.GOV> brooks@vette.llnl.gov (Eugene Brooks) writes:
>>A good estimate of the external cache size desired is the total main memory
>>divided by the number of processors you plan to configure. 
>
>So if I wanted to have 4 processors with 16 Mbyte of main memory this would
>imply a 4 Mbyte cache? That's a pretty big  cache don't you think?
I agree that it is pretty big as far as ones current notion of a cache is,
but it is pretty much the right size if your goal for the cache is to
hold portions of the problem data set which are "local" for extended periods
of time then dynamically "shared" during communication between processors.
The idea here is that the "second level cache" is a set of local memories
for the shared data set to be distributed into.

The purpose of the second level cache is to keep the relatively high miss
rate on the "small but fast" first level cache from saturating the memory
bus.  The second level cache need not be implemented with fast static ram,
it can be made of relatively slow, and therefore cheap, dynamic memory.
Essentially the same memory technology as it used in the main memory can
be used.  A per-processor second level cache size of one or several megabytes
is an entirely reasonable size, and I can show specific problems as examples
for which it would be used effectively.



brooks@maddog.llnl.gov, brooks@maddog.uucp, .../uunet!maddog.llnl.gov!brooks