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).
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.
So don't get me wrong, I'm not pushing for it but I have had quite some
users who saw me as Open MPI and LibNBC developer when Open MPI will
support non-blocking collectives. We had a long discussion about this at
the Paris meeting and decided (for various reasons) to not add
non-blocking collectives directly to the coll modules but rather have
support for LibNBC. So this is already the "light" version of the whole
effort :).
And we do not know how long this MPI-3 standardization process will take.
Best,
Torsten
--
bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Indiana University | http://www.indiana.edu
Open Systems Lab | http://osl.iu.edu/
150 S. Woodlawn Ave. | Bloomington, IN, 474045-7104 | USA
Lindley Hall Room 135 | +01 (812) 855-3608
