Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!argosy!ian
From: argosy!ian@decwrl.dec.com (Ian L. Kaplan)
Newsgroups: comp.parallel
Subject: Re: Acceptable efficiency factors
Message-ID: <9521@hubcap.clemson.edu>
Date: 30 Jun 90 12:47:03 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 47
Approved: parallel@hubcap.clemson.edu

>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%.
>
>David A. Remaklus
>NASA Lewis Research Center
>Cleveland, Ohio 44135
>xxremak@csduts1.lerc.nasa.gov

  This is somewhat tangential to the issue, but I could not resist
mentioning it.

  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.
MIMD architecture and programming continues to be a hot topic in the
computer science research community.  Some people theorize that this
is because MIMD programming is so difficult that it provides a
challenging research problem and a fertile field for Phd theses.

  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.  SIMD systems can be programmed in
_standard_ Fortran 90.  MIMD systems can only be programmed in a
language that contains extensions for synchronization.  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.  Full symbolic debugging can also be supported on a
SIMD machine.  Has anyone done a symbolic debugger for a large scale
MIMD system?

  Of course I am biased.

                       Ian Kaplan
		       MasPar Computer Corp.
		       ian@maspar.com