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

cross comiling MPICH
by Doha Ehab 10 Dec '15

10 Dec '15

Hello , I'm trying to use Android toolchain to cross compile mpi using the following commands: export PATH="$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/:$PATH" export SYS_ROOT="$NDK_ROOT/platforms/android-8/arch-arm/" export CC="arm-linux-androideabi-gcc --sysroot=$SYS_ROOT" export LD="arm-linux-androideabi-ld" export AR="arm-linux-androideabi-ar" ./configure --host=arm-linux-androideabi --prefix=/Crosscompile2/jni/mpich/ LIBS="-lc -lgcc " --disable-shared --disable-fortran --disable-cxx but I got the following error checking for pthread_key_create in -lpthread... no checking checkpointing library... configure: error: pthreads is required for checkpointing, but was not found configure: error: src/pm/hydra configure failed I also have attached the config.log but I don't know what is the problem. Thanks _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPE animation crash
by Schilling, Herbert W. (GRC-VE00) 09 Dec '15

09 Dec '15

Hi, First of all, thanks again to everyone, especially Bill Gropp, for modifying MPE so it works with OpenMPI. I did see a post somewhere about how the MPE animation code hasn't been updated in a while. Is it still something that should be good to use? It's a nice feature! In our code, it works for a while and then crashes with this Signal: Segmentation fault (11) Signal code: Address not mapped (1) Failing at address: 0x8523a90 [ 0] /lib64/libpthread.so.0(+0xf850)[0x2aaaac341850] [ 1] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe(MPI_Irecv+0xfd)[0x437a825] [ 2] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe(mpi_irecv_+0x6f)[0x43765a5] [ 3] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x4263f40] [ 4] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x3a6659a] [ 5] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x3c5fc05] [ 6] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x35e1c67] [ 7] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x3731645] [ 8] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x409ebd] [ 9] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x437ff9c] [10] /lib64/libc.so.6(__libc_start_main+0xe6)[0x2aaaac56dc36] [11] /u/hschilli/bass/BASS2.0_20151026/Code_Run/BASS_mpe_animate.exe[0x407739] *** End of error message *** What is really odd is that one I ran the exact same code with the exact same command and it died much earlier while doing some kind of memory allocation. Unfortunately, I didn't capture that error and I can't make it happen again now. Also, without digging through the code to figure out how the animations are being displayed, is there any documentation on that? Thanks! --------- Herb Schilling Scientific Applications and Visualization Team http://ocio.grc.nasa.gov/gvis Office of the Chief Information Officer NASA Glenn Research Center hschilling(a)nasa.gov<mailto:[email protected]> _______________________________________________ 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] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by William Gropp 07 Dec '15

07 Dec '15

