<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 6:39 AM, Roland Schulz <span dir="ltr">&lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I vaguely remember that someone said there are some plans of generating the verlet kernels in some new way. Do I remember that correctly or do no such plan exist? If they do, what are they?</div>
</div></blockquote><div><br></div><div>Erik has some plans - the general idea is that we use a python script to generate flat source files with no conditionality of any sort, on similar lines to the current group scheme kernel generator.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Erik, you mentioned previously that there are potential problems with intrinsics and C++. Do we already have any examples of that?</div>
<div><br></div><div>If C++ and intrinsics doesn&#39;t cause any problems one option to replace the preprocessor would be using templated functions (for an example see here: <a href="http://stackoverflow.com/questions/6179295/if-statement-inside-a-cuda-kernel/6179580#6179580" target="_blank">http://stackoverflow.com/questions/6179295/if-statement-inside-a-cuda-kernel/6179580#6179580</a> - this is for CUDA but doesn&#39;t effect the idea). </div>
</div></blockquote><div><br></div><div>Yes, that&#39;s another way we could metaprogram. I suggested Christian try it out for combining the FFT grids for better LJPME performance (see draft at <a href="https://gerrit.gromacs.org/#/c/3266/11">https://gerrit.gromacs.org/#/c/3266/11</a> in fft5p.cpp for those with access). Inasmuch as constant-propagation and dead-code optimizations probably work fine within a function, even when templated, then I think that&#39;s an approach we could use in places. It&#39;s definitely better than duplication, and often more readable than preprocessor-based techniques.</div>
<div><br></div><div>The downside for template meta-programming for non-bonded kernels is that you still get a kernel with every possible code path in it, whereas with a generator script doing the metaprogramming, you can read whichever one suits your current purpose. Being able to see the meta-programming output can be useful when developing new kernels. I imagine compile time of ~100 kernels might be a little faster overall with the generator script, and debuggers might have a better time, too.</div>
<div><br></div><div>The downside of generation is having lots of generated code. For the tarball, we should generate the code, but perhaps for the repo we should do it at configure time.<br></div><div><br></div><div><div>
On Anton, they metaprogram even harder - the executables for NPT and NVT are different, for example.</div><div><br></div></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><span class=""><font color="#888888"><div>Roland<br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</div></font></span></div>
<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" 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" 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" 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">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div><br></div></div>