<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<div>Dick, you make some excellent points. I am going to give up trying to convey my opinion on the survey to the forum.</div><div><br></div><div>If you have some time, I would like to discuss with you in detail about your opinion and get your feedback on the RMA interfaces. It is hard to follow all the discussions in the forum emails and get anything out of them as far as useful feedback so I wanted to request you for your input in a one-on-one discussion. </div><div><br></div><div>Jeff Hammond said he would communicate with you about his findings on two interfaces vs one.</div><div><br></div><div>Did you get a chance to look at the draft proposal? Have you seen the presentation on the Binding interfaces and two-vs-one interface? Do you think two different interfaces are necessary? What is your opinion on the binding interfaces (do they make sense, do you think they will be beneficial)? </div><div><br></div><div>Thanks,</div><div>Vinod.</div><div><br></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><hr id="stopSpelling">To: mpi-forum@lists.mpi-forum.org<br>From: treumann@us.ibm.com<br>Date: Mon, 16 Nov 2009 13:53:31 -0500<br>Subject: Re: [Mpi-forum] MPI user survey<br><br>
I know it is tempting to look for public input but for issues as complex as the ones the MPI Forum is trying to resolve asking a question that generates a useful answer is so hard it may not really be very useful to try.<br>
<br>
When there are 10 people in the world who have dug deeply enough into an issue to really understand it, they are unlikely to benefit from the opinions of hundreds with superficial understanding.<br>
<br>
Of course, anyone who has an agenda in politics knows the tactic of taking a poll with a simplistic question that gets 85% favorable response and then saying it demonstrates support for the 1000 page bill he is proposing. If someone else polls with a slightly different description of the same 1000 page bill he may show there is 85% opposition.<br>
<br>
I put some comments below too.<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>
<tt>mpi-forum-bounces@lists.mpi-forum.org wrote on 11/16/2009 10:10:54 AM:<br>
<br>
> [image removed] </tt><br>
<tt>> <br>
> Re: [Mpi-forum] MPI user survey</tt><br>
<tt>> <br>
> Jeff Squyres </tt><br>
<tt>> <br>
> to:</tt><br>
<tt>> <br>
> Main MPI Forum mailing list</tt><br>
<tt>> <br>
> 11/16/2009 10:13 AM</tt><br>
<tt>> <br>
> Sent by:</tt><br>
<tt>> <br>
> mpi-forum-bounces@lists.mpi-forum.org</tt><br>
<tt>> <br>
> Please respond to Main MPI Forum mailing list</tt><br>
<tt>> <br>
> On Nov 16, 2009, at 5:15 AM, Richard Treumann wrote:<br>
> <br>
> > I did not see this until Monday morning but here are some late <br>
> > comments.<br>
> ><br>
> <br>
> Thanks for all the time and effort, Dick! Making a good/useful survey <br>
> is a darn hard process... (I think we've easily consumed at least <br>
> 20-30 person-hours on this already!)<br>
> <br>
> > How do you plan to give a reasonable range of stake holders a chance <br>
> > to understand the questions and provide their answers?<br>
> ><br>
> <br>
> Are you saying that the questions are difficult to understand? I'm <br>
> not sure what your indirect assertion is here...?</tt><br>
<br>
<tt>The HPC customer (and indirectly, an MPI user) is someone who has </tt><br>
<tt>science to do that cannot be done on small systems. Many of the </tt><br>
<tt>questions seem directed to people who write MPI applications. </tt><br>
<br>
<tt>Perhaps putting questions that might apply to HPC users that don't</tt><br>
<tt>write MPI code first and telling them their answers to the first few </tt><br>
<tt>questions are important even if they do not feel they can respond to </tt><br>
<tt>the MPI programmer questions.</tt><br>
<br>
<tt>This question should not follow lots of questions directed to people </tt><br>
<tt>who write MPI apps. It is a critical question for the kind of "user"</tt><br>
<tt>we tend to forget - people/businesses with problems to run</tt><br>
<br>
<b><font face="Verdana">I expect to be able to upgrade to an MPI-3 implementation and still be able </font></b><br>
<b><font face="Verdana">to run my legacy MPI applications *without recompiling*.</font></b><font size="4"> </font><br>
<br>
<font size="4">Questions about the importance of providing a way to use hundreds of thousands of PEs</font><br>
<font size="4">effectively should be in the HPC user section. Questions about what must be done to the </font><br>
<font size="4">MPI standard in support should be directed to MPI code writers.</font><br>
<tt><br>
> <br>
> > ISVs or "closed source product" providers should be queried. They <br>
> > need to deal with their customers who are delivered an MPI 3<br>
> ><br>
> > Buyers of closed source products are stake holders in this issue. If <br>
> > I am using an MPI based product in my business, how do I feel about <br>
> > needing to buy and validate new software when my MPI provider says <br>
> > his new release breaks my production software?<br>
> ><br>
> > Providers of MPI implementations may want to think about the <br>
> > implications of an influential customer saying "Ship MPI 3 if you <br>
> > want to but to keep my business you must also keep shipping and <br>
> > supporting the MPI 2.2 that my apps still use.<br>
> ><br>
> <br>
> Distilling down your text, are you asking how we plan to get as many <br>
> respondents from as many different categories as possible?<br>
> <br>
> If so, the plan is loosely defined as follows: advertise it heavily at <br>
> the BOF this week. Further, advertise it as heavily as possible via <br>
> public venues (e.g., open source mailing lists, etc.). Finally, <br>
> advertise it as heavily as possible with individual contacts (e.g., <br>
> MPI implementor organizations who have contacts with ISVs and other <br>
> closed source application developers, customers, etc.).<br>
> <br>
> > Typical number of tasks in an MPI job may not be very informative. <br>
> > The question should (also?) try to get at:<br>
> ><br>
> > 1) What is the largest job you tend run today and consider important <br>
> > (vs something run but not critical to the mission / business)<br>
> > 2) What number of tasks do you anticipate wanting to run (and <br>
> > consider important) within the next few years?<br>
> ><br>
> > I do not see anything clearly addressing the question of "How many <br>
> > cores. CPUs. PEs (whatever term) would you hope/expect to be able to <br>
> > apply to your largest problems?"<br>
> ><br>
> <br>
> The rationale for these questions was mainly demographic data <br>
> gathering that can be used to help qualify/quantify further answers <br>
> (e.g., "among respondents who said they run apps at 2049+ MPI procs, <br>
> only 3% use one-sided communications").</tt><br>
<br>
<tt>OK - it seems to me some of the biggest issues for the future of MPI </tt><br>
<tt>are tied up with scaling and with what people hope for or expect in </tt><br>
<tt>the future. I strongly suspect that more than say 32K ranks will be </tt><br>
<tt>very hard to do well but using > 32K PEs is coming fast.</tt><br>
<br>
<tt>Maybe a section on "What you do now" and a section on "what you hope </tt><br>
<tt>to do or need to do over the next 5 years" would help.</tt><br>
<tt><br>
> <br>
> Do you have suggestions for better wording of those questions, or <br>
> replacement questions?<br>
> <br>
> > Much of the hybrid discussion is about solving problems with so many <br>
> > PEs that MPI cannot scale to enough tasks. It seems likely to me <br>
> > that someone may want to use a million processing elements and that <br>
> > MPI will never scale well to a million tasks.<br>
> ><br>
> > I assume question with the check boxes is asking about "error <br>
> > handlers". It refers to "error handles"<br>
> > <a href="http://mpi-forum.questionpro.com/akira/">http://mpi-forum.questionpro.com/akira/</a><br>
> TakeSurvey;jsessionid=dcaTO_iOlMbIqcQeW98ts</tt><br>
<br>
<tt>The question: </tt><br>
<b><font face="Verdana">How much are each of the following sets of MPI functionality used in your MPI applications?</font></b><font size="4"> </font><br>
<tt>mentions "error handles". If there is anything that could be called an "error </tt><br>
<tt>handle" I suppose it would be the predefined error classes. Are you asking if </tt><br>
<tt>use MPI_Error_class to map an rc to a class or do you mean "do you use error handlers</tt><br>
<tt>vs ERRORS_RETURN vs ERRORS_ARE_FATAL</tt><br>
<tt><br>
> ><br>
> > I do not know what this question means.<br>
> ><br>
> <br>
> I'm not quite sure how to parse the above (the link doesn't take me to <br>
> a unique question):<br>
> <br>
> 1. Are you referring to the "How much are each of the following sets <br>
> of MPI functionality used in your MPI applications?" question?<br>
> 2. Are you saying that the phrase should be "Error handlers / error <br>
> checking" (instead of "Error handles")?<br>
> 3. Are you saying that it is unclear what this specific item means?<br>
> <br>
> > MPI one-sided communication performance is more important to me than <br>
> > supporting a rich remote memory access (RMA) feature set.<br>
> ><br>
> > Having been involved in several email discussions and knowing what <br>
> > is being pressed, I can guess the desired answer. We cannot <br>
> > legitimately make decisions based on such an ambiguous question: <br>
> > What expectations of typical MPI communication are included in <br>
> > "rich"? Is using any communicator except MPI_COMM_WORLD part of <br>
> > "rich"? Is getting a non-MPI_SUCCESS return code for an error part <br>
> > of rich?<br>
> ><br>
> <br>
> Keith and I went round and round on this particular question in an off- <br>
> list email thread. His final suggestion, which I think is a good one, <br>
> is to reword the question thusly:<br>
> <br>
> "MPI one-sided communication performance (e.g., message rate and <br>
> latency) is more important to me than supporting a rich remote memory <br>
> access (RMA) feature set (e.g., communicators, datatypes)."<br>
> <br>
> What do you think?</tt><br>
<br>
<tt>I think it is so hard to ask a meaningful question to a broad audience on </tt><br>
<tt>this topic that we should remove the question. Make the question simple </tt><br>
<tt>and get simplistic answers. Make it careful and few will take the time to </tt><br>
<tt>understand the implications we try to mention.</tt><br>
<tt><br>
> <br>
> > "MPI application control of fault tolerance" -- sounds too easy. Who <br>
> > would say no? I would be happy to have MPI_Tolerate_faults( yes | no)<br>
> ><br>
> <br>
> We agonized over this one as well. The current text is an attempt to <br>
> imply that MPI won't magically handle faults for you, but rather give <br>
> control of faults to the application. The implication is that the <br>
> application will have to *do* something rather than have MPI just <br>
> handle faults "better" (which I agree, everyone will just say, "yes, <br>
> gimme that!").<br>
> <br>
> But I can definitely see how a quick read of that would lead to the <br>
> interpretation of what you said.<br>
> <br>
> Can you suggest better wording?</tt><br>
<br>
<tt>Not really. I am waiting to see what the Fault tolerance group comes up</tt><br>
<tt>with but my feeling is that the difficulty of writing fault tolerant </tt><br>
<tt>applications and the limitations it will place on general MPI </tt><br>
<tt>functionality will restrict its use to a tiny niche market at best. Unless</tt><br>
<tt>you can tell the difference between a yes that is based on assuming most </tt><br>
<tt>MPI apps can be made fault tolerant with a bit of work vs a yes, I am </tt><br>
<tt>willing to work very hard and accept many limitation on what I expect </tt><br>
<tt>to be able to do in MPI code, you do not learn much.</tt><br>
<tt><br>
> <br>
> > It would be helpful to be able to read the survey questions before <br>
> > starting to answer. I personally dislike answering a survey question <br>
> > without knowing what all the questions are. I must try to pick the <br>
> > best answer even though the question does not really fit my concern <br>
> > or I must ignore my concern on the assumption a better targeted <br>
> > question must be on the survey. (I cannot count the number of times <br>
> > I have started to answer a telephone survey only to say in the <br>
> > middle "We're done" because I have deduced the survey questions will <br>
> > not really help capture my views")<br>
> ></tt><br>
<br>
<tt>I suppose a note at the intro telling people they can flip through and </tt><br>
<tt>look at the questions before starting will be enough. </tt><br>
<br>
<tt>In this question:</tt><br>
<b><font face="Verdana">Rate the following in order of importance to your MPI applications </font></b><font size="4"> </font><br>
<br>
<tt>what does performance mean? "hours to solution" and "$$$ to solution"</tt><br>
<tt>are both very important. Best case MPI_New_put latency may not tell you much</tt><br>
<tt>about either.</tt><br>
<br>
<tt>New functions that let libmpi avoid hogging memory can certainly help </tt><br>
<tt>"$$$ to solution" but most people would not think of them as a performance</tt><br>
<tt>issue.</tt><br>
<br>
<tt>Ideas that reduce the impact of jitter at scale are clearly important </tt><br>
<tt>to both "hours to solution" and "$$$ to solution" and may be far more </tt><br>
<tt>important in future than what people often call "performance".</tt><br>
<br>
<tt><br>
> <br>
> <br>
> Josh and I talked about this quite a bit while putting the questions <br>
> in the survey web thingy. We balanced your concerns against splitting <br>
> up the survey into seemingly-smaller chunks so that we don't <br>
> intimidate respondents from abandoning the survey in the middle. In <br>
> the end, we struck a compromise:<br>
> <br>
> - split the survey up into multiple pages so that it looks/feels <br>
> shorter (vs. one, massively-long page)<br>
> - don't use data validation rules<br>
> - provide navigation links in the survey (forward and back)<br>
> <br>
> The latter 2 points allow you to click click click through the entire <br>
> survey, reading everything without entering any answers. Then, when <br>
> you've read everything, you can navigate back (or just restart) and <br>
> actually take the survey.<br>
> <br>
> That was the best compromise we could think of. Do you think we <br>
> should have one big, massively-long page with all the questions?<br>
> <br>
> -- <br>
> Jeff Squyres<br>
> jsquyres@cisco.com<br>
> <br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> mpi-forum@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
</tt><BR> </body>
</html>