I am NOT in favor of bringing LibNBC in the trunk. Some of my concerns
were already stated by Brian and Ralph, and the answers didn't clearly
address all my reticences. I don't want to bring the MPI 3 Forum
discussion on this mailing list, but I think that as long as there is
a lack of the
I am in favor of bringing this in.
- Galen
On Feb 14, 2008, at 1:15 PM, Jeff Squyres wrote:
So I don't think that we ever concluded this discussion/RFC.
I am in favor of bringing in libnbc, given the qualifications below.
Others?
On Feb 8, 2008, at 12:16 PM, Jeff Squyres wrote:
Terry --
So I don't think that we ever concluded this discussion/RFC.
I am in favor of bringing in libnbc, given the qualifications below.
Others?
On Feb 8, 2008, at 12:16 PM, Jeff Squyres wrote:
Terry -- I reluctantly agree. :-) What I envision is not difficult
(a first cut/feature-lean version is
Terry -- I reluctantly agree. :-) What I envision is not difficult
(a first cut/feature-lean version is probably only several hundred
lines of perl?), but I don't have the cycles (at present) to implement
it -- my priorities are elsewhere at the moment.
If anyone is interested in this, I
Jeff, the below sounds good if we really believe there is going to be a
whole bunch of addons. I am not sure NBC really constitute as an addon
than more some research work that might become an official API. So I
look at the NBC stuff more like a BTL or PM that is in progress of being
develope
I think your proposed approach is an excellent one! I know it will take work
to implement, which raises its own issues, but I do believe that it is the
only real long-term solution.
Just my $0.002. I would be willing to help with implementation, if that
would be of use. Not sure I understand the b
All these comments are good. I confess that although I should have, I
really did not previously consider the complexity of adding in N
contrib packages to OMPI.
The goal of the contrib packages is to easily allow additional
functionality that is nicely integrated with Open MPI. An obvious
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 c
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 repl
Hi Ralph,
> I don't have an opinion either way on this specific proposal. However, I do
> have a growing concern over the number of packages being added to the
> system, all of which want to "build by default". The build time is already
> long and rapidly growing, and our code distribution is corre
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]
> Doe
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-blockin
Hi Torsten
I don't have an opinion either way on this specific proposal. However, I do
have a growing concern over the number of packages being added to the
system, all of which want to "build by default". The build time is already
long and rapidly growing, and our code distribution is correspondi
Hi folks,
WHAT:
Merge the htor-nbc branch to the trunk. This branch adds LibNBC support
to Open MPI (via compiler-wrappers mpi{cc,CC,xx,f90,..
14 matches
Mail list logo
