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

Re: [mpich-discuss] Mac OS X version of Mpich
by Dave Goodell (dgoodell) 19 Aug '15

19 Aug '15

On Aug 19, 2015, at 6:29 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > See below where you got a warning for defining MPI to 1? That is going to break EVERYTHING in the MPI C code. Consider the declaration MPI_Init_thread. It will become 1_Init_thread. This is a serious problem. This isn't how the C preprocessor works, Jeff... "#define f x" will not change "fprintf" to "xprintf" later in the source file. > The MPI standard reserves the MPI namespace. You cannot use it. In your case, you took the entire namespace and changed it to a number :-) > > Please use a preprocessor macro like USE_MPI in your application. Do not define any symbols anywhere that being with MPI. This, however, is good advice and should fix this particular issue. -Dave _______________________________________________ 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] Mac OS X version of Mpich
by Jeff Hammond 19 Aug '15

19 Aug '15

See below where you got a warning for defining MPI to 1? That is going to break EVERYTHING in the MPI C code. Consider the declaration MPI_Init_thread. It will become 1_Init_thread. This is a serious problem. The MPI standard reserves the MPI namespace. You cannot use it. In your case, you took the entire namespace and changed it to a number :-) Please use a preprocessor macro like USE_MPI in your application. Do not define any symbols anywhere that being with MPI. Related: http://lists.mpich.org/pipermail/devel/2013-November/000274.html. It's the number 1 google hit for me and the first response is the correct answer. Best, Jeff On Tue, Aug 18, 2015 at 11:39 PM, Benjamin Svetitsky <bqs(a)julian.tau.ac.il> wrote: > Greetings MPICH experts, > > I've run code with MPICH often on my Macbook Pro (4 cores), but not > lately. Recently I updated MPICH from Macports, preparing for new > running. Now my code doesn't compile. Do you know this error message: > ------ > mpicc -c -O3 -DMPI -DPRECISION=2 -I. -DNHYP -DLU ../generic/com_mpi.c > In file included from ../generic/com_mpi.c:104: > /opt/local/include/mpich-clang37/mpi.h:116:56: error: expected identifier > static const MPI_Datatype mpich_mpi_char MPICH_ATTR_TYPE_T... > ^ > /opt/local/include/mpich-clang37/mpi.h:24:106: note: expanded from macro > 'MPICH_ATTR_TYPE_TAG' > ...__attribute__((type_tag_for_datatype(MPI,type))) > ^ > <command line>:1:13: note: expanded from here > #define MPI 1 > ^ > ----- > and then there is a sequence of similar messages, all regarding mpi.h. > The compilation halts after 20 messages. > > I originally tried this with mpich-default, with the same result. I > wondered if it had to do with an incompatibility with clang, so I installed > mpich-clang37 @3.1.4_1+gcc49, with the above result. > > The same code still runs on current MPICH and MVAPICH installations on > several systems. > > Thanks for your help, > Ben > > > -- > Prof. Benjamin Svetitsky Phone: +972-3-640 8870 > School of Physics and Astronomy Fax: +972-3-640 7932 > Tel Aviv University E-mail: bqs(a)julian.tau.ac.il > 69978 Tel Aviv, Israel WWW: http://julian.tau.ac.il/bqs > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Mac OS X version of Mpich
by Benjamin Svetitsky 18 Aug '15

18 Aug '15

_______________________________________________ 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] Loopback IPs should be filtered out by MPICH tools
by Jeff Hammond 17 Aug '15

17 Aug '15

This may be related to https://trac.mpich.org/projects/mpich/ticket/1799 and https://trac.mpich.org/projects/mpich/ticket/2213, or at least I speculate that changing host hostnames are parsed might address all three at once. Jeff On Fri, Aug 14, 2015 at 7:32 AM, Nevolin, Andrey <Andrey.Nevolin(a)emc.com> wrote: > Hi, > > > > I installed MPICH on a cluster deployed in a virtual environment. After > that I spent a lot of time trying to figure out why it doesn’t work. > > > > I’m new to MPICH (and even to MPI). Hence my suggestions about the system > functioning may contradict to the real world. But looks like in my case the > problem has the following roots: > > > > 1) Looks like MPICH nodes use something similar to ‘hostname –i’ to > discover their own IPs > > 2) If several IP aliases exist for a single host name, MPICH picks the > first of them > > 3) Order of IP aliases resembles their order in ‘/etc/hosts/’ list > > 4) VMWare hypervisor automatically adds loop back alias for the host name > (when the cluster is deployed by cloning of a single node). And this alias > is added as a first line in ‘/etc/hosts’ > > 5) All of the above means that MPICH discovers loop back IP in my case. > > > > The problem disappeared when I removed loop back alias from ‘/etc/hosts/’. > > > > Please, change IP discovery process to avoid loop back IP. Or add an > explicit requirement to documentation to avoid loop back aliases in > ‘/etc/hosts’. > > > > Thanks, > > --Andrey > > > > @Andrey_Nevolin <https://twitter.com/Andrey_Nevolin> > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] static building of mpich
by Doha Ehab 15 Aug '15

