[gmx-users] GMX-PLUMED speed
pall.szilard at gmail.com
Tue Feb 7 18:23:19 CET 2017
PS: I cam across the claim in the PLUMED docs  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!
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.
> 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
>>> 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
>>> I hope this helps.
>>> Gromacs Users mailing list
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>> * 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.
More information about the gromacs.org_gmx-users