Article View: comp.arch
Article #1918Re: cache speed
From: Marcus S. Lewis
Date: Tue, 22 Aug 1989 02:10
Date: Tue, 22 Aug 1989 02:10
47 lines
2874 bytes
2874 bytes
From article <1736@crdgw1.crd.ge.com>, by oconnordm@CRD.GE.COM
(Dennis M. O'Connor):
> roy@phri (Roy Smith) writes:
> ] Cache is, by definition, a compromise. If you really want to build
> Summary : it's currently impossible to build a 16-megabyte NMOS,
Gentles, please, my apologies. I had no intention of starting a war here
of all places. In my original post, I mentioned a co-worker "building"
a hi-perf 386. This is, at least in THIS forum, a misstatement. I
have received lots of mail, almost all of which ended at least in asking
why not use the 386 cache controller. Now I see my mistake.
He is not _DESIGNING_ a system. He is looking over motherboards, and I
was questioning (a) why he needed 128K cache, and (b) why it needed to
be 15 ns for a 33 MHz CPU. Especially since the board has the 15 ns
chips as an option (upgrade from 25 ns). I'm trying to save my company
some money here. He's buying the stuff, but I get to assemble it into a
machine. We did this once before, with a Texas MicroSystems 16 MHz CPU
in a passive backplane. He wants 33 MHz, and the only place he can get
it NOW is as a MB system.
We have a "strategic product", a voice-response system based on this
machine, currently running 8 channels under MS-DOS, and the CPU is
having trouble keeping up. The next step is to get some faster voice
boards, port the existing system to a faster setup, then convert the
whole shot to some Unix variant. My contention is that 128K cache MAY
help in the MS-DOS version, since it is one humongo program, but in the
Unix version it will be multiple tasks, scheduled by Unix, in which case
I doubt that the cache is going to be all that useful, at least not in
that size.
Is this clearer? I am still somewhat in the dark, having lurked here for
over a year, about some of the terminology you folks use. Like, (dumb,
yes, but I'm a system manager) what do you mean by a cache line? And how
does the controller deal with an invalidation: is there a penalty on a
real miss, and if so does the larger cache increase that penalty?
But please don't argue about it.
Thanks a bunch. This has been a very productive lurk.
Marc
--
Na khuya mne podpis'? | Internet: cs057@zeus.unl.edu
preferred machine->| UUCP: uunet!btni!unocss!mlewis
Go for it! | Bitnet: CS057@UNOMA1
---------------------------------------------------------------------------
Technical Details
Message-ID:
<1493@unocss.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!tank!eecae!upba!dsndata!unocss!mlewisReferences:
<1736@crdgw1.crd.ge.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!tank!eecae!upba!dsndata!unocss!mlewis From: mlewis@unocss.UUCP (Marcus S. Lewis) Newsgroups: comp.arch Subject: Re: cache speed Message-ID: <1493@unocss.UUCP> Date: 22 Aug 89 02:10:07 GMT References: <1736@crdgw1.crd.ge.com> Organization: U. of Nebraska at Omaha Lines: 47