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 toppingor is it a floor wax?
From: Brian W. Barrett (brbarret_at_[hidden])
Date: 2009-03-12 14:16:37

I'm going to stay out of the debate about whether Andy correctly
characterized the two points you brought up as a distributed OS or not.

Sandia's position on these two points remains the same as I previously
stated when the question was distributed OS or not. The primary goal of
the Open MPI project was and should remain to be the best MPI project
available. Low-cost items to support different run-times or different
non-MPI communication contexts are worth the work. But high-cost items
should be avoided, as they degrade our ability to provide the best MPI
project available (of course, others, including OMPI developers, can take
the source and do what they wish outside the primary development tree).

High performance is a concern, but so is code maintainability. If it
takes twices as long to implement feature A because I have to worry about
it's impact not only on MPI, but also on projects X, Y, Z, as an MPI
developer, I've lost something important.


On Thu, 12 Mar 2009, Richard Graham wrote:

> I am assuming that by distributed OS you are referring to the changes that
> we (not just ORNL) are trying to do. If this is the case, this is a
> mischaracterization of the of out intentions. We have two goals
> - To be able to use a different run-time than ORTE to drive Open MPI
> - To use the communication primitives outside the context of MPI (with or
> without ORTE)
> High performance is critical, and at NO time have we ever said anything
> about sacrificing performance - these have been concerns that others
> (rightfully) have expressed.
> Rich
> On 3/12/09 8:24 AM, "Jeff Squyres" <jsquyres_at_[hidden]> wrote:
>> I think I have to agree with Terry.
>> I love to inspire and see new, original, and unintended uses for Open
>> MPI. But our primary focus must remain to create, maintain, and
>> continue to deliver a high performance MPI implementation.
>> We have a long history of adding "small" things to Open MPI that are
>> useful to 3rd parties because it helps them, helps further Open MPI
>> adoption/usefulness, and wasn't difficult for us to do ("small" can
>> have varying definitions). I'm in favor of such things, as long as we
>> maintain a policy of "in cases of conflict, OMPI/high performance MPI
>> wins".
>> On Mar 12, 2009, at 9:01 AM, Terry Dontje wrote:
>>> Sun's participation in this community was to obtain a stable and
>>> performant MPI implementation that had some research work done on the
>>> side to improve those goals and the introduction of new features. We
>>> don't have problems with others using and improving on the OMPI code
>>> base but we need to make sure such usage doesn't detract from our
>>> primary goal of performant MPI implementation.
>>> However, changes to the OMPI code base to allow it to morph or even
>>> support a distributed OS does cause for some concern. That is are we
>>> opening the door to having more interfaces to support? If so is this
>>> wise in the fact that it seems to me we have a hard enough time trying
>>> to focus on the MPI items? Not to mention this definitely starts
>>> detracting from the original goals.
>>> --td
>>> 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.
>>>> Best Regards,
>>>> Andrew Lumsdaine
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]