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