[Beowulf] Alternative to MPI ABI

[Joachim Worringen]

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 
implemenations.

>    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
>      benefit.

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

-- 
Joachim Worringen - NEC C&C research lab St.Augustin
fon +49-2241-9252.20 - fax .99 - http://www.ccrl-nece.de