November 2015 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] MPI_Comm_split_type extensions
by Jeff Hammond 19 Nov '15

19 Nov '15

On Thu, Nov 19, 2015 at 1:14 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > > > On 11/19/2015 03:01 PM, Jeff Hammond wrote: > >> That is so cool! Do you have psychic powers or did you actually go from >> email to finished code in 65 minutes? >> > > Pavan maybe has the psychic powers? he asked me work on this a couple > months ago. > > That makes sense. Pavan did a Vulcan mind meld on me before I left Argonne :-) > but the two implementations have made interesting design choice: OpenMPI > went with the "add a lot of flags" approach. Pavan suggested we take an > approach that introduces only one new flag (MPIX_COMM_SPLIT_NEIGHBORHOOD) > but then uses an info argument to indicate *how* that neighborhood split > should occur. > > I strongly favor the info approach, since it is much easier to toggle features on and off as appropriate without thrashing the header. If MPICH were to support all the HWLOC options like OpenMPI, having it inside of an info key would be future-proof w.r.t. HWLOC feature changes, unlike an explicit list of types. It also makes it trivial to match the exact syntax of HWLOC commands since info keys are composed of strings. > As far as an implementation is concerned, both approaches are equivalent. > > Indeed. > As an end-user, Jeff, do you have an opinion (hah! oh, I kill me... I > thought I could type that with a straight face, I really did...) on which > approach you prefer? > > I have no opinions, just facts that others have yet to accept as truth ;-) Jeff > ==rob > > Jeff >> >> On Thu, Nov 19, 2015 at 12:39 PM, Rob Latham <robl(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> >> >> On 11/19/2015 01:34 PM, Jeff Hammond wrote: >> >> https://github.com/open-mpi/ompi/pull/320 implements features >> related to >> what was proposed in >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 and >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. >> >> It would be nice if MPICH supported such things as well. Since >> MPICH >> also uses HWLOC, I imagine it is not too difficult. >> >> I will file a ticket about this in the absence of objections. >> >> >> >> BLAMMO! >> >> >> http://git.mpich.org/mpich-dev.git/shortlog/refs/heads/comsplit_commonfs >> >> ==rob >> >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] MPI_Comm_split_type extensions
by Rob Latham 19 Nov '15

19 Nov '15

On 11/19/2015 03:01 PM, Jeff Hammond wrote: > That is so cool! Do you have psychic powers or did you actually go from > email to finished code in 65 minutes? Pavan maybe has the psychic powers? he asked me work on this a couple months ago. but the two implementations have made interesting design choice: OpenMPI went with the "add a lot of flags" approach. Pavan suggested we take an approach that introduces only one new flag (MPIX_COMM_SPLIT_NEIGHBORHOOD) but then uses an info argument to indicate *how* that neighborhood split should occur. As far as an implementation is concerned, both approaches are equivalent. As an end-user, Jeff, do you have an opinion (hah! oh, I kill me... I thought I could type that with a straight face, I really did...) on which approach you prefer? ==rob > Jeff > > On Thu, Nov 19, 2015 at 12:39 PM, Rob Latham <robl(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > > On 11/19/2015 01:34 PM, Jeff Hammond wrote: > > https://github.com/open-mpi/ompi/pull/320 implements features > related to > what was proposed in > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 and > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. > > It would be nice if MPICH supported such things as well. Since > MPICH > also uses HWLOC, I imagine it is not too difficult. > > I will file a ticket about this in the absence of objections. > > > > BLAMMO! > > http://git.mpich.org/mpich-dev.git/shortlog/refs/heads/comsplit_commonfs > > ==rob > > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] MPI_Comm_split_type extensions
by Jeff Hammond 19 Nov '15

19 Nov '15

That is so cool! Do you have psychic powers or did you actually go from email to finished code in 65 minutes? Jeff On Thu, Nov 19, 2015 at 12:39 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > > > On 11/19/2015 01:34 PM, Jeff Hammond wrote: > >> https://github.com/open-mpi/ompi/pull/320 implements features related to >> what was proposed in >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 and >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. >> >> It would be nice if MPICH supported such things as well. Since MPICH >> also uses HWLOC, I imagine it is not too difficult. >> >> I will file a ticket about this in the absence of objections. >> > > > BLAMMO! > > http://git.mpich.org/mpich-dev.git/shortlog/refs/heads/comsplit_commonfs > > ==rob > > >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] MPI_Comm_split_type extensions
by Rob Latham 19 Nov '15

19 Nov '15

On 11/19/2015 01:34 PM, Jeff Hammond wrote: > https://github.com/open-mpi/ompi/pull/320 implements features related to > what was proposed in > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 and > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. > > It would be nice if MPICH supported such things as well. Since MPICH > also uses HWLOC, I imagine it is not too difficult. > > I will file a ticket about this in the absence of objections. BLAMMO! http://git.mpich.org/mpich-dev.git/shortlog/refs/heads/comsplit_commonfs ==rob > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

MPI_Comm_split_type extensions
by Jeff Hammond 19 Nov '15

19 Nov '15

https://github.com/open-mpi/ompi/pull/320 implements features related to what was proposed in https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/297 and https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/372. It would be nice if MPICH supported such things as well. Since MPICH also uses HWLOC, I imagine it is not too difficult. I will file a ticket about this in the absence of objections. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] HYDRA_TOPO_DEBUG=1 needs a line break
by Kenneth Raffenetti 18 Nov '15

18 Nov '15

Just pushed a commit to master that should support many processing elements. Thanks for the report. Ken On 11/18/2015 10:24 AM, Kenneth Raffenetti wrote: > The newline is added after all the hwthreads are added to the string - > line 469. You might be overrunning the max string length, as that is not > well handled. Can you try doubling DBG_STR_LENGTH at the top of the file? > > Ken > > On 11/18/2015 09:09 AM, Jeff Hammond wrote: >> I followed the example on >> https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Exam… >> >> but got a huge mess rather than the output shown on the Wiki. >> >> Is the lack of line break here intentional? I think it would be more >> useful if it did. >> >> jhammond@nid00218:~/> HYDRA_TOPO_DEBUG=1 mpiexec -rmk slurm -n 8 >> -bind-to core true >> >> process 0 binding: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 2 >> binding: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 3 binding: 0 0 0 1 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 5 binding: 0 0 0 0 0 1 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0process 6 binding: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0process 1 binding: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 4 >> binding: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 7 binding: 0 0 0 0 >> 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0jhammond@nid00218:~/> >> >> The offending line appears to be 463 in >> src/pm/hydra/tools/topo/hwloc/topo_hwloc.c, but I don't know if the "\n" >> goes there or in the definition of HYDU_snprintf. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] HYDRA_TOPO_DEBUG=1 needs a line break
by Kenneth Raffenetti 18 Nov '15

18 Nov '15

The newline is added after all the hwthreads are added to the string - line 469. You might be overrunning the max string length, as that is not well handled. Can you try doubling DBG_STR_LENGTH at the top of the file? Ken On 11/18/2015 09:09 AM, Jeff Hammond wrote: > I followed the example on > https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Exam… > but got a huge mess rather than the output shown on the Wiki. > > Is the lack of line break here intentional? I think it would be more > useful if it did. > > jhammond@nid00218:~/> HYDRA_TOPO_DEBUG=1 mpiexec -rmk slurm -n 8 > -bind-to core true > > process 0 binding: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 2 > binding: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 3 binding: 0 0 0 1 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 5 binding: 0 0 0 0 0 1 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0process 6 binding: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0process 1 binding: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 4 > binding: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 7 binding: 0 0 0 0 > 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0jhammond@nid00218:~/> > > The offending line appears to be 463 in > src/pm/hydra/tools/topo/hwloc/topo_hwloc.c, but I don't know if the "\n" > goes there or in the definition of HYDU_snprintf. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

HYDRA_TOPO_DEBUG=1 needs a line break
by Jeff Hammond 18 Nov '15

18 Nov '15

I followed the example on https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Exam… but got a huge mess rather than the output shown on the Wiki. Is the lack of line break here intentional? I think it would be more useful if it did. jhammond@nid00218:~/> HYDRA_TOPO_DEBUG=1 mpiexec -rmk slurm -n 8 -bind-to core true process 0 binding: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 2 binding: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 3 binding: 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 5 binding: 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 6 binding: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 1 binding: 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 4 binding: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0process 7 binding: 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0jhammond@nid00218:~/> The offending line appears to be 463 in src/pm/hydra/tools/topo/hwloc/topo_hwloc.c, but I don't know if the "\n" goes there or in the definition of HYDU_snprintf. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

testsuite broken for out-of-place builds
by Jeff Hammond 11 Nov '15

11 Nov '15

I filed https://trac.mpich.org/projects/mpich/ticket/2313 for this. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

../../coll/alltoall1.c:11:25: fatal error: mpicolltest.h: No such file or directory
by Jeff Hammond 10 Nov '15

10 Nov '15

I tried to build the MPICH test suite with Intel MPI and it fails here: ../../coll/alltoall1.c:11:25: fatal error: mpicolltest.h: No such file or directory I got here by doing "make dist" in the test/mpi directory of the 3.2rc2 build and then unpacking the tarball mpich-testsuite-3.2rc2.tgz in a separate directory. Since I can find this file in the test tree, I think it is just missing from the "make dist" export list. [jrhammo@bowman-rps build-impi]$ find ~/MPICH/git/ -name mpicolltest.h /storage/home_intel/jrhammo/MPICH/git/test/mpi/include/mpicolltest.h Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0