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
