Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Tim Prins (tprins_at_[hidden])
Date: 2007-08-21 14:28:00

Yeah, ABI is something that has been on many people's "it would be nice
to have this someday" list, but I agree with Terry in that if this is
something we want, MPI is the place to start.

I assume that the RSL will have the same ABI problems as every other


Terry D. Dontje wrote:
> Matthias Mueller wrote:
>> Tim, all,
>> I believe that such an effort also would be an opportunity to come up
>> with a strategy regarding upwards and downwards compatibility (will a
>> binary compiled with one version work within the runtime of a different
>> version?). IMHO this is what is needed by ISV when they ship binaries,
>> it is alo needed by any user who doesn't want to recompile after any
>> (minor) upgrade by the sysadmins.
> This seems like a lot wider topic than just the ORTE. I really think that
> if the community was going to attack the ABI compatibiltiy we really
> should start at the MPI interface area.
> --td
>> AFAIK Open MPI does not have a (strong or advertised) commitment
>> regarding compatibility. It would be nice to have such a commitment and
>> also proper error messages when someone tries to run a binary in an
>> environment that is not compatible.
>> Best regards,
>> Matthias
>> On Thu, 2007-08-16 at 21:47 -0400, Tim Prins wrote:
>>> WHAT: Solicitation of feedback on the possibility of adding a runtime
>>> services layer to Open MPI to abstract out the runtime.
>>> WHY: To solidify the interface between OMPI and the runtime environment,
>>> and to allow the use of different runtime systems, including different
>>> versions of ORTE.
>>> WHERE: Addition of a new framework to OMPI, and changes to many of the
>>> files in OMPI to funnel all runtime request through this framework. Few
>>> changes should be required in OPAL and ORTE.
>>> WHEN: Development has started in tmp/rsl, but is still in its infancy. We hope
>>> to have a working system in the next month.
>>> TIMEOUT: 8/29/07
>>> ------
>>> Short version:
>>> I am working on creating an interface between OMPI and the runtime system.
>>> This would make a RSL framework in OMPI which all runtime services would be
>>> accessed from. Attached is a graphic depicting this.
>>> This change would be invasive to the OMPI layer. Few (if any) changes
>>> will be required of the ORTE and OPAL layers.
>>> At this point I am soliciting feedback as to whether people are
>>> supportive or not of this change both in general and for v1.3.
>>> Long version:
>>> The current model used in Open MPI assumes that one runtime system is
>>> the best for all environments. However, in many environments it may be
>>> beneficial to have specialized runtime systems. With our current system this
>>> is not easy to do.
>>> With this in mind, the idea of creating a 'runtime services layer' was
>>> hatched. This would take the form of a framework within OMPI, through which
>>> all runtime functionality would be accessed. This would allow new or
>>> different runtime systems to be used with Open MPI. Additionally, with such a
>>> system it would be possible to have multiple versions of open rte coexisting,
>>> which may facilitate development and testing. Finally, this would solidify the
>>> interface between OMPI and the runtime system, as well as provide
>>> documentation and side effects of each interface function.
>>> However, such a change would be fairly invasive to the OMPI layer, and
>>> needs a buy-in from everyone for it to be possible.
>>> Here is a summary of the changes required for the RSL (at least how it is
>>> currently envisioned):
>>> 1. Add a framework to ompi for the rsl, and a component to support orte.
>>> 2. Change ompi so that it uses the new interface. This involves:
>>> a. Moving runtime specific code into the orte rsl component.
>>> b. Changing the process names in ompi to an opaque object.
>>> c. change all references to orte in ompi to be to the rsl.
>>> 3. Change the configuration code so that open-rte is only linked where needed.
>>> Of course, all this would happen on a tmp branch.
>>> The design of the rsl is not solidified. I have been playing in a tmp branch
>>> (located at which everyone is
>>> welcome to look at and comment on, but be advised that things here are
>>> subject to change (I don't think it even compiles right now). There are
>>> some fairly large open questions on this, including:
>>> 1. How to handle mpirun (that is, when a user types 'mpirun', do they
>>> always get ORTE, or do they sometimes get a system specific runtime). Most
>>> likely mpirun will always use ORTE, and alternative launching programs would
>>> be used for other runtimes.
>>> 2. Whether there will be any performance implications. My guess is not,
>>> but am not quite sure of this yet.
>>> Again, I am interested in people's comments on whether they think adding
>>> such abstraction is good or not, and whether it is reasonable to do such a
>>> thing for v1.3.
>>> Thanks,
>>> Tim Prins
>>> _______________________________________________
>>> devel-core mailing list
>>> devel-core_at_[hidden]
> _______________________________________________
> devel-core mailing list
> devel-core_at_[hidden]