Thanks Dick, Eugene.  That's what I figured.  I was just hoping there might be some more obscure MPI functions that might do what I want.  I'll go ahead and write my own yielding wrapper on irecv.

Thanks again,
  Brian

sent from mobile phone

On Oct 20, 2010 5:24 AM, "Richard Treumann" <treumann@us.ibm.com> wrote:


Brian

Most HPC applications are run with one processor and one working thread per MPI process. In this case, the node is not being used for other work so if the MPI process does release a processor, there is nothing else important for it to do anyway.

In these applications, the blocking MPI call (like MPI_Recv) is issued only when there is no more computation that can be done until the MPI_Recv returns with with the message.

Unless your application has other threads that can make valuable use of the processor freed up by making MPI_Recv do yields, the polling "overhead" is probably not something to worry about.

If you do have other work available for the freed processor to turn to, the "problem" may be worth solving. MPI implementations, in general, default to a polling approach because it makes the MPI_Recv faster and if there is nothing else important for the processor to turn to, a fast MPI_Recv is what matters.


Dick Treumann  -  MPI Team          
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363



From: Brian Budge <brian.budge@gmail.com>
To: Open MPI Users <users@open-mpi.org>
Date: 10/19/2010 09:47 PM
Subject: [OMPI users] busy wait in MPI_Recv
Sent by: users-bounces@open-mpi.org





Hi all -

I just ran a small test to find out the overhead of an MPI_Recv call
when no communication...

_______________________________________________
users mailing list
users@open-mpi.org

http://www.open-mpi.org/mailman/listinfo.cgi/users


_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users