October 2015 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Wrong symlinks when using MPILIBNAME
by Balaji, Pavan 21 Oct '15

21 Oct '15

Umm. Sorry, that's my bad. Some overaggressive backward compatibility additions I did a few months ago. I'll work on a fix. -- Pavan On 10/21/15, 9:30 AM, "Torquil Macdonald Sørensen" <torquil(a)gmail.com> wrote: >If I set MPILIBNAME=mpich when running the configure script, I end up >with some wrong symlinks among the libraries. > >Inside /usr/lib, I get two links that point to themselves: > >libmpich.so -> libmpich.so >libmpichcxx.so -> libmpichcxx.so > >They should be: > >libmpich.so -> libmpich.so.0.0.0 >libmpichcxx.so -> libmpichcxx.so.0.0.0 > >On the other hand, the corresponding symlink for the fortran library is >correct: > >libmpichfort.so -> libmpichfort.so.0.0.0 > >I'm using 3.2rc1 and building with > >$ gcc --version >gcc (GCC) 5.2.1 20151020 > >If I don't set MPILIBNAME, the resulting libmpi* library files have >correct symlinks. > >Best regards >Torquil Macdonald Sørensen > >_______________________________________________ >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] error spawning processes in mpich-3.2rc1
by Min Si 21 Oct '15

21 Oct '15

