[mpich-devel] MPI_Comm_split_type extensions

[Jeff Hammond]

On Thu, Nov 19, 2015 at 1:14 PM, Rob Latham <robl at 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 at mcs.anl.gov
>> <mailto:robl at 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 at gmail.com <mailto:jeff.science at gmail.com>
>>         <mailto:jeff.science at gmail.com <mailto:jeff.science at gmail.com>>
>>
>>         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 at gmail.com <mailto:jeff.science at gmail.com>
>> 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 at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20151119/70dc1aa5/attachment-0001.html>