--- Begin Message ---
|
Subject: |
gnu: mpi: openmpi: Don't enable thread-multiple |
|
Date: |
Thu, 27 Jul 2017 16:01:59 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
The performance penalty for thread-multiple is supposed to be mitigated
in the most recent openmpi, but not in this version, and most
applications are happy with MPI_THREAD_FUNNELED.
0001-gnu-mpi-openmpi-Don-t-enable-thread-multiple.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#27850] gnu: mpi: openmpi: Don't enable thread-multiple |
|
Date: |
Mon, 21 Aug 2017 15:17:57 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hello Dave,
Sorry for the looong delay!
Dave Love <address@hidden> skribis:
> Ludovic Courtès <address@hidden> 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’.
--- End Message ---