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

Re: [mpich-discuss] Questions about non-blocking collective calls...
by Eric Chamberland 22 Oct '15

22 Oct '15

Hi Pavan and Jeff, Thanks a lot for your answers. I feel there is something to tell about mpi standard expectations... Why does the knowledge (or ignorance) of MPI users about scalability of communications in MPI should be a requirement for them for developing high-performance MPI applications? Especially when we want to keep it simple by using high-level MPI functionalities, like MPI_gather, and let the library do the best work it can... In other words, why the complexity (then scalability) of MPI algorithms is not guaranteed by the standard? If every one that is familiar with performance of MPI communication have the burden to write MPI calls in a way that it is scaling/performing well, isn't all of us rewriting essentially the same "good" code that should be in the standard? Is the standard voluntarily blind to these (crucial) questions? I may be too naive too... tell me! :) (ie, the c++ standard guarantee the sort algorithm complexity: https://en.wikipedia.org/wiki/Sort_%28C%2B%2B%29) On 21/10/15 10:03 PM, Balaji, Pavan wrote: > You might want to join the collectives working group and voice your opinion over there. Ok, where exactly do I do this? Btw, I don't want to blame anybody... I am just learning and discussing here!!! :) Thanks for reading! Eric On 21/10/15 11:56 PM, Jeff Hammond wrote: > Depending on the size of your data, you could pipeline a series of > MPI_Igather calls and process all of the data associated with the > partial buffer. Of course, this will change the layout of the buffer at > the root unless you do something interesting with datatypes (e.g. struct > with offset). This may or may not matter, if you are going to process > it anyways. > > In general, I think you may be able to do just fine with rolling your > own. It's a myth that using higher-level functionality in MPI is > _always_ better. > > Jeff > > On Wed, Oct 21, 2015 at 7:03 PM, Balaji, Pavan <balaji(a)anl.gov > <mailto:[email protected]>> wrote: > > Eric, > > The concept of partial completion of collectives did come up in the > Forum, but the Forum decided that it was rather unnatural to define > Iallgather/Igather that way. So we decided to standardize it the > way it is. > > However, there is a separate proposal for streaming collectives, > which is more along the lines of what you are thinking of. That's > obviously not in MPI-3, but might be considered for a future MPI. > You might want to join the collectives working group and voice your > opinion over there. > > With respect to writing your own igather implementation, as long as > your implementation is logarithmic, it won't be too bad. However, a > native implementation inside MPI would almost certainly do better > because: (1) it can take advantage of platform-specific features to > improve performance, and (2) if the platform doesn't give anything > special, it'll anyway do exactly what you are doing above MPI. > > So, apart from any performance bugs that the implementation might > have, using MPI Igather would be the recommended mechanism for the > best performance. > > -- Pavan > > > > > > On 10/21/15, 2:45 PM, "Eric Chamberland" > <Eric.Chamberland(a)giref.ulaval.ca > <mailto:[email protected]>> wrote: > > >Hi, > > > >A long time ago (in 2002) we programmed here a non-blocking > MPI_Igather > >with equivalent calls to MPI_Isend/MPI_Irecv (see the 2 attached > files). > > > >A very convenient advantage of this version, is that I can do some > work > >on the root process as soon as it start receiving data... Then, > it wait > >for the next communication to terminate and process the received data. > > > >Now, I am looking at MPI_Igather (and all non-blocking collective MPI > >calls), and I am somewhat surprised (or ignorant) that I cannot > have the > >root rank receive some data, then process it, then wait until the next > >"MPI_irecv" terminate... > > > >In other words, a MPI_Igather generate only 1 MPI_Request but I would > >like to have either "p" (with p = size of communicator) MPI_Request > >generated or be able to call "p" times MPI_WaitAny with the same > >MPI_Request... Am I normal? :) > > > >So my 3 questions are: > > > >#1- Is there a way to use MPI_Igather with MPI_WaitAny (or something > >else?) to process data as it is received? > > > >#2- Big question: will our implementation with MPI_Isend/MPI_Irecv > scale > >to a large number of processes? What are the possible drawbacks of > >doing it like we did? > > > >#3- Why should I replace our implementation by the native MPI_Igather? > > > >Thanks! > > > >Eric > _______________________________________________ > 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

1 0

Re: [mpich-discuss] problem after compilation
by Balaji, Pavan 22 Oct '15

22 Oct '15

