- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] mpich on Mac os x
by Wesley Bland 08 Jul '13

08 Jul '13

It seems that you're creating more communicators than MPICH can handle. It's possible that you might be able to get around this by setting the environment variable MPIR_PARAM_CTXID_EAGER_SIZE to something smaller than its default (which is 2). That frees up a few more communicators, but there is a pathological case where even with fewer communicators than the max, MPICH won't be able to agree on a new communicator id when needed. Try changing that environment variable and see if that fixes things. Wesley On Jul 8, 2013, at 5:33 AM, Reem Alraddadi <raba500(a)york.ac.uk> wrote: > Hi all, > I am using mpich-3.0.4 on Mac os x version 10.7.5 to run FLASH code. It works fine in the beginning of the run and then I got the following error: > > Fatal error in MPI_Comm_create: Other MPI error, error stack: > MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc8001349, new_comm=0x7fff606a8614) failed > MPI_Comm_create(577).................: > MPIR_Comm_create_intra(241)..........: > MPIR_Get_contextid(799)..............: > MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (169/2048 free on this process; ignore_id=0) > Fatal error in MPI_Comm_create: Other MPI error, error stack: > MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc80012b6, new_comm=0x7fff670cc614) failed > MPI_Comm_create(577).................: > MPIR_Comm_create_intra(241)..........: > MPIR_Get_contextid(799)..............: > MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (316/2048 free on this process; ignore_id=0) > Fatal error in MPI_Comm_create: Other MPI error, error stack: > MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000004, group=0xc800000e, new_comm=0x7fff629d5614) failed > MPI_Comm_create(577).................: > MPIR_Comm_create_intra(241)..........: > MPIR_Get_contextid(799)..............: > MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (2020/2048 free on this process; ignore_id=0) > Fatal error in MPI_Comm_create: Other MPI error, error stack: > MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc8000020, new_comm=0x7fff639ae614) failed > MPI_Comm_create(577).................: > MPIR_Comm_create_intra(241)..........: > MPIR_Get_contextid(799)..............: > MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (2002/2048 free on this process; ignore_id=0 > > Is there a way to fix that ? > > Thanks, > Reem > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich on Mac os x
by Reem Alraddadi 08 Jul '13

08 Jul '13

