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

Re: [mpich-discuss] [SPAM] Re: [SPAM] Re: Fw: FAIL of test_primitives in installing of mpich-3.1.2
by yangyi＠lzu.edu.cn 27 Aug '14

27 Aug '14

Thanks a lot. I'll test with "make testing". > -----原始邮件----- > 发件人: "Rajeev Thakur" <thakur(a)mcs.anl.gov> > 发送时间: 2014-08-28 09:05:51 (星期四) > 收件人: discuss(a)mpich.org > 抄送: > 主题: [SPAM] Re: [mpich-discuss] [SPAM] Re: Fw: FAIL of test_primitives in installing of mpich-3.1.2 > > Run "make testing". If all (or almost all) those tests pass, the MPICH installation is ok. The non-scalability could be for other reasons such as the application code not being suitable for a shared-memory machine. > > Rajeev > > > On Aug 27, 2014, at 7:52 PM, <yangyi(a)lzu.edu.cn> > wrote: > > > Dear Rajeev, > > Thanks for your reply. > > The time that listed is from runing a forecast of test with WRF(Weather Research and Forecasting ) model. > > I wonder the FAIL of test_primitives may cause the performance is very poor. > > Thanks! > > > > Yi > >> -----原始邮件----- > >> 发件人: "Rajeev Thakur" <thakur(a)mcs.anl.gov> > >> 发送时间: 2014-08-28 08:05:47 (星期四) > >> 收件人: discuss(a)mpich.org > >> 抄送: > >> 主题: [SPAM] Re: [mpich-discuss] Fw: FAIL of test_primitives in installing of mpich-3.1.2 > >> > >> If you run "make testing" in the top-level mpich directory, it will run the entire test suite in test/mpi. But those tests don't use as many processes as the number of cores you have listed below. (The number of processes for each test is in the testlist file in each directory under test/mpi.) So what is it that you are running with the different number of cores below? > >> > >> Rajeev > >> > >> > >> On Aug 27, 2014, at 6:14 PM, <yangyi(a)lzu.edu.cn> > >> wrote: > >> > >>> Dear sir, > >>> I installed the mpich-3.1.2 on a machine of IBM X3850 X5 which with 4 Xeon E7-4820 (8 cores, 16 threads) CPU and 64G memory. > >>> It has problem of test_primitives in make check. > >>> > >>> It uses the mininum amount of time with 8 cores. The following is the time with differernt cores: > >>> 60 cores no resuls are out although the executable program is running > >>> 56 cores EXIT CODE: 11 Segmentation fault (signal 11) > >>> 48 cores 1hour18min > >>> 40 cores 1h11m > >>> 32 cores 1h9m > >>> 24 cores 1h9m > >>> 16 cores 1h10m > >>> 8 cores 55m > >>> 4 cors 1h20m > >>> > >>> The log files of inatlling are attached. > >>> I'm looking forward to your reply at your earliest convenience. > >>> > >>> > >>> Sincerely, > >>> Yi > >>> > >>> > >>> <config.log><configure.out><make.out><make_check.out><make_install.out>_______________________________________________ > >>> 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] [SPAM] Re: Fw: FAIL of test_primitives in installing of mpich-3.1.2
by Rajeev Thakur 27 Aug '14

27 Aug '14

