Merge pull request #2670 from RosettaCommons/aleaverfay/simple_lkball_performance_improvements
Performance improvements for LK_Ball
Performance improvements for LK_Ball that will perhaps improve multithreaded performance
In particular:
LKB_ResidueInfo now holds a pointer to the singleton-managed array of WaterBuilders that it needs to compute the coordinates of the waters in scoring/derivative calculation. Previously, it had to go to the Singleton and obtain a ReadLock on the singleton once per residue per score function evaluation. Yikes! I'm hoping this reduces lock contention.
Unrelatedly, I noticed that a signficant amount of time is spent in setup-for-minimization in the construction of residue-pair atom neighbor lists. The big expense: pushing back atom-index pairs into an array. So I am now reserving space for 100 atom-index pairs.
Also. The water-positional-derivative calculation is somewhat slow and needed only during derivative evaluation, but was being computed at every score function evaluation. So that is another source of speed.
Finally, LKBall was allocating and deallocating lots of small arrays during scoring and derivative evaluation. Those small arrays have been replaced with fixedsizearray1's which can be allocated on the stack. This requires knowing an upper bound on the number of waters per heavyatom, which is now hard coded to 4 in the constant MAX_N_WATERS_PER_ATOM defined in LK_BallInfo.hh. This constant controls the size of these fixedsizearray1s.
In my hands relax_jd3 is performing just as fast in multithreaded mode and MPI mode at a small benchmark of 100 relax trajectories of 1ubq with 40 worker threads.
@fdimaio @vmullig @phbradley