[Mpi-22] MPI_INIT assertions

Thu May 15 12:03:42 CDT 2008

Hi,

I bet some setting changes (like eager protocol threshold) may need to
be global, or at least include all processes involved in a loosely
synchronous, i.e., collective manner. Is this a part of the hints
proposal? If not, changes to the settings effective on one side won't be
visible on the other side. Enter chaos.

Best regards.

Alexander

________________________________

From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Jones
Sent: Thursday, May 15, 2008 6:58 PM
To: MPI 2.2
Subject: Re: [Mpi-22] MPI_INIT assertions

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

---------------------------------------------------------------------
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.

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