🚀 go-pugleaf

In article <107900005@iuvax> gannon@iuvax.cs.indiana.edu writes:
>Here is an item that should be of interest to this group:

>From: George Cybenko <gc@uicsrd.csrd.uiuc.edu>
>Date: Fri, 21 Jul 89 21:07:15 CDT
>Subject: 1989 Bell Award for Perfect Benchmarks

>Processor Definition

>The number of processors is defined as the number of simultaneous
>program execution streams, i.e., in effect the number of  program
>counters in simultaneous operation.  For example the Cray Y-MP in
>operation today has 8 processors and the number is  projected  to
>grow  to 16 and 64 for the Cray 3 and 4.  Similarly, the Thinking
>Machines Corp. CM2 has up to 4 processors each with 16K  process-
>ing elements or is a uniprocessor with 64K processing elements.

This definition seams to be a little restrictive.
Would a data-flow processor such as Arvind's Monsoon or the recently
proposed P-RISC then have an unbounded number of processors? 
despite the fact that it might be able to issue only one arithmetic
operation per tick per processor? 

What about a multi-stream architecture such as the HEP or the CHOPP
where a large number of "instruction streams" are multiplexed onto a
single arithmetic pipeline?

(Aside: isn't the CM2 a single stream machine? I'd never heard that
the 4 quadrants could be run independently.)

(A little out of order...)
>(2)  More than 16 Processors:  The measure is the same as in  1.,
>     except  that the computer system has more than 16 processors
>     and all processors must participate in the execution of each
>     benchmark.

What does this mean for a data flow machine?  Must a multi-stream
architecture have all streams firing? even when the pipeline saturates
well below this level? 

Why should all processors be required? If the problem sizes in the
benchmark set are fixed, Amdahl's law will make it very difficult
for large machines to "compete" with small machines.


Disclaimer: I work for a company that is designing a multi-stream,
multi-processor so my concern over Bell's definitions may appear
less academic than I'd like to beleive they are.


David Callahan  (david@tera.com, david@june.cs.washington.edu,david@rice.edu)
Tera Computer Co. 	400 North 34th Street  		Seattle WA, 98103
-- 
David Callahan  (david@tera.com, david@june.cs.washington.edu,david@rice.edu)
Tera Computer Co. 	400 North 34th Street  		Seattle WA, 98103