Hi Siegmar, Thanks for providing us the test machine. We have confirmed this failure is caused by unaligned memory access inside MPICH. So the failure only happens on SPARC, which is alignment-sensitive. We will fix it. You can track the progress from this ticket. https://trac.mpich.org/projects/mpich/ticket/2309#ticket Because we do not have other SPARC platform, would you mind if we use your machine for testing during this fix ? Best regards, Min On 10/12/15 9:24 AM, Siegmar Gross wrote: > Hi Min, > >> It seems you already enabled the most detailed error outputs. We could >> not think out any clue for now. If you can give us access to your >> machine, we are glad to help you debug on it. > > Can you send me your email address because I don't want to send > login data to this list. > > > Kind regards > > Siegmar > > >> >> Min >> >> On 10/8/15 12:02 AM, Siegmar Gross wrote: >>> Hi Min, >>> >>> thank you very much for your answer. >>> >>>> We cannot reproduce this error on our test machines (Solaris i386, >>>> Ubuntu x86_64) by using your programs. And unfortunately we do not >>>> have >>>> Solaris Sparc machine thus could not verify it. >>> >>> The programs work fine on my Solaris x86_64 and Linux machines >>> as well. I only have a problem on Solaris Sparc. >>> >>> >>>> Sometime, it can happen that you need to add "./" in front of the >>>> program path, could you try it ? >>>> >>>> For example, in spawn_master.c MPI: A Message-Passing Interface >>>> Standard >>>>> #define SLAVE_PROG "./spawn_slave" >>> >>> No, it wil not work, because the programs are stored in a >>> different directory ($HOME/{SunOS, Linux}/{sparc, x86_64}/bin) >>> which is part of PATH (as well as "."). >>> >>> Can I do anything to track the source of the error? >>> >>> >>> Kind regards >>> >>> Siegmar >>> >>>> >>>> Min >>>> >>>> On 10/7/15 5:03 AM, Siegmar Gross wrote: >>>>> Hi, >>>>> >>>>> today I've built mpich-3.2rc1 on my machines (Solaris 10 Sparc, >>>>> Solaris 10 x86_64, and openSUSE Linux 12.1 x86_64) with gcc-5.1.0 >>>>> and Sun C 5.13. I still get the following errors on my Sparc machine >>>>> which I'd already reported September 8th. "mpiexec" is aliased to >>>>> 'mpiexec -genvnone'. It still doesn't matter if I use my cc- or >>>>> gcc-version of MPICH. >>>>> >>>>> >>>>> tyr spawn 119 mpichversion >>>>> MPICH Version: 3.2rc1 >>>>> MPICH Release date: Wed Oct 7 00:00:33 CDT 2015 >>>>> MPICH Device: ch3:nemesis >>>>> MPICH configure: --prefix=/usr/local/mpich-3.2_64_cc >>>>> --libdir=/usr/local/mpich-3.2_64_cc/lib64 >>>>> --includedir=/usr/local/mpich-3.2_64_cc/include64 CC=cc CXX=CC >>>>> F77=f77 >>>>> FC=f95 CFLAGS=-m64 CXXFLAGS=-m64 FFLAGS=-m64 FCFLAGS=-m64 >>>>> LDFLAGS=-m64 >>>>> -L/usr/lib/sparcv9 -R/usr/lib/sparcv9 --enable-fortran=yes >>>>> --enable-cxx --enable-romio --enable-debuginfo --enable-smpcoll >>>>> --enable-threads=multiple --with-thread-package=posix --enable-shared >>>>> MPICH CC: cc -m64 -O2 >>>>> MPICH CXX: CC -m64 -O2 >>>>> MPICH F77: f77 -m64 >>>>> MPICH FC: f95 -m64 -O2 >>>>> tyr spawn 120 >>>>> >>>>> >>>>> >>>>> tyr spawn 111 mpiexec -np 1 spawn_master >>>>> >>>>> Parent process 0 running on tyr.informatik.hs-fulda.de >>>>> I create 4 slave processes >>>>> >>>>> Fatal error in MPI_Comm_spawn: Unknown error class, error stack: >>>>> MPI_Comm_spawn(144)...........: MPI_Comm_spawn(cmd="spawn_slave", >>>>> argv=0, maxprocs=4, MPI_INFO_NULL, root=0, MPI_COMM_WORLD, >>>>> intercomm=ffffffff7fffde50, errors=0) failed >>>>> MPIDI_Comm_spawn_multiple(274): >>>>> MPID_Comm_accept(153).........: >>>>> MPIDI_Comm_accept(1057).......: >>>>> MPIR_Bcast_intra(1287)........: >>>>> MPIR_Bcast_binomial(310)......: Failure during collective >>>>> >>>>> >>>>> >>>>> >>>>> tyr spawn 112 mpiexec -np 1 spawn_multiple_master >>>>> >>>>> Parent process 0 running on tyr.informatik.hs-fulda.de >>>>> I create 3 slave processes. >>>>> >>>>> Fatal error in MPI_Comm_spawn_multiple: Unknown error class, error >>>>> stack: >>>>> MPI_Comm_spawn_multiple(162)..: MPI_Comm_spawn_multiple(count=2, >>>>> cmds=ffffffff7fffde08, argvs=ffffffff7fffddf8, >>>>> maxprocs=ffffffff7fffddf0, infos=ffffffff7fffdde8, root=0, >>>>> MPI_COMM_WORLD, intercomm=ffffffff7fffdde4, errors=0) failed >>>>> MPIDI_Comm_spawn_multiple(274): >>>>> MPID_Comm_accept(153).........: >>>>> MPIDI_Comm_accept(1057).......: >>>>> MPIR_Bcast_intra(1287)........: >>>>> MPIR_Bcast_binomial(310)......: Failure during collective >>>>> >>>>> >>>>> >>>>> >>>>> tyr spawn 113 mpiexec -np 1 spawn_intra_comm >>>>> Parent process 0: I create 2 slave processes >>>>> Fatal error in MPI_Comm_spawn: Unknown error class, error stack: >>>>> MPI_Comm_spawn(144)...........: >>>>> MPI_Comm_spawn(cmd="spawn_intra_comm", >>>>> argv=0, maxprocs=2, MPI_INFO_NULL, root=0, MPI_COMM_WORLD, >>>>> intercomm=ffffffff7fffded4, errors=0) failed >>>>> MPIDI_Comm_spawn_multiple(274): >>>>> MPID_Comm_accept(153).........: >>>>> MPIDI_Comm_accept(1057).......: >>>>> MPIR_Bcast_intra(1287)........: >>>>> MPIR_Bcast_binomial(310)......: Failure during collective >>>>> tyr spawn 114 >>>>> >>>>> >>>>> I would be grateful if somebody can fix the problem. Thank you very >>>>> much for any help in advance. I've attached my programs. Please let >>>>> me know if you need anything else. >>>>> >>>>> >>>>> Kind regards >>>>> >>>>> Siegmar >>>>> >>>>> >>>>> _______________________________________________ >>>>> discuss mailing listdiscuss(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 listdiscuss(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] mpich build error
by Rob Latham 21 Oct '15

21 Oct '15

