I believe Brian and Terry raise good points. May I offer a possible alternative? What if we only include in Open MPI an include file that contains the "hooks" to libNBC, and have the build system only "see" those if someone specifies --with-NBC (or whatever option name you like). If you like, you can make the inclusion automatic if libNBC is detected on the system. It would make sense to also add -libNBC to the mpicc et al wrappers as well when the build system includes the function definitions.
This would allow those users that want (or can) to use that library link against it, without adding a bunch of source code to our release. I suspect there are complications that will have to be dealt with, but offer it as something to consider. Also, remember that there is an added burden when we add source code to Open MPI that we haven't discussed - we are now adding coordination issues to our own release cycle. If libNBC changes, are we now going to be pressed to issue another OMPI release so that the new NBC version is included? Do we now need to coordinate our releases with theirs so that things align? And if we have an increasing number of such "included" packages, how complex is -that- release discussion going to get?!? On 2/7/08 4:48 AM, "Terry Dontje" <terry.don...@sun.com> wrote: > Torsten Hoefler wrote: >> Hi Brian, >> >>> Let me start by reminding everyone that I have no vote, so this should >>> probably be sent to /dev/null. >>> >> thanks for your comment and this will not go to /dev/null! >> >> >>> I think Ralph raised some good points. I'd like to raise another. >>> >> yes [will reply to this in a separate thread] >> >> >>> Does it make sense to bring LibNBC into the release at this point, >>> given the current standardization process of non-blocking collectives? >>> >>> My feeling is no, based on the long term support costs. We had this >>> problem with a function in LAM/MPI -- MPIL_SPAWN, I believe it was -- >>> that was almost but not quite MPI_COMM_SPAWN. It was added to allow >>> spawn before the standard was finished for dynamics. The problem is, >>> it wasn't quite MPI_COMM_SPAWN, so we were now stuck with yet another >>> function to support (in a touchy piece of code) for infinity and beyond. >>> >>> I worry that we'll have the same with LibNBC -- a piece of code that >>> solves an immediate problem (no non-blocking collectives in MPI) but >>> will become a long-term support anchor. Since this is something we'll >>> be encouraging users to write code to, it's not like support for >>> mvapi, where we can just deprecate it and users won't really notice. >>> It's one thing to tell them to update their cluster software stack -- >>> it's another to tell them to rewrite their applications. >>> >> I think this is a very good and valid point. However, I would like to >> deprecate the NBC_* things as soon as non-blocking collectives are a >> part of the standard. Of course, this would probably need two minor >> versions to "clean" the code-base, but this is (will be) our normal >> procedure (just what happened to MVAPI). >> >> > Though it doesn't seem to me that NBC is a slam dunk to get into the MPI > spec and I could > imagine it changing significantly due to someone elses opinion/needs. >> And rewriting the user's application will not be that hard, it'll mainly >> be vim:%s/NBC_/MPI_/g. Even if we change the interface (e.g. add tags or >> decide to use the more limited split collective approach), this task is >> rather easy and can be automated easily. It's not a functionality >> change, just an interface. >> >> > Though if NBC is built by default for release builds I think that raises > the bar saying that we > OMPI believe this should be used by all of our users without any > concerns that the API may > change or it might have significant issues. > > On a similar track do you have any tests that validate the > functionality/correctness of NBC > that can be ran as a part of the MTT nightly tests? > > My opinion is I have no problem with NBC being merged in just that I > don't think it should be > built by default. > > --td > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