I agree. This is a perverse interpretation. While I understand the optimization, the nonblocking routines should return an active request, not a null request. (The real optimization is probably in not creating the request, rather than freeing it; while requests should be managed in such a way that creation is cheap, its likely that defensive coding will initialize the request, which can be non-trivial. Still, this doesn’t seem worth the surprise to the user.) Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science Chief Scientist, NCSA University of Illinois Urbana-Champaign On Dec 7, 2015, at 9:29 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > I understand the optimization here, but I think Jed does have a point: it is weird. > > Further, MPI-3.1 5.1.2 p196:38-39 states: > > "A nonblocking call initiates a collective operation, which must be completed in a separate completion call." > > Arguably, this does not directly state that you need to return a valid request from any of the NBCs. But it's a reasonable interpretation to believe that it should. > > Further, Jed is right that this might be a micro-optimization (i.e., avoiding the creation or deallocation of a request), but it doesn't help much unless the app also does an associated "if" to test and see if the request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., that would be a further micro-optimization -- which probably isn't negated by the app's "if" because TEST*/WAIT* have to do the same "if" for REQUEST_NULL). > > In short: yes, this is a micro-optimization. But: > > a) it kinda falls in the "violates the law of least astonishment" category > b) is deallocating a free listed request that expensive? > c) if you have to explain this every time, are you really optimizing anything? > d) it's a single process case -- it's already damn fast. Do you really need to optimize it further? :-) > > (To be clear: I don't really care; I just bring up these points to highlight the other side of the story) > > >> On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here. >> >> Why don't you use MPI_Test instead of direct comparison? >> >> Jeff >> >> On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == >> MPI_REQUEST_NULL. This is also the case for other communicators of size >> 1. Previous versions of MPICH and also all versions of Open MPI return >> a valid request not equal to MPI_REQUEST_NULL. This bit me because it >> was natural to compare to MPI_REQUEST_NULL in a conditional for an >> Ibarrier/Issend/Iprobe algorithm. It can be worked around with a >> slightly more complicate conditional, but is this change intentional? >> >> The call returns a request handle, which must be passed to a >> completion call. >> -- MPI-3 §5.12 >> >> This does not say "unless the communicator has size 1". >> >> _______________________________________________ >> 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 >> http://jeffhammond.github.io/ >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > 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_scatter
by Jen B 07 Dec '15

07 Dec '15

In particular, it is essential for me to know what happens when the mpi_scatter is run on non-power of two number of processes. I have looked into the scatter.c file comments, but it is not mentioned anywhere there. Thanks! Best, Jen On Sat, Dec 5, 2015 at 1:05 PM, Jen B <jenbna(a)gmail.com> wrote: > Hi, > > Sorry for bugging you guys again, I have a couple of things I wanted to > make sure about. > > So mpi_scatter uses a binomial tree. If, for example, I have processes p0, > p1, p2, p3. Then the binomial tree would be p0 -> p1,p0 -> p2,p2 -> p3. For > my total message n, the parts that need to send to the processes are n0, > n1, n2, n3. Then, will p0->p1 have only n1 in transit, and p0->p2 have > n2+n3 in transit, and finally p2->p3 have n3 in transit? > > And how would the binomial tree be built for processes p0,p1,p2,p3,p4? Is > it as above with addition of p0->p4 (i.e., we get closest binomial tree and > add the rest to p0)? > > Any help will be greatly appreciated! > > Best, > Jen > _______________________________________________ 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] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jed Brown 07 Dec '15

07 Dec '15

"Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> writes: > In short: yes, this is a micro-optimization. But: > > a) it kinda falls in the "violates the law of least astonishment" category > b) is deallocating a free listed request that expensive? > c) if you have to explain this every time, are you really optimizing anything? Agreed on the above points. I just think that if returning MPI_REQUEST_NULL is valid, it needs to be explicitly allowed by the standard. My preference is to not allow it because it can make logic simpler and make memory leaks easier to debug. > d) it's a single process case -- it's already damn fast. Do you really need to optimize it further? :-) This is more delicate because having a fast serial path is important to avoid code duplication when certain base cases are performance sensitive (or when running one-process jobs). This can arise even for tightly coupled problems at large scale, e.g., in the "coarse" levels of various fast algorithms. In this particular circumstance, I think you'd be hard-pressed to find a use case where the overhead is detectable, and it's arguably less code complexity to short-circuit the whole operation in the serial case than to add an extra flag variable to be able to accommodate the possibility that MPI_REQUEST_NULL is returned. _______________________________________________ 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] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jed Brown 07 Dec '15

07 Dec '15

Jeff Hammond <jeff.science(a)gmail.com> writes: > Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and > MPI_Barrier) is a no-op for a communicator of size 1, it is trivially > complete and it would seem that MPICH is optimizing away the unnecessary > request object here. Of course it's an "optimization", but I think it may be meaningless and it's not clear to me that it's allowed by the standard. Note the explicitness in malloc(3): If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). Specifically, the MPI standard doesn't say that it "returns a request that must be completed in a separate completion call, or MPI_REQUEST_NULL indicating that the operation already completed". > Why don't you use MPI_Test instead of direct comparison? It's a state conditional to distinguish between two phases of the algorithm. I can use an extra flag, but the existing version initializes req=MPI_REQUEST_NULL and expects that starting an Ibarrier will make req equal to something else. _______________________________________________ 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] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jeff Squyres (jsquyres) 07 Dec '15

07 Dec '15

