[gmx-developers] Verlet-Tables integration

David van der Spoel spoel at xray.bmc.uu.se
Sat Nov 17 09:21:05 CET 2018 

Den 2018-11-16 kl. 23:26, skrev Erik Lindahl:
> I think that would kill performance. Tables are very sensitive to memory trashing (since they easily exhaust cache) so we want to keep the number as low as humanly possible. Similarly, for the verlet kernels it will likely be reasonably efficient to do 4x4 lookups for distances that are similar, but very bad to have to load 4x4 different tables.
This is why I proposed to have one table per neighborlist, but have many 
neighborlists. This keeps the innerloops simpler.

Also having one table for Van der Waals rather than two, and not having 
to look up the C6 and C12 should help a bit.
> 
> Tables are simply not very compatible with SIMD, although it’s a bit better with GPUs. But, overall I think It might be worth more looking into dynamically compiled analytical functions - processors are getting so fast that flops are almost free, but memory access painful.
It depends on the analytical function :) If using Slaters they may end 
up being a couple of thousand lines of code.

Finally, if flops are almost free, what is the problem with using sqrt 
instead of invsqrt, in particular for table lookups?
> 
> Cheers,
> 
> Erik
> 
> --
> Erik Lindahl <erik.lindahl at scilifelab.se>
> Professor of Biophysics
> Science for Life Laboratory
> Stockholm University & KTH
> Office (SciLifeLab): +46 8 524 81567
> Cell (Sweden): +46 73 4618050
> Cell (US): 1 267 307 8746
> 
> 
>> On Nov 16, 2018, at 11:10 PM, David van der Spoel <spoel at xray.bmc.uu.se> wrote:
>>
>>> Den 2018-11-14 kl. 09:11, skrev Berk Hess:
>>> Hi,
>>> I don't really think we need a usecase, but more people motivated to work on it.
>>> We have delayed the work also because we are waiting for a new non-bonded kernel structure. But we just as well start without that, since it will not take much work to port the additional tabulated kernels to a new framework.
>>> What is a dependency is a selecting the table index based on atom type (pairs). We want to get rid of the (mis)use of energy groups for this purpose in the group scheme.
>>
>> We can even do some small optimizations: if we have tables based on atomtype pairs, we do not need separate dispersion and repulsion tables anymore and we can put the force constants in the table as well. Although the large amount of tables will make it memory inefficient, the inner loop will be simpler. One could also make one neighborlist per atomtype pair, such that only one table goes to the innerloop and no atomtypes have to be looked up either. Of course the neighborlists would be shorter.
>>
>>> Cheers,
>>> Berk
>>>> On 13/11/2018 23.53, Mark Abraham wrote:
>>>> Hi,
>>>>
>>>> Not much has happened. I did some basic cleanup, and Erik has worked on some table classes in src/gromacs/tables. Alfredo has some old GPU kernels buried somewhere on Gerrit.
>>>>
>>>> It would be good to identify a use case that someone has interest in to e.g. contribute coding time, test cases, design idea sounding board. AFAIK none of the GROMACS core developers uses this feature, so their priorities tend to align elsewhere. However, we know it's useful to people, so we'd like to find a group that can work together to make it happen!
>>>>
>>>> Some of those dot points are a bit out of date, but the general list of things to do is about right.
>>>>
>>>> Mark
>>>>
>>>> On Tue, Nov 13, 2018 at 3:48 PM Adriaan Riet <adriaan.riet at case.edu <mailto:adriaan.riet at case.edu>> wrote:
>>>>
>>>>     Hello everyone,
>>>>
>>>>     I know that Feature #1347 talks about the necessary steps to get
>>>>     tables into Verlet (pasted below). I'm curious to know where this
>>>>     sits. I'm happy to contribute where (if) I can, but don't see
>>>>     clearly where to jump in. Have the points of the list been
>>>>     integrated into redmine feature requests? Have any of these been
>>>>     implemented yet?
>>>>
>>>>     Thanks,
>>>>     Adriaan Riet
>>>>
>>>>     Things to do (roughly in order):
>>>>
>>>>       * support regressiontests being able to read tables from grompp
>>>>         or mdrun, so that new functionality in the code doesn't need
>>>>         matching changes to the other repo for valid testing in the
>>>>         few cases where they use tables (|*CSTab*| in group-scheme
>>>>         kernels)
>>>>       * add integration tests, e.g. a Martini-style(?) non-bonded, and
>>>>         several kinds of bonded interactions
>>>>       * extract code from mdlib (particularly init_forcerec) so that
>>>>         it is callable at grompp time, make sure grompp can issue all
>>>>         notes and warnings, permit mdrun to repeat any of those that
>>>>         it might need to. Keep code for making hardware-specific
>>>>         layout decisions in mdrun, because we won't know whether the
>>>>         kernels need tables for CPUs or GPUs until then. If we can do
>>>>         it without significant loss of accuracy, grompp should handle
>>>>         any regularization of the user input (e.g. by constructing and
>>>>         testing CPU and GPU tables, if necessary).
>>>>       * move e.g. dihedral-interaction table reading to grompp, bump
>>>>         .tpr version, write to .tpr, read in mdrun, add infrastructure
>>>>         to support gmx check and gmx dump on new .tpr contents
>>>>       * move angle- and bond-interaction table reading to grompp,
>>>>         probably another .tpr version bump
>>>>       * move short-range interaction tables to grompp for group scheme
>>>>       * extend |[pairs]| to permit atom-type pairs to use an
>>>>         interaction shape read from a table, e.g. from a file named on
>>>>         that line of the topology. Should we have a per-pair-type
>>>>         scaling parameter? Requirements for simulations that use only
>>>>         user tables, and those that mix user tables with normal
>>>>         short-ranged interaction types probably differ.
>>>>       * add Verlet-scheme table-support infrastructure
>>>>       * add CPU kernels (hopefully in new scheme)
>>>>       * add GPU kernels (recycle from Alfredo's patch in gerrit)
>>>>       * after some time passes and master branch rebases enough,
>>>>         remove workaround from regressiontests (which is anyway only
>>>>         needed for group-scheme kernel testing)
>>>>
>>>>     --     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
>>>>     <mailto:gmx-developers-request at gromacs.org>.
>>>>
>>>>
>>
>>
>> -- 
>> David van der Spoel, Ph.D., Professor of Biology
>> Head of Department, Cell & Molecular Biology, Uppsala University.
>> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
>> http://www.icm.uu.se
>> -- 
>> 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.


-- 
David van der Spoel, Ph.D., Professor of Biology
Head of Department, Cell & Molecular Biology, Uppsala University.
Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
http://www.icm.uu.se

More information about the gromacs.org_gmx-developers mailing list