August 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Generalized request classes
by Rajeev Thakur 05 Aug '13

05 Aug '13

One more thing. If the receive buffers can be allocated before hand to be large enough, you can simply post a receive of a large size. It doesn't have to match the send size. It can be larger (not smaller). On Aug 5, 2013, at 12:08 PM, Jed Brown wrote: > Rajeev Thakur <thakur(a)mcs.anl.gov> writes: > >> If the sizes of messages are that unknown, you can also try MPI >> one-sided communication. > > I'd have thought the reason to use Iprobe was that the receive buffers > could not be allocated in advance, in which case one-sided puts don't > buy you anything and gets require the sizes and addresses to be sent > somehow. > >> On Aug 5, 2013, at 9:48 AM, Matthieu Dorier wrote: >> >>> For the Iprob, the case I'm considering is indeed the one where a >>> process has to do non-blocking sends and non-blocking receives of >>> undefined lengths; I ended up with two options: 1) using a busy loop >>> that does an MPI_Testany for the list of send requests and a series >>> of MPI_Iprob for a list of (source,tag) pairs, or 2) split each >>> receive operation into one Irecv of known length 1 MPI_INT that gives >>> the size of the next message, then a blocking MPI_Recv of this >>> size. No busy loop needed by one extra (yet small) message. > > A third option is to MPI_Probe on MPI_ANY_SOURCE for the expected number > of receives, allocating your receive buffer when you know the size. > This assumes you can use a single tag for the round of communication.

1 0

Re: [mpich-discuss] Generalized request classes
by Jed Brown 05 Aug '13

05 Aug '13

Rajeev Thakur <thakur(a)mcs.anl.gov> writes: > If the sizes of messages are that unknown, you can also try MPI > one-sided communication. I'd have thought the reason to use Iprobe was that the receive buffers could not be allocated in advance, in which case one-sided puts don't buy you anything and gets require the sizes and addresses to be sent somehow. > On Aug 5, 2013, at 9:48 AM, Matthieu Dorier wrote: > >> For the Iprob, the case I'm considering is indeed the one where a >> process has to do non-blocking sends and non-blocking receives of >> undefined lengths; I ended up with two options: 1) using a busy loop >> that does an MPI_Testany for the list of send requests and a series >> of MPI_Iprob for a list of (source,tag) pairs, or 2) split each >> receive operation into one Irecv of known length 1 MPI_INT that gives >> the size of the next message, then a blocking MPI_Recv of this >> size. No busy loop needed by one extra (yet small) message. A third option is to MPI_Probe on MPI_ANY_SOURCE for the expected number of receives, allocating your receive buffer when you know the size. This assumes you can use a single tag for the round of communication.

1 0

Re: [mpich-discuss] Generalized request classes
by Rajeev Thakur 05 Aug '13

05 Aug '13

If the sizes of messages are that unknown, you can also try MPI one-sided communication. Rajeev On Aug 5, 2013, at 9:48 AM, Matthieu Dorier wrote: > For the Iprob, the case I'm considering is indeed the one where a process has to do non-blocking sends and non-blocking receives of undefined lengths; I ended up with two options: 1) using a busy loop that does an MPI_Testany for the list of send requests and a series of MPI_Iprob for a list of (source,tag) pairs, or > 2) split each receive operation into one Irecv of known length 1 MPI_INT that gives the size of the next message, then a blocking MPI_Recv of this size. No busy loop needed by one extra (yet small) message. > > Matthieu > > De: "Jim Dinan" <james.dinan(a)gmail.com> > À: discuss(a)mpich.org > Envoyé: Lundi 5 Août 2013 08:28:42 > Objet: Re: [mpich-discuss] Generalized request classes > > MPI Grequests do generally require external progress, usually polling or a thread. It would be nice to see if we can make progress on the MPIX Grequests proposal. There are several unresolved issues holding up this proposal. Off the top of my head: What progress must MPI provide for the MPIX Grequest? How does this affect performance of implementations that do messaging in hardware? What can one do from within the polling function (make MPI calls, allocate memory, etc)? > > Your question about Iprobe is interesting... One could imagine doing an MPI_Waitany on several communications, including one to receive a message of unknown length. I think the only way to do this right now would be to poll using Iprobe and Testany. > > ~Jim. > > > On Sun, Aug 4, 2013 at 6:24 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > MPI_Iprobe does not do any communication itself. It doesn't do a receive, for example. So there is no need to call test/wait after an Iprobe, since there is nothing to complete. Hence no request object. > > Rajev > > > On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote: > > > Hi, > > > > Is there any hope that the currently non-standard generalized request interface (MPIX_Grequest_*) in mpich eventually becomes part of the standard (or something that looks like this API)? > > I just spent two days hopelessly trying to develop something with the standard generalized requests, but gave up: this API is basically useless unless a thread is used to do the MPI_Grequest_complete. > > > > For information, what I was trying to do was a custom version of MPI_Iprobe that takes an MPI_Request* parameter instead of a int* flag and an MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} on requests generated by different types of non-blocking operations including MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have this signature already? That would have make more sense, in my opinion). > > > > Matthieu Dorier > > PhD student at ENS Cachan Brittany and IRISA > > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Generalized request classes
by Matthieu Dorier 05 Aug '13