You seem to be mixing MPICH and a different MPI implementation (probably Open MPI). From: vinod pandey <pandeyvinod4(a)gmail.com<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Thursday, October 22, 2015 at 2:30 AM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Subject: [mpich-discuss] problem after compilation I am getting the below message after compilation /usr/bin/ld: warning: libmpi.so.1, needed by /usr//lib/libmpi_f77.so, may conflict with libmpi.so.12 Kindly help. -- ............. VINOD PANDEY _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

problem after compilation
by vinod pandey 22 Oct '15

22 Oct '15

I am getting the below message after compilation /usr/bin/ld: warning: libmpi.so.1, needed by /usr//lib/libmpi_f77.so, may conflict with libmpi.so.12 Kindly help. -- ............. VINOD PANDEY _______________________________________________ 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 Balaji, Pavan 22 Oct '15

22 Oct '15

Using autotools is only for mpich developers. We do what we can to try to find autotools version mismatches in autogen.sh, but it's not meant to be thorough. As a user, please download a tarball. -- Pavan From: Sayan Ghosh <sayandeep52(a)gmail.com<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Wednesday, October 21, 2015 at 10:09 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Subject: Re: [mpich-discuss] mpich build error Yes Jeff, you're right. I found out that it was an autotools issue, I updated autotools, and now mpich builds properly for me, with icc/gcc. The idea to look into autotools came to me from this trac discussion (that was a different issue perhaps, but still): https://trac.mpich.org/projects/mpich/ticket/1840 sg@sg:~/proj$ m4 --version m4 (GNU M4) 1.4.17 sg@sg:~/proj$ automake --version automake (GNU automake) 1.15 sg@sg:~/proj$ autoconf --version autoconf (GNU Autoconf) 2.69 sg@sg:~/proj$ libtool --version libtool (GNU libtool) 2.4.6 Thanks, Sayan On Wed, Oct 21, 2015 at 5:47 PM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: Since C is ABI compatible, just build MPICH with GCC and like with ICC apps. FWIW I compile MPICH with Intel 15/16 all the time without issues. But I'll try the latest git version to be sure. Jeff On Wednesday, October 21, 2015, Sayan Ghosh <sayandeep52(a)gmail.com<mailto:[email protected]>> wrote: Thanks Rob, here is the specific part from my mpl config, almost looks like your config: configure:13058: checking for strncmp configure:13058: icc -std=gnu99 -o conftest conftest.c >&5 configure:13058: $? = 0 configure:13058: result: yes configure:13070: checking whether strncmp needs a declaration configure:13089: icc -std=gnu99 -c conftest.c >&5 configure:13089: $? = 0 configure:13097: result: no I get build errors even with GCC 4.9 and clang with older versions of mpich, so this is definitely a system issue as you mentioned. sg@sg:~/sources/mpich-3.1.4/build$ cat /etc/debian_version 8.2 sg@sg:~/sources/mpich-3.1.4/build$ uname -a Linux sg 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux On Wed, Oct 21, 2015 at 7:39 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: 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 -- Regards, Sayan -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss -- 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] Questions about non-blocking collective calls...
by Jeff Hammond 21 Oct '15

21 Oct '15

Depending on the size of your data, you could pipeline a series of MPI_Igather calls and process all of the data associated with the partial buffer. Of course, this will change the layout of the buffer at the root unless you do something interesting with datatypes (e.g. struct with offset). This may or may not matter, if you are going to process it anyways. In general, I think you may be able to do just fine with rolling your own. It's a myth that using higher-level functionality in MPI is _always_ better. Jeff On Wed, Oct 21, 2015 at 7:03 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > Eric, > > The concept of partial completion of collectives did come up in the Forum, > but the Forum decided that it was rather unnatural to define > Iallgather/Igather that way. So we decided to standardize it the way it is. > > However, there is a separate proposal for streaming collectives, which is > more along the lines of what you are thinking of. That's obviously not in > MPI-3, but might be considered for a future MPI. You might want to join > the collectives working group and voice your opinion over there. > > With respect to writing your own igather implementation, as long as your > implementation is logarithmic, it won't be too bad. However, a native > implementation inside MPI would almost certainly do better because: (1) it > can take advantage of platform-specific features to improve performance, > and (2) if the platform doesn't give anything special, it'll anyway do > exactly what you are doing above MPI. > > So, apart from any performance bugs that the implementation might have, > using MPI Igather would be the recommended mechanism for the best > performance. > > -- Pavan > > > > > > On 10/21/15, 2:45 PM, "Eric Chamberland" <Eric.Chamberland(a)giref.ulaval.ca> > wrote: > > >Hi, > > > >A long time ago (in 2002) we programmed here a non-blocking MPI_Igather > >with equivalent calls to MPI_Isend/MPI_Irecv (see the 2 attached files). > > > >A very convenient advantage of this version, is that I can do some work > >on the root process as soon as it start receiving data... Then, it wait > >for the next communication to terminate and process the received data. > > > >Now, I am looking at MPI_Igather (and all non-blocking collective MPI > >calls), and I am somewhat surprised (or ignorant) that I cannot have the > >root rank receive some data, then process it, then wait until the next > >"MPI_irecv" terminate... > > > >In other words, a MPI_Igather generate only 1 MPI_Request but I would > >like to have either "p" (with p = size of communicator) MPI_Request > >generated or be able to call "p" times MPI_WaitAny with the same > >MPI_Request... Am I normal? :) > > > >So my 3 questions are: > > > >#1- Is there a way to use MPI_Igather with MPI_WaitAny (or something > >else?) to process data as it is received? > > > >#2- Big question: will our implementation with MPI_Isend/MPI_Irecv scale > >to a large number of processes? What are the possible drawbacks of > >doing it like we did? > > > >#3- Why should I replace our implementation by the native MPI_Igather? > > > >Thanks! > > > >Eric > _______________________________________________ > 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

