[Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement

Bronis R. de Supinski bronis at [hidden]
Thu Mar 6 13:37:38 CST 2008



Dries:

While the question of an ABI is also important, it does
not really address the primary reason that recompiling
is bad. My issue is not that the applications have to
be compiled the first time. It is that recompiling to
use the profiling interface is an excessively high
barrier for many applications.

Also, while I see your point that only a small set of
stuff needs to be placed into mpi.h, that does not
address the real question: What is the actual application
level benefit? Why do I care if I can get MPI_Comm_size
or MPI_Comm_rank inlined? Good programming practice
does not call them frequently enough for any performance
gain to matter. Alternatively, suppose I can squash some
stuff out of the MPI_Send call path. Will it really matter
to real applications? It seems unlikely, particularly
relative to the cost of lost flexibility for understanding
communication behavior and performance.

Bronis

On Thu, 6 Mar 2008, Dries Kimpe wrote:

>
> * Bronis R. de Supinski <bronis_at_[hidden]> [2008-03-06 08:58:37]:
>
> > Perhaps just as importantly to the general need of the
> > interface, the idea that inlining of MPI will provide
> > substantial benefits is inaccurate. MPI is a library
> > interface. Many implementations are distributed only in
> > binary form; unless you are proposing link time inlining
> > (possible but not without its pitfalls), they will not gain
> > any benefit from this. Even if we consider only open source
> > MPI implementations, the VAST majority of users do NOT
> > want to compile the MPI library. The possible performance
> > gain is far too small for them to take on this task.
>
> This might not be completely true.  Since there is no ABI right now, every
> MPI application needs to be recompiled before it can be used.  Even though
> the MPI library might be compiled already, the C header will contain
> inline functions (they need to be in the header to have an effect) and
> will thus be inlined into the application.  The MPI library itself can
> choose how far it goes with this inlining.  (For example, all of MPI_Send
> / MPI_Recv could be inlined if it wishes to do so).
>
> So it is NOT needed to recompile the MPI library, only the functions that
> are part of mpi.h (and any headers it might include) will be recompiled,
> and this is transparent to the application.
>
> The real issue is that an ABI and inline functions are not compatible,
> unless the implementation of the inlined functions themselves is
> considered part of the ABI.  (this means all of the structures they use,
> all of the functions they call, ...)
>
>     Dries
>
>



More information about the Mpi3-subsetting mailing list