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
