Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Meta Question -- Open MPI: Is it a dessert topping or is it a floor wax?
From: Brian W. Barrett (brbarret_at_[hidden])
Date: 2009-03-11 14:41:37

On Wed, 11 Mar 2009, Andrew Lumsdaine wrote:

> Hi all -- There is a meta question that I think is underlying some of the
> discussion about what to do with BTLs etc. Namely, is Open MPI an MPI
> implementation with a portable run time system -- or is it a distributed OS
> with an MPI interface? It seems like some of the changes being asked for
> (e.g., with the BTLs) reflect the latter -- but perhaps not everyone shares
> that view and hence the impedance mismatch.
> I doubt this is the last time that tensions will come up because of differing
> views on this question.
> I suggest that we come to some kind of common understanding of the question
> (and answer) and structure development and administration accordingly.

My personal (and I believe, Sandia's) view is that Open MPI should seek to
be the best MPI implementation it can be and to leave the distributed OS
part to a distributed OS project. This can be seen by my work with Ralph
over the past few years to reduce the amount of run-time that exists when
running on Red Storm. My vision of the (ideal, possibly impractical) Open
MPI would be one with a DPM framework (the interface between OMPI and the
run-time) and nothing else in the run-time category.

That being said, I understand the fact that we need a run-time for
platforms which are not as robust as Red Storm. I also understand the
desire to build a variety of programming paradigms on top of Open MPI's
strong infrastructure. Given the number of broken interfaces out there,
only having to fix them once with more software is attractive.

In the end, I don't want to give up the high quality MPI implementation
part of the project to achieve the goal of wider applicability. Five
years ago, we set out to build the best MPI implementation we could, and
we're not done yet. We should not give up that goal to support other
programming paradigms or projects. However, changes to better support
other projects and which do not detract from the primary goal of a high
quality MPI implementation should be pursued.