I understand the optimization here, but I think Jed does have a point: it is weird. Further, MPI-3.1 5.1.2 p196:38-39 states: "A nonblocking call initiates a collective operation, which must be completed in a separate completion call." Arguably, this does not directly state that you need to return a valid request from any of the NBCs. But it's a reasonable interpretation to believe that it should. Further, Jed is right that this might be a micro-optimization (i.e., avoiding the creation or deallocation of a request), but it doesn't help much unless the app also does an associated "if" to test and see if the request==MPI_REQUEST_NULL and therefore doesn't call TEST*/WAIT* (i.e., that would be a further micro-optimization -- which probably isn't negated by the app's "if" because TEST*/WAIT* have to do the same "if" for REQUEST_NULL). In short: yes, this is a micro-optimization. But: a) it kinda falls in the "violates the law of least astonishment" category b) is deallocating a free listed request that expensive? c) if you have to explain this every time, are you really optimizing anything? d) it's a single process case -- it's already damn fast. Do you really need to optimize it further? :-) (To be clear: I don't really care; I just bring up these points to highlight the other side of the story) > On Dec 7, 2015, at 6:39 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here. > > Why don't you use MPI_Test instead of direct comparison? > > Jeff > > On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: > In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == > MPI_REQUEST_NULL. This is also the case for other communicators of size > 1. Previous versions of MPICH and also all versions of Open MPI return > a valid request not equal to MPI_REQUEST_NULL. This bit me because it > was natural to compare to MPI_REQUEST_NULL in a conditional for an > Ibarrier/Issend/Iprobe algorithm. It can be worked around with a > slightly more complicate conditional, but is this change intentional? > > The call returns a request handle, which must be passed to a > completion call. > -- MPI-3 §5.12 > > This does not say "unless the communicator has size 1". > > _______________________________________________ > 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 > http://jeffhammond.github.io/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ 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] Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jeff Hammond 07 Dec '15

07 Dec '15

Completed requests are set to MPI_REQUEST_NULL. Since MPI_Ibarrier (and MPI_Barrier) is a no-op for a communicator of size 1, it is trivially complete and it would seem that MPICH is optimizing away the unnecessary request object here. Why don't you use MPI_Test instead of direct comparison? Jeff On Sun, Dec 6, 2015 at 10:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: > In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == > MPI_REQUEST_NULL. This is also the case for other communicators of size > 1. Previous versions of MPICH and also all versions of Open MPI return > a valid request not equal to MPI_REQUEST_NULL. This bit me because it > was natural to compare to MPI_REQUEST_NULL in a conditional for an > Ibarrier/Issend/Iprobe algorithm. It can be worked around with a > slightly more complicate conditional, but is this change intentional? > > The call returns a request handle, which must be passed to a > completion call. > -- MPI-3 §5.12 > > This does not say "unless the communicator has size 1". > > _______________________________________________ > 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 http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Behavioral change for MPI_Ibarrier(MPI_COMM_SELF, &r) in mpich-3.2
by Jed Brown 07 Dec '15

07 Dec '15

In MPICH 3.2, MPI_Ibarrier(MPI_COMM_SELF,&r) returns r == MPI_REQUEST_NULL. This is also the case for other communicators of size 1. Previous versions of MPICH and also all versions of Open MPI return a valid request not equal to MPI_REQUEST_NULL. This bit me because it was natural to compare to MPI_REQUEST_NULL in a conditional for an Ibarrier/Issend/Iprobe algorithm. It can be worked around with a slightly more complicate conditional, but is this change intentional? The call returns a request handle, which must be passed to a completion call. -- MPI-3 §5.12 This does not say "unless the communicator has size 1". _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpi_scatter
by Jen B 05 Dec '15

05 Dec '15

Hi, Sorry for bugging you guys again, I have a couple of things I wanted to make sure about. So mpi_scatter uses a binomial tree. If, for example, I have processes p0, p1, p2, p3. Then the binomial tree would be p0 -> p1,p0 -> p2,p2 -> p3. For my total message n, the parts that need to send to the processes are n0, n1, n2, n3. Then, will p0->p1 have only n1 in transit, and p0->p2 have n2+n3 in transit, and finally p2->p3 have n3 in transit? And how would the binomial tree be built for processes p0,p1,p2,p3,p4? Is it as above with addition of p0->p4 (i.e., we get closest binomial tree and add the rest to p0)? Any help will be greatly appreciated! Best, Jen _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0