Run "make testing". If all (or almost all) those tests pass, the MPICH installation is ok. The non-scalability could be for other reasons such as the application code not being suitable for a shared-memory machine. Rajeev On Aug 27, 2014, at 7:52 PM, <yangyi(a)lzu.edu.cn> wrote: > Dear Rajeev, > Thanks for your reply. > The time that listed is from runing a forecast of test with WRF(Weather Research and Forecasting ) model. > I wonder the FAIL of test_primitives may cause the performance is very poor. > Thanks! > > Yi >> -----原始邮件----- >> 发件人: "Rajeev Thakur" <thakur(a)mcs.anl.gov> >> 发送时间: 2014-08-28 08:05:47 (星期四) >> 收件人: discuss(a)mpich.org >> 抄送: >> 主题: [SPAM] Re: [mpich-discuss] Fw: FAIL of test_primitives in installing of mpich-3.1.2 >> >> If you run "make testing" in the top-level mpich directory, it will run the entire test suite in test/mpi. But those tests don't use as many processes as the number of cores you have listed below. (The number of processes for each test is in the testlist file in each directory under test/mpi.) So what is it that you are running with the different number of cores below? >> >> Rajeev >> >> >> On Aug 27, 2014, at 6:14 PM, <yangyi(a)lzu.edu.cn> >> wrote: >> >>> Dear sir, >>> I installed the mpich-3.1.2 on a machine of IBM X3850 X5 which with 4 Xeon E7-4820 (8 cores, 16 threads) CPU and 64G memory. >>> It has problem of test_primitives in make check. >>> >>> It uses the mininum amount of time with 8 cores. The following is the time with differernt cores: >>> 60 cores no resuls are out although the executable program is running >>> 56 cores EXIT CODE: 11 Segmentation fault (signal 11) >>> 48 cores 1hour18min >>> 40 cores 1h11m >>> 32 cores 1h9m >>> 24 cores 1h9m >>> 16 cores 1h10m >>> 8 cores 55m >>> 4 cors 1h20m >>> >>> The log files of inatlling are attached. >>> I'm looking forward to your reply at your earliest convenience. >>> >>> >>> Sincerely, >>> Yi >>> >>> >>> <config.log><configure.out><make.out><make_check.out><make_install.out>_______________________________________________ >>> 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] [SPAM] Re: Fw: FAIL of test_primitives in installing of mpich-3.1.2
by yangyi＠lzu.edu.cn 27 Aug '14

27 Aug '14

Dear Rajeev, Thanks for your reply. The time that listed is from runing a forecast of test with WRF(Weather Research and Forecasting ) model. I wonder the FAIL of test_primitives may cause the performance is very poor. Thanks! Yi > -----原始邮件----- > 发件人: "Rajeev Thakur" <thakur(a)mcs.anl.gov> > 发送时间: 2014-08-28 08:05:47 (星期四) > 收件人: discuss(a)mpich.org > 抄送: > 主题: [SPAM] Re: [mpich-discuss] Fw: FAIL of test_primitives in installing of mpich-3.1.2 > > If you run "make testing" in the top-level mpich directory, it will run the entire test suite in test/mpi. But those tests don't use as many processes as the number of cores you have listed below. (The number of processes for each test is in the testlist file in each directory under test/mpi.) So what is it that you are running with the different number of cores below? > > Rajeev > > > On Aug 27, 2014, at 6:14 PM, <yangyi(a)lzu.edu.cn> > wrote: > > > Dear sir, > > I installed the mpich-3.1.2 on a machine of IBM X3850 X5 which with 4 Xeon E7-4820 (8 cores, 16 threads) CPU and 64G memory. > > It has problem of test_primitives in make check. > > > > It uses the mininum amount of time with 8 cores. The following is the time with differernt cores: > > 60 cores no resuls are out although the executable program is running > > 56 cores EXIT CODE: 11 Segmentation fault (signal 11) > > 48 cores 1hour18min > > 40 cores 1h11m > > 32 cores 1h9m > > 24 cores 1h9m > > 16 cores 1h10m > > 8 cores 55m > > 4 cors 1h20m > > > > The log files of inatlling are attached. > > I'm looking forward to your reply at your earliest convenience. > > > > > > Sincerely, > > Yi > > > > > > <config.log><configure.out><make.out><make_check.out><make_install.out>_______________________________________________ > > 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] Fw: FAIL of test_primitives in installing of mpich-3.1.2
by Rajeev Thakur 27 Aug '14

27 Aug '14

