Path: utzoo!yunexus!geac!geaclib!daveb
From: daveb@geaclib.UUCP (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: quest for breakthroughs
Message-ID: <3682@geaclib.UUCP>
Date: 15 Feb 89 01:27:50 GMT
Article-I.D.: geaclib.3682
References: <21786@ames.arc.nasa.gov>
Organization: GEAC Computers, Toronto, CANADA
Lines: 62

In article <740@tetons.UUCP> bb@tetons.UUCP (Bob Blau) writes:
|  Imagine that you are the enlightened head of Imaginary Computer Corp's
	I'd like a very inexpensive dcache kit, much like the
	bit-slice processor kits of yore. 
	I don't mind if they're a bit limited in how much underlying
	memory they can handle, or if they're made affordable by simplifying
 	a little too much, because I want to use a **rather** large
	number of them.

|  What are your assumptions?
|End Product: 
	A large-memory mini, for recalcitrant/large problems that 
 	companies without gigabucks still have to solve.  It should
	fit in a small rack or large under-desk enclosure.

|Architecture:RISC, CISC, Vector
	RISC and moderately-CISC processors, like 68xxx's, MIPses and
	such-like. Standard state-of-practice stuff.

 
|Application: 
 	Scientific, logic-processing, symbolic computing.
 
|  What problems are you trying to solve?
|- Performance, Cost, Complexity, Size, Reliability, ...
	Size and complexity, primarily. 

	I want a machine with performance somewhat better than my
Stunned despite my stuffing it to bursting with slow main-memory
chips.  I want an architecture which will deal with large working
sets and ill-behaved (not very local) reference patterns without
having to sweep the slowdown under the rug by running large numbers
of users/processes in a timesharing system.
	I'd like the opportunity to do this at finite cost in the
near future by allowing me to bite the bullet and put in lots of
cache in front of a rather huge but not-too-fast main memory.  I
really do want lots of memory, and am betting that the difference in
memory speed/cost versus processor speed/cost makes investing in
cache worthwhile.  

	The assumption I'm making, you see, is that it's worthwhile
to allocating particular cache chips to particular blocks of memory
chips.  Probably along paging boundaries.  This in turn means that
I'm betting that cache invalidation/reloading on process change is a
major bottleneck when one has large amounts of cache.  This in turn
means that I'm still betting on simple multiprocessing for this kind
of application domain.  

	Of course, if one put several processors in front of this
memory hierarchy, but made sure that they didn't do strange things
like use two different page/cache sets for the same data, then it
might extend to multiprocessors...

--dave (no, we're not planning an AI document processor) c-b
[ the assumptions are basically a guess, based on the truism about
micro/mini systems repeating the history of mainframes, complete
with sillynesses and obvious bottlenecks]
-- 
 David Collier-Brown.  | yunexus!lethe!dave
 Interleaf Canada Inc. |
 1550 Enterprise Rd.   | He's so smart he's dumb.
 Mississauga, Ontario  |       --Joyce C-B