November 2012 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] How to specify number of cores for each process
by Pavan Balaji 28 Nov '12

28 Nov '12

There are two problems in your usage below. 1. I'm guessing that your host file specifies only one core for each host. Something like: host1 host2 Did you look through the mpiexec usage document that tells you how to specify multiple cores on each host? http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager You should do something like: host1:16 host2:16 (please read the documentation on the above link for more information). 2. There's option called -binding auto. Did you mean -binding none? -- Pavan On 11/27/2012 09:37 PM US Central Time, Zachary Stanko wrote: > Hello, > > I am running an MPI program on a machine with two 16-core processors > yet, no matter what configuration I use with mpiexec, I am only > receiving 4 simultaneous processes. > I would like to maximize this machine's potential and run 8 or 16 > processes. I have tried all of the channel selections and tried the > -binding option. > Since I need to specify a different working directory for each process > (due to many output files with naming conflicts), I have a config file > with 8 lines of the form: > > -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> > -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> > ...etc > > and I run: > > mpiexec -configfile <filename> > > Am I doing something wrong, or does MPICH just know best and cannot run > more than 4 jobs at a time on this system? > > Thanks, > > Zak > > > _______________________________________________ > 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] How to specify number of cores for each process
by Jeff Hammond 27 Nov '12

27 Nov '12

Did you try "mpiexec -n 16 ..."? Sent from my iPhone On Nov 27, 2012, at 10:37 PM, Zachary Stanko <zstanko(a)usgs.gov> wrote: Hello, I am running an MPI program on a machine with two 16-core processors yet, no matter what configuration I use with mpiexec, I am only receiving 4 simultaneous processes. I would like to maximize this machine's potential and run 8 or 16 processes. I have tried all of the channel selections and tried the -binding option. Since I need to specify a different working directory for each process (due to many output files with naming conflicts), I have a config file with 8 lines of the form: -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> ...etc and I run: mpiexec -configfile <filename> Am I doing something wrong, or does MPICH just know best and cannot run more than 4 jobs at a time on this system? Thanks, Zak _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

How to specify number of cores for each process
by Zachary Stanko 27 Nov '12

27 Nov '12

Hello, I am running an MPI program on a machine with two 16-core processors yet, no matter what configuration I use with mpiexec, I am only receiving 4 simultaneous processes. I would like to maximize this machine's potential and run 8 or 16 processes. I have tried all of the channel selections and tried the -binding option. Since I need to specify a different working directory for each process (due to many output files with naming conflicts), I have a config file with 8 lines of the form: -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> ...etc and I run: mpiexec -configfile <filename> Am I doing something wrong, or does MPICH just know best and cannot run more than 4 jobs at a time on this system? Thanks, Zak

1 0

Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Dave Goodell 27 Nov '12

27 Nov '12

