8
$\begingroup$

When writing MPI 3.0 code, should I pass argc and argv to the MPI_Init call or not, and why?

EDIT: Since Bill Barth's answer raised some questions I want to make some remarks:

  • Passing argc/argv is not required since MPI 1.1.
  • The question is specifically about why should/shouldn't one pass argc/argv (why shouldn't you is then not really an answer).
  • Still, sometimes you cannot pass argc/argv to MPI_Init (writing a library that uses static initialization to start MPI if main is outside your control and MPI is an implementation detail).

EDIT2: The question why wouldn't you use MPI_Init(argc, argv) has come too often now. Some reasons:

  • Doing it for the sake of compatibility with older/non-compliant/compliant MPI < 1.1 implementations is not possible since if you are using MPI2 or MPI3 features those won't work anyways.

  • MPI_Init() initializes the MPI runtime in the same way as MPI_Init(argc, argv)

  • MPI_Init(argc, argv) removes arguments passed to the MPI run-time from argc, and argv and initializes MPI. AFAIK it is the only way to clean argc and argv so if you need these to have no MPI arguments you need to use it.

  • MPI_Init() can be used in more situations that MPI_Init(argc, argv). For example your library using MPI as an implementation detail can test if MPI is initialized, and if not, call MPI_Init() and the right thing will happen. Your user doesn't know that you are using mpi, doesn't need to pass argc, argv to your library, doesn't need to change their main (in case it is taking no arguments) to use your library....

Improve this question
$\endgroup$
7
  • $\begingroup$ I don't follow why BillBarth's response doesn't answer your question. The "why wouldn't you" part looks like it sums up the gist of his response, which describes what happened with previous MPI implementations, and why not passing arguments could cause problems. Perhaps you're looking for something more definitive? $\endgroup$
    – Geoff Oxberry
    Sep 16, 2014 at 22:10
  • $\begingroup$ @GeoffOxberry The problem with the why wouldn't you answer is that it is as good as a why would you answer. Since all MPI implementations supporting MPI > 1.1 have to offer the alternative MPI_Init() which has to correctly get the arguments you pass to mpirun/mpiexec somehow (it is unspecified how), and since MPI_Init() can be used in more situations than MPI_Init(argc, argv) (and without workarounds), I don't really see the point on using MPI_Init(argc, argv) if you are targeting MPI 3.0. $\endgroup$
    – gnzlbg
    Sep 17, 2014 at 7:23
  • $\begingroup$ Compatibility with MPI implementations supporting MPI < 1.1 is not possible anyways if you have to use MPI 2.0 or MPI 3.0 features. $\endgroup$
    – gnzlbg
    Sep 17, 2014 at 7:25
  • 2
    $\begingroup$ You're still missing my basic point. The MPI distribution cannot tell at execution time whether your MPI_Init passes NULLs or not, so it probably puts stuff on the command line. If you don't pass argc and argv, then MPI_Init cannot edit them to remove its additions, therefore your code will have to be robust to spurious command-line arguments from MPI. Therefore, why take the risk of having to deal with an arbitrary and perhaps conflicting set of arguments when you can pass them to MPI_Init and get back a clean set? If you can't, you can't, but you should. $\endgroup$
    – Bill Barth
    Sep 17, 2014 at 12:31
  • $\begingroup$ See the second EDIT to the question. Basically if you want to clean argc and argv from MPI arguments and initialize MPI then use MPI_Init(argc, argv), otherwise MPI_Init() is fine (and sometimes it is necessary). $\endgroup$
    – gnzlbg
    Sep 17, 2014 at 13:07

3 Answers 3

Reset to default
2
$\begingroup$

I'd definitely pass them, but i'd pass the pointers like this MPI_init(&argc,&argv), allowing for perfectly valid call MPI_init(NULL,NULL) in your function.

Improve this answer
$\endgroup$
1
$\begingroup$

I don't know if there's something new in the 3.0 standard that makes it optional in C/C++ to not pass them, but I would definitely pass them. I don't know the current state, but in the past many implementations passed additional command-line arguments to your program when executed and then edited them out in MPI_Init(). If you want to use command-line arguments to pass options to your program, if you don't let the implementation do its editing, then you will have to interpret both your arguments and a potentially unknown number and style of arguments from the particular implementation you are using. These arguments are also highly likely to vary from implementation to implementation.

It's pretty normal to call MPI_Init() with argc and argv, so why wouldn't you?

Improve this answer
$\endgroup$
10
  • $\begingroup$ The spec says that after MPI 1.1 if you pass null to MPI_Init it should read the arguments from the environment. So why pass them to your application in the first place if it can read them from the environment? If runtimes do pass the arguments to the application anyways, then yes it makes sense to call MPI_Init with them such that at least your run-time cleans them before the rest of your application uses them. $\endgroup$
    – gnzlbg
    Sep 16, 2014 at 14:23
  • $\begingroup$ OK, so have you tested every stack available to find out if they have caught up with what they can do? If it's possible that some stack might screw up your code's argument parsing by adding extra arguments, why not let it do its part to remove those extra arguments during initialization? What's the harm in passing argc and argv to MPI_Init()? Again, why not do it? $\endgroup$
    – Bill Barth
    Sep 16, 2014 at 14:55
  • 1
    $\begingroup$ (1) I really don't understand your point about the environment info. If i call mpirun/mpiexec with some parameters, mpirun can set some enviroment variables before starting my program, and then read those from within MPI_Init. (2) I haven't tested every possible implementation, but as the question states I'm interested only on MPI 3.0 compliant implementations. There aren't a lot of those that are arcane. $\endgroup$
    – gnzlbg
    Sep 16, 2014 at 16:03
  • 2
    $\begingroup$ I missed your edit before I typed all of that. My suggestion is to pass argc and argv to the library if it wants to initialize MPI on your behalf. That, or require users to MPI_Init() and pass the library the required communicator. It's possibly unportable not call MPI_Init() with argc and argv. Petsc, for example, supports both styles. $\endgroup$
    – Bill Barth
    Sep 16, 2014 at 16:45
  • 1
    $\begingroup$ Supporting both styles seems necessary for anyone writing an MPI wrapper. $\endgroup$
    – gnzlbg
    Sep 17, 2014 at 13:08
0
$\begingroup$

The standard recommends (bold mine):

The MPI standard does not say what a program can do before an MPI_INIT or after an MPI_FINALIZE. In the MPICH implementation, you should do as little as possible.

A side effect of the (argv, argc) version is that it forces you to put MPI_Init in main and not deeper in the call stack. It is not fool proof but it implicitly tells you to put MPI_Init very early in main and not in a function that can be called twice for example.

I think this is what you have live with for a runtime system; it would be better to enforce this at compile-time for example.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.