Hi all, I am using mpich-3.0.4 on Mac os x version 10.7.5 to run FLASH code. It works fine in the beginning of the run and then I got the following error: Fatal error in MPI_Comm_create: Other MPI error, error stack: MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc8001349, new_comm=0x7fff606a8614) failed MPI_Comm_create(577).................: MPIR_Comm_create_intra(241)..........: MPIR_Get_contextid(799)..............: MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (169/2048 free on this process; ignore_id=0) Fatal error in MPI_Comm_create: Other MPI error, error stack: MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc80012b6, new_comm=0x7fff670cc614) failed MPI_Comm_create(577).................: MPIR_Comm_create_intra(241)..........: MPIR_Get_contextid(799)..............: MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (316/2048 free on this process; ignore_id=0) Fatal error in MPI_Comm_create: Other MPI error, error stack: MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000004, group=0xc800000e, new_comm=0x7fff629d5614) failed MPI_Comm_create(577).................: MPIR_Comm_create_intra(241)..........: MPIR_Get_contextid(799)..............: MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (2020/2048 free on this process; ignore_id=0) Fatal error in MPI_Comm_create: Other MPI error, error stack: MPI_Comm_create(600).................: MPI_Comm_create(comm=0x84000002, group=0xc8000020, new_comm=0x7fff639ae614) failed MPI_Comm_create(577).................: MPIR_Comm_create_intra(241)..........: MPIR_Get_contextid(799)..............: MPIR_Get_contextid_sparse_group(1146): Cannot allocate context ID because of fragmentation (2002/2048 free on this process; ignore_id=0 Is there a way to fix that ? Thanks, Reem

1 0

Support for MIC in MPICH 3.0.4
by Maciej.Golebiewski＠csiro.au 08 Jul '13

08 Jul '13

Hi, I have managed to build MPICH for MIC device and for host system with support for SCIF and using Intel compilers. I am able to start MPI processes on MIC device using mpirun from host or mpiexec on the device itself. I can also run application with some ranks on the host and some on the device. I can't however start more than 4 ranks on any device, if I try to run my application across more than 1 node (be it host or MIC cards): env I_MPI_MIC=enable mpirun -n 1 -host mike.it.csiro.au ./mpptest -bcast : -n 30 -host mic0 /tmp/mpptest.scif -bcast 0: 1: 00000011: 00000170: readv err 0 Fatal error in MPI_Allreduce: Other MPI error, error stack: MPI_Allreduce(861)...............: MPI_Allreduce(sbuf=0x7fff62945a08, rbuf=0x7c5de0, count=1, MPI_DOUBLE, MPI_MAX, MPI_COMM_WORLD) failed MPIR_Allreduce_impl(719).........: MPIR_Allreduce_intra(201)........: allreduce_intra_or_coll_fn(110)..: MPIR_Allreduce_intra(362)........: MPIC_Sendrecv(213)...............: MPIC_Wait(569)...................: MPIDI_CH3I_Progress(367).........: MPID_nem_mpich_blocking_recv(894): state_commrdy_handler(175).......: state_commrdy_handler(138).......: MPID_nem_scif_recv_handler(115)..: Communication error with rank 1 [...bunch of more error messages follows...] This problem does not occur of all ranks run on the same node: env I_MPI_MIC=enable mpirun -n 30 -host mic0 /tmp/mpptest.scif -bcast set default set font variable set curve window y 0.15 0.90 set order d d d x y d title left 'time (us)', bottom 'Size (bytes)', top 'Comm Perf for MPI (pkmic-mic0)', 'type = blocking' #p0 p1 dist len ave time (us) rate 0 29 29 0 11.448860 0.00 0 29 29 32 12.009144 2.665e+6 [...more expected output follows...] Last November there was a short thread on this list (archive: http://lists.mpich.org/pipermail/discuss/2012-November/000109.html) about seemingly similiar problem, but seemed to fizzle out before any solution was offered. I wonder whether there was any progress on it, or perhaps someone else has encountered this problem, too and managed to find a workaround/solution or at least has an explanation as to what is happening. In case someone would like to try and reproduce it, my configure invocation for MPICH on MIC was: ./configure CC="icc" CXX=icpc F77="ifort -warn noalignments" FC="ifort -warn noalignments" \ CXXFLAGS=-mmic CFLAGS=-mmic FFLAGS=-mmic FCFLAGS=-mmic \ MPICHLIB_CFLAGS="-g" MPICHLIB_CXXFLAGS="-g" MPICHLIB_FFLAGS="-g" MPICHLIB_FCFLAGS="-g" \ MPICHLIB_LDFLAGS="-g" LIBS=-lscif LDFLAGS=-L/opt/intel/mic/filesystem/base/lib64 \ --with-device=ch3:nemesis:scif,tcp --disable-romio --disable-mpe --enable-smpcoll \ --enable-fast=defopt --prefix=/apps/mpich-scif/3.0.4/mic --enable-error-checking=runtime \ --enable-timing=runtime --host=i686-linux-gnu \ --with-cross=maint/fcrosscompile/cross_values.txt.mike The settings in cross_values.txt.mike were: # The Fortran related cross compilation values. CROSS_F77_SIZEOF_INTEGER="4" CROSS_F77_SIZEOF_REAL="4" CROSS_F77_SIZEOF_DOUBLE_PRECISION="8" CROSS_F77_TRUE_VALUE="-1" CROSS_F77_FALSE_VALUE="0" CROSS_F90_ADDRESS_KIND="8" CROSS_F90_OFFSET_KIND="8" CROSS_F90_INTEGER_KIND="4" CROSS_F90_REAL_MODEL=" 6 , 37" CROSS_F90_DOUBLE_MODEL=" 15 , 307" CROSS_F90_INTEGER_MODEL=" 9" CROSS_F90_ALL_INTEGER_MODELS=" 2 , 1, 4 , 2, 9 , 4, 18 , 8," CROSS_F90_INTEGER_MODEL_MAP=" { 2 , 1 , 1 }, { 4 , 2 , 2 }, { 9 , 4 , 4 }, { 18 , 8 , 8 }," And finally, the configure invocation for MPICH on the host was: ./configure CC="icc" CXX=icpc F77="ifort -warn noalignments" FC="ifort -warn noalignments" \ MPICHLIB_CFLAGS="-g" MPICHLIB_CXXFLAGS="-g" MPICHLIB_FFLAGS="-g" MPICHLIB_FCFLAGS="-g" \ MPICHLIB_LDFLAGS="-g" LIBS=-lscif LDFLAGS=-L/usr/lib64 --with-device=ch3:nemesis:scif,tcp \ --disable-romio --disable-mpe --enable-smpcoll --enable-fast=defopt \ --prefix=/apps/mpich-scif/3.0.4/intel64 --enable-error-checking=runtime \ --enable-timing=runtime Thanks, Maciej Maciej Golebiewski Applications Support, Advanced Scientific Computing CSIRO IM&T

1 0

Re: [mpich-discuss] Running configure on Suse Enterprise 10
by Rajeev Thakur 06 Jul '13

06 Jul '13

The build seems to have completed, although it detected clock skew. Try running the cpi example in the examples directory. Rajeev On Jul 5, 2013, at 9:43 AM, anton.s.murfin(a)sellafieldsites.com wrote: > > Hi Jeff, Bill > > Thank you for your help. I have disabled f77 and f90 as you suggest using > > ./configure --prefix = /home/ris3/asm7/mpich-3.0.4_build 2>&1 --disable-fc --disable-f77 |tee c_dis_f77_f90.txt > > This did provide a successful outcome interms of a Makefile. However, when trying either; > > make 2>&1 |tee m_dis_f77_f90.txt > > or > > make 2>&1 V=1 |tee m_dis_f77_f90.txt > > the code failed to compile. > > See attached config_dis_f77_f90.log and m_dis_f77_f90.txt for details. > > You may also have seen the email from Bill regarding the integer issue so I will send the appropriate config.log file too. > > Regards, > > Anton > > > > > > Jeff Hammond <jeff.science(a)gmail.com> > Sent by: discuss-bounces(a)mpich.org > 05/07/2013 14:07 > Please respond to > discuss(a)mpich.org > > To > "discuss(a)mpich.org" <discuss(a)mpich.org> > cc > Subject > Re: [mpich-discuss] Running configure on Suse Enterprise 10 > > > > > > Disable Fortran if you don't have a Fortran compiler. The options are shown with the help invocation. > > Jeff > > Sent from my iPhone > > On Jul 5, 2013, at 6:15 AM, "anton.s.murfin(a)sellafieldsites.com" <anton.s.murfin(a)sellafieldsites.com> wrote: > > > Dear MPICH developers, > > I have downloaded and extracted mpich-3.0.4.tar.gz to /home/ris3/asm7/mpich-3.0.4/ > > I then created a build directory as /home/ris3/asm7/mpich-3.0.4_build/ > > I went back to /home/ris3/asm7/mpich-3.0.4/ and executed the .configure script detailed below > > ./configure --prefix = /home/ris3/asm7/mpich-3.0.4_build 2>&1 | tee c.txt (I confirmed I was using bash shell, using echo $SHELL) > > The output from this c.txt is attached and there is only one error right at the bottom although there are some warnings. > > No Makefile is created so the next step make doesn't work. > > I just wanted to see if you can see what the issue is. > > Many thanks > > Anton > > "The information contained in this email may be commercially sensitive and/or legally privileged. It is intended solely for the person(s) to whom it is addressed. If you are not a named recipient, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. You must not disclose it to any other person, copy or distribute it or use it for any purpose. > > Views expressed in this email are not necessarily those of Sellafield Ltd. > > Sellafield Ltd, a company owned by Nuclear Management Partners Ltd, is registered in England and Wales, Company number 1002607. The registered office is situated at Booths Park, Chelford Road, Knutsford, Cheshire WA16 8QZ." > > <c.txt> > _______________________________________________ > 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 > > ***************************************************************************** > This message was received by the Sellafield.Site Internet Email Gateway > > and was checked for Viruses and SPAM by the MessageLabs Email Management Service. > Please forward any suspicious or unwanted emails to "Spam Helpdesk" > ***************************************************************************** > > > > "The information contained in this email may be commercially sensitive and/or legally privileged. It is intended solely for the person(s) to whom it is addressed. If you are not a named recipient, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. You must not disclose it to any other person, copy or distribute it or use it for any purpose. > > Views expressed in this email are not necessarily those of Sellafield Ltd. > > Sellafield Ltd, a company owned by Nuclear Management Partners Ltd, is registered in England and Wales, Company number 1002607. The registered office is situated at Booths Park, Chelford Road, Knutsford, Cheshire WA16 8QZ." > > <config_dis_f77f90.log><m_dis_f77_f90.txt><c_dis_f77_f90.txt><config.log>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI Benchmark Suite
by Rajeev Thakur 06 Jul '13

06 Jul '13

See also the Mantevo mini-apps. http://www.mantevo.org/ On Jul 5, 2013, at 11:22 AM, Pavan Balaji wrote: > > On 07/05/2013 10:38 AM, Jiri Simsa wrote: >> Could anyone point me in the direction of programs that are >> representative of MPI programs? I am looking for something like PARSEC >> (http://parsec.cs.princeton.edu/) for MPI. In other words, I am >> interested in macro-bechnmarks not micro-benchmarks. Thank you. > > You could try the Sequoia suite. There's also the NAS parallel benchmarks and Graph500 benchmarks. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] why does a non-standard GCC in PATH break my all-Intel MPICH config?
by Jed Brown 05 Jul '13

05 Jul '13

Jeff Hammond <jeff.science(a)gmail.com> writes: > So there is no way to disable Intel's auto-detection of GCC from PATH? Well, you can turn off gcc compatibility using -no-gcc, but they still find and execute the gcc found in PATH: $ strace -f icc -E -no-gcc dummy.c |& grep execve execve("/soft/com/packages/intel/13/update4/bin/icc", ["icc", "-E", "-no-gcc", "dummy.c"], [/* 39 vars */]) = 0 [pid 10519] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10519] execve("/usr/sbin/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10519] execve("/usr/bin/gcc", ["gcc", "--print-libgcc-file-name", "-m64"], [/* 40 vars */]) = 0 [pid 10520] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10520] execve("/usr/sbin/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10520] execve("/usr/bin/gcc", ["gcc", "--print-search-dirs", "-m64"], [/* 40 vars */]) = 0 [pid 10521] execve("/usr/lib/lightdm/lightdm/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10521] execve("/usr/sbin/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = -1 ENOENT (No such file or directory) [pid 10521] execve("/usr/bin/gcc", ["gcc", "-m64", "-v", "-E", "/tmp/iccLOE84g.c"], [/* 40 vars */]) = 0 [pid 10522] execve("/usr/lib/gcc/x86_64-linux-gnu/4.4.7/cc1", ["/usr/lib/gcc/x86_64-linux-gnu/4."..., "-E", "-quiet", "-v", "-imultilib", ".", "-imultiarch", "x86_64-linux-gnu", "/tmp/iccLOE84g.c", "-D_FORTIFY_SOURCE=2", "-m64", "-mtune=generic", "-fstack-protector"], [/* 42 vars */]) = 0 [pid 10523] execve("/nfs/software/linux-ubuntu_precise_amd64/com/packages/intel/13/update4/composer_xe_2013.3.163/bin/intel64/mcpcom", ["/nfs/software/linux-ubuntu_preci"..., "@/tmp/iccargQXA8hT"], [/* 40 vars */] <unfinished ...> [pid 10523] <... execve resumed> ) = 0 > I do not see the options > http://software.intel.com/sites/products/documentation/studio/composer/en-u… > or > http://software.intel.com/sites/products/documentation/studio/composer/en-u… > any effect in this regard. Evidently -gcc-version is deprecated, though the man page does not mention that. You can use -gcc-name=/path/to/gcc-4.8.1. >> The Intel(R) C++ Compiler is interoperable with GNU* >> gcc compiler versions greater than or equal to 3.2. >> See the Intel(R) C++ Compiler Documentation for more >> information. > > Well that's complete nonsense since it is clearly not compatible with > GCC 4.8.1. $ cat dummy.c __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__ $ icc -E -gcc-version=480 dummy.c icc: command line remark #10010: option '-gcc-version=480' is deprecated and will be removed in a future release. See '-help deprecated' icc: warning #10126: invalid value '480' for '-gcc-version'; assuming '470' # 1 "dummy.c" 4 7 0 > You mean this is a _runtime_ dependency? Thank goodness I am not > trained in martial arts, or I would have just killed myself with a > lethal slap to the forehead. No, but many people configure software and then expect 'git pull && make' to work correctly. Now they have to remember to load the correct gcc module to coerce the Intel compiler to behave the same way it did during configure (or explicitly pass -gcc-name=/path/to/selected/gcc).

1 0

Re: [mpich-discuss] why does a non-standard GCC in PATH break my all-Intel MPICH config?
by Jeff Hammond 05 Jul '13

05 Jul '13

>> One corresponds to an MPICH configure with my default environment and >> the other with a vanilla environment not including my GCC 4.8.1 >> install. When the environment knows about GCC 4.8.1, configure tests >> related to C++ fail. > > See the icc(1) man page: > > GNU* gcc Interoperability > C++ compilers are interoperable if they can link > object files and libraries generated by one compiler > with object files and libraries generated by the > second compiler, and the resulting executable runs > successfully. Some GNU* gcc versions are not > interoperable, some versions are interoperable. By > default, the Intel compiler will generate code that is > interoperable with the version of gcc it finds on your > system. > > The Intel(R) C++ Compiler options that affect GNU* gcc > interoperability include: > > · -cxxlib > > · -gcc-name > > · -gcc-version > > · -gxx-name > > · -fabi-version > > · -no-gcc (see gcc Predefined Macros for more > information) So there is no way to disable Intel's auto-detection of GCC from PATH? I do not see the options http://software.intel.com/sites/products/documentation/studio/composer/en-u… or http://software.intel.com/sites/products/documentation/studio/composer/en-u… any effect in this regard. > The Intel(R) C++ Compiler is interoperable with GNU* > gcc compiler versions greater than or equal to 3.2. > See the Intel(R) C++ Compiler Documentation for more > information. Well that's complete nonsense since it is clearly not compatible with GCC 4.8.1. > We just debugged essentially this problem from some BW users that > couldn't manage to have exactly the same GCC modules loaded when they > configured PETSc as when they ran later (it took way too many emails to > pin them down on this bit of the environment changing). The gcc-version > also affects the dialect and attributes, so for example, when icc finds > a recent version of gcc, You mean this is a _runtime_ dependency? Thank goodness I am not trained in martial arts, or I would have just killed myself with a lethal slap to the forehead. > __attribute((deprecated("explanation why"))) > > works, but if it finds an old version of gcc, then "explanation why" is > not understood, so only > > __attribute((deprecated)) > > can be used. This dependence on whatever gcc is found in the path is > horrendous for reproducibility since it makes it harder to create > configurations that don't depend on the environment and even if you > concede dependence on the environment, few people realize that the > Intel's compilers change behavior based on the version of gcc found in > PATH. I completely agree. This is atrocious behavior. Does the Intel C++ compiler not work if I don't have GCC installed? What if - as is my inalienable right as the operator of my computer - I alias all GCC commands to /usr/bin/light-machine-room-on-fire or /usr/bin/pull-the-plug-on-grandma? I suppose the Intel commercial license has an indemnification clause, because otherwise, I could get rich by exploiting this nonsense. Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-discuss] MPI Benchmark Suite
by Jiri Simsa 05 Jul '13

