[Mpi3-rma] Use cases for RMA

[William Gropp]

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