Re: [mpich-discuss] mpich build error
by Sayan Ghosh 21 Oct '15

21 Oct '15

Yes Jeff, you're right. I found out that it was an autotools issue, I updated autotools, and now mpich builds properly for me, with icc/gcc. The idea to look into autotools came to me from this trac discussion (that was a different issue perhaps, but still): https://trac.mpich.org/projects/mpich/ticket/1840 sg@sg:~/proj$ m4 --version m4 (GNU M4) 1.4.17 sg@sg:~/proj$ automake --version automake (GNU automake) 1.15 sg@sg:~/proj$ autoconf --version autoconf (GNU Autoconf) 2.69 sg@sg:~/proj$ libtool --version libtool (GNU libtool) 2.4.6 Thanks, Sayan On Wed, Oct 21, 2015 at 5:47 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Since C is ABI compatible, just build MPICH with GCC and like with ICC > apps. > > FWIW I compile MPICH with Intel 15/16 all the time without issues. But > I'll try the latest git version to be sure. > > Jeff > > > On Wednesday, October 21, 2015, Sayan Ghosh <sayandeep52(a)gmail.com> wrote: > >> Thanks Rob, here is the specific part from my mpl config, almost looks >> like your config: >> >> configure:13058: checking for strncmp >> configure:13058: icc -std=gnu99 -o conftest conftest.c >&5 >> configure:13058: $? = 0 >> configure:13058: result: yes >> configure:13070: checking whether strncmp needs a declaration >> configure:13089: icc -std=gnu99 -c conftest.c >&5 >> configure:13089: $? = 0 >> configure:13097: result: no >> >> I get build errors even with GCC 4.9 and clang with older versions of >> mpich, so this is definitely a system issue as you mentioned. >> >> sg@sg:~/sources/mpich-3.1.4/build$ cat /etc/debian_version >> 8.2 >> sg@sg:~/sources/mpich-3.1.4/build$ uname -a >> Linux sg 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) >> x86_64 GNU/Linux >> >> On Wed, Oct 21, 2015 at 7:39 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: >> >>> 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 >>> >> >> >> >> -- >> Regards, >> Sayan >> > > > -- > 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 > -- 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] Questions about non-blocking collective calls...
by Balaji, Pavan 21 Oct '15

21 Oct '15

Eric, The concept of partial completion of collectives did come up in the Forum, but the Forum decided that it was rather unnatural to define Iallgather/Igather that way. So we decided to standardize it the way it is. However, there is a separate proposal for streaming collectives, which is more along the lines of what you are thinking of. That's obviously not in MPI-3, but might be considered for a future MPI. You might want to join the collectives working group and voice your opinion over there. With respect to writing your own igather implementation, as long as your implementation is logarithmic, it won't be too bad. However, a native implementation inside MPI would almost certainly do better because: (1) it can take advantage of platform-specific features to improve performance, and (2) if the platform doesn't give anything special, it'll anyway do exactly what you are doing above MPI. So, apart from any performance bugs that the implementation might have, using MPI Igather would be the recommended mechanism for the best performance. -- Pavan On 10/21/15, 2:45 PM, "Eric Chamberland" <Eric.Chamberland(a)giref.ulaval.ca> wrote: >Hi, > >A long time ago (in 2002) we programmed here a non-blocking MPI_Igather >with equivalent calls to MPI_Isend/MPI_Irecv (see the 2 attached files). > >A very convenient advantage of this version, is that I can do some work >on the root process as soon as it start receiving data... Then, it wait >for the next communication to terminate and process the received data. > >Now, I am looking at MPI_Igather (and all non-blocking collective MPI >calls), and I am somewhat surprised (or ignorant) that I cannot have the >root rank receive some data, then process it, then wait until the next >"MPI_irecv" terminate... > >In other words, a MPI_Igather generate only 1 MPI_Request but I would >like to have either "p" (with p = size of communicator) MPI_Request >generated or be able to call "p" times MPI_WaitAny with the same >MPI_Request... Am I normal? :) > >So my 3 questions are: > >#1- Is there a way to use MPI_Igather with MPI_WaitAny (or something >else?) to process data as it is received? > >#2- Big question: will our implementation with MPI_Isend/MPI_Irecv scale >to a large number of processes? What are the possible drawbacks of >doing it like we did? > >#3- Why should I replace our implementation by the native MPI_Igather? > >Thanks! > >Eric _______________________________________________ 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 Jeff Hammond 21 Oct '15

