First, I think an ABI would be an excellent idea, if only for ease of
support on our systems. However, after a quick discussion with a
colleague, I have a few concerns.
One major implementation issue is the equivalent of mpirun (which I
assume would be part of an ABI?) - or the startup requirements of
different MPI's. For example, many proprietary MPI layers require
access permissions and a context to be created for access to the high
performance interconnect, something often done outside of mpirun. This
is further complicated by what individual sites/users want to do. We
(as in our facility) are currently implementing our own MPI run on our
new system to setup a cpu/memory set for each individual mpi task to
live in.
As Greg points out, an ABI doesn't stop people from doing this and
doesn't stop vendors from having their own proprietary MPI, but it does
reduce the effectiveness of an ABI.
The other issue we are concerned about is that an ABI doesn't resolve
one of the central issues. While you might have different MPI's with
the same ABI, different mpi's behave differently and can cause a code
to behave differently. An ISV would still have to verify their code
against all MPI's they wish to support. For example, an ISV might, by
accident, make an assumption about the small message size and their
code might hang on different MPI's.
Stu.
--
<--------------------------------------------------------------------->
Dr Stuart Midgley | stuart.midg...@anu.edu.au
Supercomputer Facility | smidg...@netspace.net.au
Leonard Huxley Building 56 | +61 (0)2 6125 5988 Work
Australian National University | +61 (0)2 6125 8199 Fax
CANBERRA ACT 0200 | +61 (0)4 1125 2488 Mob
