[gmx-developers] Small hack regarding dihedrals

Mark Abraham 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
> code?
>
> 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,
maybe automatic.

Mark

> Thanks
>
> Murat
>
>
> 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.
>>
>> Cheers,
>>
>> Berk
>>
>>
>> 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.
>>
>> Murat
>>
>>
>> On Thu, Sep 26, 2013 at 12:10 AM, Bogdan Costescu <bcostescu at gmail.com>
>> wrote:
>>>
>>> On Wed, Sep 25, 2013 at 5:29 PM, MURAT OZTURK <murozturk at ku.edu.tr>
>>> wrote:
>>> > 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)
>>>     continue;
>>>   ...
>>> }
>>>
>>> Please note the comparison done on the squares of distances instead of
>>> distances, saving some CPU cycles.
>>>
>>> Good luck!
>>> Bogdan
>>> --
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>> 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
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> 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
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> 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 mailing list