21 Oct '15

Since C is ABI compatible, just build MPICH with GCC and like with ICC apps. FWIW I compile MPICH with Intel 15/16 all the time without issues. But I'll try the latest git version to be sure. Jeff On Wednesday, October 21, 2015, Sayan Ghosh <sayandeep52(a)gmail.com> wrote: > Thanks Rob, here is the specific part from my mpl config, almost looks > like your config: > > configure:13058: checking for strncmp > configure:13058: icc -std=gnu99 -o conftest conftest.c >&5 > configure:13058: $? = 0 > configure:13058: result: yes > configure:13070: checking whether strncmp needs a declaration > configure:13089: icc -std=gnu99 -c conftest.c >&5 > configure:13089: $? = 0 > configure:13097: result: no > > I get build errors even with GCC 4.9 and clang with older versions of > mpich, so this is definitely a system issue as you mentioned. > > sg@sg:~/sources/mpich-3.1.4/build$ cat /etc/debian_version > 8.2 > sg@sg:~/sources/mpich-3.1.4/build$ uname -a > Linux sg 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) > x86_64 GNU/Linux > > On Wed, Oct 21, 2015 at 7:39 AM, Rob Latham <robl(a)mcs.anl.gov > <javascript:_e(%7B%7D,'cvml','robl(a)mcs.anl.gov');>> wrote: > >> 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 >>> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','discuss(a)mpich.org');> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > > -- > Regards, > Sayan > -- 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

Re: [mpich-discuss] mpich build error
by Sayan Ghosh 21 Oct '15

21 Oct '15

Thanks Rob, here is the specific part from my mpl config, almost looks like your config: configure:13058: checking for strncmp configure:13058: icc -std=gnu99 -o conftest conftest.c >&5 configure:13058: $? = 0 configure:13058: result: yes configure:13070: checking whether strncmp needs a declaration configure:13089: icc -std=gnu99 -c conftest.c >&5 configure:13089: $? = 0 configure:13097: result: no I get build errors even with GCC 4.9 and clang with older versions of mpich, so this is definitely a system issue as you mentioned. sg@sg:~/sources/mpich-3.1.4/build$ cat /etc/debian_version 8.2 sg@sg:~/sources/mpich-3.1.4/build$ uname -a Linux sg 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) x86_64 GNU/Linux On Wed, Oct 21, 2015 at 7:39 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: > 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 > -- Regards, Sayan _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Questions about non-blocking collective calls...
by Eric Chamberland 21 Oct '15

21 Oct '15

Hi, A long time ago (in 2002) we programmed here a non-blocking MPI_Igather with equivalent calls to MPI_Isend/MPI_Irecv (see the 2 attached files). A very convenient advantage of this version, is that I can do some work on the root process as soon as it start receiving data... Then, it wait for the next communication to terminate and process the received data. Now, I am looking at MPI_Igather (and all non-blocking collective MPI calls), and I am somewhat surprised (or ignorant) that I cannot have the root rank receive some data, then process it, then wait until the next "MPI_irecv" terminate... In other words, a MPI_Igather generate only 1 MPI_Request but I would like to have either "p" (with p = size of communicator) MPI_Request generated or be able to call "p" times MPI_WaitAny with the same MPI_Request... Am I normal? :) So my 3 questions are: #1- Is there a way to use MPI_Igather with MPI_WaitAny (or something else?) to process data as it is received? #2- Big question: will our implementation with MPI_Isend/MPI_Irecv scale to a large number of processes? What are the possible drawbacks of doing it like we did? #3- Why should I replace our implementation by the native MPI_Igather? Thanks! Eric _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0