Re: [OMPI users] Is Iprobe fast when there is no message to recieve

2009-10-03 Thread Ashley Pittman
On Sat, 2009-10-03 at 07:05 -0400, Jeff Squyres wrote:
> That being said, if you just want to send a quick "notify" that an  
> event has occurred, you might want to use a specific tag and/or  
> communicator for these extraordinary messages.  Then, when the event  
> occurs, send a very short message on this special tag/communicator  
> (potentially even a 0-byte message).

> You can MPI_TEST for  
> the completion of this short/0-byte receive very quickly.  You can  
> then send the actual data of the event in a different non-blocking  
> receive that is only checked if the short "alert" message is received.

In general I would say that Iprobe is a bad thing to use, as Jeff says
post a receive in advance and then call test on this receive rather than
using Iprobe.

>From your description it sounds like a zero byte send is all you need
which should be fast in all cases.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk



Re: [OMPI users] Is Iprobe fast when there is no message to recieve

2009-10-03 Thread Jeff Squyres
Keep in mind that MPI says you do have to eventually receive the  
message -- so just checking if it's there is not enough (eventually).   
Iprobe is definitely one way.  You could also post a non-blocking  
receive (persistent or not) and MPI_TEST to see if it has completed.


However, if the message is long, MPI implementations like Open MPI  
*may* require multiple invocations of the progression engine to  
actually receive the entire message (e.g., it may get fragmented by  
the sender and use a rendezvous protocol, therefore having multiple  
states in the progression logic, each of which may only advance one or  
two states in each call to MPI_TEST).


That being said, if you just want to send a quick "notify" that an  
event has occurred, you might want to use a specific tag and/or  
communicator for these extraordinary messages.  Then, when the event  
occurs, send a very short message on this special tag/communicator  
(potentially even a 0-byte message).  Open MPI will send short  
messages eagerly and not require multiple states through a progression  
machine (heck, just about all MPI's do this).  You can MPI_TEST for  
the completion of this short/0-byte receive very quickly.  You can  
then send the actual data of the event in a different non-blocking  
receive that is only checked if the short "alert" message is received.


There are a small number of cases (e.g., resource exhaustion) where  
Open MPI will have to fall back out of the eager send mode for short  
messages, but in general, sending a short message with an alert and a  
larger message with the actual data to be processed might be a good  
choice.



On Oct 1, 2009, at 10:43 PM, Peter Lonjers wrote:

I am not sure if this is the right place the ask this question but  
here

it goes.

Simplified abstract version of the question.
I have 2 MPI processes and I want one to make an occasional signal to
the other process.  These signals will not happen at predictable  
times.
I want the other process sitting in some kind of work loop to be  
able to

make a very fast check to see if a signal has been sent to it.

What is the best way to do this.

Actual problem
I am working on a realistic neural net simulator. The neurons are  
split

into groups with one group to each processor to simulate them.
Occasionally a neuron will spike and have to send that message to
neurons on a different processor. This is a relatively rare event. The
receiving neurons need to be able to make a very fast check to see if
there is a message from neurons on another processor.

The way I am doing it now is to use simple send and receive commands.
The receiving cell does an iprobe check on every loop through  the
simulation for every cell that connects to it to see if there is a
message(spike) from that cell. If the iprobe says there is a message  
is

does a receive on that message.

This seems convoluted though. I do not actually need to receive the
message just know that a message is there. And it seems like depending
on how Iprobe works there might be a faster method.

Is Iprobe fast if there is no message to receive?
Would persistent connections work better?



Anyway any help would be greatly appreciated.

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




--
Jeff Squyres
jsquy...@cisco.com



[OMPI users] Is Iprobe fast when there is no message to recieve

2009-10-01 Thread Peter Lonjers
I am not sure if this is the right place the ask this question but here
it goes.

Simplified abstract version of the question.
I have 2 MPI processes and I want one to make an occasional signal to
the other process.  These signals will not happen at predictable times.
I want the other process sitting in some kind of work loop to be able to
make a very fast check to see if a signal has been sent to it.

What is the best way to do this.

Actual problem
I am working on a realistic neural net simulator. The neurons are split
into groups with one group to each processor to simulate them.
Occasionally a neuron will spike and have to send that message to
neurons on a different processor. This is a relatively rare event. The
receiving neurons need to be able to make a very fast check to see if
there is a message from neurons on another processor.

The way I am doing it now is to use simple send and receive commands.
The receiving cell does an iprobe check on every loop through  the
simulation for every cell that connects to it to see if there is a
message(spike) from that cell. If the iprobe says there is a message is
does a receive on that message. 

This seems convoluted though. I do not actually need to receive the
message just know that a message is there. And it seems like depending
on how Iprobe works there might be a faster method. 

Is Iprobe fast if there is no message to receive?
Would persistent connections work better?



Anyway any help would be greatly appreciated.