05 Jul '13

Jeff, I am not trying to benchmark performance of MPI or beat up on poor old bulk-synchronous MPI-1. My goal is to understand which API functions are most commonly used in programs that are representative of MPI programs. I am doing a Ph.D. on systematic testing on concurrent software. In my experience, software developers use concurrency for the sake of performance, but are unaware of the quantitative implications their designs have on the ability to thoroughly test the code they write. Recently, I have been involved in a project that explores the performance-testability trade-off in the context of multi-threaded programs and I am interested in doing the same in the context of MPI programs. As a start I would like to get a better sense of how people use MPI. I hope this puts any worries you might have about unfair performance comparisons to rest and sheds some light on what I mean by a "macro-benchmark". Best, --Jiri On Fri, Jul 5, 2013 at 1:01 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > What is a macrobenchmark? The more complexity you add to a benchmark, > the harder it is to see the details. This is why most MPI benchmarks > are microbenchmarks. As soon as you add complexity in the usage of > MPI, you run into issues with algorithmic variation. For example, all > of the "macrobenchmarks" I have seen (e.g. NAS PB) are written to > MPI-1. They are also quite simple in their use of MPI, relying upon > barrier synchronization when it may not be necessary or appropriate. > You may see papers that show UPC beating MPI for NAS PB, but these > comparisons are apples-to-oranges; if one rewrote the code to use > nonblocking collectives, RMA or other less synchronous approach, the > performance would likely be as good if not better than UPC. In this > respect, one is not so much evaluating MPI performance (which is the > point of an MPI benchmark, no?) but rather evaluating the use of a > simplistic and perhaps overly synchronous programming model that > happens to use MPI-1. > > What is it you really want to do? Do you have some new-fangled > programming model (NFPM) and you want to beat up on poor old > bulk-synchronous MPI-1? If so, just don't do that. Write your own > comparison between NFMP and MPI-3 using all the same algorithmic > tricks that NFMP does. If you want to understand the performance of > MPI in detail when employed by nontrivial applications, then you > should try to find a nontrivial application that uses MPI very > effectively. Unfortunately, many apps use MPI in a simplistic way > because they are not communication limited in the way that > strong-scaled macrobenchmarks are, hence no exotic use of MPI is > required. I find that better algorithms are usually a more effective > way to improve application performance than going OCD on my use of > MPI... > > It is entirely possible that there does not exist anything out there > that you can reuse. However, this is clearly no problem for you since > you are now well-rested and can complete the project by yourself :-) > I am, of course, referencing > http://www.cs.cmu.edu/~jsimsa/images/dilbert.jpg on your home page :-) > > Best, > > Heff > > On Fri, Jul 5, 2013 at 11:22 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > > > On 07/05/2013 10:38 AM, Jiri Simsa wrote: > >> > >> Could anyone point me in the direction of programs that are > >> representative of MPI programs? I am looking for something like PARSEC > >> (http://parsec.cs.princeton.edu/) for MPI. In other words, I am > >> interested in macro-bechnmarks not micro-benchmarks. Thank you. > > > > > > You could try the Sequoia suite. There's also the NAS parallel > benchmarks > > and Graph500 benchmarks. > > > > -- 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 > > > > -- > Jeff Hammond > jeff.science(a)gmail.com >

