[rescue] RE: divide and conquer? (CPU design)

[rescue at sunhelp.org]

The ppro had a seprate die for cache <Grin>.  The ppro/1Meg had not one
but Two seprate die for cache.
	Nick

On Thu, 21 Jun 2001, Ken Hansen wrote:

> I am *far* from being an EE, but I do know that once you move componentls off the same die, peformance takes a *huge* hit - witness the PPro with it's on-die cache compared with similar chips with cache on a separate die (PII?).
> 
> There are somethings in life where I defer to the engineering department, like high-speed computing and automatic transmissions*. I look to Cray, and see that their latest designs started to use (IIRC, Dave McGuire feel free to correct me) collections of "off-the-shelf" CPUs as opposed to dividing the CPU into numerous components, as you describe.
> 
> Real gains in speed are achieved by proximity, and dividing a CPU into multiple pieces of silicon (or whatever) will have a negative effect.
> 
> That's my $.02,
> 
> Ken
> 
> 
> -----Original Message-----
> <snip>
> 
> Message: 5
> From: dave at cca.org
> Date: Wed, 20 Jun 2001 23:38:03 EDT
> Organization: The Center for Computational Aesthetics
> To: rescue at sunhelp.org
> Subject: Re: [rescue] 670MP windfall in the surplus diving frenzy today.....
> Reply-To: rescue at sunhelp.org
> 
> mcguire at neurotica.com writes:
> 
> <snip>
> 
> Any application where there is a major multi-tasking load, and 
> system throughput is more important than single-process performance,
> a single chip of [n] million transistors would be much more usefull 
> if it were a bunch of little simple CPUs than one big complex one.
> 
> Put another way: given, say, eight instruction units on a chip,
> you will *not* be able to keep them occupied trying to dynamicaly
> schedule a single instruction stream. The OS on a heavily-loaded
> server *will* be able to keep them fully occupied if they appear
> to be eight seperate CPUs.
> 
> If you want to get really insane, you share resources between
> the CPUs, which gets you back to the Barrell Processor design.
> (The only example of that that I can remember offhand was the IO
> processors in the CDC-6600. Anyone know of any others?) But then
> you're getting excessively complex again.
> 
> Cache design becomes significant (both how best to split up the
> real estate, and how to deal with coherency), but that's solvable.
> 
> And of course, you can take [n] of these chips and make a really
> big SMP system...
> 
> I'm sure other people have thought of this, and are probably already
> working on it.
> 
> -- david fischer -- dave at cca.org -- www.cca.org -- Cthulhu told me to. --
> <snip>
> _______________________________________________
> rescue maillist  -  rescue at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/rescue
>