05 Aug '13

For the Iprob, the case I'm considering is indeed the one where a process has to do non-blocking sends and non-blocking receives of undefined lengths; I ended up with two options: 1) using a busy loop that does an MPI_Testany for the list of send requests and a series of MPI_Iprob for a list of (source,tag) pairs, or 2) split each receive operation into one Irecv of known length 1 MPI_INT that gives the size of the next message, then a blocking MPI_Recv of this size. No busy loop needed by one extra (yet small) message. Matthieu ----- Mail original ----- > De: "Jim Dinan" <james.dinan(a)gmail.com> > À: discuss(a)mpich.org > Envoyé: Lundi 5 Août 2013 08:28:42 > Objet: Re: [mpich-discuss] Generalized request classes > MPI Grequests do generally require external progress, usually polling > or a thread. It would be nice to see if we can make progress on the > MPIX Grequests proposal. There are several unresolved issues holding > up this proposal. Off the top of my head: What progress must MPI > provide for the MPIX Grequest? How does this affect performance of > implementations that do messaging in hardware? What can one do from > within the polling function (make MPI calls, allocate memory, etc)? > Your question about Iprobe is interesting... One could imagine doing > an MPI_Waitany on several communications, including one to receive a > message of unknown length. I think the only way to do this right now > would be to poll using Iprobe and Testany. > ~Jim. > On Sun, Aug 4, 2013 at 6:24 PM, Rajeev Thakur < thakur(a)mcs.anl.gov > > wrote: > > MPI_Iprobe does not do any communication itself. It doesn't do a > > receive, for example. So there is no need to call test/wait after > > an > > Iprobe, since there is nothing to complete. Hence no request > > object. > > > Rajev > > > On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote: > > > > Hi, > > > > > > > > Is there any hope that the currently non-standard generalized > > > request interface (MPIX_Grequest_*) in mpich eventually becomes > > > part of the standard (or something that looks like this API)? > > > > I just spent two days hopelessly trying to develop something with > > > the standard generalized requests, but gave up: this API is > > > basically useless unless a thread is used to do the > > > MPI_Grequest_complete. > > > > > > > > For information, what I was trying to do was a custom version of > > > MPI_Iprobe that takes an MPI_Request* parameter instead of a int* > > > flag and an MPI_Status*, in order to be able to call > > > MPI_{Wait,Test}{all,any,some} on requests generated by different > > > types of non-blocking operations including MPI_Iprob. (btw, is > > > there a reason why MPI_Iprob doesn't have this signature already? > > > That would have make more sense, in my opinion). > > > > > > > > Matthieu Dorier > > > > PhD student at ENS Cachan Brittany and IRISA > > > > http://people.irisa.fr/Matthieu.Dorier > > > > _______________________________________________ > > > > discuss mailing list discuss(a)mpich.org > > > > To manage subscription options or unsubscribe: > > > > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > > > discuss mailing list discuss(a)mpich.org > > > To manage subscription options or unsubscribe: > > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Generalized request classes
by Jim Dinan 05 Aug '13

05 Aug '13

MPI Grequests do generally require external progress, usually polling or a thread. It would be nice to see if we can make progress on the MPIX Grequests proposal. There are several unresolved issues holding up this proposal. Off the top of my head: What progress must MPI provide for the MPIX Grequest? How does this affect performance of implementations that do messaging in hardware? What can one do from within the polling function (make MPI calls, allocate memory, etc)? Your question about Iprobe is interesting... One could imagine doing an MPI_Waitany on several communications, including one to receive a message of unknown length. I think the only way to do this right now would be to poll using Iprobe and Testany. ~Jim. On Sun, Aug 4, 2013 at 6:24 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > MPI_Iprobe does not do any communication itself. It doesn't do a receive, > for example. So there is no need to call test/wait after an Iprobe, since > there is nothing to complete. Hence no request object. > > Rajev > > > On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote: > > > Hi, > > > > Is there any hope that the currently non-standard generalized request > interface (MPIX_Grequest_*) in mpich eventually becomes part of the > standard (or something that looks like this API)? > > I just spent two days hopelessly trying to develop something with the > standard generalized requests, but gave up: this API is basically useless > unless a thread is used to do the MPI_Grequest_complete. > > > > For information, what I was trying to do was a custom version of > MPI_Iprobe that takes an MPI_Request* parameter instead of a int* flag and > an MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} > on requests generated by different types of non-blocking operations > including MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have > this signature already? That would have make more sense, in my opinion). > > > > Matthieu Dorier > > PhD student at ENS Cachan Brittany and IRISA > > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Hello, I have a question regarding fmpich2s.lib
by Wesley Bland 04 Aug '13

04 Aug '13

Sorry, but we stopped supporting Windows builds a while back. There's an FAQ about it here: http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… Wesley On Sunday, August 4, 2013 at 12:41 AM, 王祺 wrote: > > Hello: > I am a new user in MPICH. Recently I use > MPICH2-1.4 + windows8 624bit + Visual Studio 2010 + Intel fortran XE parallel 2011 > After I installed MPICH2-1.4 using the .msi file, I run my project(which need all fmpich2.lib, fmpich2g.lib, fmpich2s.lib). > It is okay with fmpich2.lib and fmpich2g.lib, but I can't find fmpich2s.lib installed. > There is a mpich2s.vcproj in the source code, But I don't know how to use or install it. > Can you help me with this? It bothed me for a long time. > Thank you very much. > > Wang Qi > _______________________________________________ > discuss mailing list discuss(a)mpich.org (mailto:[email protected]) > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > >

1 0

Re: [mpich-discuss] Generalized request classes
by Rajeev Thakur 04 Aug '13

04 Aug '13

MPI_Iprobe does not do any communication itself. It doesn't do a receive, for example. So there is no need to call test/wait after an Iprobe, since there is nothing to complete. Hence no request object. Rajev On Aug 4, 2013, at 12:05 PM, Matthieu Dorier wrote: > Hi, > > Is there any hope that the currently non-standard generalized request interface (MPIX_Grequest_*) in mpich eventually becomes part of the standard (or something that looks like this API)? > I just spent two days hopelessly trying to develop something with the standard generalized requests, but gave up: this API is basically useless unless a thread is used to do the MPI_Grequest_complete. > > For information, what I was trying to do was a custom version of MPI_Iprobe that takes an MPI_Request* parameter instead of a int* flag and an MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} on requests generated by different types of non-blocking operations including MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have this signature already? That would have make more sense, in my opinion). > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Generalized request classes
by Jeff Hammond 04 Aug '13

04 Aug '13

https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Proposal has stalled. If you want to go to Spain in September and try to push it forward, I think people might be willing to help you. At this point, you should subscribe to http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-greq and have further discussion of this issue there. I copied that list to make the transition seemless. Best, Jeff On Sun, Aug 4, 2013 at 12:05 PM, Matthieu Dorier <matthieu.dorier(a)irisa.fr> wrote: > Hi, > > Is there any hope that the currently non-standard generalized request > interface (MPIX_Grequest_*) in mpich eventually becomes part of the standard > (or something that looks like this API)? > I just spent two days hopelessly trying to develop something with the > standard generalized requests, but gave up: this API is basically useless > unless a thread is used to do the MPI_Grequest_complete. > > For information, what I was trying to do was a custom version of MPI_Iprobe > that takes an MPI_Request* parameter instead of a int* flag and an > MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} on > requests generated by different types of non-blocking operations including > MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have this signature > already? That would have make more sense, in my opinion). > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com

