<div dir="ltr">[Posting at the end of the thread to avoid divergence]<div><br></div><div>First, the memory-vs-flop question is mostly relevant when doing more of one will save the other ;-) If we can avoid pushing e.g. 2*4*4=32 bytes of extra table memory data by doing SIMD computation (e.g. as we do for analytical Ewald), that can be a clear win. However, adding more floating-point operations in our very simplest interaction without removing memory ops is not going to be a clear win ;-)</div><div><br></div><div>Second, we will still need 1/sqrt(x) and/or 1/x for the normal interactions, so I think it would lead to more complex kernels that need to decide what to compute in each case. Nothing is impossible, and the new templated kernels we are planning might make it a bit easier for people to do - but it's an added complication for everyone hacking the kernels that I'd prefer to avoid until we know it would broadly used.</div><div><br></div><div>A long time ago we thought about tabulating the scaled interaction instead (to combine dispersion/repulsion), but that does not work with switched interactions (since the switching range would also be scaled). Combining "everything" into one table is a fun idea, but for OPLS I would assume that would lead to some ~400 different tables (normally there are about 30 distinct atom types remaining after pruning), which means there won't be enough data in most inner kernel iterations.</div><div><br></div><div>Finally, while all-table interactions can be a bit slow, remember that we virtually never need to tabulate van der Waals interactions in normal runs, so it's not going to influence performance at all there.</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 17, 2018 at 10:44 AM Berk Hess <<a href="mailto:hess@kth.se">hess@kth.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">But then we would need different coordinate and force buffers for each table pair, as well as a separate grid for each such buffer. Technically possible, but this will not be fast, unless we have only 2 or 3 tables.<div dir="auto"><br></div><div dir="auto">Berk</div></div>-- <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'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>.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>