Newsgroups: comp.parallel.mpi
From: starks@EMBL-Heidelberg.DE (David Starks-Browning)
Reply-To: David.Starks-Browning@EMBL-Heidelberg.DE
Subject: Re: Performance problems using mpi on the SGI Power Challenge
Organization: European Molecular Biology Laboratory, Heidelberg
Date: 2 Oct 1996 14:13:43 GMT
Message-ID: <52ttan$8a9@lion.embl-heidelberg.de>

In article <5283md$h0v@murrow.corp.sgi.com>, salo@mrjones.engr.sgi.com (Eric Salo) writes:
> As soon as you have more MPI processes than CPUs on which to run them,
> performance drops in a very big way. This was a deliberate trade-off
> that we made early on because we believed that the common case would be
> to not oversubscribe the CPUs in this way.

Of course that's what you would say publicly.  However, I believe the
reason is that the vendor (including SGI, Digital, ...) cares far more
about latency/bandwidth benchmark numbers than how the machine might
actually be used.  The former sells machines, while the latter is far less
relevant (to the vendor, that is) once the machine is sold.

> We definitely intend to go for the "best of both worlds" in some future
> release, but I don't yet have a good feel for when that might be. On
> the other hand, if I can come up with a quick-and-dirty backoff algorithm
> that appears to do the trick, I'll certainly drop it in...

Gang-scheduling may be the answer for MPI programs exhibiting highly
synchronous communication, as already reported.  How about also providing
a MPI_MAX_SPINWAIT environment variable, or something similar?  Then the
user has control over the "cost" of "performance".

It seems to me that any shared memory implementation of message passing,
including mpich, could benefit from such a tunable parameter.

Of course, taking advantage of a MAX_SPINWAIT type of parameter
*effeciently* presupposes some support from the OS, and I don't know
whether that exists in IRIX.  If not, a fast and flexible message passing
implementation might be just the incentive SGI needs.

Even a MAX_SPINWAIT parameter is limited because it is static, so there is
still room for more elegant backoff algorithms.

Regards,
David

=========================================================================
David Starks-Browning                         | starks@EMBL-Heidelberg.DE
Parallel Programming Consultant               |
Supercomputing Resource for Molecular Biology |
European Molecular Biology Laboratory         |
Meyerhofstrasse 1                             | tel: +49(0)6221-387 279
D-69117 Heidelberg, Germany                   | fax: +49(0)6221-387 306
=========================================================================


