Closed minsii closed 4 years ago
Diff from September F2F meeting: 843d8bb..d560514
Summary of changes:
THREAD_SERIALIZED
safety.2.1 SHMEM_QUERY_INTEROPERABILITY
to showcase how the progress support can help program to avoid deadlock.Performance impact when implementation supports progress for MPI:
Nevertheless, I feel that the optimizations of asynchronous progress is irrelevant to this proposal. Thus, I do not discuss them in detail in the proposal.
@jdinan @nspark I just moved the PR to again the main spec. Could you please check if all your comments are addressed?
@manjugv For the performance concern about private context, I do not think adding support for MPI progress (e.g., using a software thread) can degrade the performance of SHMEM operations that use a private context. The additional thread should only touch the "context" used for MPI and does not access the resource isolated for any private context. What do you think?
@jdinan The last push includes all changes. Could you please review again?
The PDF version for official reading at Nov 13, 2019 specification meeting: openshmem-spec-interoperability-20191029.pdf
Would it be helpful for the example to also show how to create an MPI communicator that has the same rank and OpenSHMEM PE numbering? I think the easiest way is something like:
MPI_Comm_split(MPI_COMM_WORLD, 0, shmem_my_pe(), &shmem_comm);
Would it be helpful for the example to also show how to create an MPI communicator that has the same rank and OpenSHMEM PE numbering? I think the easiest way is something like:
MPI_Comm_split(MPI_COMM_WORLD, 0, shmem_my_pe(), &shmem_comm);
Agreed. Then the user program can use shmem_comm
instead of MPI_COMM_WORLD
in the program and safely assume that the rank and PE are equal. I will add the example.
The last push contains two changes:
MPI_Comm_split
.@manjugv @jdinan Can you please review?
Special ballot changes: ec2ca5fe...816b271a
Instead of:
that contains all processes in \VAR{MPI_COMM_WORLD} and uses the same \ac{MPI} rank and \openshmem \ac{PE} numbering.
I think the following might read a little easier:
that contains all processes in \VAR{MPI_COMM_WORLD} and each process has the same \ac{MPI} rank number as its \openshmem \ac{PE} number.
@RaymondMichael Thanks! Fixed.
@jdinan I just noticed that I forget to remove the green color highlights in this PR. Sorry for this mistake. Can I create a different PR to add the fix?
\color{ForestGreen}
\input{content/interoperability}
\color{black}
Good catch -- DocEdit posted in #327
This PR rewrites
Annex D - Interoperability with other Programming Models
. It clarifies MPI Interoperability and defines an OpenSHMEM extended API for querying interoperability features. The interoperability with other communication libraries and languages will be addressed in future work.Related discussion can be found at ticket-243 and pr-1