<HTML>
<HEAD>
<TITLE>Re: [Mpi-22] MPI_INIT assertions</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>We should be careful about making a change in MPI 2.2, knowing that we will likely turn around again<BR>
in MPI 3.0 and change things again. If we are talking about changing the interface in 2.2, and<BR>
then extending the assertions/hints in 3.0, this seems fine, but if we may want to change the<BR>
interface yet again in 3.0, we should rethink things.<BR>
I will add that if we are going to add some sort of “info” argument to ‘MPI_Init()’, we should deprecate<BR>
MPI_Init() and MPI_Init_thread(), and include the threading specification in the “info” object.<BR>
Finally, before we decide on how to pass hints/assertions (if we do) to MPI_Init(), we should<BR>
define a consistent way across the standard for passing information between the application and<BR>
the library, as this is not the only instance where this is useful, and a uniform way of doing this<BR>
makes things much easier on users.<BR>
<BR>
Rich<BR>
<BR>
<BR>
On 5/14/08 9:14 AM, "Richard Treumann" <treumann@us.ibm.com> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>MPI_Init time assertions must be few and each must be valuable or the concept will fall like a house of cards.<BR>
<BR>
There is nothing in my proposal for MPI_Init time assertions that<B> rules out</B> providing other mechanisms in MPI 3 for giving guidance to the MPI implementation. In MPI 3 we can consider more hints and we can add the abiility to give stronger direction to MPI or provide it on a more granular basis -<B> If it makes sense</B>. These extra mechanisms are far to complex to consider as part of MPI 2.2.<BR>
<BR>
I would not use the phrase that Dries does when he says "</SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>Assertions are bad</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>" but I agree with the the sentiment behind his statement. I think there should be a very small number of assertions defined in the standard and for each there should be a good rationale. For MPI 2.2 there should be a great rationale because we can come back in MPI 3 and add more assertions if we miss some important ones. It is much harder to remove one that turns out to be real trouble.<BR>
<BR>
Each assertion the the MPI Standard defines has the potential to break some piece of code that is valid MPI but that depends on semantic the assertion says is optional. The author of the routine that calls MPI_Init has the power to declare assertions and the authors of other parts of an applicaton must either live within the rules or explicitly shield against them. <BR>
<BR>
For project teams that develop complete applications, the decision to use an assertion belongs to the team, team leader or architect. If it is decided that an application will use a specific assertion it is the team lead who must make sure all developers understand the decision and write appropriate code. All testing will be done with the assertion in place.<BR>
<BR>
For third part libraries, the only option is to either forbid all assertions or explicitly pick some to allow. If there are 4 potential assertions, it is not very hard to decide for each one - "Will the library tolerate it?". If there are 50 assertions, library authors will seldom allow them all and will be more tempted to just say "No assertions allowed" because making judgements about each of 50 is too difficult.<BR>
<BR>
For Community developed code where people contribute source but are not under direct control of an architect or team lead, reviewing each submission for compliance with one or two assertions may be acceptable but reviewing for 50 each time somebody contributes new code is not.<BR>
<BR>
<BR>
<BR>
Dick Treumann - MPI Team/TCEM <BR>
IBM Systems & Technology Group<BR>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<BR>
Tele (845) 433-7846 Fax (845) 433-8363<BR>
<BR>
<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>mpi-22-bounces@lists.mpi-forum.org wrote on 05/14/2008 07:21:41 AM:<BR>
<BR>
> * Terry Jones <trj@llnl.gov> [2008-05-13 15:19:07]:<BR>
> <BR>
> > You can also imagine other possibilities to provide helpful context. For <BR>
> > instance, perhaps the user could provide Assertions that would help MPI IO <BR>
> > with read-ahead prefetching or write-behind, or even meta-data operations <BR>
> > (e.g., later I will be creating one file per MPI task).<BR>
> <BR>
> Things like read-ahead or write-behind clearly shouldn't be assertions but<BR>
> hints. (And, probably 'one file per MPI task' too -- if this is still going to<BR>
> be needed in 2 years)<BR>
> <BR>
> MPI already has hints that can capture some of the things mentioned<BR>
> above. <BR>
> <BR>
> access_style: (read_once, write_once, read_mostly, write_mostly, sequential,<BR>
> reverse_sequential, and random) <BR>
> sequential -> this can easily be used to turn on read-ahead <BR>
> IF THE MPI LIBRARY decides this is useful<BR>
> <BR>
> Assertions are bad -- they break compatibility -- and should only be<BR>
> tolerated if they provide real benefits and if the same cannot be obtained<BR>
> through existing mechanisms (hints, ...). <BR>
> <BR>
> In the examples mentioned, this is not the case.<BR>
> <BR>
> Dries<BR>
> <BR>
> [attachment "attia6gr.dat" deleted by Richard <BR>
> Treumann/Poughkeepsie/IBM] _______________________________________________<BR>
> mpi-22 mailing list<BR>
> mpi-22@lists.mpi-forum.org<BR>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><BR>
</SPAN></FONT></FONT><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>_______________________________________________<BR>
mpi-22 mailing list<BR>
mpi-22@lists.mpi-forum.org<BR>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'><BR>
</SPAN></FONT></FONT>
</BODY>
</HTML>