15 Aug '15

Hello, I have rebuilt mpich with the following cflags and LDflag: export CFLAGS="-march=armv5te -I/home/doha/buildroot-2015.02/output/host/usr/include/" export LDFLAGS="--static -L/home/doha/buildroot-2015.02/output/host/usr/lib/" but still get this mpiexec: symbolic link to `mpiexec.hydra' file mpiexec.hydra mpiexec.hydra: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Thanks, Doha On Wed, Aug 12, 2015 at 12:26 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > The static flag should go into LDFLAGS or LIBS, not CFLAGS. > > Also, for libtool to interpret it correctly, it'll need to be "--static", > not "-static" (double dash instead of single dash). > > -- Pavan > > From: Doha Ehab > Reply-To: "discuss(a)mpich.org" > Date: Tuesday, August 11, 2015 at 11:24 AM > To: "discuss(a)mpich.org" > Subject: Re: [mpich-discuss] static building of mpich > > No , but after I did make and make install I checked whether it was > statically built using the following command : > > file bin/mpiexec > mpiexec: symbolic link to `mpiexec.hydra' > > Then I typed > > file bin/mpiexec.hydrampiexec.hydra: ELF 32-bit LSB executable, Intel > 80386, version 1 (SYSV), dynamically linked (uses shared libs), for > GNU/Linux 2.6.24, BuildID[sha1]=0xb4510fb70ac8047d9028dbafe2d43848140fe894, > not stripped > > I don't understand why it is dynamically linked and not statically linked > > > On Mon, Aug 10, 2015 at 6:13 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> Did you do make and make install? >> >> -- Pavan >> >> From: Doha Ehab >> Reply-To: "discuss(a)mpich.org" >> Date: Sunday, August 9, 2015 at 7:24 PM >> To: "discuss(a)mpich.org" >> Subject: [mpich-discuss] static building of mpich >> >> Hello, >> i'm trying to cross compile mpich , I have extracted mpich-3.1.3 the I >> created a folder name build inside it . In order to statically build mpich >> I used the following commands: >> >> export CC="/home/doha/buildroot-2015.02/output/host/usr/bin/arm-linux-gcc" >> export AR="/home/doha/buildroot-2015.02/output/host/usr/bin/arm-linux-ar" >> export CFLAGS="-march=armv5te -static >> -I/home/doha/buildroot-2015.02/output/host/usr/include/" >> export LDFLAGS="-L/home/doha/buildroot-2015.02/output/host/usr/lib/" >> >> >> cc=/home/doha/buildroot-2015.02/output/host/usr/bin/arm-linux-gcc >> ./configure --prefix=/home/doha/mpich-3.1.3/build/ --host=arm-linux >> --disable-shared --with-pm=hydra --with-device=ch3:nemesis >> --disable-fortran >> >> >> but nothing appears in the build folder while it shows no errors on the >> terminal >> >> _______________________________________________ >> 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

Loopback IPs should be filtered out by MPICH tools
by Nevolin, Andrey 14 Aug '15

14 Aug '15

Hi, I installed MPICH on a cluster deployed in a virtual environment. After that I spent a lot of time trying to figure out why it doesn't work. I'm new to MPICH (and even to MPI). Hence my suggestions about the system functioning may contradict to the real world. But looks like in my case the problem has the following roots: 1) Looks like MPICH nodes use something similar to 'hostname -i' to discover their own IPs 2) If several IP aliases exist for a single host name, MPICH picks the first of them 3) Order of IP aliases resembles their order in '/etc/hosts/' list 4) VMWare hypervisor automatically adds loop back alias for the host name (when the cluster is deployed by cloning of a single node). And this alias is added as a first line in '/etc/hosts' 5) All of the above means that MPICH discovers loop back IP in my case. The problem disappeared when I removed loop back alias from '/etc/hosts/'. Please, change IP discovery process to avoid loop back IP. Or add an explicit requirement to documentation to avoid loop back aliases in '/etc/hosts'. Thanks, --Andrey @Andrey_Nevolin<https://twitter.com/Andrey_Nevolin> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Fortran 2008 compatibility of mpif.h and mpiof.h: Suggested fix
by Martin Diehl 13 Aug '15

13 Aug '15

