Toon, > We are planning to develop a MorphMPI library. As explained a bit > higher > 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 MPI > library. To take into account the (binary incompatible) difference in > the MPI libraries, the MorphMPI can be recompiled to be compatible with > 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 small. Tim