The warnings are intel's preprocessor being a bit pickier than gnu's cpp the errors, though, are indeed odd. I will eat my sock if strncmp really truly is not on your system; far more likely the strncmp test failed for some unrelated reason. Look at your src/mpl/config.log. On my system, the (successful) check for strncmp looks like this: configure:12723: checking for strncmp configure:12723: ccache gcc -o conftest -Wall -g -Wno-unused-label -fstack-usage -fPIC -ggdb3 -I /home/robl/work/soft/lustre/include conftest.c >&5 conftest.c:65:6: warning: conflicting types for built-in function 'strncmp' char strncmp (); ^ configure:12723: $? = 0 configure:12723: result: yes configure:12734: checking whether strncmp needs a declaration configure:12752: ccache gcc -c -Wall -g -Wno-unused-label -fstack-usage -fPIC -ggdb3 -I /home/robl/work/soft/lustre/include conftest.c >&5 configure:12752: $? = 0 configure:12759: result: no Does yours look like this? ==rob > Hi, > > I am getting an error while trying to compile the latest mpich (from the > git repo) with Intel 15.0.1 compiler...excerpt of the error: > > In file included from ../../.././src/mpl/include/mpl.h(10), > from ../../.././src/mpl/src/mplstr.c(7): > ./include/mplconfig.h(238): warning #14: extra text after expected end > of preprocessing directive > #ifndef _mpl_ > ^ > > In file included from ../../.././src/mpl/include/mpl.h(10), > from ../../.././src/mpl/src/mplstr.c(7): > ./include/mplconfig.h(239): warning #2217: white space is required > between the macro name "_mpl_" and its replacement text > #define _mpl_ > ^ > > In file included from ../../.././src/mpl/include/mpl.h(111), > from ../../.././src/mpl/src/mplstr.c(7): > ../../.././src/mpl/include/mplstr.h(48): error: #error directive: > "strncmp is required" > #error "strncmp is required" > ^ > > ../../.././src/mpl/src/mplstr.c(41): warning #266: function "isdigit" > declared implicitly > if (isdigit(nc)) { > ^ > > Internal error: null pointer > > > Please suggest. > > -- > Regards, > Sayan > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Wrong symlinks when using MPILIBNAME
by Torquil Macdonald Sørensen 21 Oct '15

21 Oct '15

If I set MPILIBNAME=mpich when running the configure script, I end up with some wrong symlinks among the libraries. Inside /usr/lib, I get two links that point to themselves: libmpich.so -> libmpich.so libmpichcxx.so -> libmpichcxx.so They should be: libmpich.so -> libmpich.so.0.0.0 libmpichcxx.so -> libmpichcxx.so.0.0.0 On the other hand, the corresponding symlink for the fortran library is correct: libmpichfort.so -> libmpichfort.so.0.0.0 I'm using 3.2rc1 and building with $ gcc --version gcc (GCC) 5.2.1 20151020 If I don't set MPILIBNAME, the resulting libmpi* library files have correct symlinks. Best regards Torquil Macdonald Sørensen _______________________________________________ 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] mpich 3.1.4 with PBS Pro 12
by Seo, Sangmin 21 Oct '15

21 Oct '15

Hi Tsung, Hydra is configured to compile pbs_launch.c when tm.h and libtorque are found in the path. Does the path you specified in the “with-pbs” options have tm.h and libtorque? Regards, Sangmin > On Oct 20, 2015, at 4:31 AM, T. H. Chiang <th.chiang(a)gmail.com> wrote: > > Hi, > > I'm having trouble compiling hydra with the "--with-pbs" options, > something seem to be wrong with the configure steps > which causes files such as pbs_launch.c to be skipped during compilation. > > Anybody encountered similar problem/needs? > > -- > yours truly, > > Tsung Han Chiang / 江宗翰 > _______________________________________________ > 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

mpich build error
by Sayan Ghosh 20 Oct '15

20 Oct '15

