Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!news.cs.indiana.edu!ariel.unm.edu!spectre.unm.edu!john
From: john@spectre.unm.edu (John Prentice)
Newsgroups: comp.sys.super
Subject: Re: Massively Parallel LINPACK on the Intel Touchstone Delta machine
Message-ID: <1991Jun10.235501.7039@ariel.unm.edu>
Date: 10 Jun 91 23:55:01 GMT
References: <1991Jun6.144903.20456@chpc.utexas.edu> <1991Jun06.205144.22611@ariel.unm.edu> <1991Jun10.144354.695@chpc.utexas.edu>
Organization: Dept. of Math & Stat, University of New Mexico, Albuquerque
Lines: 22

In article <1991Jun10.144354.695@chpc.utexas.edu> gary@chpc.utexas.edu (Gary Smith) writes:
>
>Using Speedup(f,p) = 1/[(1-f)+(f/p)], with f being the fraction of code
>parallelized and p being the number of processors, and unrealistically
>assuming no overhead, a speedup of 64000 using 65536 processors requi-
>res that the problem be 99.9999634% parallel.  How many problems do you
>know of that are that parallel?
>

Very few.  But this misses the central question.  If we are going to even
get a factor of 100 speedup in the new few years, how else are we going to
do it other than by use of massive parallelism?  If there is an alternative,
I would be overjoyed to know about it.  I don't particularly find
parallel computing fun and it is not particularly easy, but I just don't
see any alternative.  That it has limitations, so what?  The question
still remains, what is the alternative?

John
-- 
John K. Prentice    john@spectre.unm.edu (Internet)
Computational Physics Group
Amparo Corporation, Albuquerque, NM