Dear MPICH maintainers, when I try to compile my Fortran application in strict 2008 standard and include mpif.h, I'll get an error or a warning from both, the GNU and the Intel Fortran compiler, complaining about the declaration of some datatypes When invoking gfortran with -std=f2008ts, the complaints are: Error: GNU Extension: Nonstandard type declaration INTEGER*8 at (1) Warning: Obsolescent feature: Old-style character length at (1) and for ifort with -stand f08, I'll get : warning #6916: Fortran 2008 does not allow this length specification. [8] The CHARACTER* form of a CHARACTER declaration is an obsolescent feature in Fortran 2008. According to http://fortranwiki.org/fortran/show/Modernizing+Old +Fortran, this can be solved by the following changes in mpif.h and mpiof.h: diff mpif.h mpif.h_new 16,17c16,17 < CHARACTER*1 MPI_ARGVS_NULL(1,1) < CHARACTER*1 MPI_ARGV_NULL(1) --- > CHARACTER(len=1) MPI_ARGVS_NULL(1,1) > CHARACTER(len=1) MPI_ARGV_NULL(1) 528c528 < integer*8 MPI_DISPLACEMENT_CURRENT --- > integer(kind=8) MPI_DISPLACEMENT_CURRENT 546,547c546,547 < REAL*8 MPI_WTIME, MPI_WTICK < REAL*8 PMPI_WTIME, PMPI_WTICK --- > REAL(kind=8) MPI_WTIME, MPI_WTICK > REAL(kind=8) PMPI_WTIME, PMPI_WTICK diff mpiof.h mpiof.h_new 29c29 < integer*8 MPI_DISPLACEMENT_CURRENT --- > integer(kind=8) MPI_DISPLACEMENT_CURRENT Please find the modified files attached. best regards Martin Diehl -- ------------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …(a)mpie.de. If you are not sure of the validity please contact rco(a)mpie.de Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …(a)mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an rco(a)mpie.de ------------------------------------------------- _______________________________________________ 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] From file reading to memory sharing
by Balaji, Pavan 12 Aug '15

12 Aug '15

