Newsgroups: comp.parallel.mpi
From: Steve Barnard <steve@megafauna.com>
Reply-To: steve@megafauna.com
Subject: Re: MPI question
Organization: megafauna
Date: Sat, 01 Jun 1996 02:26:59 -0800
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <31B01AF3.442A@megafauna.com>

Raja Daoud wrote:
> 
> Steve Barnard  <steve@megafauna.com> wrote:
> >We're considering trying to keep track of and to limit the number of
> >outstanding messages.  These are all non-blocking sends and receives.
> 
> In general, wild use of Isend isn't a good idea, sooner or later the MPI
> implementation will run out of resources and abort (or return an error)
> If an implementation doesn't do that, it's violating the standard.
> Isend is there to allow overlap of comm/comp if applicable, and for
> cases were the user wants to be "lazy" and break a deadlock instead of
> coding "properly" and avoiding it by design.
> 
> My advice is to make non-blocking calls the exception, not the rule.  It
> may be acceptable to expect MPI to handle O(N) requests (N = #processes)
> -- though it's not guaranteed -- but not #requests proportional to data
> size (if that's case here).  Different implementations may give you a
> runtime switch to control the # pending requests they can handle, but
> that's only a stop-gap measure.  For scalable and portable code, use
> Isend carefully.
> 
> --Raja
> 
> -=-
> Raja Daoud                                      Hewlett-Packard Co.
> raja@rsn.hp.com                                 Convex Division

Blocking sends and receives are not an option here.  This code is 
targeted for networks of workstations with rather high IPC bandwidth.  
It generates lots of sometimes rather short messages in a very irregular 
pattern.  Blocking sends and receives would make it *really* slow.

	Steve Barnard

