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

Re: [mpich-discuss] One Mistake in MPICH Wiki
by Balaji, Pavan 22 Aug '14

22 Aug '14

Thank you. I’ve corrected it on the wiki. Regards, — Pavan On Aug 22, 2014, at 7:30 AM, 俞博文 <jxb002(a)qq.com> wrote: > Hi, > > I am using MPICH-3.1.2 with Hydra process manager, and I use ssh as daemon. I need to specify a private key for password-less login ( ssh -i <FILENAME> ). Document below says there is one environment variable HYDRA_LAUNCH_EXTRA_ARGS which controls the arguments passed to the launcher(ssh). > https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Envi… > > However, it doesn't work. After I checked the source code, it is actually HYDRA_LAUNCHER_EXTRA_ARGS, so there is one mistake in that document. This is troublesome for beginners. > > Thanks, > Steven > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Balaji, Pavan 22 Aug '14

22 Aug '14

On Aug 21, 2014, at 8:42 PM, Nick Radcliffe <nradclif(a)cray.com> wrote: >> If buffers overlap, use memmov and not memcpy: > > Good point, you would have to use memmov in general for overlapping source and target buffers. I was thinking of the special case where the source and target buffers are identical. > >> I don’t think so. It’s an incorrect program to get from a buffer to itself. MPICH is being helpful is catching this user error. > > Do you know where in the standard this is specified? I'm having trouble finding it. The parameter in PUT is a “const void *”. It’s read-only for MPI. — Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

One Mistake in MPICH Wiki
by 俞博文 22 Aug '14

22 Aug '14

Hi, I am using MPICH-3.1.2 with Hydra process manager, and I use ssh as daemon. I need to specify a private key for password-less login ( ssh -i <FILENAME> ). Document below says there is one environment variable HYDRA_LAUNCH_EXTRA_ARGS which controls the arguments passed to the launcher(ssh).‍ https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Envi… However, it doesn't work. After I checked the source code, it is actually HYDRA_LAUNCHER_EXTRA_ARGS, so there is one mistake in that document. This is troublesome for beginners. Thanks, Steven

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Boisvert, Sebastien 21 Aug '14

21 Aug '14

> ________________________________________ > From: Nick Radcliffe [nradclif(a)cray.com] > Sent: Thursday, August 21, 2014 8:42 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > If buffers overlap, use memmov and not memcpy: > Good point, you would have to use memmov in general for overlapping source and target buffers. I was thinking of the special case where the source and target buffers are identical. Identical buffers overlap, right ? So MPICH should not be calling memcpy with those operands, or the user should not do that in the first place maybe. > > I don’t think so. It’s an incorrect program to get from a buffer to itself. MPICH is being helpful is catching this user error. > Do you know where in the standard this is specified? I'm having trouble finding it. > -Nick > ________________________________________ > From: Boisvert, Sebastien [boisvert(a)anl.gov] > Sent: Thursday, August 21, 2014 7:30 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > ________________________________________ > > From: Nick Radcliffe [nradclif(a)cray.com] > > Sent: Thursday, August 21, 2014 5:47 PM > > To: discuss(a)mpich.org > > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > > src=0x19a5f40 len=4 > > It looks like memcpy is doing a check to make sure the source and destination buffers don't overlap. This seems like a bug to me -- when doing an MPI_Get from a buffer to itself, the implementation should probably just do nothing and return. > I disagree. > If buffers overlap, use memmov and not memcpy: > " If copying takes place between objects that overlap, the behavior is undefined." > --source: http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html > Also: > http://stackoverflow.com/questions/1960991/which-one-to-use-memmove-or-memc… > > > -Nick > > ________________________________________ > > From: alessandro.fanfarillo(a)gmail.com [alessandro.fanfarillo(a)gmail.com] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it] > > Sent: Thursday, August 21, 2014 5:25 PM > > To: discuss(a)mpich.org > > Subject: [mpich-discuss] MPI_Get on the same memory location > > Dear all, > > I'm having the following error: > > Fatal error in MPI_Get: Internal MPI error!, error stack: > > MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, > > MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, > > win=0xa0000000) failed > > MPIDI_Get(247).....: > > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > > src=0x19a5f40 len=4 > > if I try to execute MPI_Get on the same memory location on a shared > > memory machine (my laptop). > > I cannot find anything in the standard that denies it for the one-sided. > > Running with OpenMPI everything works fine. > > Is it a bug or I missed something in the standard? > > Thanks. > > Alessandro > > -- > > Alessandro Fanfarillo > > Dip. di Ingegneria Civile ed Ingegneria Informatica > > Università di Roma "Tor Vergata" > > NCAR Office: +1 (303) 497-2442 > > Tel: +39-06-7259 7719 > > _______________________________________________ > > 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] MPI_Get on the same memory location
by Nick Radcliffe 21 Aug '14

