* Bronis R. de Supinski <bronis_at_[hidden]> [2008-03-06 08:58:37]:

Perhaps just as importantly to the general need of the interface, the idea that inlining of MPI will provide substantial benefits is inaccurate. MPI is a library interface. Many implementations are distributed only in binary form; unless you are proposing link time inlining (possible but not without its pitfalls), they will not gain any benefit from this. Even if we consider only open source MPI implementations, the VAST majority of users do NOT want to compile the MPI library. The possible performance gain is far too small for them to take on this task.

This might not be completely true. Since there is no ABI right now, every MPI application needs to be recompiled before it can be used. Even though the MPI library might be compiled already, the C header will contain inline functions (they need to be in the header to have an effect) and will thus be inlined into the application. The MPI library itself can choose how far it goes with this inlining. (For example, all of MPI_Send / MPI_Recv could be inlined if it wishes to do so). So it is NOT needed to recompile the MPI library, only the functions that are part of mpi.h (and any headers it might include) will be recompiled, and this is transparent to the application. The real issue is that an ABI and inline functions are not compatible, unless the implementation of the inlined functions themselves is considered part of the ABI. (this means all of the structures they use, all of the functions they call, ...) Dries *