If you run "make testing" in the top-level mpich directory, it will run the entire test suite in test/mpi. But those tests don't use as many processes as the number of cores you have listed below. (The number of processes for each test is in the testlist file in each directory under test/mpi.) So what is it that you are running with the different number of cores below? Rajeev On Aug 27, 2014, at 6:14 PM, <yangyi(a)lzu.edu.cn> wrote: > Dear sir, > I installed the mpich-3.1.2 on a machine of IBM X3850 X5 which with 4 Xeon E7-4820 (8 cores, 16 threads) CPU and 64G memory. > It has problem of test_primitives in make check. > > It uses the mininum amount of time with 8 cores. The following is the time with differernt cores: > 60 cores no resuls are out although the executable program is running > 56 cores EXIT CODE: 11 Segmentation fault (signal 11) > 48 cores 1hour18min > 40 cores 1h11m > 32 cores 1h9m > 24 cores 1h9m > 16 cores 1h10m > 8 cores 55m > 4 cors 1h20m > > The log files of inatlling are attached. > I'm looking forward to your reply at your earliest convenience. > > > Sincerely, > Yi > > > <config.log><configure.out><make.out><make_check.out><make_install.out>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Fw: FAIL of test_primitives in installing of mpich-3.1.2
by yangyi＠lzu.edu.cn 27 Aug '14

27 Aug '14

Dear sir, I installed the mpich-3.1.2 on a machine of IBM X3850 X5 which with 4 Xeon E7-4820 (8 cores, 16 threads) CPU and 64G memory. It has problem of test_primitives in make check. It uses the mininum amount of time with 8 cores. The following is the time with differernt cores: 60 cores no resuls are out although the executable program is running 56 cores EXIT CODE: 11 Segmentation fault (signal 11) 48 cores 1hour18min 40 cores 1h11m 32 cores 1h9m 24 cores 1h9m 16 cores 1h10m 8 cores 55m 4 cors 1h20m The log files of inatlling are attached. I'm looking forward to your reply at your earliest convenience. Sincerely, Yi

1 0

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

27 Aug '14

This should be fixed in mpich/master. http://git.mpich.org/mpich.git/commitdiff/3a6de022076fc2863eae2daf14c283fc9… — Pavan On Aug 22, 2014, at 3:48 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Hmm. I wonder what the right fix would be. Should we even bother cleaning up stuff in the install directory during a “make clean” or equivalent? Would the right fix be to simply remove the “rm -f” line? > > — Pavan > > On Aug 22, 2014, at 1:11 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > >> On Aug 21, 2014, at 8:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >>> >>> In the root Makefile is >>> >>> # we can only have one clean-local, so we hook into it via conditionally >>> # defined variables in the dependencies section >>> clean-local: $(CLEAN_LOCAL_TARGETS) >>> rm -f ${DESTDIR}${bindir}/mpic++ >> >> I was curious if that was my fault as part of the build system rewrite, so I took a peek at his. It looks like a bug from Pavan's commit in June 2012: http://git.mpich.org/mpich.git/commitdiff/cd88cf96 >> >> The commit he references in his commit was the build system overhaul: http://git.mpich.org/mpich.git/commit/4153c8f8680eeb09a80424f2cc787e799e804… >> >> This is the relevant Makefile.sm that was present at the time of the overhaul: http://git.mpich.org/mpich.git/blob/5283393cd41ab38548477ef967f4205539d8e53… >> >> It has this "rm -f" in a (simplemake-specific) "uninstall-postamble" target, which is rather different from a "clean-local" target. This logic should probably be moved to an "uninstall-local" target instead. I'm in favor adding an UNINSTALL_LOCAL_TARGETS parallel to the CLEAN_LOCAL_TARGETS pattern already in use, but that's a decision for the MPICH guys to make. >> >>> I do not see how this could be correct, since >>> >>> 1) mucking with DESTDIR would require sudo for some configurations and make clean shouldn’t require sudo >>> >>> 2) should make clean muck with DESTDIR anyways? >>> >>> When I run make clean after a make install I do get an permissions error in trying to remove that link. >> >> I agree, it is not correct. >> >> -Dave >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > 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] "make testing" fails on machine?
by James 26 Aug '14

