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


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.


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,

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.


Tim Prins
devel-core mailing list

devel-core mailing list

Reply via email to