21 Aug '14

> If buffers overlap, use memmov and not memcpy: Good point, you would have to use memmov in general for overlapping source and target buffers. I was thinking of the special case where the source and target buffers are identical. > I don’t think so. It’s an incorrect program to get from a buffer to itself. MPICH is being helpful is catching this user error. Do you know where in the standard this is specified? I'm having trouble finding it. -Nick ________________________________________ From: Boisvert, Sebastien [boisvert(a)anl.gov] Sent: Thursday, August 21, 2014 7:30 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] MPI_Get on the same memory location > ________________________________________ > From: Nick Radcliffe [nradclif(a)cray.com] > Sent: Thursday, August 21, 2014 5:47 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > src=0x19a5f40 len=4 > It looks like memcpy is doing a check to make sure the source and destination buffers don't overlap. This seems like a bug to me -- when doing an MPI_Get from a buffer to itself, the implementation should probably just do nothing and return. I disagree. If buffers overlap, use memmov and not memcpy: " If copying takes place between objects that overlap, the behavior is undefined." --source: http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html Also: http://stackoverflow.com/questions/1960991/which-one-to-use-memmove-or-memc… > -Nick > ________________________________________ > From: alessandro.fanfarillo(a)gmail.com [alessandro.fanfarillo(a)gmail.com] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it] > Sent: Thursday, August 21, 2014 5:25 PM > To: discuss(a)mpich.org > Subject: [mpich-discuss] MPI_Get on the same memory location > Dear all, > I'm having the following error: > Fatal error in MPI_Get: Internal MPI error!, error stack: > MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, > MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, > win=0xa0000000) failed > MPIDI_Get(247).....: > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > src=0x19a5f40 len=4 > if I try to execute MPI_Get on the same memory location on a shared > memory machine (my laptop). > I cannot find anything in the standard that denies it for the one-sided. > Running with OpenMPI everything works fine. > Is it a bug or I missed something in the standard? > Thanks. > Alessandro > -- > Alessandro Fanfarillo > Dip. di Ingegneria Civile ed Ingegneria Informatica > Università di Roma "Tor Vergata" > NCAR Office: +1 (303) 497-2442 > Tel: +39-06-7259 7719 > _______________________________________________ > 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

MPICH make clean requires sudo and mucks with DESTDIR
by Barry Smith 21 Aug '14

21 Aug '14

In the root Makefile is # we can only have one clean-local, so we hook into it via conditionally # defined variables in the dependencies section clean-local: $(CLEAN_LOCAL_TARGETS) rm -f ${DESTDIR}${bindir}/mpic++ I do not see how this could be correct, since 1) mucking with DESTDIR would require sudo for some configurations and make clean shouldn’t require sudo 2) should make clean muck with DESTDIR anyways? When I run make clean after a make install I do get an permissions error in trying to remove that link. Barry

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Alessandro Fanfarillo 21 Aug '14

21 Aug '14

