bug#27850: gnu: mpi: openmpi: Don't enable thread-multiple

[ludo@gnu.org (Ludovic Courtès)]

Hello Dave,

Sorry for the looong delay!

Dave Love <fx@gnu.org> skribis:

> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>>> Maybe, but what about the non-ABI compatibility I expect there is?  (I
>>> don't know whether there's still any penalty from thread-multiple
>>> anyhow; I guess not, as I see it's not the default.) 
>>
>> I propose this because you had written that the “performance penalty for
>> thread-multiple is supposed to be mitigated in the most recent openmpi.”
>> If it’s not, then fine.
>
> I don't know the value of "mitigated".  I could ask or, better, measure
> when I get back from holiday (at least micro-benchmarks over
> Infiniband).

OK, makes sense.  I asked an Open MPI developer here at work and they
confirmed that it’s reasonable to assume that thread-multiple support
has some overhead.

I went ahead and applied the patch you posted, minus the extra outputs,
and without ‘string-append’ in the description (which prevents l10n).

>> What do you have in mind for SLURM?
>
> There's integration with SLURM (--with-slurm), PBS/Torque, and LSF (or,
> I guess, Open Lava in the free world).  I don't know much about them,
> but they build MCA modules.  Unlike the gridengine support, they link
> against libraries for the resource managers, so you want them to be
> add-ons which are only installed when required (not like the Fedora
> packaging).

I see.  I suppose we could make them separate outputs to avoid the
overhead, if that’s justified?

> I hope I can give useful feedback, and any criticism is meant
> constructively.  However, I'm not representative of UK HPC people --
> happier to use functional Scheme than Python, and believing in packaging
> for a start!

Got it!

Thank you,
Ludo’.