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 [email protected] http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] 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