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

Re: [mpich-discuss] MPICH make clean requires sudo and mucks with DESTDIR
by Balaji, Pavan 22 Aug '14

22 Aug '14

Hmm. I wonder what the right fix would be. Should we even bother cleaning up stuff in the install directory during a “make clean” or equivalent? Would the right fix be to simply remove the “rm -f” line? — Pavan On Aug 22, 2014, at 1:11 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On Aug 21, 2014, at 8:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> 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 was curious if that was my fault as part of the build system rewrite, so I took a peek at his. It looks like a bug from Pavan's commit in June 2012: http://git.mpich.org/mpich.git/commitdiff/cd88cf96 > > The commit he references in his commit was the build system overhaul: http://git.mpich.org/mpich.git/commit/4153c8f8680eeb09a80424f2cc787e799e804… > > This is the relevant Makefile.sm that was present at the time of the overhaul: http://git.mpich.org/mpich.git/blob/5283393cd41ab38548477ef967f4205539d8e53… > > It has this "rm -f" in a (simplemake-specific) "uninstall-postamble" target, which is rather different from a "clean-local" target. This logic should probably be moved to an "uninstall-local" target instead. I'm in favor adding an UNINSTALL_LOCAL_TARGETS parallel to the CLEAN_LOCAL_TARGETS pattern already in use, but that's a decision for the MPICH guys to make. > >> 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. > > I agree, it is not correct. > > -Dave > > _______________________________________________ > 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

MPE Profiling?
by James 22 Aug '14

22 Aug '14

Hi, (Apologies if this is the wrong place to post, but all the links on the MPE page seem to redirect to MPICH.) I am trying to build the MPE profiling libraries to work with MPICH. However, I am getting about a thousand lines of compile error messages, because some MPE routines use K&R-style function declarations, which don't match up with the prototypes in mpi.h 00106 log_mpi_core.c: In function 'MPI_Allgather': 00107 log_mpi_core.c:1550:8: error: argument 'sendbuf' doesn't match prototype 00108 void * sendbuf; 00109 ^ 00110 In file included from log_mpi_core.c:10:0: 00111 /opt/mpich/include/mpi.h:1002:5: error: prototype declaration 00112 int MPI_Allgather(const void *sendbuf, int sendcount, MPI_Datatype sendtype, void *recvbuf, 00113 ^ Before I go and try to fix all these myself, could I ask 1) Has it already been done somewhere? or 2) Has it not been done because there's now something better than MPE for tracing/profiling? To be clear, I'm not interested in profiling MPI itself, but what the program is doing between calls to MPI routines. Thanks, James

1 0

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

22 Aug '14

On Aug 22, 2014, at 1:43 PM, Brian Van Straalen <bvstraalen(a)lbl.gov> wrote: > Is there a significant cost to have the MPI implementation provide a check for aliasing? We do check for this error by default in MPICH (which is why this email thread started). There’s a way to turn off the checking through a configure flag as well as an environment variable, if needed. But that’s essentially saying — I know it’s wrong, but I’m too lazy to fix my application. — Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Brian Van Straalen 22 Aug '14

22 Aug '14