Thank you all for the replies, I have this error with mpich2-1.5 and I have the similar behavior with a slightly different error message with mpich-3.1.2. About the code, the situation is a bit more difficult: I wrote a library which implements the coarray support in gfortran. In other words, gfortran translates the coarray syntax in library calls, the library implements the communication using the one-sided routines. Copying a value on the same buffer is allowed by coarrays (it is not an error). I have the same Nick's opinion; anyway, if the standard does not tell anything about this case it is up to the implementation. I'm going to modify the library in order to manage this case. Thanks all. On Thu, Aug 21, 2014 at 4:42 PM, Seo, Sangmin <sseo(a)anl.gov> wrote: > Hi Alessandro, > > It is very hard to think about the reason for your problem without any code. > Can you send us your test code and the version of MPICH you are using? > > Thanks, > -- > Sangmin Seo > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > http://www.mcs.anl.gov/~sseo/ > > > On Aug 21, 2014, at 5:25 PM, Alessandro Fanfarillo > <fanfarillo(a)ing.uniroma2.it> wrote: > > Dear all, > > I'm having the following error: > > Fatal error in MPI_Get: Internal MPI error!, error stack: > MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, > MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, > win=0xa0000000) failed > MPIDI_Get(247).....: > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > src=0x19a5f40 len=4 > > if I try to execute MPI_Get on the same memory location on a shared > memory machine (my laptop). > > I cannot find anything in the standard that denies it for the one-sided. > > Running with OpenMPI everything works fine. > > Is it a bug or I missed something in the standard? > > Thanks. > > Alessandro > > -- > > Alessandro Fanfarillo > Dip. di Ingegneria Civile ed Ingegneria Informatica > Università di Roma "Tor Vergata" > NCAR Office: +1 (303) 497-2442 > Tel: +39-06-7259 7719 > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > -- Alessandro Fanfarillo Dip. di Ingegneria Civile ed Ingegneria Informatica Università di Roma "Tor Vergata" NCAR Office: +1 (303) 497-2442 Tel: +39-06-7259 7719

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Boisvert, Sebastien 21 Aug '14

21 Aug '14

> ________________________________________ > From: Balaji, Pavan [balaji(a)anl.gov] > Sent: Thursday, August 21, 2014 7:27 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > I don’t think so. It’s an incorrect program to get from a buffer to itself. MPICH is being helpful is catching this user error. This is also my opinion. > — Pavan > On Aug 21, 2014, at 7:10 PM, Nick Radcliffe <nradclif(a)cray.com> wrote: > > I didn't mean there was a bug in memcpy. I meant the bug was in MPI_Get, which should indeed be checking that pointers are not aliased. > > > > -Nick > > > > From: Brian Van Straalen [bvstraalen(a)lbl.gov] > > Sent: Thursday, August 21, 2014 6:21 PM > > To: discuss(a)mpich.org > > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > > > It depends on what version of memcpy you are using. If you are calling IEEE std 1003.1 2004 then memcpy is defined as > > > > void *memcpy(void *restrict s1, const void *restrict s2, size_t n); > > > > so this form of calling memcpy is illegal and the error from memcpy is correct. > > > > The routine calling memcpy should verify you are not aliased, or incorrect behavior is very likely on newer architectures. It would be better to check for aliased data before calling memcpy. > > > > Brian Van Straalen > > > > > > On Aug 21, 2014, at 3:47 PM, Nick Radcliffe <nradclif(a)cray.com> wrote: > > > >>> MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > >> src=0x19a5f40 len=4 > >> > >> It looks like memcpy is doing a check to make sure the source and destination buffers don't overlap. This seems like a bug to me -- when doing an MPI_Get from a buffer to itself, the implementation should probably just do nothing and return. > >> > >> -Nick > >> > >> ________________________________________ > >> From: alessandro.fanfarillo(a)gmail.com [alessandro.fanfarillo(a)gmail.com] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it] > >> Sent: Thursday, August 21, 2014 5:25 PM > >> To: discuss(a)mpich.org > >> Subject: [mpich-discuss] MPI_Get on the same memory location > >> > >> Dear all, > >> > >> I'm having the following error: > >> > >> Fatal error in MPI_Get: Internal MPI error!, error stack: > >> MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, > >> MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, > >> win=0xa0000000) failed > >> MPIDI_Get(247).....: > >> MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > >> src=0x19a5f40 len=4 > >> > >> if I try to execute MPI_Get on the same memory location on a shared > >> memory machine (my laptop). > >> > >> I cannot find anything in the standard that denies it for the one-sided. > >> > >> Running with OpenMPI everything works fine. > >> > >> Is it a bug or I missed something in the standard? > >> > >> Thanks. > >> > >> Alessandro > >> > >> -- > >> > >> Alessandro Fanfarillo > >> Dip. di Ingegneria Civile ed Ingegneria Informatica > >> Università di Roma "Tor Vergata" > >> NCAR Office: +1 (303) 497-2442 > >> Tel: +39-06-7259 7719 > >> _______________________________________________ > >> 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 > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > _______________________________________________ > 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] MPI_Get on the same memory location
by Boisvert, Sebastien 21 Aug '14

21 Aug '14

