[gmx-developers] slightly odd-looking code

Szilárd Páll pall.szilard at gmail.com
Mon Mar 23 15:54:56 CET 2020


Jan,

If you want to profile and try to tune performance, I suggest you focus on
the main simulation tool called "mdrun" and in particular its core
functionalities as this is the tool that will be consuming the vast
majority of compute cycles.

If you are using profiling tools to explore the code, find hot functions
and such, I suggest that you grab one of the benchmark systems from here:
http://ftp.gromacs.org/benchmarks/
and run one of those (make sure to pick a "PME" input if there are
multiple).

And start by running those through a profiler ( e.g. run "gmx mdrun -s
topol.tpr -nsteps 1000" for a 1000-iteration run). If you are proficient at
profiling tools, you can also drop in manual annotation (or profiler
start/stop) into out internal timer/profiler facilities (see
src/gromacs/timing/wallcycle.cpp).

Let us know if you have further questions.

Cheers,
--
Szilárd


On Mon, Mar 23, 2020 at 3:36 PM jan <rtm443x at googlemail.com> wrote:

> Hi, see below
>
> On 23/03/2020, cblau <cblau at gwdg.de> wrote:
>
> [snip]
> >
> > As GROMACS is already highly specialised, it is a bit challenging to
> > speed up quickly (though definitely possible to contribute in meaningful
> > ways).
>
> My initial look is profile then see look at the most basic things such
> as memory hierarchy use. I mean, really basic stuff which you'll
> already have covered but at least it's a learning phase for me.
>
> >
> > With all urgency in mind, there is quite a time-delay in the way new
> > code gets incorporated, because we do very much require scientific
> > correctness and thorough code review to make sure that all simulation
> > results are meaningful and we don't waste a ton of people efforts and
> > compute power on a slight bug.
>
> Is good
>
> >
> > The largest speed up in a short time frame (the next months) is inmy
> > option achieved by teaching people how to use GROMACS in the most
> > efficient ways and make sure that people running simulations run them
> > correctly.
>
> Knowing how to use a tool correctly is best way to get good results. I
> keep seeing the results where this does not happen. So I get you.
> I'll look on the site for reading material but any other pointers
> would help - but bear in mind I'm very new to this, and numerical
> simulation isn't my thing so start simple!
>
> >
> > If you like, we can briefly chat tomorrow on how GROMACS is set up and
> > the "usual ways" to contribute to GROMACS if you send me a personal
> email.
> >
>
> Will do
>
> thanks
>
> jan
>
>
> >
> > Best,
> > Christian
> >
> > On 2020-03-23 14:58, jan wrote:
> >> Hi,
> >> I'm a general back-end dev.  Given the situation, and folding at home
> >> using gromacs, I thought I'd poke through the code. I noticed
> >> something unexpected, and was advised to email it here. in edsam.cpp,
> >> this:
> >>
> >>
> >> void do_linacc(rvec* xcoll, t_edpar* edi)
> >> {
> >>      /* loop over linacc vectors */
> >>      for (int i = 0; i < edi->vecs.linacc.neig; i++)
> >>      {
> >>          /* calculate the projection */
> >>          real proj = projectx(*edi, xcoll, edi->vecs.linacc.vec[i]);
> >>
> >>
> >>          /* calculate the correction */
> >>          real preFactor = 0.0;
> >>          if (edi->vecs.linacc.stpsz[i] > 0.0)
> >>          {
> >>              if ((proj - edi->vecs.linacc.refproj[i]) < 0.0)
> >>              {
> >>                  preFactor = edi->vecs.linacc.refproj[i] - proj;
> >>              }
> >>          }
> >>          if (edi->vecs.linacc.stpsz[i] < 0.0)
> >>          {
> >>              if ((proj - edi->vecs.linacc.refproj[i]) > 0.0)
> >>              {
> >>                  preFactor = edi->vecs.linacc.refproj[i] - proj;
> >>              }
> >>          }
> >>         [...]
> >>
> >>
> >> In both cases it reaches the same code
> >>
> >>    preFactor = edi->vecs.linacc.refproj[i] - proj
> >>
> >> That surprised me a bit, is it deliberate? If so it may be the code
> >> can be simplified anyway.
> >>
> >> That aside, if you're looking for performance I might be able to help.
> >> I don't know the high level stuff *at this point* and my C++ is so
> >> rusty it creaks, but I can brush that up, do profiling and whatnot.
> >> I'm pretty experience, just not in this area.  Speeding things up is
> >> something I've got a track record of (though I usually have a good
> >> feel for the problem domain first, which I don't here)
> >>
> >> Would it be of some value for me to try getting more speed? If so,
> >> first thing I'd need is to get this running under cygwin, which I'm
> >> struggling with.
> >>
> >> regards
> >>
> >> jan
> >>
> > --
> > Gromacs Developers mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developers
> or
> > send a mail to gmx-developers-request at gromacs.org.
> >
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_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-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20200323/0ce73d45/attachment-0003.html>


More information about the gromacs.org_gmx-developers mailing list