[mpich-discuss] MPI polling question with MPI_Iprobe

[Nicolas Rosner]

Eric seems to mean how Probe() and Iprobe() are implemented, indeed:

> seems like both of these functions are doing polling instead of getting notification


But when he shows the loop example later on,

> while (true) {
>                //wait for message without using CPU power
>               //receive message and process it
> }

... I can't help but wonder whether perhaps he's busy-waiting
unnecessarily tightly on Probe() himself? If so, perhaps inserting a
short usleep() between probe calls might alleviate the load (assuming
he can afford the latency).

Eric, if you did mean what Probe does internally and this is obvious,
please disregard.

Hth N.






On Wed, Sep 21, 2011 at 4:25 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
> Hi Eric,
>
> On 09/21/2011 01:56 PM, Eric Hui wrote:
>>
>> I found that there is MPI_Probe and MPI_Iprobe. It seems like both of
>> these functions are doing polling instead of getting notification when
>> there is message arrived, so it is taking up 100% of the CPU power even
>> when it is just idling to wait for message.
>
> Most MPI implementations are optimized for latency, so they poll frequently
> to ensure that. You can configure MPICH2 with --with-device=ch3:sock to get
> "blocking mode" (meaning MPI will sleep when there is nothing to do), but
> this is very implementation specific. If you configure MPICH2 differently or
> use a different MPI implementation, you might go back to the "polling mode"
> which you are currently seeing.
>
>  -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
> _______________________________________________
> mpich-discuss mailing list     mpich-discuss at mcs.anl.gov
> To manage subscription options or unsubscribe:
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>