prompted by work I did breaking up restraints in domino2 in order to improve filtering and restraint evaluation and work special casing restraints in order to handle spring natively in Bullet and openmm, I thought it could be cool to add functionality to IMP to automatically modify the set of restraints used in order to make them faster. The idea would be to have a static list in the kernel of known optimizations. Restraints, or anything else, could add optimizations to the list, and then optimizers would apply the optimizations before performing its optimization steps (and clean up the changes upon exit from the optimizer).
optimizations could include things like: - automatically replacing DistancePairScores which use Harmonics with HarmonicDistancePairScore - replacing BondSingletonScores with HarmonicDistancePairScores when appropopriate (the makeup of the bonds can't change) etc - use the C++-only generic restraints in some common cases
These can provide a factor of two reduction in evaluation time in certain cases.
Disadvantages: - calling optimize with only one iteration would be kind of slow, but why would you do that - work needs to be done by me :-)
This would be different from the restraint/container optimization in Domino2--the name of that should probably change to decomposition or something less generic.
So, how much do people want more speed when evaluating lots of simple restraints?
Daniel -
Minimizing function calls (wrappers, virtual functions etc) would of course be very relevant! Currently not a lot of users are performing full atomic optimization and thus may be the reason it did not come up till now. But, with new applications such those of Dave, Hao, Charles, and others is will be quite beneficial.
In the mean time though, it might be good to have an IMP developer meeting (as well as a section in the IMP pages) discussing code optimization (for example minimizing function calls within loops, the cost of virtual functions etc).
makes sense?
Keren.
On Sep 28, 2010, at 4:16 PM, Daniel Russel wrote:
> prompted by work I did breaking up restraints in domino2 in order to > improve filtering and restraint evaluation and work special casing > restraints in order to handle spring natively in Bullet and openmm, > I thought it could be cool to add functionality to IMP to > automatically modify the set of restraints used in order to make > them faster. The idea would be to have a static list in the kernel > of known optimizations. Restraints, or anything else, could add > optimizations to the list, and then optimizers would apply the > optimizations before performing its optimization steps (and clean up > the changes upon exit from the optimizer). > > optimizations could include things like: > - automatically replacing DistancePairScores which use Harmonics > with HarmonicDistancePairScore > - replacing BondSingletonScores with HarmonicDistancePairScores when > appropopriate (the makeup of the bonds can't change) etc > - use the C++-only generic restraints in some common cases > > These can provide a factor of two reduction in evaluation time in > certain cases. > > Disadvantages: > - calling optimize with only one iteration would be kind of slow, > but why would you do that > - work needs to be done by me :-) > > This would be different from the restraint/container optimization in > Domino2--the name of that should probably change to decomposition or > something less generic. > > So, how much do people want more speed when evaluating lots of > simple restraints? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (2)
-
Daniel Russel -
Keren Lasker