[gmx-users] GMX-PLUMED speed

[Szilárd Páll]

PS: I cam across the claim in the PLUMED docs [1] that the default i
multi-threading _off_. It seems to also imply that PLUMED ignores the
standard means to set the number of threads (OMP_NUM_THREADS). What
worries me more is this claim:
"The optimum number of threads is not necessary "all of them", nor
should be equal to the number of threads used to parallelize MD."

I advise everyone to be careful with setting PLUMED_NUM_THREADS to
values other than the default set with OMP_NUM_THREADS/-ntomp or 1.
Different "width" parallel regions within the same program _might_
cause slowdowns where you don't expect it. It depends on the behavior
the OpenMP library implements, so it's best to test!

[1] https://plumed.github.io/doc-v2.2/user-doc/html/_openmp.html

--
Szilárd


On Tue, Feb 7, 2017 at 5:56 PM, Szilárd Páll <pall.szilard at gmail.com> wrote:
> For what is worth, I'm not surprised by the impact of PLUMED. It's
> quite easy to ruin the GROMACS performance by doing a ton of serial
> work on a single rank. Unless I'm mistaken, PLUMED does that quite a
> bit and there is very little parallelization -- it does have limited
> multi-threading but no domain decompostion. Hence, the more work
> PLUMED needs to do
>  i) per rank (when mdrun runs with many threads/rank) or
>  ii) on the master rank,
> the higher the impact on simulation performance.
>
> Cheers,
> --
> Szilárd
>
>
> On Sun, Feb 5, 2017 at 11:08 PM,  <jkrieger at mrc-lmb.cam.ac.uk> wrote:
>> Interesting finding. Have you tried leaving out the two options
>> independently? Also would be good to try that with gromacs-2016.
>>
>> What is your system size and cluster usage? This sounds a phenomenal speed
>> as well as speed up.
>>
>> You should probably share this on the plumed google group too.
>>
>> Best wishes
>> James
>>
>>>
>>> Dears,
>>>
>>> I am using gromacs v5.1.4 with PLUMED v2.3.0.
>>>
>>> Through my experience as a novice in using PLUMED, I have noticed that not
>>> writing the restraint/forces info in a file and not using a STRIDE
>>> accelerate the code significantly.
>>>
>>> Using a line such as follows in the plumed parameters set:
>>> PRINT ARG=restraint.bias
>>>
>>> instead of the most correct:
>>> PRINT STRIDE=10000 ARG=restraint.bias FILE=bias
>>>
>>> would make gmx run at 950 ns/day instead of 550 ns/day.
>>>
>>> The inconvenient is that the log file becomes large (all the restraint are
>>> written in it) and messy (the values are mixing with the rest of the info
>>> on exchanges), but the speed up is considerable.
>>>
>>> Note that I still print the values of the restraint in a file, which I
>>> haven’t tried to remove but it could also speed up the run.
>>>
>>> Someone should may be look at this as he speed up applies on XX replicas
>>> so lots of CPU time (cooling system, energy, climat change, …) is
>>> wasted.
>>>
>>> I hope this helps.
>>> X-
>>> --
>>> Gromacs Users mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send
>>> a mail to gmx-users-request at gromacs.org.
>>
>>
>>
>> --
>> Gromacs Users mailing list
>>
>> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-request at gromacs.org.