> One thing I'll caution against is premature optimization (a popular quote
> is "premature optimization is the root of all evil" -- an exaggeration to
> be sure, but there's a lesson there).
>
> Let's say that we're even initializing the force array to 0 every step.
> Compare that to, for instance, to *any* component of the force evaluation.
> The time spent doing initialization (even every step) I would predict to be
> negligible compared to the cost of even just the bond interactions.
> Certainly, that cost will be negligible compared to the direct-space
> nonbonded interaction (or the reciprocal space component which scales as
> O(N logN)).
>
This assumption is likely only true for serial code. The issue that most often
arrises is when one initializes a big array on every core but then each core (cpu
or gpu) only ever reads or writes to a fraction of the entire shared array.
If it is only called once at the beginning of a run it's probably fine to zero it
and not worry. But any array operation inside a loop is almost always going
to be expensive. It's probably not a concern in python say where the math
itself is slow but in C or Fortran unecessarily initializing whole arrays can
be very expensive, especially if it causes cache misses later in the code.
> The point is, initialization is almost *always* a good thing to do. You
> should only *not* do it if both of the following are true:
>
> 1. You know for a fact it's not necessary (and comments should be added to
> explain why this is true).
I agree with this although more for the fact that you should properly understand
how memory is being accessed by your code - very important in parallel programming.
Initializing arrays is not an excuse for not understanding how memory is used in your code.
> 2. You've actually tested that the initialization adds a measurable
> performance penalty.
This should not be necessary if you understand 1 properly.
All the best
Ross
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Nov 13 2018 - 17:00:03 PST
