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.