[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpi-21] ABI - call for working group
On Jan 13, 2008, at 2:41 PM, Greg Bronevetsky wrote:
But surely the morph layer needs to be compiled against the local
MPI? I
would much prefer a situation whereby my customers do not have to
build
anything. By having a standard binary interface (which MPI
implementations are free to satisfy using the morph layer - and there
should still be an option to compile and link against the "native"
implementation to avoid any performance penalty in the morph layer),
there's nothing to compile.
I agree that it would be preferable. The question is: is it cost of
standardizing it (effort + reduction in implementor flexibility)
worth the benefit? In light of how much the morph layers can do, it
seems to me that for most of the features in the ABI proposal the
answer is no.
If your goal is to allow any user to trivially run with any installed
MPI, then I agree that a morph layer makes that goal more difficult
than an ABI.
However, ISVs typically support a limited number of MPI's that they
have qualified with their software. When customers ask for other
MPI's, they may make a "best effort" attempt to support them (e.g.,
providing a custom build against that MPI), but real support can be
difficult because of inexperience with that MPI, lack of engineering/
testing resources, other customer support load on qualified platforms,
etc.
- With an ABI, the customer may unknowingly run against an unqualified
MPI, even if the ISV won't support unqualified MPI's.
- When using a morph layer, there will likely be an extra step of
having the customer compile the morph layer against their desired
MPI. However, this may have two unexpected benefits:
1. Greatly reduce the possibility of accidentally using an
unqualified MPI
2. It makes the process "just difficult enough" to discourage all
but those who really do want to use their own MPI (i.e., they have to
compile the morph layer)
--
Jeff Squyres
Cisco Systems