Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!chinet!steinmetz!davidsen
From: davidsen@steinmetz.UUCP
Newsgroups: comp.arch
Subject: Re: Will caches ever become obsolete?
Message-ID: <1261@steinmetz.steinmetz.UUCP>
Date: Wed, 4-Mar-87 15:50:46 EST
Article-I.D.: steinmet.1261
Posted: Wed Mar  4 15:50:46 1987
Date-Received: Sat, 7-Mar-87 00:17:45 EST
References: <3182@wateng.UUCP>
Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr)
Distribution: comp
Organization: General Electric CRD, Schenectady, NY
Lines: 29
Keywords: cache, coherence problems


Several bits of information on cache. First the improvement I
have noted is more like 20% than the large numbers you have
heard elsewhere. This doesn't mean that you *can't* get large
improvements, just that they happen when memory is way too slow.

Second, putting the cache on a multi-port memory controller was
not state of the art when I first saw it in 1968. It may come
back for some designs. It eliminates (more or less) cycle
stealing by placing N processors and N i/o subsystems on a
multiport memory. The memory controller has the cache.

Third, in a Harvard archetecture, the data and address space is
separate, eliminating the need to worry about syncing the
contents of the code (unless someone plans to go back to
self-modifying code :-}).

Finally, The IBM 4Mbit chips are said to run at 45ns, and the
16Mbit chips being prototyped in Japan are about half that. The
16Mbit chips are "proofs of existance, not beta test versions".
I think that your conjecture that main memory may be fast enough
is certainly probably for most applications, particularly since
the majority of new machines will probably use at least a 32bit
data path, cutting the number of accesses.
-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)