Xin, No, he's not referring to MPI requests. He means large number of operations each reading a small amount of data (from a file). Matthieu, that’s terrible. Don't do that. -- Pavan On 8/12/15, 2:34 PM, "Zhao, Xin" <xinzhao3(a)illinois.edu> wrote: >Hi Matthieu, > >If you are referring to the requests used by RMA operations, there is a CVAR (MPIR_CVAR_CH3_RMA_ACTIVE_REQ_THRESHOLD) in MPICH which can control number of active RMA requests. Basically what it does is if number of active RMA requests reaches that value, RMA operation will be blockingly waiting until number of active requests is reduced. > >If you want to tune that CVAR, I suggest you using the latest MPICH (http://www.mpich.org/static/downloads/nightly/master/mpich/) because we recently modify the default value of it. > >Thanks, >Xin > >________________________________________ >From: Dorier, Matthieu [mdorier(a)anl.gov] >Sent: Wednesday, August 12, 2015 12:36 PM >To: discuss(a)mpich.org >Subject: Re: [mpich-discuss] From file reading to memory sharing > >Hi, > >I'm gessing the cause of the performance issue is the large number of small requests, because when I read the full 7GB using a single process issuing one single MPI_File_read, it gets much better. > >Matthieu >________________________________________ >From: Wei-keng Liao [wkliao(a)eecs.northwestern.edu] >Sent: Wednesday, August 12, 2015 11:56 AM >To: discuss(a)mpich.org >Subject: Re: [mpich-discuss] From file reading to memory sharing > >Hi, Matthieu > >If you have "a series of subdomains (blocks) to load from the file", >one way to get a better I/O performance is to concatenate the filetypes >into a single one and then use only one MPI_File_set_view and one >MPI_File_read_all to read the data. > >FYI. This request aggregation strategy is also used in PnetCDF. > >Wei-keng > >On Aug 12, 2015, at 11:27 AM, Dorier, Matthieu wrote: > >> Hi, >> >> I'm trying to refactor an MPI code using MPI one-sided communications. >> >> The initial version of the code reads its data from a file containing a 3D array of floats. Each process has a series of subdomains (blocks) to load from the file, so they all open the file and then issue a series of MPI_File_set_view and MPI_File_read. The type passed to MPI_File_set_view is constructed using MPI_Type_create_subarray to match the block that needs to be loaded. >> >> This code performs very poorly even at small scale: the file is 7GB but the blocks are a few hundreds of bytes, and each process has many blocks to load. >> >> Instead, I would like to have process rank 0 load the entire file, then expose it over RMA. I'm not familiar at all with MPI one-sided operations, since I never used them before, but I guess there should be a simple way to reuse the subarray datatype of my MPI_File_set_view and use it in the context of an MPI_Get. I'm just not sure what the arguments of this MPI_Get would be. My guess is: origin_count would be the number of floats in a single block, origin_datatype would be MPI_FLOAT, target_rank = 0, target_disp = 0, target_count = 1, target_datatype = my subarray datatype. Would that be correct? >> >> Thanks, >> >> Matthieu >> _______________________________________________ >> 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

Re: [mpich-discuss] From file reading to memory sharing
by Zhao, Xin 12 Aug '15

12 Aug '15

Hi Matthieu, If you are referring to the requests used by RMA operations, there is a CVAR (MPIR_CVAR_CH3_RMA_ACTIVE_REQ_THRESHOLD) in MPICH which can control number of active RMA requests. Basically what it does is if number of active RMA requests reaches that value, RMA operation will be blockingly waiting until number of active requests is reduced. If you want to tune that CVAR, I suggest you using the latest MPICH (http://www.mpich.org/static/downloads/nightly/master/mpich/) because we recently modify the default value of it. Thanks, Xin ________________________________________ From: Dorier, Matthieu [mdorier(a)anl.gov] Sent: Wednesday, August 12, 2015 12:36 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] From file reading to memory sharing Hi, I'm gessing the cause of the performance issue is the large number of small requests, because when I read the full 7GB using a single process issuing one single MPI_File_read, it gets much better. Matthieu ________________________________________ From: Wei-keng Liao [wkliao(a)eecs.northwestern.edu] Sent: Wednesday, August 12, 2015 11:56 AM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] From file reading to memory sharing Hi, Matthieu If you have "a series of subdomains (blocks) to load from the file", one way to get a better I/O performance is to concatenate the filetypes into a single one and then use only one MPI_File_set_view and one MPI_File_read_all to read the data. FYI. This request aggregation strategy is also used in PnetCDF. Wei-keng On Aug 12, 2015, at 11:27 AM, Dorier, Matthieu wrote: > Hi, > > I'm trying to refactor an MPI code using MPI one-sided communications. > > The initial version of the code reads its data from a file containing a 3D array of floats. Each process has a series of subdomains (blocks) to load from the file, so they all open the file and then issue a series of MPI_File_set_view and MPI_File_read. The type passed to MPI_File_set_view is constructed using MPI_Type_create_subarray to match the block that needs to be loaded. > > This code performs very poorly even at small scale: the file is 7GB but the blocks are a few hundreds of bytes, and each process has many blocks to load. > > Instead, I would like to have process rank 0 load the entire file, then expose it over RMA. I'm not familiar at all with MPI one-sided operations, since I never used them before, but I guess there should be a simple way to reuse the subarray datatype of my MPI_File_set_view and use it in the context of an MPI_Get. I'm just not sure what the arguments of this MPI_Get would be. My guess is: origin_count would be the number of floats in a single block, origin_datatype would be MPI_FLOAT, target_rank = 0, target_disp = 0, target_count = 1, target_datatype = my subarray datatype. Would that be correct? > > Thanks, > > Matthieu > _______________________________________________ > 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] From file reading to memory sharing
by Dorier, Matthieu 12 Aug '15

12 Aug '15

Hi, I'm gessing the cause of the performance issue is the large number of small requests, because when I read the full 7GB using a single process issuing one single MPI_File_read, it gets much better. Matthieu ________________________________________ From: Wei-keng Liao [wkliao(a)eecs.northwestern.edu] Sent: Wednesday, August 12, 2015 11:56 AM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] From file reading to memory sharing Hi, Matthieu If you have "a series of subdomains (blocks) to load from the file", one way to get a better I/O performance is to concatenate the filetypes into a single one and then use only one MPI_File_set_view and one MPI_File_read_all to read the data. FYI. This request aggregation strategy is also used in PnetCDF. Wei-keng On Aug 12, 2015, at 11:27 AM, Dorier, Matthieu wrote: > Hi, > > I'm trying to refactor an MPI code using MPI one-sided communications. > > The initial version of the code reads its data from a file containing a 3D array of floats. Each process has a series of subdomains (blocks) to load from the file, so they all open the file and then issue a series of MPI_File_set_view and MPI_File_read. The type passed to MPI_File_set_view is constructed using MPI_Type_create_subarray to match the block that needs to be loaded. > > This code performs very poorly even at small scale: the file is 7GB but the blocks are a few hundreds of bytes, and each process has many blocks to load. > > Instead, I would like to have process rank 0 load the entire file, then expose it over RMA. I'm not familiar at all with MPI one-sided operations, since I never used them before, but I guess there should be a simple way to reuse the subarray datatype of my MPI_File_set_view and use it in the context of an MPI_Get. I'm just not sure what the arguments of this MPI_Get would be. My guess is: origin_count would be the number of floats in a single block, origin_datatype would be MPI_FLOAT, target_rank = 0, target_disp = 0, target_count = 1, target_datatype = my subarray datatype. Would that be correct? > > Thanks, > > Matthieu > _______________________________________________ > 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