Confirmed, code review has integrated the TI features from Ross's group. I
am working through the new kNLCPNE_AFE.h library, nearly done with that as
well. There is a good deal of code replication across libraries--not just
in the non-bonded routines of kNLCPNE but also in the particle--mesh
routines of kPSSE and related libraries. We might look into removing that
but at present the level is manageable.
Future plans:
- Implement and test a lookup table for erfc(r)/r based on the base 2
logarithm of r2... it would work very much like pmemd CPU at that point,
but with a slightly different indexing system. One of those things that
just has to be tried to see whether it makes things faster but if lookups
from texture memory aren't terribly expensive it maintain the same accuracy
and save exp() and exp2f() in the inner loop.
- Implement an alternate pipeline for doing the dynamics calculation based
on the gemstones domain decomposition. A sorting method that keeps atoms
in both linear and local neighborhood formats, updated at every step, will
be central to this approach. Developers will then be able to choose
whether to work with the linear list of atoms or the domain decomposition
to implement new methods. The code will include numerous stencils for
importing groups of atoms into __shared__ memory which developers can use
to implement new energy functions or methods. Once things are in
__shared__ it's much easier for the uninitiated to write efficeint GPU
code, so the trick is to make an apparatus for getting there.
Cheers,
Dave
On Mon, Apr 17, 2017 at 6:18 PM, Charles Lin <clin92.ucsd.edu> wrote:
> afaik the code review includes the ti code.
>
> -Charlie
>
> ________________________________________
> From: Ross Walker [rosscwalker.gmail.com] on behalf of Ross Walker [
> ross.rosswalker.co.uk]
> Sent: Monday, April 17, 2017 3:17 PM
> To: AMBER Developers Mailing List
> Cc: Daniel Mermelstein; Charles Lin
> Subject: Re: [AMBER-Developers] Code review of pmemd.cuda
>
> Hi Dave,
>
> Thanks for doing the code documentation. This will prove very helpful down
> the line. Modifying the whitespace though will potentially making patching
> a pain especially the TI code update. The beta is already built against
> AMBER 16 and, fortunately we have merged everything into master already.
> Additional betas will be a pain in the butt though since we'll have to
> maintain 2 versions of the code, one with the new whitespace and one that
> matches AMBER 16. We may end up having to provide tar files of the entire
> CUDA directory instead of a patch for future betas which is not ideal (it
> precludes us making the beta public) but that's something we'll have to
> figure out.
>
> Dan, Charlie - make sure you have all your latest changes merged into the
> master. Dave please work closely with Dan and Charlie to make sure this
> goes smoothly.
>
> We should also do a sanity check on performance and code correctness
> although from what you describe this should only be cosmetic changes yes?
>
> What do you have planned beyond the code review? We should coordinate
> things closely on this to make sure it doesn't conflict with what we plan
> running up to AMBER 18.
>
> All the best
> Ross
>
> > On Apr 17, 2017, at 6:00 PM, David Cerutti <dscerutti.gmail.com> wrote:
> >
> > To all:
> >
> > I am nearly finished with my code review of pmemd.cuda. Comments have
> been
> > added throughout with the goal of identifying every function's formal
> > arguments, clarifying the beginning and end of various long blocks of
> code,
> > and better documenting pre-processor directives with a long reach (i.e.
> > this #endif ends what?).
> >
> > While I have tried to preserve Scott's convention of extending assignment
> > statements to collect related variables into groups, a great deal of
> white
> > space has been removed in the interest of adhering to a strict
> 96-character
> > limit on each line. This will significantly increase the amount of code
> > that can fit on the screen at one time, and permit two or more terminal
> > windows to display separate libraries side by side for easy
> > cross-referencing. Spacing has also been added or removed to emphasize
> the
> > binding order of operations (I have a pretty detailed method, but please
> > don't feel that it is required for future commits). Additionally, I have
> > made an effort to decouple braces from pre-processor directives and
> provide
> > indentation for the pre-processor directives themselves to help
> developers
> > more easily gain a sense of where their code sits in very involved
> sections
> > like the non-bonded inner loops in kNLCPNE.h.
> >
> > IF YOU HAVE OUTSTANDING EDITS and need to commit them, I have made no
> > functional changes to the code quite yet--I wanted to get the review done
> > before I start making other changes. Please send me a mail directly if
> you
> > need to merge your items--it is straightforward to go back to the last
> > commit from two weeks ago and see the code as it was beforehand to make a
> > diff, but with the review nearly done I will help work out the best way
> to
> > do the merge.
> >
> > Cheers,
> > Dave
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 17 2017 - 16:00:03 PDT
