I have been following this being very interested, I will create a PR for my branch then.
To be clear, I already did the OMPI change before this discussion came up, so this will be the one, however the change to other naming schemes is easy. 2014-12-19 7:48 GMT+00:00 George Bosilca <bosi...@icl.utk.edu>: > > 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 >> > > > _______________________________________________ > 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/26038.php > -- Kind regards Nick
