[mpiwg-hybridpm] Hybrid telecon fiasco

[Jim Dinan]

Jeff,

This debate is entirely academic, made possible by the totally
(intentionally) evasive definition of MPI processes in the spec.  The
language used in the proposal, and the language we have been using all
along to describe endpoints is the right language to use.  I'm not
suggesting that we change anything.

Coming back to navel gazing..  We agree that a rank is an important
component of an MPI process, and that endpoints have ranks.  We also agreed
that the execution resource behind an MPI process (OS process, thread,
etc..) is outside of the scope of MPI.  Apart from this, the most
significant remaining difference I see is membership in MPI_COMM_WORLD.
 Endpoints are not in WORLD.  But then again, spawned processes are in a
different WORLD.  I don't see anything in the spec that requires all MPI
processes to be in present MPI_COMM_WORLD.  MPI_COMM_WORLD is defined to
contain all processes that were accessible after MPI_Init was called.

Sure, I might be taking a little bit of a leap here.  In the proposal we
are saying "everywhere that you see 'process' in the spec, replace it with
'process or endpoint'".

 ~Jim.


On Tue, Apr 8, 2014 at 1:59 PM, Jeff Squyres (jsquyres)
<jsquyres at cisco.com>wrote:

> On Apr 8, 2014, at 1:51 PM, Jim Dinan <james.dinan at gmail.com> wrote:
>
> > Well..  I think this could tomato tomato.  And it's mixed up with OS
> notions of heavyweight and lightweight processes/threads (which are outside
> of the MPI spec., but define a big chunk of how MPI works in practice).
>  From the perspective of the MPI standard, processes created by
> MPI_Comm_create_endpoints
>
> ...but this is exactly my point.  You're not creating any (MPI) processes
> with MPI_Comm_create_endpoints.  You're (potentially) creating multiple new
> endpoints within individual MPI processes.  How those map to underlying OS
> processes is irrelevant -- in the language of MPI, you are *not* creating
> any processes.
>
> Yes, I realize I'm harping on you -- but if the people who are pitching
> this to the MPI Forum can't get the terminology correct, there is no
> possible way that end users will have a hope of understanding it.
>
> > and processes created by mpiexec should all have MPI process semantics.
>
> No argument; MPI processes and endpoints within an MPI process should have
> quite similar semantics.
>
> > This gets tricky when we map these MPI processes to OS processes and
> threads, because we typically have some assumptions and restrictions there,
> but those OS constructs are technically outside of the MPI spec.
>
> Correct: these issues are outside the scope of the MPI spec.
>
> All I'm asking for is: when you're discussing this proposal, use the
> proper terminology and language so that there is a minimum of confusion
> here.
>
> > We could have called the MPI_Comm_create_endpoints
> MPI_Comm_create_processes, but that might give everyone headaches.
>
> And it would have been incorrect, because you're not creating MPI
> processes.  That's what MPI_Comm_spawn[_multiple] is for.
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> mpiwg-hybridpm mailing list
> mpiwg-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20140409/3cc6733c/attachment-0001.html>