[mpiwg-hybridpm] Hybrid telecon fiasco
Jeff Squyres (jsquyres)
jsquyres at cisco.com
Tue Apr 8 12:59:06 CDT 2014
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/
More information about the mpiwg-hybridpm
mailing list