<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Jeff, <div><br></div><div>Please see the RMA wiki page, it has a draft proposal (as a file attachment). It should include datatypes.<br><div><br></div><div>Thanks,</div><div>Vinod.</div><div><br></div><div>--<br><span style="font-size:10pt;font-family:'Verdana','sans-serif'">Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802</span><br><br><br><br>> Date: Tue, 15 Sep 2009 17:19:51 -0500<br>> From: jeff.science@gmail.com<br>> To: mpi3-rma@lists.mpi-forum.org<br>> Subject: [Mpi3-rma] non-contiguous support in RMA & one-sided pack/unpack (?)<br>> <br>> The arguments to MPI_RMA_xfer make no reference to datatype,<br>> suggesting that only contiguous patches of primitive types will be<br>> supported. Do I understand this correctly? I queried old emails and<br>> cannot find an answer to this question if it already exists. I<br>> apologize for my inadequate search skills if I missed it.<br>> <br>> It seems there are a few possibilities for non-contiguous support in RMA:<br>> <br>> 1. RMA is decidedly low-level and makes no attempt to support<br>> non-contiguous data<br>> 2. RMA supports arbitrary datatypes, including derived datatypes for<br>> non-contiguous patches<br>> 3. RMA supports non-contiguous patches via a few simple mechanisms -<br>> strided, etc. - like ARMCI<br>> 4. RMA supports non-contiguous patches implicitly using one-sided<br>> pack/unpack functionality, presumably implemented with active messages<br>> 5. RMA stipulated non-contiguous support but is vague enough to allow<br>> a variety of implementations<br>> <br>> It is not my intent to request any or all of the aforementioned<br>> features, but merely to suggest them as possible ideas to be discussed<br>> and adopted or eliminated based upon their relative merits and the<br>> philosophical preferences of the principles (e.g. Vinod).<br>> <br>> (4) seems rather challenging, but potentially desirable in certain<br>> contexts where a large number of sub-MPI calls impedes performance.<br>> Of course, one-sided unpack may result in very negative behavior if<br>> implemented or used incorrectly and is perhaps too risky to consider.<br>> <br>> One practical motivation for my thinking about this is the<br>> non-blocking performance (rather, lack thereof) of Global Arrays on<br>> BlueGene/P due to the need to explicitly advance the DCMF messenger<br>> for every contiguous segment, which cannot be done asynchronously due<br>> to the lack of thread-spawning capability. I understand there may be<br>> similar issues on the Cray XT5 (message injection limits in CNL?), but<br>> I don't know enough about the technical details to elaborate.<br>> <br>> Best,<br>> <br>> Jeff<br>> <br>> -- <br>> Jeff Hammond<br>> Argonne Leadership Computing Facility<br>> jhammond@mcs.anl.gov / (630) 252-5381<br>> http://www.linkedin.com/in/jeffhammond<br>> http://home.uchicago.edu/~jhammond/<br>> _______________________________________________<br>> mpi3-rma mailing list<br>> mpi3-rma@lists.mpi-forum.org<br>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<br></div></div></body>
</html>