Path: utzoo!attcan!uunet!samsung!emory!hubcap!bcsaic!carroll
From: bcsaic!carroll@beaver.cs.washington.edu (Jeff Carroll)
Newsgroups: comp.parallel
Subject: Re: Acceptable efficiency factors
Message-ID: <9567@hubcap.clemson.edu>
Date: 5 Jul 90 13:26:12 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 77
Approved: parallel@hubcap.clemson.edu

In article <9521@hubcap.clemson.edu> argosy!ian@decwrl.dec.com (Ian L. Kaplan) writes:
> (David Remaklus writes:)
>>In a recent conversation with some colleagues of mine at the Ames NAS
>>facility concerning parallel processing, they mentioned their experiences
>>porting a code to the Intel i860 hybercube located there (128 nodes,
>>7.5 gigaFLOPS peek).  On this particular code they were able to
>>achieve about 300 MFLOPS for an efficiency factor of about 2.5%.  This
>>low efficiency factor didn't seem to bother them but it sure bothered
>>me.  Other colleagues of ours at the United Technologies Research Center
>>in East Hartford, CT ported similar codes to their 1/4 CM-2 and achieved
>>anywhere from 600 to 800 MFLOPS for an efficancy factor of more than 50%.

	We have an application that runs at roughly 70% efficiency on
our iPSC/860. Email me for details.	


>  Perhaps the difference in the execution efficiency between the Intel
>cube (an MIMD machine) and the CM-2 (a SIMD machine) is due to the
>fact (not doubt hotly contested) that SIMD systems are easier to
>program.  Easier to program also means easier to fit one's problem to...

	I thought marketing was taboo on the net.  :^)

	In this case I think it's far more likely that the low
efficiencies are due to the fact that there are no good market-ready
compilers for the i860 as yet.

>  A term like "ease of programming" is often used without giving much
>definition, so I will try to flesh out my claims.  One definition of
>ease of programming is that much of the machine architecture is
>abstracted and the programmer can think about writing a program that
>describes the problem rather than thinking about shoehorning the
>problem onto the machine.

	Maybe. But for problems that defy application of a
data-parallel algorithm (and thus run at very ordinary speeds on a
data-parallel machine), one is quickly persuaded to learn to use a
shoehorn.  

>...  SIMD systems can be programmed in
>_standard_ Fortran 90.  MIMD systems can only be programmed in a
>language that contains extensions for synchronization.

	Well, no. An iPSC can be programmed in standard FORTRAN
77 (who uses FORTRAN 90 anyway?). Think of a network of Unix-like
systems supporting an RPC mechanism. That's the way you program an iPSC.
Once you've finished decomposing your problem, it's no more painful than
writing FORTRAN under VMS (groan...).

	What you say is true of some (if not all) other MIMD systems.

> ...The SIMD
>programmer need only consider machine architecture when it comes to
>making their program run more efficiently.  The MIMD programmer must
>consider the machine architecture or the program will not run
>deterministicly.

	Granted: but, in my opinion, the rewards are great.

>
>  Of course I am biased.
>
>                       Ian Kaplan
>		       MasPar Computer Corp.
>		       ian@maspar.com

	Let's hear it for truth in advertising.

	Jeff Carroll
	carroll@atc.boeing.com

disclaimer #1: I am not associated with Intel Corporation, except as a
satisfied customer.

disclaimer #2: these are personal opinions, not official positions of the
Boeing Company (though the two may coincide, especially regarding such
things as FORTRAN 90.)