Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hubcap!uiucdcs!pur-ee!uiucdcsm.cs.uiuc.edu!grunwald
From: uiucdcs!pur-ee!uiucdcsm.cs.uiuc.edu!grunwald@uunet.uu.net
Newsgroups: comp.parallel
Subject: Re: Breakthrough at Sandia?
Message-ID: <1223@hubcap.UUCP>
Date: 28 Mar 88 13:23:10 GMT
Sender: fpst@hubcap.UUCP
Lines: 29
Approved: parallel@hubcap.clemson.edu

Basically, they took problems well suited to parallelism (wave equation,
finite difference methods for beam stress and one other one) and did good
implementations.

For a fixed problem size, they got from 550 -> 650 speedup. If you fix the
problem size *per processor* (i.e. the problem gets bigger as you throw
more processesors at it), the ``scaled speedup'' peaks at 1020.

This is for total execution time -- loading, running & unloaded.

The scaled speedup measure is justified because many problems sizes are
simply constrained by time, not by the problem. In those cases, you just
want the thing done within a reasonable time. If you can run a larger version
of the problem in that time, you're happy about it.

The 550 -> 650 speedup indicates that the serial code was about .15%, which
is much better than Amdahl conjectured to be possible.

Interestingly, Gene Amdahl gave a talk here right after this came out -- from
his comments, I don't think that he had read the paper. He conjectured that
optimistic parallelism to be expected from hypercube systems for a general
job mix would be about 12% (i.e. 126 of 1024) for a fixed problem size.

Obviously, you don't use hypercubes for a general job mix. Or at least not
the entire hypercube.

Dirk Grunwald
Univ. of Illinois
grunwald@m.cs.uiuc.edu