<div dir="ltr">Jeff,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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'".</div>
<div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 1:59 PM, Jeff Squyres (jsquyres) <span dir="ltr"><<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Apr 8, 2014, at 1:51 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>> wrote:<br>

<br>
> 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<br>

<br>
</div>...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.<br>

<br>
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.<br>
<div class=""><br>
> and processes created by mpiexec should all have MPI process semantics.<br>
<br>
</div>No argument; MPI processes and endpoints within an MPI process should have quite similar semantics.<br>
<div class=""><br>
> 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.<br>
<br>
</div>Correct: these issues are outside the scope of the MPI spec.<br>
<br>
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.<br>
<div class=""><br>
> We could have called the MPI_Comm_create_endpoints MPI_Comm_create_processes, but that might give everyone headaches.<br>
<br>
</div>And it would have been incorrect, because you're not creating MPI processes.  That's what MPI_Comm_spawn[_multiple] is for.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
For corporate legal information go to: <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
<br>
_______________________________________________<br>
mpiwg-hybridpm mailing list<br>
<a href="mailto:mpiwg-hybridpm@lists.mpi-forum.org">mpiwg-hybridpm@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm</a><br>
</div></div></blockquote></div><br></div>