David,
When I start seeing global switch tests in inner loops:
else if ((ti_sc_lst(real_i)+ti_sc_lst(real_j) .eq. 1) .or. &
*(emil_sc_lcl .eq. *1 .and.
ti_sc_lst(real_i)+ti_sc_lst(real_j) .ge. 1)) then
if (ti_lst(1,real_i)+ti_lst(1,real_j) .ge. 1) then !TI region 1
this has always been a reliable warning sign for me in the past that the
overall structure of the code needs reorganization.
The GPU code does this sort of thing at compile time and that's where
decisions like this belong IMO. And it's not any one if/then that is the
problem but rather that these guys tend to reproduce like bunnies once they
appear.
Sure, CPUs are really good at this sort of thing, and outside the inner
loops I don't care about them. But here, I do.
OTOH the more there are, the more I can refactor them out of GPU
incarnations and that's free performance beer.
That and I'm on the verge of rethinking the GPU code itself because so many
assumptions that were valid in 2010 no longer hold.
Scott
On Wed, Feb 12, 2014 at 6:46 PM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Wed, Feb 12, 2014, Jason Swails wrote:
> > >
> > > What's left in Sander that people crave for in PMEMD?
> > >
> >
> > QM/MM.
>
> Certainly, QM/MM is in sander but not pmemd. But do people "crave for it"
> to be added to pmemd? The usual argument is that the QM part quickly
> becomes
> the time bottleneck, so the fact that MM is faster in pmemd becomes
> irrelevant -- there is little need (yet) to think about porting QM/MM to
> pmemd. (I could be wrong here.)
>
> Similar arguments apply for PBSA and RISM: these are both in sander, but
> are slow, and limit performance. Again, any speed advantage PMEMD has for
> the other parts of the calculation are minimal. So there is no hurry to
> put PBSA or RISM into pmemd.
>
> The emap functionality is similar, but maybe not identical, since it is not
> as big a time-hog as QM, PBSA or RISM. So far, I don't think most emap
> calculations (and there aren't very many of them, since only a few people
> are using this capability) need highly efficient MM. But there is more of
> an argument here that emap capability in pmemd might be desirable.
>
> On the other hand, I don't really see Scott's argument, that emap (et al)
> somehow make it hard to keep going on pmemd.cuda development. It's quite
> modular, and there is a simple if-statement in mdin to disable this for
> GPUs.
> We've always had a list of things that aren't supported for GPUs; having a
> few more entires in that list doesn't seem that bad (to me). We're
> learning
> how to document this better, both in the code and in the Manual.
>
> Scott says he wants "more control ... on feature additions that will run
> on the GPU." We *should* establish a better mechanism for suggesting and
> vetting requests for new GPU features. But I don't (yet) see that another
> code fork is needed to accomplish this.
>
> ...dac
>
>
> _______________________________________________
> 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 Wed Feb 12 2014 - 19:30:04 PST
