Robert G. Brown wrote:
> Ashley Pittman writes:
>> Personnel I think a MPI ABI would be a good thing however this is not
>> the way to do it.
> And this is exactly right. Futhermore, we all know the right way to do
> it. It is for a new governing body or consortium to be established (or
> more likely the old MPI Forum body promoted) to which all/most of the
> MPI makers subscribe. Let's call this imaginary body the "MPIETF" (MPI
> Engineering Task Force) in homage of sorts, since MPIABITF is a bit
Interesting but not very practical/pragmatic. There is a more
lightweight process IMHO that can attain the same goal (and way faster):
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).
So if it is technically feasable to have an ABI, the interface of the
MorphMPI library can be the ABI. The MorphMPI ABI will than translate
the calls to the real MPI in whatever (incompatible) format the MPI
library is encoded in.
If the MorphMPI library catches on, MPI vendors *have* an interest in
matching the ABI as specified by MorphMPI because this would mean that
MorphMPI would have to do *no* conversion anymore at all (and can thus
actually be skipped) and thus the translation (read: the MPI library) is
faster. OTOH vendors that are not convinced of having an ABI can wait if
the MorphMPI approach becomes popular before taking a decision if they
want to align with the ABI or not.
I'm not so much for 'mandating' a standard, de facto standards are way
more interesting and usually end up in soth. superior imo.