On Thu, Dec 18, 2014 at 2:27 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com
> wrote:

> On Dec 17, 2014, at 9:52 PM, George Bosilca <bosi...@icl.utk.edu> wrote:
>
> >> I don't understand how MPIX_<something> is better.
> >>
> >> Given that there is *zero* commonality between any MPI extension
> implemented between MPI implementations, how exactly is having the same
> prefix any less confusing?
> >
> > This is an overstatement. There were quite a few examples over the last
> few years (PERUSE, libNBC, ULFM). They all took different approaches for
> the naming of their functions, increasing the potential users confusion. As
> a developer for one of these MPI extensions I would rather go with a unique
> naming scheme to free our users from the hassle of the name checking.
>
> PERUSE and libNBC were both exposed through actual MPI functions -- not
> extensions.
>

No, they we both exposed in the most convenient way for users: PERSUE_* and
NBC_*.

If you put ULFM in ompi/mpiext, we don't have a strict policy on the
> exposed extension symbols, that's true.  But FWIW, the existing ones that
> are in the OMPI github tree are all OMPI_* symbols.
>
> All this being said, if your *real* complaint is that you want the same
> prefixes for ULFM between OMPI and MPICH, then great -- use MPIX in both.
> That's an entirely different case than what I have been talking about
> because you *do* have the same functions/behavior in multiple MPI
> implementations.
>

I had no complaint. I simply made a statement based on my prior experience
as a developer of two such extensions, extensions that 1) have (or had) a
reasonable number of users; and 2) were useful enough to be finally
supported by multiple open source MPI implementations.

We made little progress over the last couple of [extremely long] emails and
the original topic diverged and got diluted. Lets hold on our discussion
here and let Nick, Keita and the others go ahead and complete their work.
We can fiddle over the naming scheme during our face-to-face meeting in
January.

  George.

My point is that if we have OMPI-specific extensions (which most likely
> will be), then having an OMPI_ prefix is a Good Thing because it clearly
> identifies them as belonging to OMPI, not other MPI implementations.


> >> My point is that using an extension is inherently non-portable.  The
> chances for <something> to collide between different MPI implementations is
> actually quite high.  Indeed, if everyone uses MPIX_<something>, then
> there's a very real possibility that MPIX_Foo != MPIX_Foo != MPIX_Foo.
> That's *horrible*.
> >
> > Horrible sure, but highly improbable (function names have a meaning)
>
> I think we're being being subjective here -- there's no real way to
> quantify this.  We might have to agree to disagree on this point.
>
> One real place that MPI implementations may collide on extension names are
> symbols for upcoming/new functions (e.g., MPI-4 functions).  MPICH, for
> example, put the NBCs in as MPIX_Ibarrier (etc.) before MPI-3 was formally
> passed.  OMPI, however, just put those functions in as MPI_Ibarrier() -- we
> never marked them as MPIX.  I.e., we wanted until the NBCs were formally
> voted in and then put them in as their final names.
>
> The rationale for this approach so that a) we waited until it was pretty
> certain that these functions were final final final, and b) people could
> start using the functions immediately without having to worry about whether
> they are named MPIX_foo or MPI_foo.
>
> If OMPI continues this policy, then OMPI/MPICH won't collide on these
> names.
>
> >> -----
> >> #if defined(OPEN_MPI) && OPEN_MPI
> >>   OMPI_Foo(a,b,c);
> >> #endif
> >>
> >> ...
> >>
> >> #if defined(MPICH) && MPICH
> >>   MPIX_Foo(f,e,d,c,b,a);
> >> #endif
> >> -----
> >
> > This is horrible! This is the kind of solution that neither a developer
> or a user of such an extension would promote.
>
> Er... regardless of whether the OMPI extension begins with MPIX_ or OMPI_,
> how does that change the above code pattern?
>
> Extensions are *always* potentially non-portable.
>
> >> I guess my fundamental question is: why impose commonality of names
> where there is no commonality of function signature and behavior?
> >
> > The overarching goal of an MPI extension is to show the interest of the
> approach and eventually become part of the standard.
>
> I guess we disagree there.  There's been 2 OMPI extensions that have
> existed for several releases that have no intention of ever going into the
> standard.
>
> > A well designed extension will have a unique function signature and
> behavior, not only across different implementations but across different
> versions.
>
> ...er... by definition, any given implementation cannot guarantee that.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2014/12/26037.php
>

Reply via email to