Is there a significant cost to have the MPI implementation provide a check for aliasing? int bytes;MPI_Aint N; MPI_Type_size(type,bytes); N=bytes*(MPI_Aint)n; /* most functions need to compute these two terms already anyways */ assert(s2>s1?s1+N>s2:s2+N>s1) For properly reentrant functions this could prevent many bugs (I had noticed this was in the MPIR functions in the OP). It would make the statement "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure.” a nice hard rule that you catch earlier in the call graph. Brian On Aug 22, 2014, at 7:56 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > That’s not “aliased” (as per the MPI standard), since the input and output buffers are not overlapping (I would have preferred saying “overlapping” to “aliased”). > > Note that the example in the standard that shows overlapping uses copyIntBuffer(a,b,7), not copyIntBuffer(a,b,3). > > — Pavan > > On Aug 22, 2014, at 9:37 AM, Michael L. Stokes <Michael.Stokes(a)uah.edu> wrote: > >> The MPI spec you reference gives an example of aliasing (bottom p.10, top p.11). Would the following also >> be considered aliasing? >> >> #include <stdio.h> >> #include <stdlib.h> >> >> void copyIntBuffer( int *pin, int *pout, int len ) { >> int i; >> for(i=0; i<len; ++i) >> *pout++ = *pin++; >> }; >> >> int main() { >> int array[10]={0,1,2,3,4,5,6,7,8,9}; >> int *a = &array[0]; >> int *b = &array[3]; >> copyIntBuffer(a,b,3); >> return 0; >> } >> >> It is my belief that a definition of a term is much better than an example, albeit more difficult. >> >> My $.05 >> Mike >> >> >> On 08/22/2014 08:25 AM, Carsten Clauss wrote: >>> MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure." >>> >>> Cheers, >>> Carsten >>> >>> On 08/22/2014 03:10 PM, Balaji, Pavan wrote: >>>> >>>> On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>>> 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. >>>> >>>> It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid. Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it). >>>> >>>> In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap. >>>> >>>> We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3. >>>> >>>> — Pavan >>>> >>>> -- >>>> 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 >>>> >>> >> >> _______________________________________________ >> 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 Brian Van Straalen Lawrence Berkeley Lab BVStraalen(a)lbl.gov Computational Research (510) 486-4976 Division (crd.lbl.gov)

1 0

Re: [mpich-discuss] MPICH make clean requires sudo and mucks with DESTDIR
by Dave Goodell (dgoodell) 22 Aug '14

22 Aug '14

On Aug 21, 2014, at 8:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > 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 was curious if that was my fault as part of the build system rewrite, so I took a peek at his. It looks like a bug from Pavan's commit in June 2012: http://git.mpich.org/mpich.git/commitdiff/cd88cf96 The commit he references in his commit was the build system overhaul: http://git.mpich.org/mpich.git/commit/4153c8f8680eeb09a80424f2cc787e799e804… This is the relevant Makefile.sm that was present at the time of the overhaul: http://git.mpich.org/mpich.git/blob/5283393cd41ab38548477ef967f4205539d8e53… It has this "rm -f" in a (simplemake-specific) "uninstall-postamble" target, which is rather different from a "clean-local" target. This logic should probably be moved to an "uninstall-local" target instead. I'm in favor adding an UNINSTALL_LOCAL_TARGETS parallel to the CLEAN_LOCAL_TARGETS pattern already in use, but that's a decision for the MPICH guys to make. > 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. I agree, it is not correct. -Dave

1 0

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

22 Aug '14

That’s not “aliased” (as per the MPI standard), since the input and output buffers are not overlapping (I would have preferred saying “overlapping” to “aliased”). Note that the example in the standard that shows overlapping uses copyIntBuffer(a,b,7), not copyIntBuffer(a,b,3). — Pavan On Aug 22, 2014, at 9:37 AM, Michael L. Stokes <Michael.Stokes(a)uah.edu> wrote: > The MPI spec you reference gives an example of aliasing (bottom p.10, top p.11). Would the following also > be considered aliasing? > > #include <stdio.h> > #include <stdlib.h> > > void copyIntBuffer( int *pin, int *pout, int len ) { > int i; > for(i=0; i<len; ++i) > *pout++ = *pin++; > }; > > int main() { > int array[10]={0,1,2,3,4,5,6,7,8,9}; > int *a = &array[0]; > int *b = &array[3]; > copyIntBuffer(a,b,3); > return 0; > } > > It is my belief that a definition of a term is much better than an example, albeit more difficult. > > My $.05 > Mike > > > On 08/22/2014 08:25 AM, Carsten Clauss wrote: >> MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure." >> >> Cheers, >> Carsten >> >> On 08/22/2014 03:10 PM, Balaji, Pavan wrote: >>> >>> On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>>> 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. >>> >>> It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid. Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it). >>> >>> In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap. >>> >>> We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3. >>> >>> — Pavan >>> >>> -- >>> 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 >>> >> > > _______________________________________________ > 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

