<div dir="ltr"><div>Hi,</div><div><br></div><div>Jan, the biggest bang-for-buck optimizations relevant to Folding@Home are to</div><div><br></div><div>a) offer to build them an OpenCL-enabled GROMACS &quot;core&quot; (ie the version of GROMACS that they run, when they run GROMACS). Currently they seem to run all GPU jobs with OpenCL and OpenMM, which is nice but leaves a lot of throughput on the table. The GROMACS OpenCL port is mature and stable, runs on AMD/NVIDIA/Intel current GPUs, and should present no more driver/user problems than their OpenMM one. Their concept of a GPU slot is a single GPU accompanied by a single CPU thread/, whereas the GROMACS OpenCL port would prefer multiple dedicated cores. That&#39;s still better than leaving GPUs empty if there&#39;s not enough OpenMM jobs in the queue, though the actual performance will be woeful compared to GROMACS when you give it a healthy chunk of CPU cores also. Could even be better than OpenMM&#39;s GPU core, depending how modern that one is, too ;-) The GROMACS CUDA port is better still (and in 2020 can do a decent job even with only a single CPU core), but they have made a philosophical choice to use OpenCL only.<br></div><div> b) update the GROMACS CPU core  in F@H because the one used in F@H is several years behind and losing the benefit of the hard optimization work that we&#39;ve done in the meantime.</div><div>c) demonstrate that they can maintainably and usefully offer more than two x86 builds of that GROMACS CPU core (GROMACS has lots of SIMD specialized flavours, but F@H only offers SSE4.1 and basic AVX from those flavours, which leaves a lot of performance on the table on recent x86 CPUs. We already have all the logic needed to work out which pre-built GROMACS to download and run, because we use it in containerized GROMACS builds also.)<br></div><div><br></div><div>Unfortunately they&#39;ve never open-sourced any of that, so finding out where to start is the first challenge. But that way you&#39;ll have a lot more impact sooner than you will from profiling GROMACS runs after 30 years of optimization. ;-)</div><div><br></div><div>Mark<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 23 Mar 2020 at 14:59, jan &lt;<a href="mailto:rtm443x@googlemail.com">rtm443x@googlemail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
I&#39;m a general back-end dev.  Given the situation, and folding@home<br>
using gromacs, I thought I&#39;d poke through the code. I noticed<br>
something unexpected, and was advised to email it here. in edsam.cpp,<br>
this:<br>
<br>
<br>
void do_linacc(rvec* xcoll, t_edpar* edi)<br>
{<br>
    /* loop over linacc vectors */<br>
    for (int i = 0; i &lt; edi-&gt;vecs.linacc.neig; i++)<br>
    {<br>
        /* calculate the projection */<br>
        real proj = projectx(*edi, xcoll, edi-&gt;vecs.linacc.vec[i]);<br>
<br>
<br>
        /* calculate the correction */<br>
        real preFactor = 0.0;<br>
        if (edi-&gt;vecs.linacc.stpsz[i] &gt; 0.0)<br>
        {<br>
            if ((proj - edi-&gt;vecs.linacc.refproj[i]) &lt; 0.0)<br>
            {<br>
                preFactor = edi-&gt;vecs.linacc.refproj[i] - proj;<br>
            }<br>
        }<br>
        if (edi-&gt;vecs.linacc.stpsz[i] &lt; 0.0)<br>
        {<br>
            if ((proj - edi-&gt;vecs.linacc.refproj[i]) &gt; 0.0)<br>
            {<br>
                preFactor = edi-&gt;vecs.linacc.refproj[i] - proj;<br>
            }<br>
        }<br>
       [...]<br>
<br>
<br>
In both cases it reaches the same code<br>
<br>
  preFactor = edi-&gt;vecs.linacc.refproj[i] - proj<br>
<br>
That surprised me a bit, is it deliberate? If so it may be the code<br>
can be simplified anyway.<br>
<br>
That aside, if you&#39;re looking for performance I might be able to help.<br>
I don&#39;t know the high level stuff *at this point* and my C++ is so<br>
rusty it creaks, but I can brush that up, do profiling and whatnot.<br>
I&#39;m pretty experience, just not in this area.  Speeding things up is<br>
something I&#39;ve got a track record of (though I usually have a good<br>
feel for the problem domain first, which I don&#39;t here)<br>
<br>
Would it be of some value for me to try getting more speed? If so,<br>
first thing I&#39;d need is to get this running under cygwin, which I&#39;m<br>
struggling with.<br>
<br>
regards<br>
<br>
jan<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div>