[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27850] gnu: mpi: openmpi: Don't enable thread-multiple
From: |
Ludovic Courtès |
Subject: |
[bug#27850] gnu: mpi: openmpi: Don't enable thread-multiple |
Date: |
Tue, 01 Aug 2017 19:39:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hi Dave,
Dave Love <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>> Dave Love <address@hidden> skribis:
>>
>>> Ludovic Courtès <address@hidden> writes:
>>
>> [...]
>>
>>>>> (arguments
>>>>> `(#:configure-flags `("--enable-static"
>>>>>
>>>>> - "--enable-mpi-thread-multiple"
>>>>
>>>> Should we upgrade our openmpi package instead of doing this?
>>>
>>> I don't know whether they've fixed all the breakage I knew about in
>>> OMPI 2 or whether there's still any penalty from thread-multiple. 1.10
>>> seems fairly safe, but I don't have strong opinions if people think 2 is
>>> solid. Apart from ABI incompatibility, I assume it has the usual
>>> incompatibilities at the mpirun/MCA level, and that they aren't well
>>> documented.
>>
>> ABI compatibility is normally not an issue with Guix, so I’d be in favor
>> of upgrading to 2.0.3. Would you like to do it?
>
> 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.
> 2.1 probably also needs non-trivial work in figuring out whether it
> still needs a bundled libevent, for instance.
Sure, that’s packaging. :-)
> If anyone's using it seriously, I'd have thought effort would be better
> spent on support for SLURM (as it's in Guix) and supporting
> high-performance fabrics (which I started on).
You already mentioned openfabrics a couple of times I think. Mentioning
it more won’t turn it into an actual package. :-) It’s on my to-do
list, I guess it’s on yours too, so we’ll get there.
What do you have in mind for SLURM?
As for “using it seriously”, I think this is a needlessly aggressive way
to express your frustration. People *are* using Guix “seriously” in HPC
already, but (1) different application domains emphasize different
aspects of “HPC”, and (2) there’s on-going work to improve Guix for HPC
and your feedback is invaluable here.
HTH,
Ludo’.