🚀 go-pugleaf

In article <ANIK.92Dec13020643@polaris.crhc.uiuc.edu>, anik@crhc.uiuc.edu (Sadun Anik) writes:


|> I don't follow the logic here. Since when MPP usage has been an
|> important factor in uP design? 

I really couldn't say.  Certainly, commodity uP's have already been
used in MPP's.  *At least* the following, probably more:
SPARC by Thinking Machines,
i860 by Intel, and similar applications by Alliant and FPS (now Cray),
88k (and 68k before that) by BBN,
Program announcements by Cray wrt to Alpha/21064 chip (no product yet)
Program announcements by Convex wrt to HP-PA/(7100?) chip (no product yet)
(There are probably others if I kept thinking about it.)

My point is that commodity uP's are already being used in MPP designs.
I don't know why MPP requirements *wouldn't* be an important factor,
considering the potential for a successful MPP vendor with good sales
to sell hundreds of thousands, possibly even millions, of chips per
year.

                              I wouldn't hold my breath to see 128
|> bit FP in a uP. It may happen in the future, but only when desktop
|> machine users require  it. 

Well, it will take a long time before many desktop users require it.
In fact, it is precisely this difference between the desktop user
and the MPP Teracomputer user that caused me to point out this
new requirement.  There are very few legitimate needs for 
greater than 64 bit FP precision today, even at GFLOPS/GBytes.
At TeraFLOPS/TeraBytes, however, there will be *some* problems
which will require 128 bit FP in order to solve them efficiently.
(Actually, not quite precise.  They will require more than 64 bits.)
With MPP systems consuming potentially thousands of chips each, 
I would not think it is prudent to ignore their requirements.
However, because most problems will still fit in 64 bits, full speed
128 bit FP is not a requirement.  The possibility of full speed
128 bit FP is interesting, though, with double speed 64 bit, and
quad speed 32 bit.  With 100 million transistor CPUs coming up,
there are some interesting possibilities.


|> Sadun Anik, U of Illinois at Urbana-Champaign
|> Center for Reliable and High-performance Computing
|> e-mail: anik@crhc.uiuc.edu

-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h>