> We are planning to develop a MorphMPI library. As explained a bit
> up in this thread, the MorphMPI library will be used while *compiling*
> the app. The library that implements the MorphMPI calls will be linked
> with dynamically. The MorphMPI on its turn links with some specific
> library. To take into account the (binary incompatible) difference in
> the MPI libraries, the MorphMPI can be recompiled to be compatible
> any other MPI implementation (without having to recompile the app).
I am in the process of developing MorphMPI and have designed my
implementation a bit different than what you propose (my apologies if I
misunderstood what you have said). I am creating one main library, which
users will compile and run against, and which should not need to be
recompiled. This library will then open a plugin depending on what MPI
the user would like to use. Then, it will dynamically open the actual
MPI implementation. In other words, to add support for another MPI one
would just need to drop the appropriate plugin into the right directory.
As far as overhead is concerned, it appears that it will be minimal. In
the 32 bit world most conversions can be optimized away, and in the
64bit world it looks like only minimal conversions will need to be made.
The main exception to this is defined structures (aka MPI_Status) and
any cases where a user can pass an array to an MPI function. These will
require a bit more work, but it still looks like the overhead will be