[gmx-developers] Small hack regarding dihedrals
mark.j.abraham at gmail.com
Thu Sep 26 10:18:03 CEST 2013
On Thu, Sep 26, 2013 at 9:25 AM, MURAT OZTURK <murozturk at ku.edu.tr> wrote:
> Are you referring to the pdihs_noener_simd() function?
> It seems that there is a "#define SIMD_BONDEDS" instruction that is just for
> this job? If I delete that line, does the SIMD functionality go away? If
> not, where exactly does the code decide whether to use SIMD functions? Can I
> disable SIMD selectively for dihedrals only?
> Also, would it be preferable to use 4.6 and disable SIMD, or go back to 4.5
> and do the hack over there, performance wise? I understand 4.5 has many
> native assembly loops, whereas 4.6 takes advantage of the compiler, so if I
> am going to disable SIMD, is it better to use the 4.5 version with native
> I am probably going to be locked into 1 or 2 cores with this system, so I
> need to squeeze the maximum out of them.
I would leave all of that alone. Look at the code that dispatches
pdihs* functions and use a conditional to trigger the modified C
kernel when that is what you want. You may find life easier if you
derive a new proper dihedral type, based on type 1 but with a higher
number. Now your topology can encode which dihedral function gets
called. Presumably that will make avoiding the SIMD code path easier,
> On Thu, Sep 26, 2013 at 10:02 AM, Berk Hess <hess at kth.se> wrote:
>> But note that in 4.6 with SIMD (SSE/AVX) enablebd, dihedrals mostly (when
>> only forces, no energies are needed) get calculated by a special SIMD
>> dihedral function. You will need modifiy the conditional such that the plain
>> C function always gets called.
>> On 09/26/2013 08:04 AM, MURAT OZTURK wrote:
>> Thank you very much. I need to build a toy system to test it, but sounds
>> just about right. I might even hard-code the square of threshold to save
>> another flop, following your philosophy. A flop is a flop :)
>> Again, thank you.
>> On Thu, Sep 26, 2013 at 12:10 AM, Bogdan Costescu <bcostescu at gmail.com>
>>> On Wed, Sep 25, 2013 at 5:29 PM, MURAT OZTURK <murozturk at ku.edu.tr>
>>> > Is it OK to intorduce the conditional into pdihs(), and bypass even
>>> > calling
>>> > dopdihs() if r_kj ( as reported by calling dih_angle() ) is less then
>>> > threshold?
>>> Yes. It makes sense to abort calculating as soon as you have enough
>>> information to make the decision. You can place your test immediately
>>> after calling dih_angle(), as it gives you r_jk. The code could look
>>> like (based on your own proposal):
>>> /* outside of the loop */
>>> threshold2 = threshold * threshold;
>>> for (i = 0; (i < nbonds); )
>>> phi = dih_angle(...)
>>> midDist2 = iprod(r_jk, r_jk);
>>> if (midDist2 > threshold2)
>>> Please note the comparison done on the squares of distances instead of
>>> distances, saving some CPU cycles.
>>> Good luck!
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> Please don't post (un)subscribe requests to the list. Use the
>>> www interface or send it to gmx-developers-request at gromacs.org.
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
> gmx-developers mailing list
> gmx-developers at gromacs.org
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
More information about the gromacs.org_gmx-developers