Hi, I am getting an error while trying to compile the latest mpich (from the git repo) with Intel 15.0.1 compiler...excerpt of the error: In file included from ../../.././src/mpl/include/mpl.h(10), from ../../.././src/mpl/src/mplstr.c(7): ./include/mplconfig.h(238): warning #14: extra text after expected end of preprocessing directive #ifndef _mpl_ ^ In file included from ../../.././src/mpl/include/mpl.h(10), from ../../.././src/mpl/src/mplstr.c(7): ./include/mplconfig.h(239): warning #2217: white space is required between the macro name "_mpl_" and its replacement text #define _mpl_ ^ In file included from ../../.././src/mpl/include/mpl.h(111), from ../../.././src/mpl/src/mplstr.c(7): ../../.././src/mpl/include/mplstr.h(48): error: #error directive: "strncmp is required" #error "strncmp is required" ^ ../../.././src/mpl/src/mplstr.c(41): warning #266: function "isdigit" declared implicitly if (isdigit(nc)) { ^ Internal error: null pointer Please suggest. -- Regards, Sayan _______________________________________________ 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] Semantics of MPI_Send and MPI_Isend
by Dorier, Matthieu 20 Oct '15

20 Oct '15

That's good to know, thanks. Matthieu ________________________________________ From: Halim Amer [aamer(a)anl.gov] Sent: Tuesday, October 20, 2015 12:37 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] Semantics of MPI_Send and MPI_Isend Matthieu, My answer might be misleading because it was focused mostly on what the standard says. From an implementation perspective, large messages often go through a rendez-vous protocol and matching occurs before the actual data-movement takes place. Since matching large messages is decoupled from the corresponding data-movement, their actual transfer can be overlapped with the small Send operations in your example. --Halim www.mcs.anl.gov/~aamer On 10/20/15 11:02 AM, Dorier, Matthieu wrote: > Ok thanks! > Matthieu > ________________________________________ > From: Halim Amer [aamer(a)anl.gov] > Sent: Tuesday, October 20, 2015 10:57 AM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Semantics of MPI_Send and MPI_Isend > > I think understanding section 3.7.4 in MPI 3.1 is required as well. The > non-overtaking requirement of pt2pt communication is extended to > nonblocking communication with the notion of order. Basically, in your > code the Isend operation will not be matched if the previous Send > operation is still pending (if same target, same tag, and same > communicator). > > So yes, you will lose the benefit of asynchronous communication if you > introduce synchronous communication in the middle. Although a system > might buffer standard sends, it is implementation dependent and the user > should not rely on it. > > --Halim > www.mcs.anl.gov/~aamer > > On 10/20/15 10:17 AM, Jeff Hammond wrote: >> I recommend that you read "Semantics of Point-to-Point Communication" in >> the MPI standard (section 3.5 in MPI 3.1). It has all of the >> information that you seek. >> >> Best, >> >> Jeff >> >> >> On Tue, Oct 20, 2015 at 7:58 AM, Dorier, Matthieu <mdorier(a)anl.gov >> <mailto:[email protected]>> wrote: >> > >> > Hi, >> > >> > In my program I have a loop of this form: >> > >> > loop { >> > MPI_Send(small message) >> > MPI_Isend(big message) >> > } >> > do_some_computation() >> > MPI_Waitall >> > >> > The sends and isends all have the same target rank. >> > >> > Is there a risk that an MPI_Send forces a previously posted MPI_Isend >> to complete before it can complete itself (in which case I would loose >> the benefit of using non-blocking sends)? >> > >> > Thanks, >> > >> > Matthieu >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> 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 _______________________________________________ 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] Semantics of MPI_Send and MPI_Isend
by Halim Amer 20 Oct '15

20 Oct '15

