Subject: Re: MPI Job startup

From: L J Clarke <[email-masked]>
Date: Mon, 8 Mar 93 14:17:41 GMT

Hi there

Spring has arrived in Scotland :-) For the thrid say this year we have
beautiful sunshine :-) The snow on the Caringorms is meling fast :-(

Now it's MPI job startup.  Thanks to Bill and Rusty for starting this
one off. 

The MPI_INIT style is familiar.  It makes it explicit that the bit of
the program before MPI_INIT is executing in parallel, and no MPI
services can be used before MPI_INIT.  As Jim correctly points out.  It
documents to the user what s/he is using.  The trouble is, that the user
will almost always end up calling MPI_INIT right after entry into main,
because what can the user usefully do before MPI_INIT? We should
consider providing this approach. 

I really don't like the MPI_CALL approach.  It serves to confuse the
user.  It looks like there is one main running, and the function
reference in MPI_CALL magically runs in parallel.  What of use can the
user do before MPI_CALL? It looks to the user like the static (global)
data is all accessible everywhere.  I don't think this is intended, and
I don't think this is what should be provided. 

What about the other approach, in which the user provides a "virtual
main" and the MPI library supplies a "actual main", which calls the
virtual main.  I guess the virtual main calls MPI_INIT and then calls
the actual main.  This removes the necessity for the user to call
MPI_INIT, and means that s/he cannot make the mistake of attempting to
use MPI services before they are available.  We *might* be able to get
this past C programmers.  I believe that we would have enormous problems
trying to get this past crusty fortran programmers --- "What, you mean I
have to write a subroutine instead of a program?". 

Wait up though, this is what is happening anyway.  Your process never
starts in your own main.  Your "actual main" is a "virtual main", and
the compiler/stdlib/runtime executes a preamble to main.

FOURTH suggestion
-----------------

There is no MPI initialisation procedure.  The user program is
"attatched to MPI" and can use MPI services as soon as the user program
starts to execute. 

This means that we require system vendors to embed any MPI
initialisation his/her implementation requires in the preamble before
main. 

Dead simple.

Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: L J Clarke <[email-masked]>
Date: Mon, 8 Mar 93 14:24:19 GMT

Ooops - small oversight.

> initialisation his/her implementation requires in the preamble before

Not quite true, Lyndon, you missed something :-)

On the other hand all of the MPI service routines could do one check of
a static boolean to see if MPI has been initialised, and if not then
call an initialisation routine which inverts the static boolean. 

I just prefer if it happened for sure in the preamble.

Best Wishes
Lyndon

ps replying to my own mail, hmmm :-)

---

From: [email-masked]
Date: Mon, 8 Mar 93 12:02:53 PST

Here are some comments I haven't seen yet about MPI job startup
suggestions.

> initialisation his/her implementation requires in the preamble before

This approach has the disadvantage that it requires intimate 
collaboration with the vendor's runtime language-support library.
The interfaces to those libraries are usually undocumented and subject
to change without notice.  This means that one needs vendor cooperation
to write and maintain an MPI implementation using this approach.

From the MPI user's standpoint, "FOURTH suggestion" seems
indistinguishable from the earlier proposal that there be no
explicit initialization call, and that initialization be done by
having each MPI routine check a static boolean.

A minor problem with the static boolean suggestion is that then the
initialization routine does not have access to those parts of the
environment passed as (argc,argv).  Such access is sometimes useful.

  (For example... TCGMSG's static process initializer uses
  command-line arguments to inform each process of its place in the
  grand scheme of things.  In C, the command-line arguments are
  accessible to TCGMSG because the application has to pass them to
  the TCGMSG initialization procedure.  (In Fortran, TCGMSG's
  initialization procedure is called without arguments, and it has
  to hunt up the argc and argv that presumably stored by Fortran
  initialization in global variables.  See above comments about
  undocumented interfaces.)

The MPI_Main approach (MPI does the initialization, user provides a 
subroutine) seems to have the disadvantage that it works for only
one package.  If MPI takes this approach, then I don't see how any
other package FOO can too, if an application wants to use both MPI
and FOO.

MPI_Call has the slight problem that if another package FOO adopts
the MPI_Call approach, then we end up with

    main (argc,argv)
    { MPI_main (argc,argv,myMPIinitializer); }

    myMPIinitializer (argc,argv)
    { FOO_main (argc,argv,myFOOinitializer); }

    myFOOinitializer (argc,argv)
    { myapplication (argc,argv); }

compared to

    main (argc,argv)
    { MPI_Init (argc,argv);
      FOO_Init (argc,argv);
      myapplication (argc,argv);
    }
    
Certainly this is not an enormous problem, but I don't see where
the extra complexity buys anything.

I like MPI_Init (augmented if necessary for dynamic processes).

--Rik Littlefield