<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3603" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=859011516-17112009><FONT face=Arial 
color=#0000ff size=2>No objections - let's go for 2 separate questions, 
e.g.:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=859011516-17112009><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=859011516-17112009><FONT face=Arial 
color=#0000ff size=2><FONT face="Courier New" color=#000000 size=3>"Do you want 
to achieve higher performance by disabling certain MPI-3 features in your 
program?</FONT></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=859011516-17112009><FONT 
face="Courier New">"If so, do you prefer subsetting or 
assertions?"</FONT></SPAN><SPAN class=859011516-17112009><FONT face=Arial 
color=#0000ff size=2></DIV></FONT></SPAN><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi-forum-bounces@lists.mpi-forum.org 
[mailto:mpi-forum-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Richard 
Treumann<BR><B>Sent:</B> Tuesday, November 17, 2009 2:09 PM<BR><B>To:</B> Main 
MPI Forum mailing list<BR><B>Subject:</B> Re: [Mpi-forum] MPI user 
survey<BR></FONT><BR></DIV>
<DIV></DIV>
<P>I have serious doubts about the rationale forf doing a survey but if the 
Forum goes ahead, I would want these questions made distinct. Please do not put 
assertions and subsetting in the same question.<BR><BR>I think subsetting MPI is 
probably not useful. Too messy in so many ways. I would reply NO. <BR><BR>I 
think assertions are relatively clean and simple for both application writer and 
MPI implementor. Assertions address problems that will become serious at scale. 
They do provide a bit of a hurdle for authors of 3-party libraries but not a 
serious one. (explained below). I would reply YES<BR><BR>Dick <BR><BR>footnote 
re 3rd party libraries<BR><BR>If a legacy code version of a third party library 
depends on some guarantee provided by the MPI standard and the application 
author asserts that guarantee is not needed, there could be surprise results 
(perhaps wrong answers, more often error messages saying an assertion is 
violated) from the library. The transition problem is real.<BR><BR>New versions 
of the library can query whether there are assertions it cannot live with and 
give a clean error message. Something like "The use of assertion MPI_NO_CANCEL 
is not allowed when using Fredlib."<BR><BR>If certain assertions prove to be 
valuable because applications that use them either run faster or use less 
memory, the 3rd party library author may be pressured by customers to find a a 
way to make the library live within the assertions. This may be a bit of work 
for the library author but rejecting an MPI feature or a customer request that 
has significant value just because it would mean a bit of work does not deserve 
much sympathy.<BR><BR>If some assertion proves to have little or no value, the 
3rd party library author can tell his customer that and and decline to rewrite 
the library to allow that assertion on a application that uses the 
library.<BR><BR>The middle ground in which the assertion has real payoff but the 
3rd party library cannot reasonably live with it can be a marketing 
inconvenience for the library author but it is ultimately the customer's choice 
whether to remove the assertion or find a way to solve his problem without that 
library.<BR><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 height=16 
alt='Inactive hide details for "Supalov, Alexander" ---11/17/2009 02:10:36 AM---Dear Jeff, Please add, irrespective of the RMA aspec' 
src="cid:859011516@17112009-2827" width=16 border=0><FONT 
color=#424282>"Supalov, Alexander" ---11/17/2009 02:10:36 AM---Dear Jeff, Please 
add, irrespective of the RMA aspect, the following question:</FONT><BR><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
  <TBODY>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>From:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=1 border=0><BR><FONT size=2>"Supalov, Alexander" 
      <alexander.supalov@intel.com></FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>To:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=1 border=0><BR><FONT size=2>Main MPI Forum mailing list 
      <mpi-forum@lists.mpi-forum.org></FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Date:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=1 border=0><BR><FONT size=2>11/17/2009 02:10 AM</FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Subject:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=1 border=0><BR><FONT size=2>Re: [Mpi-forum] MPI user 
  survey</FONT></TD></TR>
  <TR vAlign=top>
    <TD width="1%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=96 border=0><BR><FONT color=#5f5f5f size=2>Sent by:</FONT></TD>
    <TD width="100%"><IMG height=1 alt="" src="cid:859011516@17112009-282E" 
      width=1 border=0><BR><FONT 
      size=2>mpi-forum-bounces@lists.mpi-forum.org</FONT></TD></TR></TBODY></TABLE>
<HR style="COLOR: #8091a5" align=left width="100%" noShade SIZE=2>
<BR><BR><BR><TT>Dear Jeff,<BR><BR>Please add, irrespective of the RMA aspect, 
the following question:<BR><BR>"Do you want to achieve higher performance by 
disabling certain MPI-3 features in your program (thru subsetting, assertions, 
etc.)?"<BR><BR>Best regards.<BR><BR>Alexander<BR><BR>-----Original 
Message-----<BR>From: mpi-forum-bounces@lists.mpi-forum.org [</TT><TT><A 
href="mailto:mpi-forum-bounces@lists.mpi-forum.org">mailto:mpi-forum-bounces@lists.mpi-forum.org</A></TT><TT>] 
On Behalf Of Jeff Squyres<BR>Sent: Monday, November 16, 2009 7:36 PM<BR>To: Main 
MPI Forum mailing list<BR>Subject: Re: [Mpi-forum] MPI user survey<BR><BR>Folks 
--<BR><BR>Tel me exactly what to put on the survey.  :-)<BR><BR><BR>On Nov 
16, 2009, at 10:11 AM, Christian Bell wrote:<BR><BR>><BR>> On Nov 16, 
2009, at 11:55 AM, Jeff Hammond wrote:<BR>><BR>> > Can we completely 
ignore the performance-richness dichotomy and ask<BR>> > the 
following?<BR>> ><BR>> > "Would you benefit if the MPI Forum 
enhances and extends the  <BR>> existing<BR>> > one-sided 
operations?  That is, would you like to replace MPI<BR>> > two-sided 
calls in your code with one-sided ones and/or use MPI<BR>> > instead of 
another one-sided API (e.g. ARMCI)?"<BR>><BR>> Why not be frank and to the 
point:<BR>><BR>> The MPI Forum is currently investigating whether it is 
worthwhile<BR>> supporting two RMA interfaces -- a feature-rich RMA interface 
and/or a<BR>> performance-oriented interface with potentially more 
constraints.<BR>><BR>> a) I only care about performance-oriented 
RMA<BR>> b) I want RMA to implement a rich set of features at the cost of 
some<BR>> performance/portability<BR>> c) I think supporting 2 interfaces 
is a must because...<BR>> [...]<BR>><BR>> I won't elaborate more here 
because my slant against a feature-rich<BR>> RMA will start showing (if it 
hasn't already).<BR>><BR>><BR>> For the RMA folks:<BR>><BR>> 
FWIW, I think a new feature-rich RMA just gives users more ways to<BR>> write 
bad programs and hints at a performance benefit that<BR>> implementations may 
never actually deliver.  An all-encompassing RMA<BR>> interface is a 
noble goal but it doesn't seem compatible with all the<BR>> specialization 
that needs to happen to exploit newer architectures.<BR>> RMA will always be 
a form of specialization so it better come with a<BR>> large carrot for users 
to consider it.  I'd rather have a skinny and<BR>> constrained RMA 
interface that has a fighting chance to deliver what<BR>> it aims to provide. 
 What's wrong with labeling a performance-oriented<BR>> interface with 
"DEPRECATED: BAD IDEA" in 5 years if it will have<BR>> failed?  IMHO, 
it's no worse than banking on a feature-rich RMA<BR>> interface that may (yet 
again) drown in apathy.<BR>><BR>> No disrespect is intended to those 
already working hard to come up<BR>> with a complete feature-rich and 
performance-portable RMA, but I see<BR>> too much pain for very little 
gain.<BR>><BR>>         . . christian<BR>><BR>> 
_______________________________________________<BR>> mpi-forum mailing 
list<BR>> mpi-forum@lists.mpi-forum.org<BR>> </TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</A></TT><TT><BR>><BR><BR><BR>-- 
<BR>Jeff 
Squyres<BR>jsquyres@cisco.com<BR><BR>_______________________________________________<BR>mpi-forum 
mailing list<BR>mpi-forum@lists.mpi-forum.org<BR></TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</A></TT><TT><BR>---------------------------------------------------------------------<BR>Intel 
GmbH<BR>Dornacher Strasse 1<BR>85622 Feldkirchen/Muenchen Germany<BR>Sitz der 
Gesellschaft: Feldkirchen bei Muenchen<BR>Geschaeftsfuehrer: Douglas Lusk, Peter 
Gleissner, Hannes Schwaderer<BR>Registergericht: Muenchen HRB 47456 
Ust.-IdNr.<BR>VAT Registration No.: DE129385895<BR>Citibank Frankfurt (BLZ 502 
109 00) 600119052<BR><BR>This e-mail and any attachments may contain 
confidential material for<BR>the sole use of the intended recipient(s). Any 
review or distribution<BR>by others is strictly prohibited. If you are not the 
intended<BR>recipient, please contact the sender and delete all 
copies.<BR><BR><BR>_______________________________________________<BR>mpi-forum 
mailing list<BR>mpi-forum@lists.mpi-forum.org<BR></TT><TT><A 
href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</A></TT><TT><BR></TT><BR><BR><pre>---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
</pre></BODY></HTML>