[bug#27905] changes for openmpi

[Dave Love]

Ludovic Courtès <address@hidden> writes:

> Hi Dave,
>
> Dave Love <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> writes:
>>
>>>> * mpi.scm (hwloc)[outputs]: Replace lib with nogui.
>>>> (hwloc)[arguments]: Change configure --prefix; use "nogui" output,
>>>> not "lib"; populate "all" output.
>>>> (openmpi)[inputs]: Use hwloc-nogui.
>>>
>>> The downside of this is that the “nogui” output is less discoverable
>>> (and it’s another user-visible breakage.)
>>
>> I don't think that's a problem, as people who want to avoid the GUI
>> stuff will look for an alternative.
>>
>>> Also, it shouldn’t make any difference to the closure size of openmpi
>>> anyway, no?
>>
>> No, but I think you should be able to run the hwloc programs on compute
>> nodes without requiring X support, and you sometimes need to run openmpi
>> programs specifically with openmpi (for memory affinity, for instance).
>
> OK so the gain over the current status (with the “lib” output) is that
> people would be able to get, say, ‘hwloc-bind’, without getting the full
> ‘lstopo’ and its dependencies, right?

Right.

> I guess that makes sense, though at the same time ‘lstopo’ is probably
> the most widely used program in hwloc.

I'm surprised at that, since it's something you'd only normally run once
on a node, and I'd normally only have the nogui variant on them anyhow.
(You can dump the topology and display it separately if necessary, but
the graphical output is often unwieldy on recent compute nodes -- or
even not-so-recent ones.)

> Perhaps we should keep the
> current “lib” separation, and instead provide an “hwloc-minimal”
> package that does not depend on X11/Cairo?

I've no strong feelings, but I'd still call it "nogui", or similar --
more descriptive.  (Debian calls it -nox and Fedora has hwloc and
hwloc-gui.)  The no-GUI lstopo adds little to the closure.

>>> > +         (add-after 'install 'install-openmpi
>>> > +           (lambda* (#:key outputs #:allow-other-keys)
>>> > +             (let ((dest (format #f "~a/lib/valgrind"
>>> > +                                 (assoc-ref outputs "openmpi"))))
>>> > +               (mkdir-p dest)
>>> > +               (zero?
>>> > +                (system (format #f "mv ~a/lib/valgrind/libmpiwrap* ~a"
>>> > +                                (assoc-ref outputs "out") dest)))))))))
>>> 
>>> Why move it to a separate output?  After all, we can keep it in “out”
>>> since all it costs is the size of libmpiwrap.so, right?
>>
>> That would still pull in valgrind, which drags in a lot else (gdb, perl,
>> python...).  The support isn't commonly used as far as I can tell, and
>> isn't configured by default -- I forgot about the performance hit
>> <https://www.open-mpi.org/faq/?category=debugging#memchecker_overhead>.
>
> The hunk above is within Valgrind, so I don’t understand what you mean
> by “that would still pull in valgrind.”

Sorry -- confused by the time lag.  The rationale was that it either
depends upon, or needs when it's used -- I can't remember -- the rest,
which involves gdb's closure.

I'm happy to drop libmpiwrap support anyhow, at least until another MPI
might need it, if I was wrong that the openmpi built-in is a performance
issue.  Apologies for the misinformation and wasted time, though it was
based on what's on the openmpi web site.

> My suggestion was to:
>
>   1. Remove Valgrind from the inputs of Open MPI;
>   2. Not add the ‘install-openmpi’ phase above to Valgrind.
>
> Does that make sense?
>
> Thank you,
> Ludo’.