Fantastic. Thanks. — Pavan On Aug 22, 2014, at 8:25 AM, Carsten Clauss <c.clauss(a)fz-juelich.de> wrote: > MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure." > > Cheers, > Carsten > > On 08/22/2014 03:10 PM, Balaji, Pavan wrote: >> >> On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> 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. >> >> It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid. Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it). >> >> In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap. >> >> We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3. >> >> — Pavan >> >> -- >> 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 >> > > -- > Carsten Clauss > www.par-tec.com > _____________________________________ > ParTec Cluster Competence Center GmbH > > Possartstrasse 20 > D-81679 Muenchen > > Geschäftsführer RA. Dipl.-Ing. Bernhard Frohwitter Eingetragen beim > Amtsgericht München HRB 151545 Steuer-Nr. 08/32305, Ust-ID DE235527064 > _______________________________________________ > 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 Michael L. Stokes 22 Aug '14

22 Aug '14

The MPI spec you reference gives an example of aliasing (bottom p.10, top p.11). Would the following also be considered aliasing? #include <stdio.h> #include <stdlib.h> void copyIntBuffer( int *pin, int *pout, int len ) { int i; for(i=0; i<len; ++i) *pout++ = *pin++; }; int main() { int array[10]={0,1,2,3,4,5,6,7,8,9}; int *a = &array[0]; int *b = &array[3]; copyIntBuffer(a,b,3); return 0; } It is my belief that a definition of a term is much better than an example, albeit more difficult. My $.05 Mike On 08/22/2014 08:25 AM, Carsten Clauss wrote: > MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument > of type OUT or type INOUT cannot be aliased with any other argument > passed to an MPI procedure." > > Cheers, > Carsten > > On 08/22/2014 03:10 PM, Balaji, Pavan wrote: >> >> On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> 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. >> >> It’s less clear for GET, but the standard says it’s equivalent to >> sending and receiving, which should imply overlapping buffers is >> invalid. Either way, I can’t imagine that not being the intention of >> the RMA working group (I’m a part of it). >> >> In MPI-2, this was not a problem at all since we couldn’t send data >> from the local public window to a remote public window (two >> simultaneous locks were not allowed; FENCE didn’t allow load/store >> and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but >> forgot to make it clear that they shouldn’t overlap. >> >> We should try to make it clearer in the standard, though I don’t >> think it’s valid even in MPI-3. >> >> — Pavan >> >> -- >> 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 Carsten Clauss 22 Aug '14

22 Aug '14

MPI-3, Section 2.3, page 10: "Unless specified otherwise, an argument of type OUT or type INOUT cannot be aliased with any other argument passed to an MPI procedure." Cheers, Carsten On 08/22/2014 03:10 PM, Balaji, Pavan wrote: > > On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> 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. > > It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid. Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it). > > In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap. > > We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3. > > — Pavan > > -- > 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 > -- Carsten Clauss www.par-tec.com _____________________________________ ParTec Cluster Competence Center GmbH Possartstrasse 20 D-81679 Muenchen Geschäftsführer RA. Dipl.-Ing. Bernhard Frohwitter Eingetragen beim Amtsgericht München HRB 151545 Steuer-Nr. 08/32305, Ust-ID DE235527064

1 0

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

22 Aug '14

On Aug 22, 2014, at 7:59 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > 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. It’s less clear for GET, but the standard says it’s equivalent to sending and receiving, which should imply overlapping buffers is invalid. Either way, I can’t imagine that not being the intention of the RMA working group (I’m a part of it). In MPI-2, this was not a problem at all since we couldn’t send data from the local public window to a remote public window (two simultaneous locks were not allowed; FENCE didn’t allow load/store and PUT/GET in the same epoch, etc.). In MPI-3 we allowed this, but forgot to make it clear that they shouldn’t overlap. We should try to make it clearer in the standard, though I don’t think it’s valid even in MPI-3. — Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0