[Mpi3-rma] MPI 3 RMA Examples needed

[Jeff Hammond]

Keith,

Pavan and I are trying to separate implementation versus semantic
shortcomings by comparing ARMCI and MVAPICH over IB, and I will try to
also include OFED in an apples-to-apples-to-apples comparison of the
simplest operations.  Both ARMCI and MVAPICH are heavily tuned for IB
and so I expect the implementation quality to be fairly similar;
hence, performance differences are probably due to semantics.

We are also working going to see how close we can get to ARMCI with
MPI-2 RMA in an attempt to elucidate the semantic limitations of the
MPI standard.  Obviously, ARMCI is not the end-all-be-all in one-sided
APIs, but I cannot get GASNet to function and OpenSHMEM is vaporware
(i.e. I cannot download it nor is it available on any machine I have
access to) so I choose to focus exclusively on ARMCI.

Jeff

On Sun, Jan 31, 2010 at 5:47 PM, William Gropp <wgropp at illinois.edu> wrote:
> I agree that performance is an important issue, and we will need to discuss
> it.  However, all too many of the current implementations are unnecessarily
> poor in performance, so to first order, I believe we should concentrate on
> what our users need (and believe can be implemented efficiently on some
> platform) rather than the experience people have had with slow and
> unoptimized implementations.
>
> Bill
>
> On Jan 31, 2010, at 5:34 PM, Underwood, Keith D wrote:
>
>> This is an excellent framing of one of the things that will help the RMA
>> group move forward; however, I do believe we need to get performance into
>> the process.  What I do not know is how we separate performance of the
>> interface from performance of an implementation.  Just because you are able
>> to implement something without unbearably awkward code doesn't mean that
>> code will perform.  How do we account for what is a semantic problem (it
>> isn't POSSIBLE to implement this piece of code and make it go fast) and what
>> is an implementation problem (nobody has bothered to make this piece of code
>> fast)?  That input is just as important as what is syntactically awkward.
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
>>> bounces at lists.mpi-forum.org] On Behalf Of William Gropp
>>> Sent: Sunday, January 31, 2010 7:17 AM
>>> To: MPI 3.0 Remote Memory Access working group
>>> Subject: [Mpi3-rma] MPI 3 RMA Examples needed
>>>
>>> Dear MPI RMA Group,
>>>
>>> We have several partial MPI RMA proposals.  To move forward, we need
>>> to have a better understanding of the real needs by users, and we will
>>> probably need to make some tough decisions about what we will support
>>> and what we won't (as Marc has noted, some fairly obvious shared
>>> memory operations are very tough in OpenMP, so its clear that being
>>> universal isn't requred).
>>>
>>> What we'd like by this *Friday* are some specific examples of
>>> operations that are hard to achieve in MPI RMA *and* that have a clear
>>> application need.  What we *don't* want is simply "we should have a
>>> better  Put", "we need active messages", or "the implementations I've
>>> used are
>>> too slow".  What we do want is something like the following:
>>>
>>> We've implemented a halo exchange with MPI-RMA, and the construction
>>> of the Memory windows is awkward and limiting, particularly if the
>>> domains are created dynamically, making it hard to create the memory
>>> windows collectively.  We need either a method that lets us export a
>>> local window or a way to allow all processes to refer to one single
>>> window (something like the MPI_WIN_WORLD proposal).  Example code can
>>> be found at <url here>  (or post on wiki).
>>>
>>> or
>>>
>>> We need a fetch and increment (or something similar) to implement a
>>> remote lock that will allow us to make a complex series of remote
>>> updates (and accesses) atomically that are needed for <specific
>>> application description here>.  As shown in Using MPI-2, while a fetch
>>> and increment is possible in MPI-RMA, it is extremely complex and
>>> awkward.
>>>
>>> We'll take these examples and compare them to the current proposals
>>> and the original MPI RMA in order to evaluate where we are.
>>>
>>> Again, please send us your concrete requirements by Friday, Feb 5th.
>>> Thanks!
>>>
>>> Bill and Rajeev
>>>
>>> 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
>
>
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>



-- 
Jeff Hammond
Argonne Leadership Computing Facility
jhammond at mcs.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond