<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>Are you going to be attending the forum this week? I will try to address some of the alternatives you mention below in the presentation tomorrow.</div><div><br></div><div>Thanks,</div><div>Vinod.<br><br>> Date: Tue, 9 Dec 2008 13:15:59 -0600<br>> From: jeff.science@gmail.com<br>> To: mpi3-rma@lists.mpi-forum.org<br>> Subject: Re: [Mpi3-rma] FW: draft of a proposal for RMA interfaces<br>> <br>> On Tue, Dec 9, 2008 at 7:51 AM, Vinod tipparaju <tipparajuv@hotmail.com> wrote:<br>> <br>>>> inside of GA, I have to manually do everything that ARMCI_Malloc did previously?<br>>><br>>> yes the user has to. Do you think that is a bad idea?<br>> <br>> I think it depends on the user. I see the following possibilities:<br>> <br>> 1. MPI RMA includes functionality for allocating different types of<br>> memory segments (shared, private, etc.) just as ARMCI did, and perhaps<br>> more functionality than that. MPI knows when users are abusing memory<br>> and can address this directly via useful error messages, etc.<br>> <br>> 2. A separate library which makes managing the complexities of on-node<br>> memory in a heterogeneous and/or multicore context is developed<br>> independently of MPI.<br>> <br>> 3. Users roll there own in all cases...<br>> a. ...resulting in properly executing code which runs at top speed<br>> because the user knows what they are doing or their usage is simple<br>> enough that it doesn't matter.<br>> b. ...correctly but with limited performance because a naive<br>> approach is used.<br>> c. ...leading to catastrophic problems because they don't know<br>> what they're doing.<br>> <br>> I know of enough evil hacking among application programmers to greatly<br>> fear (3c). The negative consequences of (3b) depend on the machine.<br>> For example, if one uses basic malloc and all memory is<br>> process-private, then on a big SMP node like Ranger@TACC, the<br>> performance will suffer because the RMA will not completely bypass the<br>> communication protocol, as GA/ARMCI currently does. Even when MPI RMA<br>> shortcuts when it knows it is staying within a node, there still must<br>> be a memcpy between the two segments of private memory that would not<br>> occur if the user uses shmalloc. Of course, some users may want this<br>> for consistency but for others it may kill performance.<br>> <br>> I don't believe I understand all the issues clearly enough to say much<br>> more, but if MPI aims to support heterogeneous platforms, the<br>> complexity of on-node memory hierarchies that paradigm introduces,<br>> along with the complexity of dealing with different types of multicore<br>> CPUs, suggests that MPI users would benefit greatly from an allocator<br>> which encapsulates these various paradigms into a single, portable<br>> framework which is in sync with MPI's RMA protocol.<br>> <br>> I imagine a mix of (2) and (3) is the most likely scenario but (2)<br>> won't fully address the problem unless it focuses directly on being<br>> paired with MPI RMA. As a user, and a stupid and lazy one at that,<br>> (1) is the best I can hope for.<br>> <br>> Thanks,<br>> <br>> Jeff<br>> <br>> -- <br>> Jeff Hammond<br>> The University of Chicago<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></body>
</html>