Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-10-12 06:36:22


Ashley Pittman wrote:

> The second problem is that of linking, most MPI vendors already have
> MPI_Init in their own library, having another library with it's own
> wrapper MPI_Init in it is going to lead to a whole world of pain to do
> with dynamic linking and symbol resolution. This is not something that
> has ever been done before to the best of my knowledge and there is a
> very good reason for that.

Right but the header file of the MorphMPI library could define
MorphMPI_Init for instance to avoid this. Additionally it could generate
the necessary macro's (*if* the user requests this) to automatically
convert all it's calls to MPI_Init to MorphMPI_Init. Of course one
should be sure that this is done in the whole application or not at all
but there are easy ways to verify that.

>
> Thirdly is the performance issue, any MPI vendor worth his salt tries
> very hard to reduce the number of function calls and library's between
> the application and the network, adding another one is a step in the
> wrong direction. This may not matter so much for ethernet clusters but
> certainly for some people the software stack accounts for a surprising
> percentage of "network" latency.

Do you really think one extra function call would make a difference to
the level of being unacceptable? If that is the case MPI libraries would
only be available as archives instead of dynamic libraries because a
call to a dynamic library also costs an extra dereference.

toon