Regarding: "We are still investigating with the input from the user
community to get an idea on if this is necessary or a smaller sub-set
of Reduce Operations are suļ¬cient
to be used as OP TYPE values (e.g. RMA ACC SUM, RMA ACC PROD, RMA ACC
LXOR, etc.)."
What is supported by ARMCI - Put, Get, Acc with multiplicative factor
ala AXPY or min/max-like operations - is sufficient for everything I
can imagine doing with MPI RMA, but perhaps that is because my use of
ARMCI has limited my imagination.
Regarding "target_mem":
It appears that there is a special (read: restricted?) interface for
the remote memory segment but nothing locally? Will it be possible to
implement no-copy one-sided on all platforms if the local access is
done not on memory encapsulated by such a special structure but a
plain pointer ("origin_addr")? The DCMF_Put call
<http://dcmf.anl-external.org/docs/api/dcmf/group__PUT.html>, for
example, requires the use of DCMF_Memregion on both the source and the
receiver, so it would appear that either the local registration is
implicit in the "xfer" call or the operation cannot be no-copy. If
local registration is implicit, and this process is non-trivial, then
the latency on "xfer" will be substantial since registered malloc can
take a while on some platforms. It will probably be easier on
implementers to use a more restrictive form of the "xfer" operation
which uses "target_mem"-like restricted memory regions for both the
local and remote processes. It may also be of practical value when
RMA operations are used in a multi-threaded context since the
programmer could impose restrictions upon the local memory region so
that it was accessible by only one thread (e.g. during Acc RMA)or
accessible by all threads (read-only i.e. Put RMA) and unsafe usage
would throw an error rather.
I am not a computer scientist and apologize for any stupidity
contained in this email.
Best,
Jeff
--
Jeff Hammond
Argonne Leadership Computing Facility
jhammond(a)mcs.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammondhttp://home.uchicago.edu/~jhammond/
There has been stunning silence since this email, so I will go ahead and toss out a thought...
In the draft design goals, I don't see two issues that I see as key. The first is "support for high message rate/low overhead communications to random targets". As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS. The second is "elimination of the access epoch requirement". This one may be, um, more controversial, but I believe it is part and parcel with the first one. That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations. Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set... I will hold out hope that this isn't the case ;-)
Keith
> -----Original Message-----
> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma-
> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp
> Sent: Wednesday, August 05, 2009 12:37 PM
> To: mpi3-rma(a)lists.mpi-forum.org
> Subject: [Mpi3-rma] MPI3 RMA Design Goals
>
> I've added versions of the RMA design goals that we discussed at the
> Forum meeting last week to the wiki page for our group (
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
> ). This is a draft; lets discuss these. Also, feel free to add to
> the discussion, particularly in the background section.
>
> Bill
>
> William Gropp
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
Good idea. I added a slightly edited version to the wiki.
Bill
On Aug 5, 2009, at 2:59 PM, Rajeev Thakur wrote:
> How about also adding some high-level goals, such as the following.
>
> "The existing MPI-2 RMA API appears to not meet the needs of
> application
> programmers and library writers and hence is not widely used. RMA as a
> programming paradigm, however, is still valued and needed. The goal of
> this subgroup is to fix the existing MPI-2 RMA API or develop a new
> API
> that library writers (e.g., PGAS and Global Arrays) and application
> programmers would actually want to use."
>
> Rajeev
>
>
>
>
>> -----Original Message-----
>> From: mpi3-rma-bounces(a)lists.mpi-forum.org
>> [mailto:[email protected]] On Behalf Of
>> William Gropp
>> Sent: Wednesday, August 05, 2009 1:37 PM
>> To: mpi3-rma(a)lists.mpi-forum.org
>> Subject: [Mpi3-rma] MPI3 RMA Design Goals
>>
>> I've added versions of the RMA design goals that we discussed at the
>> Forum meeting last week to the wiki page for our group (
>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
>> ). This is a draft; lets discuss these. Also, feel free
>> to add to
>> the discussion, particularly in the background section.
>>
>> Bill
>>
>> William Gropp
>> Deputy Director for Research
>> Institute for Advanced Computing Applications and Technologies
>> Paul and Cynthia Saylor Professor of Computer Science
>> University of Illinois Urbana-Champaign
>>
>>
>>
>>
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma(a)lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign
How about also adding some high-level goals, such as the following.
"The existing MPI-2 RMA API appears to not meet the needs of application
programmers and library writers and hence is not widely used. RMA as a
programming paradigm, however, is still valued and needed. The goal of
this subgroup is to fix the existing MPI-2 RMA API or develop a new API
that library writers (e.g., PGAS and Global Arrays) and application
programmers would actually want to use."
Rajeev
> -----Original Message-----
> From: mpi3-rma-bounces(a)lists.mpi-forum.org
> [mailto:[email protected]] On Behalf Of
> William Gropp
> Sent: Wednesday, August 05, 2009 1:37 PM
> To: mpi3-rma(a)lists.mpi-forum.org
> Subject: [Mpi3-rma] MPI3 RMA Design Goals
>
> I've added versions of the RMA design goals that we discussed at the
> Forum meeting last week to the wiki page for our group (
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
> ). This is a draft; lets discuss these. Also, feel free
> to add to
> the discussion, particularly in the background section.
>
> Bill
>
> William Gropp
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
I've added versions of the RMA design goals that we discussed at the
Forum meeting last week to the wiki page for our group ( https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage
). This is a draft; lets discuss these. Also, feel free to add to
the discussion, particularly in the background section.
Bill
William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign
