Let me start by reminding everyone that I have no vote, so this should
probably be sent to /dev/null.
I think Ralph raised some good points. I'd like to raise another.
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.
Just my $0.02,
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
