<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:st1="urn:schemas-microsoft-com:office:smarttags" 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 11 (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]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PostalCode"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="Street"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="address"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@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";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p
{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";}
tt
{font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
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><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I think Alexander hit on the answer to
this: how is the user to know what is going to offer an implementation
some advantage? What may look like it could offer a lot of benefit from a
users perspective (ready send) could be considered low priority by the
implementer. Especially in the constrained environments example, every implementer
for a constrained environment could have a different perception of what they
can make fast and small. So, an application that runs fine on a Cell SPE
could blow up the code memory footprint on a Clearspeed. This is
ultimately bad for the user. That is to say nothing of the dynamic memory
footprint, which I am sure an implementer could trim with appropriate
guarantees.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I’m not sure official subsetting is
the right answer or what the right approach for getting that functionality
would be, but I am pretty sure that MPI on a Cell SPE is going to be a subset –
whether it is official or not :-)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Keith<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> mpi-22-bounces@lists.mpi-forum.org
[mailto:mpi-22-bounces@lists.mpi-forum.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Richard Treumann<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, May 09, 2008 3:48 PM<br>
<b><span style='font-weight:bold'>To:</span></b> MPI 2.2<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [Mpi-22] Memory
footprint concern</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Hi Keith <br>
<br>
Say the MPI implementor for the Cell SPE version of MPI did a good job of
organizing his functionality (perhaps by making subsetting decisions that work
for the structure of his implementation). Say there is an MPI application that
only makes calls to the 6 essential MPI routines plus MPI_Allreduce and
MPI_Bcast. When that application is statically bound to the MPI implementation
by a smart linker that follows dependancy chains and only brings in needed
subroutines don't you get the desired result? <br>
<br>
What more do you get in this case from having the MPI standard dictate the
subsets and asking the user to declare what subsets he will need? If you leave
it to the implementor to devise the subsets and change them as some ways of
slicing and dicing libmpi prove more useful than others it may be better than
having the standard lock down the dividing lines based on today's best guess. <br>
<br>
It does occur to me that the linker cannot tell if the MPI_Bcast call will need
the code that supports MPI_Bcast on intercommunicators even though that is
rarely used. That means if the application has an MPI_Bcast call, both
(probably needed) intracomm- and (probably not needed) intercomm support enter
the footprint. <br>
<br>
Dick <br>
<br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
<st1:address w:st="on"><st1:Street w:st="on">Dept</st1:Street> 0lva</st1:address>
/ MS P963 -- <st1:Street w:st="on"><st1:address w:st="on">2455 South Road</st1:address></st1:Street>
-- <st1:place w:st="on"><st1:City w:st="on">Poughkeepsie</st1:City>, <st1:State
w:st="on">NY</st1:State> <st1:PostalCode w:st="on">12601</st1:PostalCode></st1:place><br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
</span></font><tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>mpi-22-bounces@lists.mpi-forum.org
wrote on 05/09/2008 02:34:33 PM:</span></font></tt><font size=2
face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<tt><font face="Courier New">> Imagine, for example, MPI running on a Cell
SPE. Yes, it sounds </font></tt><br>
<tt><font face="Courier New">> crazy, but people are working on it. If
you look at the state in </font></tt><br>
<tt><font face="Courier New">> MPI-2 today, and assume it will grow
proportionally with complexity,</font></tt><br>
<tt><font face="Courier New">> MPI-3 could be really nasty in that context.
So, while I agree that</font></tt><br>
<tt><font face="Courier New">> an arbitrarily large number of permutations
is a terrible idea for </font></tt><br>
<tt><font face="Courier New">> everyone involved (implementers
wouldn’t leverage all of the </font></tt><br>
<tt><font face="Courier New">> options, ISVs wouldn’t test them,
people who write third party </font></tt><br>
<tt><font face="Courier New">> libraries would have a huge headache dealing
with the arbitrary </font></tt><br>
<tt><font face="Courier New">> combination of features chosen by the
application), it seems like it</font></tt><br>
<tt><font face="Courier New">> would be prudent to try to figure out how to
provide some mechanisms</font></tt><br>
<tt><font face="Courier New">> in this direction. I don’t know if this
overlaps with your idea </font></tt><br>
<tt><font face="Courier New">> about assertions or not, but they do seem to
be related.</font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> </span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> Keith</span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> </span></font></tt><o:p></o:p></p>
</div>
</div>
</body>
</html>