26 Aug '14

Thanks, that let me find the problem - B and C did not have their own names listed in //etc/hosts. Things seem to work OK now. FWIW, the gethostbyname man page says the function is obsolete :-( James On Tue, 26 Aug 2014 13:37:03 -0700, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > Internally MPICH calls ‘gethostbyname’ in initialization. Looks like the > function does not work on your B&C machines. > > — > Huiwei > > On Aug 26, 2014, at 3:24 PM, James <jamesqf(a)charter.net> wrote: > >> Unexpected output in collparmt: MPID_nem_tcp_init(377).............: >> gethostbyname failed, q2 (errno 1) > > _______________________________________________ > 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] "make testing" fails on machine?
by Lu, Huiwei 26 Aug '14

26 Aug '14

Internally MPICH calls ‘gethostbyname’ in initialization. Looks like the function does not work on your B&C machines. — Huiwei On Aug 26, 2014, at 3:24 PM, James <jamesqf(a)charter.net> wrote: > Unexpected output in collparmt: MPID_nem_tcp_init(377).............: > gethostbyname failed, q2 (errno 1)

1 0

"make testing" fails on machine?
by James 26 Aug '14

26 Aug '14

Hi, I'm having a strange problem with mpich. I built & installed it on machine A (a Lenovo T61 running OpenSuSE 13.1), and it seems to run fine on that machine (using mpiexec to start multiple processes). Now I built it on machines B & C (both Intel quad-core, one with OpenSuSE 12.2, one with 13.1). The code is from the same .tgz file ( mpich-3.1.2.tgz) and configured the same (--prefix=/opt/mpich --disable-fortran), but 'make testing' fails with messages like the following. (But if I make e.g. the cpi example and run it as a non-MPI program, it runs ok.) As far as I can tell, the relevant paths & environment vars are exactly the same on all three systems. Any clues as to what my problem could be, or even where to start looking? I did try running mpiexec with the -verbose flag, but none of the output seemed to make sense to me. James Unexpected output in collparmt: Fatal error in MPI_Init: Other MPI error, error stack: Unexpected output in collparmt: MPIR_Init_thread(498)..............: Unexpected output in collparmt: MPID_Init(177).....................: channel initialization failed Unexpected output in collparmt: MPIDI_CH3_Init(89).................: Unexpected output in collparmt: MPID_nem_init(320).................: Unexpected output in collparmt: MPID_nem_tcp_init(171).............: Unexpected output in collparmt: MPID_nem_tcp_get_business_card(418): Unexpected output in collparmt: MPID_nem_tcp_init(377).............: gethostbyname failed, q2 (errno 1) Unexpected output in collparmt: Unexpected output in collparmt: =================================================================================== Unexpected output in collparmt: = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES Unexpected output in collparmt: = PID 29078 RUNNING AT q2 Unexpected output in collparmt: = EXIT CODE: 1 Unexpected output in collparmt: = CLEANING UP REMAINING PROCESSES Unexpected output in collparmt: = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES

1 0

Re: [mpich-discuss] MPI_Get on the same memory location
by Alessandro Fanfarillo 23 Aug '14

23 Aug '14

