<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 7:27 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></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">I'm hoping to be able to get in:<br>
- non-bonded CUDA module split into multiple compilation units (WIP/in gerrit)<br></blockquote><div><br></div><div>Ooh, yes please :-)</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">
- non-bonded task-splitting (for now w/o DD across multiple GPUs and<br>
perhaps CPU & GPU(s)).<br>
- multiple heterogeneous load balancing improvements (WIP, but some of<br>
it will probably miss the deadline as it greatly depends on the GPU<br>
bonded kernels which will most likely still take quite some time to<br>
finalize).</blockquote><div><br></div><div>Great.</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">
I assume that<br>
i) Verlet kernel generation and<br>
ii) extending the testing framework<br>
are not considered anymore for 5.1, right?<br>
<br>
The former would be important to know because we've held back adding<br>
new sets of kernels to the Verlet scheme as the preprocessor generated<br>
kernels have been considered an undesired direction (for fair<br>
reasons). But now there is a need for feature completion of the Verlet<br>
scheme, so adding new kernels is unavoidable.<br></blockquote><div><br></div><div>I had a brief discussion with Erik today. He wants to run a few more experiments on crippleware compilers, but if we can implement kernels with</div><div><br></div><div>template <const int ewaldType, const int LJType,...> oneKernelToRuleThemAll(args)</div><div>{</div><div> ...</div><div> switch(ewaldType)</div><div> {</div><div> case analyticalPME: callThatInlinedFunction(args); break;</div><div> case tabulatedPME: callTheOtherInlinedFunction(args); break;</div><div> ...</div><div> }</div><div> ...</div><div>}</div><div><br></div><div>and have the dead code / function all eliminated properly by the compiler, then we have our generator. For compilation speed, we'd probably want to play games to have each template instantiation generated in its own compilation unit. This is C++98 technology and a brain-dead optimization, so it really should work... The code transformation is straightforward, once we decide compilers are up to the job.</div><div><br></div><div>What sets of kernels do we need/want to add? Which of those are for feature completion? (If we need to prioritise.)</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">
I know I'm partly responsible for letting the discussion on latter<br>
issue die out (sorry Teemu), but given the rather low level of<br>
interest in discussing the matter, I don't think that resurrecting the<br>
discussion before 5.1 makes much sense.<br></blockquote><div><br></div><div>While important, I think testing infrastructure needs to be worked on between release periods - to avoid elaborate commit dependencies, if nothing else. I have a bunch of WIP, including 4xn kernel unit tests, but life will be quite complex enough without trying to sort them out now. </div><div><br></div><div>Mark</div><div><br></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">
<br>
Cheers,<br>
--<br>
Szilárd<br>
<div class=""><div class="h5"><br>
<br>
On Wed, Nov 26, 2014 at 6:18 PM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> It's time we got organized for the next minor release. Generally policy is<br>
> unchanged - we do a feature-change release at least once a year, and bugfix<br>
> releases periodically on the last minor/major release. An "extra" release<br>
> for some special purpose is negotiable.<br>
><br>
> I propose<br>
><br>
> * now:<br>
> + get code you want to be considered for 5.1 into gerrit (tag the first<br>
> line of the commit message [RFC] or [WIP] if you know that the current state<br>
> of the code is not a serious candidate for merging)<br>
> + get your karma up by participating in review of others' code<br>
> + reply to this email (or comment on your patches in gerrit) to guide<br>
> other people about what might be important for them to review<br>
><br>
> * mid-January:<br>
> + release 5.0.x<br>
> + release 5.1-beta from whatever is the tip of master branch at the time<br>
> + fork release-5-1 branch then (still open for functionality changes<br>
> until the 5.1-rc1 releases; gerrit's feature for cherry picking between<br>
> branches will make this fork manageable)<br>
><br>
> * early-to-mid February:<br>
> + release 5.1-rc1<br>
> + close release-5-1 to new functionality, it remains open for bug fixes,<br>
> test cases, and documentation only<br>
> + test widely on any plausible machine and compiler for portability and<br>
> correctness<br>
> + release 5.1-rc[234] if that seems like a good idea<br>
><br>
> * mid-March:<br>
> + release 5.0.x for hopefully the last time, pretty much close<br>
> release-5-0 branch<br>
> + release 5.1<br>
> + remove the group cutoff scheme<br>
> + ...<br>
> + Profit!<br>
><br>
> Do speak up if you have a suggestion for a change / request for special<br>
> consideration / whatever. I've deliberately left the Christmas period open<br>
> for people who might want to do a last code push at that time, but a huge<br>
> patch landing without warning on January 10... will probably get ignored by<br>
> me.<br>
><br>
> Please note that things like ongoing contribution with testing and code<br>
> review are the primary things that might earn an authorship on Gromacs<br>
> papers (5.0 is still on my TODO list, sorry) - adding some feature is<br>
> awesome, but what reward structure we can offer needs to focus on the large<br>
> amount of inglorious work that has to happen.<br>
><br>
> Things team Stockholm are actively working on that we'd like to have ready<br>
> for 5.1 (and the names of the primary people involved)<br>
> * new DD communication support (Berk)<br>
> * enhancements to pull code (Berk)<br>
> * Verlet scheme support for tables, vacuum, Generalized Born (Berk, Alfredo)<br>
> * GPU support for tabulated interactions (Alfredo)<br>
> * GPU acceleration of (at least) dihedral interactions (Iman)<br>
> * combined FFTs for LJ-PME (Christian)<br>
> * offload of bonded interactions for enhancing load balance (Mark)<br>
> * support for latest CUDA offerings (Szilard)<br>
> * OpenCL non-bonded support (mostly Anca from <a href="http://www.streamcomputing.eu" target="_blank">http://www.streamcomputing.eu</a>,<br>
> Mark)<br>
> * support for CPU-based SIMD on everything on the horizon (Erik)<br>
><br>
> Like everything else, none of that's going to block releases, but since 5.1<br>
> will be the last minor release with the group cutoff scheme, feature<br>
> completion of the Verlet scheme will be an internal priority for<br>
> development, review, and testing. Full feature completion is unlikely to<br>
> happen, so support for twin-range multiple-time stepping, QM/MM, and AdReS<br>
> may disappear unless people want to put the work in.<br>
><br>
> There's a lot of code already in Gerrit awaiting review, particularly from<br>
> Teemu on the analysis tools. I need to help out more there, but do check if<br>
> he's fixing stuff that you might care about!<br>
><br>
> If you're working on code that you might want to get into 5.1, speak up!<br>
><br>
> Happy reviewing!<br>
><br>
> Mark<br>
><br>
</div></div><div class=""><div class="h5">> --<br>
> Gromacs Developers mailing list<br>
><br>
> * Please search the archive at<br>
> <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<br>
> posting!<br>
><br>
> * Can'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<br>
> send a mail to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<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'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>.</div></div></blockquote></div><br></div></div>