[Mpi3-rma] Use cases for RMA

[Bronis R. de Supinski]

Tom:

My recollection is that you had some difficulty trying
to use MPI for the distributed table with caching
implementation besides performance. Were you looking
at MPI one sided communication? If so, what was
the issue again?

Bronis



On Wed, 3 Mar 2010, William Gropp wrote:

> It sounds like this doesn't require anything more than what's already
> been requested by Jeff.  That is, MPI-2 RMA is fine as long as the
> implementation is efficient (a quality of implementation issue, best
> addressed with benchmarks at procurement, rather than changing the
> standard).  Let me know if I'm missing something.
>
> Bill
>
> On Mar 3, 2010, at 9:45 AM, Bronis R. de Supinski wrote:
>
> >
> > Bill:
> >
> > One use case that I am familiar with at LLNL is to
> > distribute large read-only (write-once) tables. We
> > have libraries with this access pattern; the current
> > method is to replicate the tables in all MPI processes.
> > We have done a prototype implementation using GAs to
> > distribute the table. We also need support for caching
> > values locally. I think a good RMA implementation
> > would allow us to build a generic implementation of
> > the distribute and cache functionality...
> >
> > Bronis
> >
> >
> > On Wed, 3 Mar 2010, William Gropp wrote:
> >
> >> I went through the mail that was sent out in response to our request
> >> for use cases, and I must say it was underwhelming.  I've included a
> >> short summary below; based on this, we aren't looking at the correct
> >> needs.  I don't think that these are representative of *all* of the
> >> needs of RMA, but without good use cases, I don't see how we can
> >> justify any but the most limited extensions/changes to the current
> >> design.  Please (a) let me know if I overlooked something and (b)
> >> send
> >> me (and the list) additional use cases.  For example, we haven't
> >> included any of the issues needed to implement PGAS languages, nor
> >> have we addressed the existing SHMEM codes.  Do we simply say that a
> >> high-quality implementation will permit interoperation with whatever
> >> OpenSHMEM is?  And what do we do about the RMI issue that one of the
> >> two use cases that we have raises?
> >>
> >> Basically, I received two detailed notes for the area of Quantum
> >> Chemistry.  In brief:
> >>
> >> MPI-2 RMA is already adequate for most parts, as long as the
> >> implementation makes progress (as it is required to) on passive
> >> updates.  Requires get or accumulate; rarely requires put.
> >> Dynamic load balancing (a related but separate issue) needs some sort
> >> of RMW.  (Thanks to Jeff Hammond)
> >>
> >> More complex algorithms and data structures appear to require remote
> >> method invocation (RMI).  Sparse tree updates provide one example.
> >> (Thanks to Robert Harrison)
> >>
> >> 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 at lists.mpi-forum.org
> >> http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >>
> >>
> > _______________________________________________
> > mpi3-rma mailing list
> > mpi3-rma at 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
>
>
>
>
>
>