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

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

21 Aug '14

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<mailto:[email protected]>> 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<mailto:[email protected]> [alessandro.fanfarillo(a)gmail.com<mailto:[email protected]>] on behalf of Alessandro Fanfarillo [fanfarillo(a)ing.uniroma2.it<mailto:[email protected]>] Sent: Thursday, August 21, 2014 5:25 PM To: discuss(a)mpich.org<mailto:[email protected]> 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<mailto:[email protected]> 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 Brian Van Straalen 21 Aug '14

21 Aug '14

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

1 0

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

21 Aug '14

> 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

1 0

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

21 Aug '14

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<mailto:[email protected]>> 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<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI_Get on the same memory location
by Alessandro Fanfarillo 21 Aug '14

21 Aug '14

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

1 0

Re: [mpich-discuss] inter-language compatibility
by Rob Latham 21 Aug '14

21 Aug '14

On 08/21/2014 12:24 PM, Michael L. Stokes wrote: > And to mix it up a bit, let's also > assume that some of the processes (C or FORTRAN) are using mixed native > word sizes (32/64 bit). heterogenous nodes will require MPICH-1.2.7p1. Good luck should you choose to take that route -- no one can offer you any support for it. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] inter-language compatibility
by Junchao Zhang 21 Aug '14

21 Aug '14

Chapter 17.2 Language Interoperability of MPI-3.0 may help. --Junchao Zhang On Thu, Aug 21, 2014 at 12:24 PM, Michael L. Stokes <Michael.Stokes(a)uah.edu> wrote: > I am interesting in knowing (understanding) the difficulties in > programming MPI when one of more processes within > a process group is written in C and one or more is written in FORTRAN. > And to mix it up a bit, let's also > assume that some of the processes (C or FORTRAN) are using mixed native > word sizes (32/64 bit). > > I have been asked to write some benchmark code that exposes these issues. > If there is any code that illustrates > these issues please send a link. > > Thanks > Mike Stokes > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

inter-language compatibility
by Michael L. Stokes 21 Aug '14

21 Aug '14

I am interesting in knowing (understanding) the difficulties in programming MPI when one of more processes within a process group is written in C and one or more is written in FORTRAN. And to mix it up a bit, let's also assume that some of the processes (C or FORTRAN) are using mixed native word sizes (32/64 bit). I have been asked to write some benchmark code that exposes these issues. If there is any code that illustrates these issues please send a link. Thanks Mike Stokes

1 0

Re: [mpich-discuss] MPI point-to-point question
by Rajeev Thakur 20 Aug '14

20 Aug '14

Shouldn't be. On Aug 20, 2014, at 10:28 PM, "Boisvert, Sebastien" <boisvert(a)anl.gov> wrote: > OK ! > > And, would there be a performance difference if I use MPI_Improbe and MPI_Mrecv > (with MPI_THREAD_FUNNELED) ? > >> ________________________________________ >> From: Rajeev Thakur [thakur(a)mcs.anl.gov] >> Sent: Wednesday, August 20, 2014 10:13 PM >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] MPI point-to-point question >> Just use MPI_ANY_SOURCE and MPI_ANY_TAG in the MPI_Iprobe, so it will return the first available message. >> Rajeev >> On Aug 20, 2014, at 8:37 PM, "Boisvert, Sebastien" <boisvert(a)anl.gov> wrote: >>> Hi, >>> >>> When using MPI_Isend + MPI_Test + MPI_Iprobe + MPI_Recv (MPI point-to-point), >>> is there a way to give a hint to MPICH to tell it that the order of messages between each >>> pair of MPI ranks does not need to be enforced ? >>> _______________________________________________ >>> 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 point-to-point question
by Boisvert, Sebastien 20 Aug '14

20 Aug '14

OK ! And, would there be a performance difference if I use MPI_Improbe and MPI_Mrecv (with MPI_THREAD_FUNNELED) ? > ________________________________________ > From: Rajeev Thakur [thakur(a)mcs.anl.gov] > Sent: Wednesday, August 20, 2014 10:13 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] MPI point-to-point question > Just use MPI_ANY_SOURCE and MPI_ANY_TAG in the MPI_Iprobe, so it will return the first available message. > Rajeev > On Aug 20, 2014, at 8:37 PM, "Boisvert, Sebastien" <boisvert(a)anl.gov> wrote: > > Hi, > > > > When using MPI_Isend + MPI_Test + MPI_Iprobe + MPI_Recv (MPI point-to-point), > > is there a way to give a hint to MPICH to tell it that the order of messages between each > > pair of MPI ranks does not need to be enforced ? > > _______________________________________________ > > 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