guix-patches
[Top][All Lists]
Advanced

[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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]