[gmx-developers] slightly odd-looking code

[jan]

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