[Beowulf] Alternative to MPI ABI
joachim at ccrl-nece.de
Tue Mar 22 10:22:36 PST 2005
Donald Becker wrote:
> On Tue, 22 Mar 2005, Jeff Squyres wrote:
>>Instead, I would like to propose an alternative to an MPI ABI.
> This is related to one of my pet "thought projects" for several years.
> We have largely completed developing an alternate cluster programming
> model that is better suited to most applications.
Are you sure you know what most application developers want, and are
capable to handle?
> The current MPI design is the wrong model for clusters.
> It represents a static view of the cooperating machines
> The MPI "cluster size", MPI_Comm_size(MPI_COMM_WORLD, ...), is
> static for all time. There is no way to take advantage of new
> machines, or reduce the number of machines that the application
> depends on.
New nodes can be added (MPI_COMM_UNIVERSE!). For the removal of nodes,
you are right, see "failures".
> MPI has a model of initialize-compute-terminate.
> There is no explicit support for checkpointing, executing as a
> service, or running "forever".
There are a lot of examples for either application-driven checkpointing,
automatic checkpointing or a combination of both. What kind of support
do you have in mind?
MPI was not designed to let machines communicate on some system-level.
What kind of "MPI service" do you have in mind? Did you check the whole
dynamic-process chapter of MPI-2 (accept, connect,...)?
I also think that some sort of defined interaction with the scheduling
systems is desirable for MPI-2 dynamic processes (to get an answer to
the question "where can I run my new processes?"). But this needs to be
very ligthweight and abstract, to allow a wide range of actual
> MPI has no concept of failures
This is true, and is addressed by current research projects (MPI-FT,
FT-MPI, maybe Open-MPI) and should be covered by a potential update of
the MPI standard.
> MPI's strength is collective mathematically-oriented operations, not
> communication. I understand that even the name "Message Passing.."
> indicates that stream communication isn't the focus, but many
> applications expect and work well with a sockets-based model.
Do you think a one-model-for-everything strategy would be successful?
> Cross-architecture jobs are theoretically supported, but very
> difficult to implement. The capability adds complexity without
MPI provides everything you need. The fact that it is hard to implement
or set up is a problem of the implementation, not the standard.
> Communicators besides MPI_COMM_WORLD are rarely used. The capability
> adds complexity with little benefit.
Hmm, so you don't want communicators? I'd say that they are critical to
any sort of dynamic environment. Besides that, they are already used
today in many more complex codes, and you can't cleanly implement a
library calling MPI without them.
Largely, what you describe sounds more like some variant of grid
computing. MPI is not about grid computing, it's mostly about
performance, but can be embedded in a grid environment. But it should
not try to represent a grid environment itself.
Joachim Worringen - NEC C&C research lab St.Augustin
fon +49-2241-9252.20 - fax .99 - http://www.ccrl-nece.de
More information about the Beowulf