1 0

Generalized request classes
by Matthieu Dorier 04 Aug '13

04 Aug '13

Hi, Is there any hope that the currently non-standard generalized request interface (MPIX_Grequest_*) in mpich eventually becomes part of the standard (or something that looks like this API)? I just spent two days hopelessly trying to develop something with the standard generalized requests, but gave up: this API is basically useless unless a thread is used to do the MPI_Grequest_complete. For information, what I was trying to do was a custom version of MPI_Iprobe that takes an MPI_Request* parameter instead of a int* flag and an MPI_Status*, in order to be able to call MPI_{Wait,Test}{all,any,some} on requests generated by different types of non-blocking operations including MPI_Iprob. (btw, is there a reason why MPI_Iprob doesn't have this signature already? That would have make more sense, in my opinion). Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier

1 0

Hello, I have a question regarding fmpich2s.lib
by 王祺 04 Aug '13

04 Aug '13

Hello: I am a new user in MPICH. Recently I use MPICH2-1.4 + windows8 624bit + Visual Studio 2010 + Intel fortran XE parallel 2011 After I installed MPICH2-1.4 using the .msi file, I run my project(which need all fmpich2.lib, fmpich2g.lib, fmpich2s.lib). It is okay with fmpich2.lib and fmpich2g.lib, but I can't find fmpich2s.lib installed. There is a mpich2s.vcproj in the source code, But I don't know how to use or install it. Can you help me with this? It bothed me for a long time. Thank you very much. Wang Qi

1 0