With this debate over a common interface, I've noticed
that some have been talking about a common API (ie:
code-level compatibility) and others an ABI (ie:
binary-level compatibility). There's a big difference,
so I think it might be helpful if it was cleared up as
to what it was that was wanted. :)
Assuming an ABI, I suggest calling it IPM (for
Implementation-Proof MPI - yes, another recursive
An ABI could be written as:
1) A wrapper that the program linked to, where the
wrapper could connect to any one of a number of MPI
2) A wrapper around the MPI library which provided a
standard interface programs could be compiled against
3) An environment that dlopen()ed both the program AND
an MPI library
Any of these would allow you to have a high degree of
independence of language-specific quirks, (1) in
particular as you could both generic and
language-specific transliteration code. You'd simply
link to what was most appropriate.
(1) would also have the benefit that you could
effectively exploit compiler-specific features (eg:
OpenMP) or language-specific parallelisms (eg: Occam)
because the wrapper would (in part or in whole) be
inside the application and therefore would have access
to all of these bug^H^H^Hfeatures.
(2) has the benefit that the library presents a common
interface, no matter what. Any variation can be
handled inside the wrapper. That means you could use
anything that provides essentially the same
capabilities, not just MPI. It might also make it
easier to handle mixed MPI-1 and MPI-2 environments,
as the differences at the application layer would be
(3) has the advantage that you could hot-swap MPI
implementations, while an application is running. This
might be interesting in network research and possibly
useful for really exotic environments, I can't see it
would have much to offer otherwise.
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!