I've created a ticket to track this, although I have no idea when we might get around to actually implementing a workaround for broken RHEL 5.5: http://trac.mpich.org/projects/mpich/ticket/1760 -Dave On Nov 27, 2012, at 3:17 PM CST, Yauheni Zelenko wrote: > Hi, Dave! > > I played with preprocessor output aand it looks like this is problem of RHEL 5.5. > > _FILE_OFFSET_BITS=64 forces to redirect stat/fstat to their 64 bit counterparts (with __asm__) . > > _LARGEFILE64_SOURCE defines stat/fstat/stat64/fstat64. > > So combination of both will cause redefinition of stat64/fstat64. > > BTW _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 appear twice in compiler command line. > > Eugene. > ________________________________________ > From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] > Sent: Wednesday, November 21, 2012 10:38 AM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 > > Hi Eugene, > > I was not able to reproduce this behavior on RHEL 5.8 with gcc-4.1 or gcc-4.6 (though I was able to reproduce the earlier LLONG_MAX issue). > > Would you please dig in here and debug a bit for us? It seems that there is something very specific about your environment and/or compiler that is causing a problem here. > > -Dave > > On Nov 20, 2012, at 7:07 PM CST, Yauheni Zelenko wrote: > >> Your guess is correct. Compilation is fine when only one of defines left in command line. >> >> You could try to install CentOS which is copy of RHEL. >> >> Alternatively, I could send files in questions. >> >> Eugene. >> ________________________________________ >> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >> Sent: Tuesday, November 20, 2012 4:57 PM >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >> >> My suspicion is that it is more likely related to the following arguments: >> >> ----8<---- >> -D_LARGEFILE64_SOURCE >> -D_FILE_OFFSET_BITS=64 >> ----8<---- >> >> Can you try running that same gcc command from the build directory's "src/mpi/romio" directory but with omitting various combinations of the two above options? >> >> Reading the source of feature.h and/or stat.h would probably also help, although I do not have a RHEL5/6 system handy. >> >> -Dave >> >> On Nov 20, 2012, at 6:09 PM CST, Yauheni Zelenko wrote: >> >>> Hi, Dave! >>> >>> See attached files for make output in verbose mode and generated assembler code. >>> >>> Eugene. >>> ________________________________________ >>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>> Sent: Tuesday, November 20, 2012 3:18 PM >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>> >>> It seems unlikely to me that the headers distributed in RHEL5/RHEL6 are incompatible with GCC being in C99 mode. Can you give me a little more information about what's failing? Perhaps run "make V=1 2>&1 | tee m.txt" and send m.txt as an attachment? >>> >>> -Dave >>> >>> On Nov 20, 2012, at 5:08 PM CST, Yauheni Zelenko wrote: >>> >>>> Hi, Dave! >>>> >>>> I think this is result of inlining in C99 mode. >>>> >>>> Eugene. >>>> ________________________________________ >>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>> Sent: Tuesday, November 20, 2012 3:06 PM >>>> To: discuss(a)mpich.org >>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>> >>>> I'm not sure I follow you on the fstat64/stat64 double-definition issue. Is this just some sort of bug in the RHEL6 headers? Is there something that we (MPICH) are doing incorrectly w.r.t. this? >>>> >>>> -Dave >>>> >>>> On Nov 14, 2012, at 5:39 PM CST, Yauheni Zelenko wrote: >>>> >>>>> Hi, Dave! >>>>> >>>>> Build failed on first compilation because fstat64 and stat64 defined twice. Likely because of these functions inlining in /usr/include/sys/stat.h. >>>>> >>>>> Also GCC 4.7.2 warnings on Red Hat Enterprise Linux 6: >>>>> >>>>> src/mpltrmem.c: In function 'MPL_trdump': >>>>> src/mpltrmem.c:536:14: warning: variable 'old_head' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/opminloc.c: In function 'MPIR_MINLOC': >>>>> src/mpi/coll/opminloc.c:85:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/opmaxloc.c: In function 'MPIR_MAXLOC': >>>>> src/mpi/coll/opmaxloc.c:86:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/ch3/src/ch3u_rma_sync.c: In function 'MPIDI_CH3I_Recv_rma_msg': >>>>> src/mpid/ch3/src/ch3u_rma_sync.c:1251:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpid/ch3/src/mpidi_pg.c: In function 'connToString': >>>>> src/mpid/ch3/src/mpidi_pg.c:972:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPIDI_CH3I_Progress': >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:394:21: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPID_nem_handle_pkt': >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:636:17: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:684:13: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c: In function 'alloc_sc_plfd_tbls': >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:183:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_sc' will never be NULL [-Waddress] >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:184:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_plfd' will never be NULL [-Waddress] >>>>> src/mpid/common/datatype/mpid_type_debug.c: In function 'MPIDI_Datatype_printf': >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:59: warning: variable 'sticky_ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:48: warning: variable 'sticky_lb' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:44: warning: variable 'ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:31: warning: variable 'true_ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:236:11: warning: variable 'string' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_bruck': >>>>> src/mpi/coll/iallgather.c:329:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_inter': >>>>> src/mpi/coll/iallgather.c:580:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_rec_dbl': >>>>> src/mpi/coll/iallgatherv.c:259:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_bruck': >>>>> src/mpi/coll/iallgatherv.c:398:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_redscat_allgather': >>>>> src/mpi/coll/iallreduce.c:282:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_rec_dbl': >>>>> src/mpi/coll/iallreduce.c:425:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/ired_scat_block.c: In function 'MPIR_Ireduce_scatter_block_inter': >>>>> src/mpi/coll/ired_scat_block.c:899:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/ireduce.c: In function 'MPIR_Ireduce_SMP': >>>>> src/mpi/coll/ireduce.c:677:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> >>>>> Eugene. >>>>> ________________________________________ >>>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>>> Sent: Wednesday, November 14, 2012 2:46 PM >>>>> To: discuss(a)mpich.org >>>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>>> >>>>> This is because you have selected a bare "--enable-strict" option to configure, which defaults to c89. I'll see if there's a more pleasant way around this, but in the meantime is it acceptable for you to pass "--enable-strict=c99" instead? >>>>> >>>>> The problem occurs because your compiler still responds to the "long long" type but disables the "LLONG_MAX" constant when asked for c89 mode. >>>>> >>>>> -Dave >>>>> >>>>> On Nov 14, 2012, at 4:14 PM CST, Yauheni Zelenko wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> I'm trying to compile MPICH 3.0 rc1 on Red Hat Enterprise Linux 5 and compilation failed because of undefined LLONG_MAX. >>>>>> >>>>>> LLONG_MAX definition in /usr/include/limits.h is depend on C99 condition. -std=c89 is passed to GCC. >>>>>> >>>>>> My configure options: >>>>>> >>>>>> ./configure --prefix=${InstallDir} \ >>>>>> --with-pm=hydra --with-device=ch3:nemesis \ >>>>>> --disable-chekpointing \ >>>>>> --enable-strict --enable-fast=O3 \ >>>>>> --disable-f77 --disable-fc \ >>>>>> CC=/grid/common/pkgs/gcc/v4.4.5/bin/gcc CFLAGS="-m32 -fPIC" \ >>>>>> CPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp \ >>>>>> CXX=/grid/common/pkgs/gcc/v4.4.5/bin/g++ CXXFLAGS="-m32 -fPIC" \ >>>>>> CXXCPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp >>>>>> >>>>>> GCC 4.4.5 is also produce next warnings: >>>>>> >>>>>> mpi-io/write.c: In function 'MPIOI_File_write': >>>>>> mpi-io/write.c:126: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_all.c: In function 'MPIOI_File_write_all': >>>>>> mpi-io/write_all.c:109: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_allb.c: In function 'MPIOI_File_write_all_begin': >>>>>> mpi-io/write_allb.c:105: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_ord.c: In function 'PMPI_File_write_ordered': >>>>>> mpi-io/write_ord.c:98: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_ord.c:100: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_ordb.c: In function 'PMPI_File_write_ordered_begin': >>>>>> mpi-io/write_ordb.c:104: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_ordb.c:106: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_sh.c: In function 'PMPI_File_write_shared': >>>>>> mpi-io/write_sh.c:100: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_sh.c:102: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/mpiu_external32.c: In function 'MPIU_write_external32_conversion_fn': >>>>>> mpi-io/mpiu_external32.c:24: warning: implicit declaration of function 'MPIR_Datatype_iscontig' >>>>>> mpi-io/mpiu_external32.c:24: warning: nested extern declaration of 'MPIR_Datatype_iscontig' >>>>>> mpi-io/mpiu_external32.c: In function 'MPIU_datatype_full_size': >>>>>> mpi-io/mpiu_external32.c:123: warning: unused variable 'extent' >>>>>> ./pm/pmiserv/pmip_cb.c: In function 'parse_exec_params': >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>>> src/mpi/datatype/status_set_elements.c: In function 'PMPI_Status_set_elements': >>>>>> src/mpi/datatype/status_set_elements.c:54: warning: unused variable 'size' >>>>>> src/mpi/datatype/status_set_elements_x.c: In function 'MPIR_Status_set_elements_x_impl': >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' undeclared (first use in this function) >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: (Each undeclared identifier is reported only once >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: for each function it appears in.) >>>>>> >>>>>> Eugene. >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 >>> <make><close.s>_______________________________________________ >>> 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 > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

