Re: How constant are MPI constants?

Craig J. Fischberg (Craig.Fischberg@ae.ge.com)
Wed, 01 May 1996 12:46:21 -0400

William Gropp wrote:
>
> Ergh. Constants. The original (1.0) definition meant "unchanging between
> MPI_Init and MPI_Finalize". In the C sense, this did not imply const, since
> MPI_Init could set the values. In 1.1 this was strengthened to be "usable as
> compile-time initializers"; this allowed using "address of object" in C, and
> constrained implementations in Fortran (basically forcing PARAMETER). The
> language interoperability may further constrain implementations by mandating
> the most restrictive (Fortran) form. Because of this, it is probably
> premature to decide the "const" status of the MPI "constants" until after the
> language interoperability section is through its first real vote.
>
> Having said that, It seems likely that everything (including predefined
> communicators) except for MPI_BOTTOM will be const. Some implementations will
> have to change, but this is independent of the C++ binding.
>
> I'd be interested in if the language interoperability section will impact the
> C++ implementations more than it already does the C implementations.
>
> Bill

As both an imlementor and end user I will make a suggestion that will
probably make most of you cringe. I would have gone even further
with the definition of constants under MPI-1. I would have liked to
see the actual values (i.e. integers) for the constants defined in
the standard. And, I would like to say that no MPI function could
be defined as a macro. Why? So that the particular mpi library
implementation could be loaded at run-time using shared-object
libraries without having to re-compile the code.

For example, if my job is to be wholly contained within an SGI I
would set-up the environment to load the SGI optimized shared-library
version of MPI for use within a single box. If my job is to be
split between an SGI and several other boxes, I could set up my
environment to load shared object versions of MPICH or CHIMP at
run time. In this way, I can use the same binary of my application
and load the best library implementation for the particular job
that I am running.

It is too late to consider something like this. However, I
figured it was worth having people think about it.

-- 
====================================================================
Craig J Fischberg                  E-mail: Craig.Fischberg@ae.ge.com
GE Aircraft Engines                Phone: 513-552-2716
One Neumann Way M/D T207           Fax:   513-552-3153
Cincinnati, OH 45215-6301
====================================================================