[mpich-discuss] MPI_Probe

[Jie Chen]

Hello Nicolas,

Thank you very much for your kind reply. Let me describe my scenario. In my application each process needs data from every other processes and performs calculations. So a natural work flow, for process p0, is requests data from p1, does calculation; then requests data from p2, does calculation; so on and so forth. Even though the data are evenly distributed among processes, the work loads for each data are different. So other processes don't know when p0 requests data. Thus, a natural design is to let every process have 2 threads, while one thread is doing the normal calculations, the other is responsible for probing requests and sending/receiving data.

What concerns me, is the efficacy of this design. Since probing costs CPU cycles, and since after one process sends the data request, and it has to wait the other process to receive the request and to send the data, there might be a lot overhead introduced in addition to the normal calculations. The MPI standard only defines what probing does, but it does not define how probing is implemented. So I guess it would be hard to estimate in advance how large the overhead is.

On the other hand, knowing the overhead is beneficial, since I am at the stage of algorithmic design but not implementation. If I know that probing is problematic (which perhaps not), I would try to redo the algorithmic design and not allow things like "a process does not know when other processes request data from it" happen.

Jie






----------------------------------------------------------------------

Message: 1
Date: Sat, 7 Jan 2012 16:56:39 -0300
From: Nicolas Rosner <nrosner at gmail.com>
Subject: Re: [mpich-discuss] MPI_Probe
To: mpich-discuss at mcs.anl.gov
Message-ID:
	<CAMWXxrG4aE38FbQTjwWW_OftwU1oH+HVin-55uw-BZ-6eDRe-g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Jie,

The MPICH2 developers have already answered your questions, but may I
throw in an additional suggestion from an end user point of view?

> If in my process I have two threads, one of which issues the MPI_Probe call, will [...]

> In general I also want to understand what does MPI_Probe do [...]

I was wondering if perhaps you would be better off in such cases by
replacing "also" with "first"? Note that you don't need threads to
understand Probe, but you do need a firm grasp on the basics of Probe
to understand how it would behave in the presence of multithreading. I
mean this as just one possible example of a more general trend or
approach, of course (not really Probe-specific).

While mixing MPI with threads is possible and indeed quite common
nowadays, I think it's crucial to keep in mind that doing so
prematurely may be harmful to your learning curve. The complexities of
a scenario involving both are often considerably more than the sum of
their respective ones.

Personally, I'd ensure?having understood any relevant MPI
functionality without threads first.

Hope this helps!

Nicol?s