using MPICH_FAILED_PROCESSES
by Ma, Zhaoming 27 Nov '12

27 Nov '12

I am trying to use the following to catch failed processes, MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*) I am using MPICH2 1.4 and g++. Someone posted a C program that does this successfully. The link is http://hi.baidu.com/ejoywx/item/74233ccb9dd20815515058ae. However, I am having trouble making my C++ testing program (attached) working. The code compiled ok but produces the following runtime error, terminate called after throwing an instance of 'MPI::Exception' APPLICATION TERMINATED WITH THE EXIT STRING: Aborted (signal 6) If I comment out the line "MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*)" or put it in a try and catch block, the test program runs fine. Thank you for your help. Zhaoming

1 0

Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Yauheni Zelenko 27 Nov '12

27 Nov '12

Hi, Dave! I played with preprocessor output aand it looks like this is problem of RHEL 5.5. _FILE_OFFSET_BITS=64 forces to redirect stat/fstat to their 64 bit counterparts (with __asm__) . _LARGEFILE64_SOURCE defines stat/fstat/stat64/fstat64. So combination of both will cause redefinition of stat64/fstat64. BTW _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 appear twice in compiler command line. Eugene. ________________________________________ From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] Sent: Wednesday, November 21, 2012 10:38 AM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 Hi Eugene, I was not able to reproduce this behavior on RHEL 5.8 with gcc-4.1 or gcc-4.6 (though I was able to reproduce the earlier LLONG_MAX issue). Would you please dig in here and debug a bit for us? It seems that there is something very specific about your environment and/or compiler that is causing a problem here. -Dave On Nov 20, 2012, at 7:07 PM CST, Yauheni Zelenko wrote: > Your guess is correct. Compilation is fine when only one of defines left in command line. > > You could try to install CentOS which is copy of RHEL. > > Alternatively, I could send files in questions. > > Eugene. > ________________________________________ > From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] > Sent: Tuesday, November 20, 2012 4:57 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 > > My suspicion is that it is more likely related to the following arguments: > > ----8<---- > -D_LARGEFILE64_SOURCE > -D_FILE_OFFSET_BITS=64 > ----8<---- > > Can you try running that same gcc command from the build directory's "src/mpi/romio" directory but with omitting various combinations of the two above options? > > Reading the source of feature.h and/or stat.h would probably also help, although I do not have a RHEL5/6 system handy. > > -Dave > > On Nov 20, 2012, at 6:09 PM CST, Yauheni Zelenko wrote: > >> Hi, Dave! >> >> See attached files for make output in verbose mode and generated assembler code. >> >> Eugene. >> ________________________________________ >> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >> Sent: Tuesday, November 20, 2012 3:18 PM >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >> >> It seems unlikely to me that the headers distributed in RHEL5/RHEL6 are incompatible with GCC being in C99 mode. Can you give me a little more information about what's failing? Perhaps run "make V=1 2>&1 | tee m.txt" and send m.txt as an attachment? >> >> -Dave >> >> On Nov 20, 2012, at 5:08 PM CST, Yauheni Zelenko wrote: >> >>> Hi, Dave! >>> >>> I think this is result of inlining in C99 mode. >>> >>> Eugene. >>> ________________________________________ >>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>> Sent: Tuesday, November 20, 2012 3:06 PM >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>> >>> I'm not sure I follow you on the fstat64/stat64 double-definition issue. Is this just some sort of bug in the RHEL6 headers? Is there something that we (MPICH) are doing incorrectly w.r.t. this? >>> >>> -Dave >>> >>> On Nov 14, 2012, at 5:39 PM CST, Yauheni Zelenko wrote: >>> >>>> Hi, Dave! >>>> >>>> Build failed on first compilation because fstat64 and stat64 defined twice. Likely because of these functions inlining in /usr/include/sys/stat.h. >>>> >>>> Also GCC 4.7.2 warnings on Red Hat Enterprise Linux 6: >>>> >>>> src/mpltrmem.c: In function 'MPL_trdump': >>>> src/mpltrmem.c:536:14: warning: variable 'old_head' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/opminloc.c: In function 'MPIR_MINLOC': >>>> src/mpi/coll/opminloc.c:85:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/opmaxloc.c: In function 'MPIR_MAXLOC': >>>> src/mpi/coll/opmaxloc.c:86:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>> src/mpid/ch3/src/ch3u_rma_sync.c: In function 'MPIDI_CH3I_Recv_rma_msg': >>>> src/mpid/ch3/src/ch3u_rma_sync.c:1251:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpid/ch3/src/mpidi_pg.c: In function 'connToString': >>>> src/mpid/ch3/src/mpidi_pg.c:972:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPIDI_CH3I_Progress': >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:394:21: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPID_nem_handle_pkt': >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:636:17: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:684:13: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c: In function 'alloc_sc_plfd_tbls': >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:183:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_sc' will never be NULL [-Waddress] >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:184:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_plfd' will never be NULL [-Waddress] >>>> src/mpid/common/datatype/mpid_type_debug.c: In function 'MPIDI_Datatype_printf': >>>> src/mpid/common/datatype/mpid_type_debug.c:238:59: warning: variable 'sticky_ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:48: warning: variable 'sticky_lb' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:44: warning: variable 'ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:31: warning: variable 'true_ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:236:11: warning: variable 'string' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_bruck': >>>> src/mpi/coll/iallgather.c:329:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_inter': >>>> src/mpi/coll/iallgather.c:580:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_rec_dbl': >>>> src/mpi/coll/iallgatherv.c:259:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_bruck': >>>> src/mpi/coll/iallgatherv.c:398:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_redscat_allgather': >>>> src/mpi/coll/iallreduce.c:282:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_rec_dbl': >>>> src/mpi/coll/iallreduce.c:425:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/ired_scat_block.c: In function 'MPIR_Ireduce_scatter_block_inter': >>>> src/mpi/coll/ired_scat_block.c:899:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/ireduce.c: In function 'MPIR_Ireduce_SMP': >>>> src/mpi/coll/ireduce.c:677:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> >>>> Eugene. >>>> ________________________________________ >>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>> Sent: Wednesday, November 14, 2012 2:46 PM >>>> To: discuss(a)mpich.org >>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>> >>>> This is because you have selected a bare "--enable-strict" option to configure, which defaults to c89. I'll see if there's a more pleasant way around this, but in the meantime is it acceptable for you to pass "--enable-strict=c99" instead? >>>> >>>> The problem occurs because your compiler still responds to the "long long" type but disables the "LLONG_MAX" constant when asked for c89 mode. >>>> >>>> -Dave >>>> >>>> On Nov 14, 2012, at 4:14 PM CST, Yauheni Zelenko wrote: >>>> >>>>> Hi! >>>>> >>>>> I'm trying to compile MPICH 3.0 rc1 on Red Hat Enterprise Linux 5 and compilation failed because of undefined LLONG_MAX. >>>>> >>>>> LLONG_MAX definition in /usr/include/limits.h is depend on C99 condition. -std=c89 is passed to GCC. >>>>> >>>>> My configure options: >>>>> >>>>> ./configure --prefix=${InstallDir} \ >>>>> --with-pm=hydra --with-device=ch3:nemesis \ >>>>> --disable-chekpointing \ >>>>> --enable-strict --enable-fast=O3 \ >>>>> --disable-f77 --disable-fc \ >>>>> CC=/grid/common/pkgs/gcc/v4.4.5/bin/gcc CFLAGS="-m32 -fPIC" \ >>>>> CPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp \ >>>>> CXX=/grid/common/pkgs/gcc/v4.4.5/bin/g++ CXXFLAGS="-m32 -fPIC" \ >>>>> CXXCPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp >>>>> >>>>> GCC 4.4.5 is also produce next warnings: >>>>> >>>>> mpi-io/write.c: In function 'MPIOI_File_write': >>>>> mpi-io/write.c:126: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_all.c: In function 'MPIOI_File_write_all': >>>>> mpi-io/write_all.c:109: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_allb.c: In function 'MPIOI_File_write_all_begin': >>>>> mpi-io/write_allb.c:105: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_ord.c: In function 'PMPI_File_write_ordered': >>>>> mpi-io/write_ord.c:98: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_ord.c:100: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_ordb.c: In function 'PMPI_File_write_ordered_begin': >>>>> mpi-io/write_ordb.c:104: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_ordb.c:106: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_sh.c: In function 'PMPI_File_write_shared': >>>>> mpi-io/write_sh.c:100: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_sh.c:102: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/mpiu_external32.c: In function 'MPIU_write_external32_conversion_fn': >>>>> mpi-io/mpiu_external32.c:24: warning: implicit declaration of function 'MPIR_Datatype_iscontig' >>>>> mpi-io/mpiu_external32.c:24: warning: nested extern declaration of 'MPIR_Datatype_iscontig' >>>>> mpi-io/mpiu_external32.c: In function 'MPIU_datatype_full_size': >>>>> mpi-io/mpiu_external32.c:123: warning: unused variable 'extent' >>>>> ./pm/pmiserv/pmip_cb.c: In function 'parse_exec_params': >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>> src/mpi/datatype/status_set_elements.c: In function 'PMPI_Status_set_elements': >>>>> src/mpi/datatype/status_set_elements.c:54: warning: unused variable 'size' >>>>> src/mpi/datatype/status_set_elements_x.c: In function 'MPIR_Status_set_elements_x_impl': >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' undeclared (first use in this function) >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: (Each undeclared identifier is reported only once >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: for each function it appears in.) >>>>> >>>>> Eugene. >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 >> <make><close.s>_______________________________________________ >> 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] MPICH2 for Win: Topology functions
by Alejandro Allievi 27 Nov '12