1 0

Re: [mpich-discuss] why does a non-standard GCC in PATH break my all-Intel MPICH config?
by Jed Brown 05 Jul '13

05 Jul '13

Jeff Hammond <jeff.science(a)gmail.com> writes: > One corresponds to an MPICH configure with my default environment and > the other with a vanilla environment not including my GCC 4.8.1 > install. When the environment knows about GCC 4.8.1, configure tests > related to C++ fail. See the icc(1) man page: GNU* gcc Interoperability C++ compilers are interoperable if they can link object files and libraries generated by one compiler with object files and libraries generated by the second compiler, and the resulting executable runs successfully. Some GNU* gcc versions are not interoperable, some versions are interoperable. By default, the Intel compiler will generate code that is interoperable with the version of gcc it finds on your system. The Intel(R) C++ Compiler options that affect GNU* gcc interoperability include: · -cxxlib · -gcc-name · -gcc-version · -gxx-name · -fabi-version · -no-gcc (see gcc Predefined Macros for more information) The Intel(R) C++ Compiler is interoperable with GNU* gcc compiler versions greater than or equal to 3.2. See the Intel(R) C++ Compiler Documentation for more information. We just debugged essentially this problem from some BW users that couldn't manage to have exactly the same GCC modules loaded when they configured PETSc as when they ran later (it took way too many emails to pin them down on this bit of the environment changing). The gcc-version also affects the dialect and attributes, so for example, when icc finds a recent version of gcc, __attribute((deprecated("explanation why"))) works, but if it finds an old version of gcc, then "explanation why" is not understood, so only __attribute((deprecated)) can be used. This dependence on whatever gcc is found in the path is horrendous for reproducibility since it makes it harder to create configurations that don't depend on the environment and even if you concede dependence on the environment, few people realize that the Intel's compilers change behavior based on the version of gcc found in PATH.

1 0

why does a non-standard GCC in PATH break my all-Intel MPICH config?
by Jeff Hammond 05 Jul '13

05 Jul '13

Not attached are two config.log files. They were too big. They are instead in my Dropbox Public folder: https://dl.dropboxusercontent.com/u/58983082/mpich-intel-badgcc-config.log https://dl.dropboxusercontent.com/u/58983082/mpich-intel-okgcc-config.log One corresponds to an MPICH configure with my default environment and the other with a vanilla environment not including my GCC 4.8.1 install. When the environment knows about GCC 4.8.1, configure tests related to C++ fail. How does MPICH sniff out this non-standard GCC install when I'm using Intel and how do I fix it? Or is the Intel compiler doing this on its own and there's nothing MPICH can do about it? If the latter, does anyone know how to force the Intel compiler to ignore my non-standard GCC install? Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0