> ________________________________________ > From: Nick Radcliffe [nradclif(a)cray.com] > Sent: Thursday, August 21, 2014 5:47 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > src=0x19a5f40 len=4 > It looks like memcpy is doing a check to make sure the source and destination buffers don't overlap. This seems like a bug to me -- when doing an MPI_Get from a buffer to itself, the implementation should probably just do nothing and return. I disagree. If buffers overlap, use memmov and not memcpy: " If copying takes place between objects that overlap, the behavior is undefined." --source: http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html Also: http://stackoverflow.com/questions/1960991/which-one-to-use-memmove-or-memc… > -Nick > ________________________________________ > From: alessandro.fanfarillo(a)gmail.com [alessandro.fanfarillo(a)gmail.com] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it] > Sent: Thursday, August 21, 2014 5:25 PM > To: discuss(a)mpich.org > Subject: [mpich-discuss] MPI_Get on the same memory location > Dear all, > I'm having the following error: > Fatal error in MPI_Get: Internal MPI error!, error stack: > MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, > MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, > win=0xa0000000) failed > MPIDI_Get(247).....: > MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 > src=0x19a5f40 len=4 > if I try to execute MPI_Get on the same memory location on a shared > memory machine (my laptop). > I cannot find anything in the standard that denies it for the one-sided. > Running with OpenMPI everything works fine. > Is it a bug or I missed something in the standard? > Thanks. > Alessandro > -- > Alessandro Fanfarillo > Dip. di Ingegneria Civile ed Ingegneria Informatica > Università di Roma "Tor Vergata" > NCAR Office: +1 (303) 497-2442 > Tel: +39-06-7259 7719 > _______________________________________________ > 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] MPI_Get on the same memory location
by Balaji, Pavan 21 Aug '14

21 Aug '14

I don’t think so. It’s an incorrect program to get from a buffer to itself. MPICH is being helpful is catching this user error. — Pavan On Aug 21, 2014, at 7:10 PM, Nick Radcliffe <nradclif(a)cray.com> wrote: > I didn't mean there was a bug in memcpy. I meant the bug was in MPI_Get, which should indeed be checking that pointers are not aliased. > > -Nick > > From: Brian Van Straalen [bvstraalen(a)lbl.gov] > Sent: Thursday, August 21, 2014 6:21 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI_Get on the same memory location > > It depends on what version of memcpy you are using. If you are calling IEEE std 1003.1 2004 then memcpy is defined as > > void *memcpy(void *restrict s1, const void *restrict s2, size_t n); > > so this form of calling memcpy is illegal and the error from memcpy is correct. > > The routine calling memcpy should verify you are not aliased, or incorrect behavior is very likely on newer architectures. It would be better to check for aliased data before calling memcpy. > > Brian Van Straalen > > > On Aug 21, 2014, at 3:47 PM, Nick Radcliffe <nradclif(a)cray.com> wrote: > >>> MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 >> src=0x19a5f40 len=4 >> >> It looks like memcpy is doing a check to make sure the source and destination buffers don't overlap. This seems like a bug to me -- when doing an MPI_Get from a buffer to itself, the implementation should probably just do nothing and return. >> >> -Nick >> >> ________________________________________ >> From: alessandro.fanfarillo(a)gmail.com [alessandro.fanfarillo(a)gmail.com] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it] >> Sent: Thursday, August 21, 2014 5:25 PM >> To: discuss(a)mpich.org >> Subject: [mpich-discuss] MPI_Get on the same memory location >> >> Dear all, >> >> I'm having the following error: >> >> Fatal error in MPI_Get: Internal MPI error!, error stack: >> MPI_Get(156).......: MPI_Get(origin_addr=0x19a5f40, origin_count=4, >> MPI_BYTE, target_rank=0, target_disp=0, target_count=4, MPI_BYTE, >> win=0xa0000000) failed >> MPIDI_Get(247).....: >> MPIR_Localcopy(357): memcpy arguments alias each other, dst=0x19a5f40 >> src=0x19a5f40 len=4 >> >> if I try to execute MPI_Get on the same memory location on a shared >> memory machine (my laptop). >> >> I cannot find anything in the standard that denies it for the one-sided. >> >> Running with OpenMPI everything works fine. >> >> Is it a bug or I missed something in the standard? >> >> Thanks. >> >> Alessandro >> >> -- >> >> Alessandro Fanfarillo >> Dip. di Ingegneria Civile ed Ingegneria Informatica >> Università di Roma "Tor Vergata" >> NCAR Office: +1 (303) 497-2442 >> Tel: +39-06-7259 7719 >> _______________________________________________ >> 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 -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0