27 Nov '12

Hi Rajeev, Thanks for the reply. Found the culprit: a function declaration within "main". Program works fine when I move it out of main, don't know why though. Alejandro On Tue, Nov 27, 2012 at 4:01 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > Can you send us a small standalone test program that demonstrates the error? > > Rajeev > > On Nov 27, 2012, at 7:27 AM, Alejandro Allievi wrote: > >> Hi, >> >> I'm setting up a grid topology and associated communicator using the >> function Setup_grid below. It works fine for process zero but throws: >> >> Fatal error in PMPI_Comm_rank: Invalid communicator, error stack: >> PMPI_Comm_rank(109): MPI_Comm_rank(MPI_COMM_NULL, rank=000000000022FE4C) failed >> PMPI_Comm_rank(66).: Null communicator >> >> Does MPICH2 for Win7 support topology functions??? >> >> Thanks for any help. >> >> Alejandro >> >> ************CODE BELOW*************************** >> void Setup_grid(GRID_INFO_T* grid /* out */) { >> int old_rank; >> int dimensions[2]; >> int wrap_around[2]; >> int coordinates[2]; >> int free_coords[2]; >> >> >> /* Set up Global Grid Information */ >> MPI_Comm_size(MPI_COMM_WORLD, &(grid->p)); >> MPI_Comm_rank(MPI_COMM_WORLD, &old_rank); >> >> printf("Process %d of %d inside Setup_Grid\n", old_rank, grid->p); >> >> /* We assume p is a perfect square */ >> grid->q = (int) sqrt((double) grid->p); >> dimensions[0] = dimensions[1] = grid->q; >> >> /* We want a circular shift in second dimension. */ >> /* Don't care about first */ >> wrap_around[0] = wrap_around[1] = 1; >> MPI_Cart_create(MPI_COMM_WORLD, 2, dimensions, >> wrap_around, 1, &(grid->comm)); >> >> MPI_Comm_rank(grid->comm, &(grid->my_rank)); >> MPI_Cart_coords(grid->comm, grid->my_rank, 2, coordinates); >> grid->my_row = coordinates[0]; >> grid->my_col = coordinates[1]; >> >> /* Set up row communicators */ >> free_coords[0] = 0; >> free_coords[1] = 1; >> MPI_Cart_sub(grid->comm, free_coords, &(grid->row_comm)); >> >> /* Set up column communicators */ >> free_coords[0] = 1; >> free_coords[1] = 0; >> MPI_Cart_sub(grid->comm, free_coords, &(grid->col_comm)); >> >> printf("Process %d leaving Setup_Grid\n", old_rank); >> >> } /* Setup_grid */ >> >> -- >> Alejandro Allievi >> http://www.ace-net.ca/wiki/Alejandro_Allievi >> >> "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, >> notre véritable sentiment n'est pas celui dans lequel nous n'avons >> jamais vacillé; mais celui auquel nous sommes le plus habituellement >> revenus". Denis Diderot. >> >> Este e-mail esta consignado sólo para el destinatario designado en el >> mismo y puede contener información confidencial y privilegiada. Su >> distribución o copiado está prohibido. Si Usted no fuera el >> destinatario designado, por favor notifíquenos de inmediato y destruya >> este e-mail en forma permanente así como todas las copias del mismo. >> Ce courriel peut renfermer des renseignements confidentiels et >> privilégiés et s'adresse au destinataire désigné seulement. La >> distribution ou la copie de ce courriel est interdit. Si vous n'êtes >> pas le destinataire désigné, veuillez nous en aviser immédiatement et >> détruire de façon permanente ce courriel ainsi que toute copie de >> celui-ci. This e-mail may contain confidential information, and is >> intended only for the named recipient and may be privileged. >> Distribution or copying of this email is prohibited. If you are not >> the named recipient, please notify us immediately and permanently >> destroy this email and all copies of it. >> _______________________________________________ >> 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 -- Alejandro Allievi http://www.ace-net.ca/wiki/Alejandro_Allievi "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, notre véritable sentiment n'est pas celui dans lequel nous n'avons jamais vacillé; mais celui auquel nous sommes le plus habituellement revenus". Denis Diderot. Este e-mail esta consignado sólo para el destinatario designado en el mismo y puede contener información confidencial y privilegiada. Su distribución o copiado está prohibido. Si Usted no fuera el destinatario designado, por favor notifíquenos de inmediato y destruya este e-mail en forma permanente así como todas las copias del mismo. Ce courriel peut renfermer des renseignements confidentiels et privilégiés et s'adresse au destinataire désigné seulement. La distribution ou la copie de ce courriel est interdit. Si vous n'êtes pas le destinataire désigné, veuillez nous en aviser immédiatement et détruire de façon permanente ce courriel ainsi que toute copie de celui-ci. This e-mail may contain confidential information, and is intended only for the named recipient and may be privileged. Distribution or copying of this email is prohibited. If you are not the named recipient, please notify us immediately and permanently destroy this email and all copies of it.

