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 correspondingly
increasing in size.
I therefore would like to raise two areas for thought:
1. Do we need to, at some point, begin to ask if all these packages -have-
to be included as source code in our code base? Can we devise a means such
that people could download them separately and link the libraries to us in
some other fashion?
I only ask the community to consider because we seem to be developing a
mindset whereby everything "looks good" and/or is wanted by "someone". If we
continue down the path of adding everything that someone might find
interesting, one could envision code releases in the GBytes, taking more
than an hour to configure and build as every conceivable package "builds by
default".
2. Have we applied the "rational thought" filter here - i.e., are we
building by default what a large percentage of the user community will use,
or are we building by default all things that somebody, somewhere, someday
-might- use? If the latter, is that really how we want to define the
"default" build?
I'm not proposing solutions as I don't know the answers. I only wonder if we
have really thought about what is happening, and if we need to begin
thinking about alternative approaches.
For example, as a first step on #2, wouldn't it make more sense to at least
have the build system -not- build some things by default when in "developer"
mode, but build by default when doing an optimized installation? This would
save those of us who have to build frequently from all the time penalties of
building things we have no use for in our daily work (which is becoming a
significant part of the code base), while retaining this "build everything
conceivable" approach. I suggest this only because, while I certainly -can-
turn it all "off", the number of options required to turn off all these
unneeded "default" code areas is becoming large, and constantly seems to be
growing.
Just some thoughts to ponder...
Ralph
On 2/6/08 2:14 PM, "Torsten Hoefler"
<torsten.hoef...@informatik.tu-chemnitz.de> wrote:
> 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,...}-nbc.
>
>
> WHY:
> Users asked for it - this will enable to use non-blocking collective
> operations with Open MPI easily.
>
>
> WHEN:
> Before 1.3 closes
>
>
> TIMEOUT:
> I will do the merge at February 13th if no one opposes.
>
>
> DESCRIPTION:
> LibNBC implements non-blocking collective operations in an MPI-style. It
> was planned that Open MPI supports this extension as MPIX_<collective>.
> However, this would require another MPIX_{Test,Wait} which might collide
> with any MPIX_ extensions (cf. Generalized Requests). So we decided on
> the Paris meeting last year that we just import LibNBC and keep the NBC_
> namespace which should not collide with anything and enables portability
> without code-changes (since LibNBC can be linked with any MPI).
>
> More information on LibNBC is available in "Implementation and
> Performance Analysis of Non-Blocking Collective Operations for MPI" and
> on http://www.unixer.de/research/nbcoll/ .
>
> Impact to the code base:
> The impact will be minimal because LibNBC will be added as a third-party
> library (like vt) in ompi/contrib/libnbc. Jeff did all the build-system
> magic to get LibNBC's configure script called after ompi is built. So
> this glue-code is also minimal.
>
> Impact on compilation time:
> The implementation will be compiled and installed by default (unless it
> disables itself during configure).
>
> Impact on running time:
> No impact since it just offers additional functionality. No Open MPI
> functionality will be changed. It is also only linked if those calls are
> actually used. The command-line arguments are only added if the user
> uses the -nbc mpi-compiler wrapper. However, using the calls does not
> necessarily mean that the library achieves any overlap (this depends on
> the network and also Open MPI's configuration, e.g., leave_pinned for
> InfiniBand).
>
> Best,
> Torsten
>
>
