Just to drop in, I can/and will provide whatever interface you want (if you want my contribution).
However just to help my ignorance, 1. Adam Moody's method still requires a way to create a distinguished string per processor, i.e. the spilt is entirely done via the string/color, which then needs to be deciphered by the coder. This seems to me to be more cumbersome than just providing the level of split dependent on HW type? 2. My implementation does this via hwloc locality designators, hence it is a generic interface for "all" hardware types. This seems like a more generic way of dividing communicators compared to Adam's. Without having the user to figure out where the processors are located. Or did I miss something? This is not to say that one or the other is superior, I just see two different ways of creating communicators. Adams is full user control, using hwloc is fully hardware determined, or should be. Secondly, do you think there is something wrong with the code as the splitting did not take into account the L3 cache and socket correctly? 2014-12-02 15:56 GMT+01:00 Jeff Squyres (jsquyres) <jsquy...@cisco.com>: > On Dec 2, 2014, at 1:10 AM, George Bosilca <bosi...@icl.utk.edu> wrote: > > >> Are you referring to something Adam Moody proposed? Or some other Adam? > > > > He did more than proposing, he provided a link to the implementation in > SCR. So yes, I was indeed referring to Adam Moody. > > Ah -- you're referring to > http://www.open-mpi.org/community/lists/users/2014/11/25871.php. Got it. > > >> FWIW, we’ve traditionally named Open MPI-specific extensions "OMPI_" > instead of "MPIX_" (which can be confused with other MPI implementation > extensions). > > > > Indeed, it was a choice we made long ago. Thinking about this > retroactively it was a bad choice. We (UTK) maintain some of the > extensions, and as other MPI libraries start providing similar extensions > (while they are discussed in the MPI Forum), users start asking for a > common naming scheme in order to simplify their life. > > I've talked to users who ask for the opposite -- since MPI extensions are, > by definition, specific to a particular MPI implementation, they > specifically asked for OMPI MPI extensions to *not* be MPIX_*, because then > it's easy to identify that it's an Open MPI extension (vs. an extension for > some other MPI implementation). > > > Other than a preferential reason, what other competing reason do we have > to stick with OMPI_ instead of MPIX_? > > I think it's largely informal, so we can do whatever we want. > > The namespace MPIX_ is not regulated (nor mandated), so there's > possibilities for collisions, which would be pretty dreadful for users. > > I like the OMPI_ prefix because it clearly identifies the function as > specific to Open MPI (i.e., you really should enclose it in #if > defined(OPEN_MPI) / #endif). > > If you/users really want MPIX_, how about: use OMPI_Foo as the "real" > name, and have alternate entry points via MPIX_Foo? (via #define, wrapper > functions, or whatever) > > Then we all win. Huzzah! > > -- > 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/25902.php > -- Kind regards Nick