1 0

Re: [mpich-discuss] MPICH2 for Win: Topology functions
by Rajeev Thakur 27 Nov '12

27 Nov '12

Can you send us a small standalone test program that demonstrates the error? Rajeev On Nov 27, 2012, at 7:27 AM, Alejandro Allievi wrote: > Hi, > > I'm setting up a grid topology and associated communicator using the > function Setup_grid below. It works fine for process zero but throws: > > Fatal error in PMPI_Comm_rank: Invalid communicator, error stack: > PMPI_Comm_rank(109): MPI_Comm_rank(MPI_COMM_NULL, rank=000000000022FE4C) failed > PMPI_Comm_rank(66).: Null communicator > > Does MPICH2 for Win7 support topology functions??? > > Thanks for any help. > > Alejandro > > ************CODE BELOW*************************** > void Setup_grid(GRID_INFO_T* grid /* out */) { > int old_rank; > int dimensions[2]; > int wrap_around[2]; > int coordinates[2]; > int free_coords[2]; > > > /* Set up Global Grid Information */ > MPI_Comm_size(MPI_COMM_WORLD, &(grid->p)); > MPI_Comm_rank(MPI_COMM_WORLD, &old_rank); > > printf("Process %d of %d inside Setup_Grid\n", old_rank, grid->p); > > /* We assume p is a perfect square */ > grid->q = (int) sqrt((double) grid->p); > dimensions[0] = dimensions[1] = grid->q; > > /* We want a circular shift in second dimension. */ > /* Don't care about first */ > wrap_around[0] = wrap_around[1] = 1; > MPI_Cart_create(MPI_COMM_WORLD, 2, dimensions, > wrap_around, 1, &(grid->comm)); > > MPI_Comm_rank(grid->comm, &(grid->my_rank)); > MPI_Cart_coords(grid->comm, grid->my_rank, 2, coordinates); > grid->my_row = coordinates[0]; > grid->my_col = coordinates[1]; > > /* Set up row communicators */ > free_coords[0] = 0; > free_coords[1] = 1; > MPI_Cart_sub(grid->comm, free_coords, &(grid->row_comm)); > > /* Set up column communicators */ > free_coords[0] = 1; > free_coords[1] = 0; > MPI_Cart_sub(grid->comm, free_coords, &(grid->col_comm)); > > printf("Process %d leaving Setup_Grid\n", old_rank); > > } /* Setup_grid */ > > -- > Alejandro Allievi > http://www.ace-net.ca/wiki/Alejandro_Allievi > > "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, > notre véritable sentiment n'est pas celui dans lequel nous n'avons > jamais vacillé; mais celui auquel nous sommes le plus habituellement > revenus". Denis Diderot. > > Este e-mail esta consignado sólo para el destinatario designado en el > mismo y puede contener información confidencial y privilegiada. Su > distribución o copiado está prohibido. Si Usted no fuera el > destinatario designado, por favor notifíquenos de inmediato y destruya > este e-mail en forma permanente así como todas las copias del mismo. > Ce courriel peut renfermer des renseignements confidentiels et > privilégiés et s'adresse au destinataire désigné seulement. La > distribution ou la copie de ce courriel est interdit. Si vous n'êtes > pas le destinataire désigné, veuillez nous en aviser immédiatement et > détruire de façon permanente ce courriel ainsi que toute copie de > celui-ci. This e-mail may contain confidential information, and is > intended only for the named recipient and may be privileged. > Distribution or copying of this email is prohibited. If you are not > the named recipient, please notify us immediately and permanently > destroy this email and all copies of it. > _______________________________________________ > 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] Mpich2's behavior when too many messages are sent
by Matthieu Dorier 27 Nov '12

