<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Do you really think it is just a couple of ifs?  If this is
not MPI_COMM_WORLD… if this is a derived datatype but not contiguous
locally… if this is a derived datatype but not contiguous remotely…
if these are not the same datatypes… if this is not heterogeneous… <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You also get into the trade-offs (that we obviously have to make
even with two routines as well)… so, should contiguous derived datatypes be
fast or slow?  Well, obviously the NIC based agent can handle them if you
do the math in the MPI library, but that math takes instructions.   One
of the things that was put on the table in Chicago was “should we have
specialized functions for each native datatype?”  <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ultimately, it is all about what your performance targets are in
terms of latency and issue rate.  On one end of the spectrum, you have
MPI_Isend().  On the other you have the speed of a native processor
store.  Which end of the spectrum do we want to be on?  If we want
broader penetration for RMA, we need to move toward the latter.  So, yeah,
“a handful of ifs” may be an issue… Particularly on any
architecture where a given thread isn’t all that speedy…<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Keith<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
mpi3-rma-bounces@lists.mpi-forum.org
[mailto:mpi3-rma-bounces@lists.mpi-forum.org] <b>On Behalf Of </b>Richard
Treumann<br>
<b>Sent:</b> Wednesday, September 16, 2009 3:05 PM<br>
<b>To:</b> MPI 3.0 Remote Memory Access working group<br>
<b>Subject:</b> Re: [Mpi3-rma] non-contiguous support in RMA & one-sided
pack/unpack (?)<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p> </o:p></p>

<p style='margin-bottom:12.0pt'>Hi Jeff<br>
<br>
I do not understand the need for two distinct origin side operations if you
will assume the agency infrastructure must always be standing by ready to be
activated. <br>
<br>
The MPI implementation will be able to determine at the origin side if the
parameters passed into a complex RMA fit the capabilities of its NIC. It can
decide whether to use the intrinsic NIC mode or the software agent mode. If it has
a NIC that does integer accumulate but not floating point accumulate, the
implementation can pick between NIC mode and agent mode. When a new NIC that
does floating point accumulate comes along, the implementation can exploit it
with no need for application rewrite.<br>
<br>
On the other hand, the RAW RMA can be used by by applications that want to
exploit NIC capabilities that are widely available today and do not want to
drag in overheads for an agent waiting on the sidelines. An agent that they may
know will never be needed. If someday in the future the typical NIC has certain
additional capabilities we can add a richer RAW operation to the MPI standard.<br>
<br>
Can you explain to me what you expect to have always available as a software
agent that will be there at no significant cost in memory or harm to
performance of non-RMA operations?<br>
<br>
Are you thinking we need two distinct routines just to avoid a couple
"if" tests to decide inside libmpi whether to use NIC based or agent
based RMA?<br>
<br>
Dick <br>
<br>
Dick Treumann - MPI Team <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<img width=16 height=16 id="_x0000_i1025"
src="cid:image001.gif@01CA36E1.7F111D50"
alt="Inactive hide details for Jeff Hammond ---09/16/2009 04:37:33 PM---I was having the same thoughts during my hideous commute tod"><span
style='color:#424282'>Jeff Hammond ---09/16/2009 04:37:33 PM---I was having the
same thoughts during my hideous commute today. Clearly, future systems may have
ver</span><o:p></o:p></p>

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 width="100%"
 style='width:100.0%'>
 <tr>
  <td width="1%" valign=top style='width:1.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=96 height=1 id="_x0000_i1026"
  src="cid:image003.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt;color:#5F5F5F'>From:</span><o:p></o:p></p>
  </td>
  <td width="100%" valign=top style='width:100.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=1 height=1 id="_x0000_i1027"
  src="cid:image004.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt'>Jeff Hammond <jeff.science@gmail.com></span><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width="1%" valign=top style='width:1.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=96 height=1 id="_x0000_i1028"
  src="cid:image003.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt;color:#5F5F5F'>To:</span><o:p></o:p></p>
  </td>
  <td width="100%" valign=top style='width:100.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=1 height=1 id="_x0000_i1029"
  src="cid:image004.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt'>"MPI 3.0 Remote Memory Access working
  group" <mpi3-rma@lists.mpi-forum.org></span><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width="1%" valign=top style='width:1.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=96 height=1 id="_x0000_i1030"
  src="cid:image003.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt;color:#5F5F5F'>Date:</span><o:p></o:p></p>
  </td>
  <td width="100%" valign=top style='width:100.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=1 height=1 id="_x0000_i1031"
  src="cid:image004.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt'>09/16/2009 04:37 PM</span><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width="1%" valign=top style='width:1.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=96 height=1 id="_x0000_i1032"
  src="cid:image003.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt;color:#5F5F5F'>Subject:</span><o:p></o:p></p>
  </td>
  <td width="100%" valign=top style='width:100.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=1 height=1 id="_x0000_i1033"
  src="cid:image004.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt'>Re: [Mpi3-rma] non-contiguous support in RMA
  & one-sided pack/unpack (?)</span><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width="1%" valign=top style='width:1.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=96 height=1 id="_x0000_i1034"
  src="cid:image003.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt;color:#5F5F5F'>Sent by:</span><o:p></o:p></p>
  </td>
  <td width="100%" valign=top style='width:100.0%;padding:0in 0in 0in 0in'>
  <p class=MsoNormal><img width=1 height=1 id="_x0000_i1035"
  src="cid:image004.png@01CA36E1.7F111D50"><br>
  <span style='font-size:10.0pt'>mpi3-rma-bounces@lists.mpi-forum.org</span><o:p></o:p></p>
  </td>
 </tr>
</table>

<div class=MsoNormal>

<hr size=2 width="100%" noshade style='color:#8091A5' align=left>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<tt><span style='font-size:10.0pt'><snip></span></tt><br>
<span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt>I'm not sure I understand all this talk about assertions upon</tt><br>
<tt>initialization, since I was hoping that Raw_xfer and general-purpose</tt><br>
<tt>xfer (Gen_xfer) would both always be available but that the former</tt><br>
<tt>would be much faster in certain contexts, since implementing the Raw</tt><br>
<tt>version close to hardware doesn't require much work and would not</tt><br>
<tt>interfere with how Gen_xfer operates.  Am I missing something?</tt><br>
<br>
<tt><snip></tt><br>
<br>
</span><o:p></o:p></p>

</div>

</div>

</body>

</html>