[Mpi-22] MPI_INIT assertions

Richard Graham rlgraham at [hidden]
Thu May 15 12:33:02 CDT 2008 

Assertions should not change semantics ­ these are defined by the standard.
Assertions
 may provide ³help² to the implementation, what ever that means.  I may be
missing some thing,
 but I really don¹t see a difference (aside  from name) between assertions
an hints ­ both are
 ways of the user conveying information to the library.

Rich

On 5/15/08 12:58 PM, "Terry Jones" <trj_at_[hidden]> wrote:

> 
> If we are to allow an extensible mechanism for Assertions, then I like the
> idea of a "Hints/Info" like interface where one may query to find out what the
> implementation supports. However, an Assertions version would need to be
> clearly distinct from Hints to adequately convey that Assertions *may change
> the semantic rules* (which Hints do not).
> 
> An Extensible Assertions interface would presumably allow for many
> optimizations by relaxing semantics that are unneeded by the application.
> However, for Assertions the application must be aware because they can change
> the outcome of the application. I mentioned read-ahead as an example.
> Asserting a read-ahead of a given size would permit different results for
> files opened Read+Write on a file system that provides strong consistency
> semantics.
> 
> I believe Extensible Assertions would be utilized by applications because as
> application teams currently move from platform to platform they make
> themselves aware of environment variable tunables and use such tunables. I
> would like to see applications dynamically change these tunables during a run
> to accommodate different application phases efficiently. Allowing such a
> mechanism to alter semantics gives freedom for increased performance (albeit
> at the cost that the application must be aware of what they are doing, and
> there is added complexity for all involved).
> 
> I would also support Dick's original thought of a small, pre-defined set of
> Assertions. This is a small step in the direction of Extensible Assertions
> (with smaller opportunity for misuse and 'easier to swallow' adoption), and
> could be designed with an interface that would later permit Extensible
> Assertions. But I would keep the interface sufficiently distinct from Hints to
> avoid confusion.
> 
> Regards,
>  Terry
> 
> 
> At 11:25 AM -0400 5/15/08, Richard Graham wrote:
>> We should be careful about making a change in MPI 2.2, knowing that we will
>> likely turn around again
>>  in MPI 3.0 and change things again.  If we are talking about changing the
>> interface in 2.2, and
>>  then extending the assertions/hints in 3.0, this seems fine, but if we may
>> want to change the
>>  interface yet again in 3.0, we should rethink things.
>> I will add that if we are going to add some sort of  "info" argument to
>> 'MPI_Init()', we should deprecate
>>  MPI_Init() and MPI_Init_thread(), and include the threading specification in
>> the "info" object.
>> Finally, before we decide on how to pass hints/assertions (if we do) to
>> MPI_Init(), we should
>>  define a consistent way across the standard for passing information between
>> the application and
>>  the library, as this is not the only instance where this is useful, and a
>> uniform way of doing this
>>  makes things much easier on users.
>> 
>> Rich
>> 
>> 
>> On 5/14/08 9:14 AM, "Richard Treumann" <treumann_at_[hidden]> wrote:
>>> MPI_Init time assertions must be few and each must be valuable or the
>>> concept will fall like a house of cards.
>>> 
>>> There is nothing in my proposal for MPI_Init time assertions that rules out
>>> 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 - If it makes sense. These extra mechanisms are far to complex to
>>> consider as part of MPI 2.2.
>>> 
>>> I would not use the phrase that Dries does when he says "Assertions are bad"
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> Dick Treumann  -  MPI Team/TCEM
>>> IBM Systems & Technology Group
>>> Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
>>> Tele (845) 433-7846         Fax (845) 433-8363
>>> 
>>> 
>>> mpi-22-bounces_at_[hidden] wrote on 05/14/2008 07:21:41 AM:
>>> 
>>>> > * Terry Jones <trj_at_[hidden]> [2008-05-13 15:19:07]:
>>>> >
>>>>> > > You can also imagine other possibilities to provide helpful context.
For
>>>>> > > instance, perhaps the user could provide Assertions that would help
>>>>> MPI IO
>>>>> > > with read-ahead prefetching or write-behind, or even meta-data
>>>>> operations
>>>>> > > (e.g., later I will be creating one file per MPI task).
>>>> >
>>>> > Things like read-ahead or write-behind clearly shouldn't be assertions
>>>> but
>>>> > hints. (And, probably 'one file per MPI task' too -- if this is still
>>>> going to
>>>> > be needed in 2 years)
>>>> >
>>>> > MPI already has hints that can capture some of the things mentioned
>>>> > above.
>>>> >
>>>> > access_style: (read_once, write_once, read_mostly, write_mostly,
>>>> sequential,
>>>> > reverse_sequential, and random)
>>>> >     sequential -> this can easily be used to turn on read-ahead
>>>> >                   IF THE MPI LIBRARY decides this is useful
>>>> >
>>>> > Assertions are bad -- they break compatibility -- and should only be
>>>> > tolerated if they provide real benefits and if the same cannot be
>>>> obtained
>>>> > through existing mechanisms (hints, ...).
>>>> >
>>>> > In the examples mentioned, this is not the case.
>>>> >
>>>> >    Dries
>>>> >
>>>> > [attachment "attia6gr.dat" deleted by Richard
>>>> > Treumann/Poughkeepsie/IBM]
>>>> _______________________________________________
>>>> > mpi-22 mailing list
>>>> > mpi-22_at_[hidden]
>>>> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>>> <http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22>
>>> 
>>> _______________________________________________
>>> mpi-22 mailing list
>>> mpi-22_at_[hidden]
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>> <http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22>
>> 
>> 
>> _______________________________________________
>> mpi-22 mailing list
>> mpi-22_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
> 
> 
> 
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22



* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080515/10869bfc/attachment.html>

More information about the Mpi-22 mailing list