27 Nov '12

Thank you both for your answer! Matthieu ----- Mail original ----- > De: "Darius Buntinas" <buntinas(a)mcs.anl.gov> > À: discuss(a)mpich.org > Envoyé: Mardi 27 Novembre 2012 15:49:15 > Objet: Re: [mpich-discuss] Mpich2's behavior when too many messages are sent > > The MPI standard allows an implementation to run out of resources, so > MPICH is compliant here :-). As Jeff mentioned it is a "quality of > implementation" issue and some implementations might be able to > handle it better than others. Simply queuing the sends on the > sender side can lead to deadlocks, so something trickier is needed > (imagine that the receiver posts a blocking receive with tag A > followed by a million receives with tag B, and the sender sends a > million messages with tag B then one message with tag A. If we > queue the messages at the sender, the receiver will never receive > the message with tag A and the program deadlocks). > > We've seen such "flow-control" problems before (some in out test > suite), and generally the solution is to add some sort of > synchronization in the application, e.g., to an Ssend (or Issend so > long as you wait on the requests often enough) once in a while to > let the receiver catch up. > > -d > > On Nov 27, 2012, at 2:50 AM, Matthieu Dorier wrote: > > > Hello, > > > > I have a program that include two processes, one is doing a lot of > > MPI_Isend, the other one loops, receives the messages using > > MPI_Irecv and treats them. > > I'd like to know what the MPI-2 standard says, and what Mpich2 > > does, if the first process is too fast and the second process > > cannot keep up with the number of messages sent. Is the first > > process supposed to eventually block, waiting for the messages to > > be received, or will the application crashes? > > > > Thanks > > > > Matthieu Dorier > > PhD student at ENS Cachan Brittany and IRISA > > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > > 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] Mpich2's behavior when too many messages are sent
by Darius Buntinas 27 Nov '12

27 Nov '12

The MPI standard allows an implementation to run out of resources, so MPICH is compliant here :-). As Jeff mentioned it is a "quality of implementation" issue and some implementations might be able to handle it better than others. Simply queuing the sends on the sender side can lead to deadlocks, so something trickier is needed (imagine that the receiver posts a blocking receive with tag A followed by a million receives with tag B, and the sender sends a million messages with tag B then one message with tag A. If we queue the messages at the sender, the receiver will never receive the message with tag A and the program deadlocks). We've seen such "flow-control" problems before (some in out test suite), and generally the solution is to add some sort of synchronization in the application, e.g., to an Ssend (or Issend so long as you wait on the requests often enough) once in a while to let the receiver catch up. -d On Nov 27, 2012, at 2:50 AM, Matthieu Dorier wrote: > Hello, > > I have a program that include two processes, one is doing a lot of MPI_Isend, the other one loops, receives the messages using MPI_Irecv and treats them. > I'd like to know what the MPI-2 standard says, and what Mpich2 does, if the first process is too fast and the second process cannot keep up with the number of messages sent. Is the first process supposed to eventually block, waiting for the messages to be received, or will the application crashes? > > Thanks > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0