July 2013 - discuss - mailman3.cels.anl.gov

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

Re: [mpich-discuss] MPI Benchmark Suite
by Jeff Hammond 05 Jul '13

05 Jul '13

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] discuss Digest, Vol 9, Issue 10
by Sufeng Niu 05 Jul '13

05 Jul '13

Thanks a lot! Jim. Now I make sense Sufeng On Fri, Jul 5, 2013 at 11:25 AM, <discuss-request(a)mpich.org> wrote: > Send discuss mailing list submissions to > discuss(a)mpich.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mpich.org/mailman/listinfo/discuss > or, via email, send a message with subject or body 'help' to > discuss-request(a)mpich.org > > You can reach the person managing the list at > discuss-owner(a)mpich.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of discuss digest..." > > > Today's Topics: > > 1. Re: beginner for remote mem access (sufeng) (Pavan Balaji) > 2. MPI Benchmark Suite (Jiri Simsa) > 3. Re: beginner for remote mem access (sufeng) (Jim Dinan) > 4. Re: beginner for remote mem access (sufeng) (Sufeng Niu) > 5. Re: beginner for remote mem access (sufeng) (Pavan Balaji) > 6. Re: MPI Benchmark Suite (Pavan Balaji) > 7. Re: beginner for remote mem access (sufeng) (Sufeng Niu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 05 Jul 2013 10:36:07 -0500 > From: Pavan Balaji <balaji(a)mcs.anl.gov> > To: discuss(a)mpich.org > Cc: Sufeng Niu <sniu(a)hawk.iit.edu> > Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng) > Message-ID: <51D6E7E7.8070306(a)mcs.anl.gov> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > On 07/05/2013 10:28 AM, Sufeng Niu wrote: > > 1. > > MPI_Win_fence is not similar to MPI_Barrier in some cases. The > > MPICH implementation can turn some calls into no-ops and others into > > MPI_Reduce_scatter. > > I am not quite sure about "turn some calls into no-ops and others into > > MPI_Reduce_scatter" Could you please give an example if possible? > > Another thing is if a process create a window for other process, but the > > data access is available after some operations. Should I use > > MPI_Win_fence or MPI_Barrier to sync? or other methods? > > MPI_WIN_FENCE will make sure that all PUT/GET/ACCUMULATE operations are > complete locally and remotely. This is probably what you need. > > MPI_BARRIER is useless in this case since PUT/GET/ACCUMULATE can be > nonblocking. > > > 2. > > Regarding "use MPI window as thread level", I really don't > > understand your thinking at all. MPI RMA is not shared memory nor is > > MPI a threading model. > > Sorry for uncleared statements, right now I would like to do > > multithreads and MPI hybrid programming. let me give an example: I have > > 3 processes, each one has 8 threads. thread 0 in process 0 creates a RMA > > window. if I would like all other threads to access it, should I use > > thread 0 in process 1, thread 0 in process 2 to MPI_Get the data from > > window, then use shared memory for internal threads to load the data? i > > am not sure what is the proper way for RMA in hybrid model. > > All threads within the OS process are part of the same MPI rank. Any of > them can access the window as the same rank. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > > ------------------------------ > > Message: 2 > Date: Fri, 5 Jul 2013 11:38:13 -0400 > From: Jiri Simsa <jsimsa(a)cs.cmu.edu> > To: discuss(a)mpich.org > Subject: [mpich-discuss] MPI Benchmark Suite > Message-ID: > <CAHs9ut-= > FJeUDG-T2-qqDhcDMBGfGuXPHG7VQp8_xYzXTxPAzA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > 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. > > Best, > > --Jiri Simsa >

1 0

Re: [mpich-discuss] beginner for remote mem access (sufeng)
by Sufeng Niu 05 Jul '13

05 Jul '13

Thanks a lot! Now I got it. Sufeng On Fri, Jul 5, 2013 at 11:20 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On 07/05/2013 11:18 AM, Sufeng Niu wrote: > >> for hybrid RMA issue, did you mean in each rank, remote get the data >> into a shared memory, then threads in each rank load it by thread-level >> operation? >> > > All threads are in the same process, so they all already share memory. > Perhaps its best if you try to learn how threads work before attempting to > use them with MPI. > > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > -- Best Regards, Sufeng Niu ECASP lab, ECE department, Illinois Institute of Technology Tel: 312-731-7219

1 0