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