Thanks for the suggestions. There are two versions of the library: MPI-2/MPI-3 and GASNet. Thanks Alessandro On Sat, Aug 23, 2014 at 5:05 PM, Brian Van Straalen <bvstraalen(a)lbl.gov> wrote: > > I’d recommend > > @inproceedings{dotsenko2004multi, > title={A multi-platform co-array fortran compiler}, > author={Dotsenko, Yuri and Coarfa, Cristian and Mellor-Crummey, John}, > booktitle={Proceedings of the 13th International Conference on Parallel > Architectures and Compilation Techniques}, > pages={29--40}, > year={2004}, > organization={IEEE Computer Society} > } > > > @inproceedings{coarfa2005evaluation, > title={An evaluation of global address space languages: co-array fortran > and unified parallel C}, > author={Coarfa, Cristian and Dotsenko, Yuri and Mellor-Crummey, John and > Cantonnet, Fran{\c{c}}ois and El-Ghazawi, Tarek and Mohanti, Ashrujit and > Yao, Yiyi and Chavarr{\'\i}a-Miranda, Daniel}, > booktitle={Proceedings of the tenth ACM SIGPLAN symposium on Principles > and practice of parallel programming}, > pages={36--47}, > year={2005}, > organization={ACM} > } > > > Which has a large discussion of aliasing and performance with the Rice CAF > compiler and Berkeley UPC compiler > > Short answer is to a) not go through the communication layer when you are in > a shared address space, and b) you have to trick Fortran with dummy > variables so it thinks you are not aliasing, or drop directly to load/store > instructions when handling accesses that share an address space. > > You could also look at some messaging layers that are designed specifically > to support global address space language development, like GASNet or ARMCI. > > Brian > > > > On Aug 23, 2014, at 7:44 AM, William Gropp <wgropp(a)illinois.edu> wrote: > > It is amusing that the original reason for the restriction on aliasing of > arguments comes from Fortran - MPI-1 wanted the language-independent spec to > be expressible in both Fortran and C, and this is a property of Fortran (and > one which aids in performance). > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > On Aug 22, 2014, at 6:04 PM, Brian Van Straalen <bvstraalen(a)lbl.gov> wrote: > > > Disabling the check is probably a bad idea. if you disable it in MPI you > will still push a call to memcpy that has aliased buffers. For many > systems memcpy still does the right thing, but modern fancy memcpy > implementations have permission to produce wrong results if the regions > overlap. > > The MPI spec is clear, and the coarray spec is also clear, and clearly > different. I would recommend handling this in your library implementation > and leave your MPI build as standard. Other MPI builds will be done > standard and you will just be delaying the work. You can’t call MPI_Get > with aliased locations. > > Brian > > > > On Aug 22, 2014, at 3:18 PM, Alessandro Fanfarillo > <fanfarillo(a)ing.uniroma2.it> wrote: > > Could you tell me which flag disables the check? I would suggest this > procedure as temporary workaround. > > Thanks > > On Fri, Aug 22, 2014 at 2:41 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > On Aug 22, 2014, at 1:43 PM, Brian Van Straalen <bvstraalen(a)lbl.gov> wrote: > > Is there a significant cost to have the MPI implementation provide a check > for aliasing? > > > We do check for this error by default in MPICH (which is why this email > thread started). > > There’s a way to turn off the checking through a configure flag as well as > an environment variable, if needed. But that’s essentially saying — I know > it’s wrong, but I’m too lazy to fix my application. > > — Pavan > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > > -- > > Alessandro Fanfarillo > Dip. di Ingegneria Civile ed Ingegneria Informatica > Università di Roma "Tor Vergata" > NCAR Office: +1 (303) 497-2442 > Tel: +39-06-7259 7719 > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > Brian Van Straalen Lawrence Berkeley Lab > BVStraalen(a)lbl.gov Computational Research > (510) 486-4976 Division (crd.lbl.gov) > > > > > _______________________________________________ > 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 > > > Brian Van Straalen Lawrence Berkeley Lab > BVStraalen(a)lbl.gov Computational Research > (510) 486-4976 Division (crd.lbl.gov) > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Alessandro Fanfarillo Dip. di Ingegneria Civile ed Ingegneria Informatica Università di Roma "Tor Vergata" NCAR Office: +1 (303) 497-2442 Tel: +39-06-7259 7719

1 0