Matthieu, My answer might be misleading because it was focused mostly on what the standard says. From an implementation perspective, large messages often go through a rendez-vous protocol and matching occurs before the actual data-movement takes place. Since matching large messages is decoupled from the corresponding data-movement, their actual transfer can be overlapped with the small Send operations in your example. --Halim www.mcs.anl.gov/~aamer On 10/20/15 11:02 AM, Dorier, Matthieu wrote: > Ok thanks! > Matthieu > ________________________________________ > From: Halim Amer [aamer(a)anl.gov] > Sent: Tuesday, October 20, 2015 10:57 AM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Semantics of MPI_Send and MPI_Isend > > I think understanding section 3.7.4 in MPI 3.1 is required as well. The > non-overtaking requirement of pt2pt communication is extended to > nonblocking communication with the notion of order. Basically, in your > code the Isend operation will not be matched if the previous Send > operation is still pending (if same target, same tag, and same > communicator). > > So yes, you will lose the benefit of asynchronous communication if you > introduce synchronous communication in the middle. Although a system > might buffer standard sends, it is implementation dependent and the user > should not rely on it. > > --Halim > www.mcs.anl.gov/~aamer > > On 10/20/15 10:17 AM, Jeff Hammond wrote: >> I recommend that you read "Semantics of Point-to-Point Communication" in >> the MPI standard (section 3.5 in MPI 3.1). It has all of the >> information that you seek. >> >> Best, >> >> Jeff >> >> >> On Tue, Oct 20, 2015 at 7:58 AM, Dorier, Matthieu <mdorier(a)anl.gov >> <mailto:[email protected]>> wrote: >> > >> > Hi, >> > >> > In my program I have a loop of this form: >> > >> > loop { >> > MPI_Send(small message) >> > MPI_Isend(big message) >> > } >> > do_some_computation() >> > MPI_Waitall >> > >> > The sends and isends all have the same target rank. >> > >> > Is there a risk that an MPI_Send forces a previously posted MPI_Isend >> to complete before it can complete itself (in which case I would loose >> the benefit of using non-blocking sends)? >> > >> > Thanks, >> > >> > Matthieu >> > >> > _______________________________________________ >> > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> > To manage subscription options or unsubscribe: >> > https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> 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] Semantics of MPI_Send and MPI_Isend
by Dorier, Matthieu 20 Oct '15

20 Oct '15

Ok thanks! Matthieu ________________________________________ From: Halim Amer [aamer(a)anl.gov] Sent: Tuesday, October 20, 2015 10:57 AM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] Semantics of MPI_Send and MPI_Isend I think understanding section 3.7.4 in MPI 3.1 is required as well. The non-overtaking requirement of pt2pt communication is extended to nonblocking communication with the notion of order. Basically, in your code the Isend operation will not be matched if the previous Send operation is still pending (if same target, same tag, and same communicator). So yes, you will lose the benefit of asynchronous communication if you introduce synchronous communication in the middle. Although a system might buffer standard sends, it is implementation dependent and the user should not rely on it. --Halim www.mcs.anl.gov/~aamer On 10/20/15 10:17 AM, Jeff Hammond wrote: > I recommend that you read "Semantics of Point-to-Point Communication" in > the MPI standard (section 3.5 in MPI 3.1). It has all of the > information that you seek. > > Best, > > Jeff > > > On Tue, Oct 20, 2015 at 7:58 AM, Dorier, Matthieu <mdorier(a)anl.gov > <mailto:[email protected]>> wrote: > > > > Hi, > > > > In my program I have a loop of this form: > > > > loop { > > MPI_Send(small message) > > MPI_Isend(big message) > > } > > do_some_computation() > > MPI_Waitall > > > > The sends and isends all have the same target rank. > > > > Is there a risk that an MPI_Send forces a previously posted MPI_Isend > to complete before it can complete itself (in which case I would loose > the benefit of using non-blocking sends)? > > > > Thanks, > > > > Matthieu > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > 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] Semantics of MPI_Send and MPI_Isend
by Halim Amer 20 Oct '15

20 Oct '15

I think understanding section 3.7.4 in MPI 3.1 is required as well. The non-overtaking requirement of pt2pt communication is extended to nonblocking communication with the notion of order. Basically, in your code the Isend operation will not be matched if the previous Send operation is still pending (if same target, same tag, and same communicator). So yes, you will lose the benefit of asynchronous communication if you introduce synchronous communication in the middle. Although a system might buffer standard sends, it is implementation dependent and the user should not rely on it. --Halim www.mcs.anl.gov/~aamer On 10/20/15 10:17 AM, Jeff Hammond wrote: > I recommend that you read "Semantics of Point-to-Point Communication" in > the MPI standard (section 3.5 in MPI 3.1). It has all of the > information that you seek. > > Best, > > Jeff > > > On Tue, Oct 20, 2015 at 7:58 AM, Dorier, Matthieu <mdorier(a)anl.gov > <mailto:[email protected]>> wrote: > > > > Hi, > > > > In my program I have a loop of this form: > > > > loop { > > MPI_Send(small message) > > MPI_Isend(big message) > > } > > do_some_computation() > > MPI_Waitall > > > > The sends and isends all have the same target rank. > > > > Is there a risk that an MPI_Send forces a previously posted MPI_Isend > to complete before it can complete itself (in which case I would loose > the benefit of using non-blocking sends)? > > > > Thanks, > > > > Matthieu > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > 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