You can mark member variables "mutable" to mean they aren't const when the class is. This is generally used for caches and stuff like that. In general, declaring a method const is used to imply logical constness instead of physical constness. That is, it means that doing it 2x with the same arguments should give the same answer, rather than that none of the bits should change.
On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com wrote:
> Hi, > > Let me consult with the high IMP society about some IMP scoring and > caching design issues, don't wanna mess things up. > > I've been profiling code, and consequently wanted to cache some > intermediate computations that are made during pair score evaluations > (e.g., the distance between particles). I just need the last intermediate > from each computation, so I thought of simply adding a [cache_] variable to > my scoring class, and store the intermediate computations there. BUT, > ::evaluate() and ::evaluate_index() are const functions, so I can't do > that. Another option is to add an output parameter to ::evaluate(), but > that's also not very clean. Is it absolutely necessary that these functions > are const? Or any other suggestions so that I can cache intermediate > calculations during ::evaluate()? This can speed some things up > considerably. > > Barak
I think we need more general caching mechanism. For example, if my score includes LennardJones and Coulombic terms, currently each one will compute the same distance, in addition there is external calculation that decides if we should score the pair of particles based on the distance between them. so instead of one distance calculation there are three. It would be great just to be able to pass the distance to evaluate() to avoid additional calculations.
On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com wrote: > You can mark member variables "mutable" to mean they aren't const when the > class is. This is generally used for caches and stuff like that. In general, > declaring a method const is used to imply logical constness instead of > physical constness. That is, it means that doing it 2x with the same > arguments should give the same answer, rather than that none of the bits > should change. > > > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com wrote: >> >> Hi, >> >> Let me consult with the high IMP society about some IMP scoring and >> caching design issues, don't wanna mess things up. >> >> I've been profiling code, and consequently wanted to cache some >> intermediate computations that are made during pair score evaluations (e.g., >> the distance between particles). I just need the last intermediate from each >> computation, so I thought of simply adding a [cache_] variable to my scoring >> class, and store the intermediate computations there. BUT, ::evaluate() and >> ::evaluate_index() are const functions, so I can't do that. Another option >> is to add an output parameter to ::evaluate(), but that's also not very >> clean. Is it absolutely necessary that these functions are const? Or any >> other suggestions so that I can cache intermediate calculations during >> ::evaluate()? This can speed some things up considerably. >> >> Barak > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
It might make sense to introduce something a DistancePairScore base. It could have an evaluate that takes the distance between the two particles and the difference vector (and maybe the distance to avoid dup sqrts). One could then have a variant of PairsRestraint that takes a list of such pair scores and caches things for each pair passed in.
It would also have the nice advantage of making it clear that certain scores are invariant to rigid transforms and so provide a more principled basis for ignoring, eg, terms that are within a rigid body or not recomputing things when rigid mc moves are performed.
Doing this would involve forking: IMP::PairScore (and corresponding macros) IMP::core::PairRestraint IMP::container::PairsRestraint IMP::internal::TupleRestraint IMP::internal::ContainerRestraint
On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com wrote:
> I think we need more general caching mechanism. For example, if my > score includes LennardJones and Coulombic terms, currently each one > will compute the same distance, in addition there is external > calculation that decides if we should score the pair of particles > based on the distance between them. so instead of one distance > calculation there are three. It would be great just to be able to pass > the distance to evaluate() to avoid additional calculations. > > On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com wrote: > > You can mark member variables "mutable" to mean they aren't const when > the > > class is. This is generally used for caches and stuff like that. In > general, > > declaring a method const is used to imply logical constness instead of > > physical constness. That is, it means that doing it 2x with the same > > arguments should give the same answer, rather than that none of the bits > > should change. > > > > > > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com > wrote: > >> > >> Hi, > >> > >> Let me consult with the high IMP society about some IMP scoring and > >> caching design issues, don't wanna mess things up. > >> > >> I've been profiling code, and consequently wanted to cache some > >> intermediate computations that are made during pair score evaluations > (e.g., > >> the distance between particles). I just need the last intermediate from > each > >> computation, so I thought of simply adding a [cache_] variable to my > scoring > >> class, and store the intermediate computations there. BUT, ::evaluate() > and > >> ::evaluate_index() are const functions, so I can't do that. Another > option > >> is to add an output parameter to ::evaluate(), but that's also not very > >> clean. Is it absolutely necessary that these functions are const? Or any > >> other suggestions so that I can cache intermediate calculations during > >> ::evaluate()? This can speed some things up considerably. > >> > >> Barak > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
just my 2 cents: I const_cast things. Don't know if it's a good thing, people were telling me to avoid mutable. I'm ok with dina that we need something more standardized.
Y
Le 07/06/12 00:19, Daniel Russel a écrit : > It might make sense to introduce something a DistancePairScore base. > It could have an evaluate that takes the distance between the two > particles and the difference vector (and maybe the distance to avoid > dup sqrts). One could then have a variant of PairsRestraint that takes > a list of such pair scores and caches things for each pair passed in. > > It would also have the nice advantage of making it clear that certain > scores are invariant to rigid transforms and so provide a more > principled basis for ignoring, eg, terms that are within a rigid body > or not recomputing things when rigid mc moves are performed. > > Doing this would involve forking: > IMP::PairScore (and corresponding macros) > IMP::core::PairRestraint > IMP::container::PairsRestraint > IMP::internal::TupleRestraint > IMP::internal::ContainerRestraint > > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman <duhovka@gmail.com > mailto:duhovka@gmail.com> wrote: > > I think we need more general caching mechanism. For example, if my > score includes LennardJones and Coulombic terms, currently each one > will compute the same distance, in addition there is external > calculation that decides if we should score the pair of particles > based on the distance between them. so instead of one distance > calculation there are three. It would be great just to be able to pass > the distance to evaluate() to avoid additional calculations. > > On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel <drussel@gmail.com > mailto:drussel@gmail.com> wrote: > > You can mark member variables "mutable" to mean they aren't > const when the > > class is. This is generally used for caches and stuff like that. > In general, > > declaring a method const is used to imply logical constness > instead of > > physical constness. That is, it means that doing it 2x with the same > > arguments should give the same answer, rather than that none of > the bits > > should change. > > > > > > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh > <barak.raveh@gmail.com mailto:barak.raveh@gmail.com> wrote: > >> > >> Hi, > >> > >> Let me consult with the high IMP society about some IMP scoring and > >> caching design issues, don't wanna mess things up. > >> > >> I've been profiling code, and consequently wanted to cache some > >> intermediate computations that are made during pair score > evaluations (e.g., > >> the distance between particles). I just need the last > intermediate from each > >> computation, so I thought of simply adding a [cache_] variable > to my scoring > >> class, and store the intermediate computations there. BUT, > ::evaluate() and > >> ::evaluate_index() are const functions, so I can't do that. > Another option > >> is to add an output parameter to ::evaluate(), but that's also > not very > >> clean. Is it absolutely necessary that these functions are > const? Or any > >> other suggestions so that I can cache intermediate calculations > during > >> ::evaluate()? This can speed some things up considerably. > >> > >> Barak > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
maybe we should have an IMP "high society" meeting and think how to improve both software design and performance of scoring functions. I have been looking into atomic resolution functions recently and have some suggestions there, and Daniel and Barak know what we need for low resolution. So we can come up with something that will cover all resolutions efficiently.
On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill yannick@salilab.org wrote: > just my 2 cents: > I const_cast things. Don't know if it's a good thing, people were telling me > to avoid mutable. > I'm ok with dina that we need something more standardized. > > Y > > > Le 07/06/12 00:19, Daniel Russel a écrit : > > It might make sense to introduce something a DistancePairScore base. It > could have an evaluate that takes the distance between the two particles and > the difference vector (and maybe the distance to avoid dup sqrts). One could > then have a variant of PairsRestraint that takes a list of such pair scores > and caches things for each pair passed in. > > It would also have the nice advantage of making it clear that certain scores > are invariant to rigid transforms and so provide a more principled basis for > ignoring, eg, terms that are within a rigid body or not recomputing things > when rigid mc moves are performed. > > Doing this would involve forking: > IMP::PairScore (and corresponding macros) > IMP::core::PairRestraint > IMP::container::PairsRestraint > IMP::internal::TupleRestraint > IMP::internal::ContainerRestraint > > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com wrote: >> >> I think we need more general caching mechanism. For example, if my >> score includes LennardJones and Coulombic terms, currently each one >> will compute the same distance, in addition there is external >> calculation that decides if we should score the pair of particles >> based on the distance between them. so instead of one distance >> calculation there are three. It would be great just to be able to pass >> the distance to evaluate() to avoid additional calculations. >> >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com wrote: >> > You can mark member variables "mutable" to mean they aren't const when >> > the >> > class is. This is generally used for caches and stuff like that. In >> > general, >> > declaring a method const is used to imply logical constness instead of >> > physical constness. That is, it means that doing it 2x with the same >> > arguments should give the same answer, rather than that none of the bits >> > should change. >> > >> > >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com >> > wrote: >> >> >> >> Hi, >> >> >> >> Let me consult with the high IMP society about some IMP scoring and >> >> caching design issues, don't wanna mess things up. >> >> >> >> I've been profiling code, and consequently wanted to cache some >> >> intermediate computations that are made during pair score evaluations >> >> (e.g., >> >> the distance between particles). I just need the last intermediate from >> >> each >> >> computation, so I thought of simply adding a [cache_] variable to my >> >> scoring >> >> class, and store the intermediate computations there. BUT, ::evaluate() >> >> and >> >> ::evaluate_index() are const functions, so I can't do that. Another >> >> option >> >> is to add an output parameter to ::evaluate(), but that's also not very >> >> clean. Is it absolutely necessary that these functions are const? Or >> >> any >> >> other suggestions so that I can cache intermediate calculations during >> >> ::evaluate()? This can speed some things up considerably. >> >> >> >> Barak >> > >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
Sounds like a good idea. How about next Wednesday at 11 (PST)? Can everyone who is interested make it or VC in then?
On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman duhovka@gmail.com wrote:
> maybe we should have an IMP "high society" meeting and think how to > improve both software design and performance of scoring functions. I > have been looking into atomic resolution functions recently and have > some suggestions there, and Daniel and Barak know what we need for low > resolution. So we can come up with something that will cover all > resolutions efficiently. > > On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill yannick@salilab.org wrote: > > just my 2 cents: > > I const_cast things. Don't know if it's a good thing, people were > telling me > > to avoid mutable. > > I'm ok with dina that we need something more standardized. > > > > Y > > > > > > Le 07/06/12 00:19, Daniel Russel a écrit : > > > > It might make sense to introduce something a DistancePairScore base. It > > could have an evaluate that takes the distance between the two particles > and > > the difference vector (and maybe the distance to avoid dup sqrts). One > could > > then have a variant of PairsRestraint that takes a list of such pair > scores > > and caches things for each pair passed in. > > > > It would also have the nice advantage of making it clear that certain > scores > > are invariant to rigid transforms and so provide a more principled basis > for > > ignoring, eg, terms that are within a rigid body or not recomputing > things > > when rigid mc moves are performed. > > > > Doing this would involve forking: > > IMP::PairScore (and corresponding macros) > > IMP::core::PairRestraint > > IMP::container::PairsRestraint > > IMP::internal::TupleRestraint > > IMP::internal::ContainerRestraint > > > > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com > wrote: > >> > >> I think we need more general caching mechanism. For example, if my > >> score includes LennardJones and Coulombic terms, currently each one > >> will compute the same distance, in addition there is external > >> calculation that decides if we should score the pair of particles > >> based on the distance between them. so instead of one distance > >> calculation there are three. It would be great just to be able to pass > >> the distance to evaluate() to avoid additional calculations. > >> > >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com > wrote: > >> > You can mark member variables "mutable" to mean they aren't const when > >> > the > >> > class is. This is generally used for caches and stuff like that. In > >> > general, > >> > declaring a method const is used to imply logical constness instead of > >> > physical constness. That is, it means that doing it 2x with the same > >> > arguments should give the same answer, rather than that none of the > bits > >> > should change. > >> > > >> > > >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> Let me consult with the high IMP society about some IMP scoring and > >> >> caching design issues, don't wanna mess things up. > >> >> > >> >> I've been profiling code, and consequently wanted to cache some > >> >> intermediate computations that are made during pair score evaluations > >> >> (e.g., > >> >> the distance between particles). I just need the last intermediate > from > >> >> each > >> >> computation, so I thought of simply adding a [cache_] variable to my > >> >> scoring > >> >> class, and store the intermediate computations there. BUT, > ::evaluate() > >> >> and > >> >> ::evaluate_index() are const functions, so I can't do that. Another > >> >> option > >> >> is to add an output parameter to ::evaluate(), but that's also not > very > >> >> clean. Is it absolutely necessary that these functions are const? Or > >> >> any > >> >> other suggestions so that I can cache intermediate calculations > during > >> >> ::evaluate()? This can speed some things up considerably. > >> >> > >> >> Barak > >> > > >> > > >> > > >> > _______________________________________________ > >> > IMP-dev mailing list > >> > IMP-dev@salilab.org > >> > https://salilab.org/mailman/listinfo/imp-dev > >> > > >> _______________________________________________ > >> IMP-dev mailing list > >> IMP-dev@salilab.org > >> https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
if it were a little earlier (like 10-10:30) I could skype in
Y
On 06/07/2012 09:22 PM, Daniel Russel wrote: > Sounds like a good idea. How about next Wednesday at 11 (PST)? Can > everyone who is interested make it or VC in then? > > On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman <duhovka@gmail.com > mailto:duhovka@gmail.com> wrote: > > maybe we should have an IMP "high society" meeting and think how to > improve both software design and performance of scoring functions. I > have been looking into atomic resolution functions recently and have > some suggestions there, and Daniel and Barak know what we need for low > resolution. So we can come up with something that will cover all > resolutions efficiently. > > On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill <yannick@salilab.org > mailto:yannick@salilab.org> wrote: > > just my 2 cents: > > I const_cast things. Don't know if it's a good thing, people > were telling me > > to avoid mutable. > > I'm ok with dina that we need something more standardized. > > > > Y > > > > > > Le 07/06/12 00:19, Daniel Russel a écrit : > > > > It might make sense to introduce something a DistancePairScore > base. It > > could have an evaluate that takes the distance between the two > particles and > > the difference vector (and maybe the distance to avoid dup > sqrts). One could > > then have a variant of PairsRestraint that takes a list of such > pair scores > > and caches things for each pair passed in. > > > > It would also have the nice advantage of making it clear that > certain scores > > are invariant to rigid transforms and so provide a more > principled basis for > > ignoring, eg, terms that are within a rigid body or not > recomputing things > > when rigid mc moves are performed. > > > > Doing this would involve forking: > > IMP::PairScore (and corresponding macros) > > IMP::core::PairRestraint > > IMP::container::PairsRestraint > > IMP::internal::TupleRestraint > > IMP::internal::ContainerRestraint > > > > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman > <duhovka@gmail.com mailto:duhovka@gmail.com> wrote: > >> > >> I think we need more general caching mechanism. For example, if my > >> score includes LennardJones and Coulombic terms, currently each one > >> will compute the same distance, in addition there is external > >> calculation that decides if we should score the pair of particles > >> based on the distance between them. so instead of one distance > >> calculation there are three. It would be great just to be able > to pass > >> the distance to evaluate() to avoid additional calculations. > >> > >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel > <drussel@gmail.com mailto:drussel@gmail.com> wrote: > >> > You can mark member variables "mutable" to mean they aren't > const when > >> > the > >> > class is. This is generally used for caches and stuff like > that. In > >> > general, > >> > declaring a method const is used to imply logical constness > instead of > >> > physical constness. That is, it means that doing it 2x with > the same > >> > arguments should give the same answer, rather than that none > of the bits > >> > should change. > >> > > >> > > >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh > <barak.raveh@gmail.com mailto:barak.raveh@gmail.com> > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> Let me consult with the high IMP society about some IMP > scoring and > >> >> caching design issues, don't wanna mess things up. > >> >> > >> >> I've been profiling code, and consequently wanted to cache some > >> >> intermediate computations that are made during pair score > evaluations > >> >> (e.g., > >> >> the distance between particles). I just need the last > intermediate from > >> >> each > >> >> computation, so I thought of simply adding a [cache_] > variable to my > >> >> scoring > >> >> class, and store the intermediate computations there. BUT, > ::evaluate() > >> >> and > >> >> ::evaluate_index() are const functions, so I can't do that. > Another > >> >> option > >> >> is to add an output parameter to ::evaluate(), but that's > also not very > >> >> clean. Is it absolutely necessary that these functions are > const? Or > >> >> any > >> >> other suggestions so that I can cache intermediate > calculations during > >> >> ::evaluate()? This can speed some things up considerably. > >> >> > >> >> Barak > >> > > >> > > >> > > >> > _______________________________________________ > >> > IMP-dev mailing list > >> > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > >> > https://salilab.org/mailman/listinfo/imp-dev > >> > > >> _______________________________________________ > >> IMP-dev mailing list > >> IMP-dev@salilab.org mailto:IMP-dev@salilab.org > >> https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org mailto:IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
OK. Does 10 work for everyone?
On Jun 8, 2012, at 12:40 AM, Yannick SPILL wrote:
> if it were a little earlier (like 10-10:30) I could skype in > > Y > > On 06/07/2012 09:22 PM, Daniel Russel wrote: >> >> Sounds like a good idea. How about next Wednesday at 11 (PST)? Can everyone who is interested make it or VC in then? >> >> On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman duhovka@gmail.com wrote: >> maybe we should have an IMP "high society" meeting and think how to >> improve both software design and performance of scoring functions. I >> have been looking into atomic resolution functions recently and have >> some suggestions there, and Daniel and Barak know what we need for low >> resolution. So we can come up with something that will cover all >> resolutions efficiently. >> >> On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill yannick@salilab.org wrote: >> > just my 2 cents: >> > I const_cast things. Don't know if it's a good thing, people were telling me >> > to avoid mutable. >> > I'm ok with dina that we need something more standardized. >> > >> > Y >> > >> > >> > Le 07/06/12 00:19, Daniel Russel a écrit : >> > >> > It might make sense to introduce something a DistancePairScore base. It >> > could have an evaluate that takes the distance between the two particles and >> > the difference vector (and maybe the distance to avoid dup sqrts). One could >> > then have a variant of PairsRestraint that takes a list of such pair scores >> > and caches things for each pair passed in. >> > >> > It would also have the nice advantage of making it clear that certain scores >> > are invariant to rigid transforms and so provide a more principled basis for >> > ignoring, eg, terms that are within a rigid body or not recomputing things >> > when rigid mc moves are performed. >> > >> > Doing this would involve forking: >> > IMP::PairScore (and corresponding macros) >> > IMP::core::PairRestraint >> > IMP::container::PairsRestraint >> > IMP::internal::TupleRestraint >> > IMP::internal::ContainerRestraint >> > >> > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com wrote: >> >> >> >> I think we need more general caching mechanism. For example, if my >> >> score includes LennardJones and Coulombic terms, currently each one >> >> will compute the same distance, in addition there is external >> >> calculation that decides if we should score the pair of particles >> >> based on the distance between them. so instead of one distance >> >> calculation there are three. It would be great just to be able to pass >> >> the distance to evaluate() to avoid additional calculations. >> >> >> >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com wrote: >> >> > You can mark member variables "mutable" to mean they aren't const when >> >> > the >> >> > class is. This is generally used for caches and stuff like that. In >> >> > general, >> >> > declaring a method const is used to imply logical constness instead of >> >> > physical constness. That is, it means that doing it 2x with the same >> >> > arguments should give the same answer, rather than that none of the bits >> >> > should change. >> >> > >> >> > >> >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Let me consult with the high IMP society about some IMP scoring and >> >> >> caching design issues, don't wanna mess things up. >> >> >> >> >> >> I've been profiling code, and consequently wanted to cache some >> >> >> intermediate computations that are made during pair score evaluations >> >> >> (e.g., >> >> >> the distance between particles). I just need the last intermediate from >> >> >> each >> >> >> computation, so I thought of simply adding a [cache_] variable to my >> >> >> scoring >> >> >> class, and store the intermediate computations there. BUT, ::evaluate() >> >> >> and >> >> >> ::evaluate_index() are const functions, so I can't do that. Another >> >> >> option >> >> >> is to add an output parameter to ::evaluate(), but that's also not very >> >> >> clean. Is it absolutely necessary that these functions are const? Or >> >> >> any >> >> >> other suggestions so that I can cache intermediate calculations during >> >> >> ::evaluate()? This can speed some things up considerably. >> >> >> >> >> >> Barak >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > IMP-dev mailing list >> >> > IMP-dev@salilab.org >> >> > https://salilab.org/mailman/listinfo/imp-dev >> >> > >> >> _______________________________________________ >> >> IMP-dev mailing list >> >> IMP-dev@salilab.org >> >> https://salilab.org/mailman/listinfo/imp-dev >> > >> > >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
works for me.
On Fri, Jun 8, 2012 at 7:08 AM, Daniel Russel drussel@gmail.com wrote: > OK. Does 10 work for everyone? > > On Jun 8, 2012, at 12:40 AM, Yannick SPILL wrote: > > if it were a little earlier (like 10-10:30) I could skype in > > Y > > On 06/07/2012 09:22 PM, Daniel Russel wrote: > > Sounds like a good idea. How about next Wednesday at 11 (PST)? Can everyone > who is interested make it or VC in then? > > On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman duhovka@gmail.com wrote: >> >> maybe we should have an IMP "high society" meeting and think how to >> improve both software design and performance of scoring functions. I >> have been looking into atomic resolution functions recently and have >> some suggestions there, and Daniel and Barak know what we need for low >> resolution. So we can come up with something that will cover all >> resolutions efficiently. >> >> On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill yannick@salilab.org wrote: >> > just my 2 cents: >> > I const_cast things. Don't know if it's a good thing, people were >> > telling me >> > to avoid mutable. >> > I'm ok with dina that we need something more standardized. >> > >> > Y >> > >> > >> > Le 07/06/12 00:19, Daniel Russel a écrit : >> > >> > It might make sense to introduce something a DistancePairScore base. It >> > could have an evaluate that takes the distance between the two particles >> > and >> > the difference vector (and maybe the distance to avoid dup sqrts). One >> > could >> > then have a variant of PairsRestraint that takes a list of such pair >> > scores >> > and caches things for each pair passed in. >> > >> > It would also have the nice advantage of making it clear that certain >> > scores >> > are invariant to rigid transforms and so provide a more principled basis >> > for >> > ignoring, eg, terms that are within a rigid body or not recomputing >> > things >> > when rigid mc moves are performed. >> > >> > Doing this would involve forking: >> > IMP::PairScore (and corresponding macros) >> > IMP::core::PairRestraint >> > IMP::container::PairsRestraint >> > IMP::internal::TupleRestraint >> > IMP::internal::ContainerRestraint >> > >> > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com >> > wrote: >> >> >> >> I think we need more general caching mechanism. For example, if my >> >> score includes LennardJones and Coulombic terms, currently each one >> >> will compute the same distance, in addition there is external >> >> calculation that decides if we should score the pair of particles >> >> based on the distance between them. so instead of one distance >> >> calculation there are three. It would be great just to be able to pass >> >> the distance to evaluate() to avoid additional calculations. >> >> >> >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com >> >> wrote: >> >> > You can mark member variables "mutable" to mean they aren't const >> >> > when >> >> > the >> >> > class is. This is generally used for caches and stuff like that. In >> >> > general, >> >> > declaring a method const is used to imply logical constness instead >> >> > of >> >> > physical constness. That is, it means that doing it 2x with the same >> >> > arguments should give the same answer, rather than that none of the >> >> > bits >> >> > should change. >> >> > >> >> > >> >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh barak.raveh@gmail.com >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Let me consult with the high IMP society about some IMP scoring and >> >> >> caching design issues, don't wanna mess things up. >> >> >> >> >> >> I've been profiling code, and consequently wanted to cache some >> >> >> intermediate computations that are made during pair score >> >> >> evaluations >> >> >> (e.g., >> >> >> the distance between particles). I just need the last intermediate >> >> >> from >> >> >> each >> >> >> computation, so I thought of simply adding a [cache_] variable to my >> >> >> scoring >> >> >> class, and store the intermediate computations there. BUT, >> >> >> ::evaluate() >> >> >> and >> >> >> ::evaluate_index() are const functions, so I can't do that. Another >> >> >> option >> >> >> is to add an output parameter to ::evaluate(), but that's also not >> >> >> very >> >> >> clean. Is it absolutely necessary that these functions are const? Or >> >> >> any >> >> >> other suggestions so that I can cache intermediate calculations >> >> >> during >> >> >> ::evaluate()? This can speed some things up considerably. >> >> >> >> >> >> Barak >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > IMP-dev mailing list >> >> > IMP-dev@salilab.org >> >> > https://salilab.org/mailman/listinfo/imp-dev >> >> > >> >> _______________________________________________ >> >> IMP-dev mailing list >> >> IMP-dev@salilab.org >> >> https://salilab.org/mailman/listinfo/imp-dev >> > >> > >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> > >> > >> > _______________________________________________ >> > IMP-dev mailing list >> > IMP-dev@salilab.org >> > https://salilab.org/mailman/listinfo/imp-dev >> > >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
Just to remind people that the meeting to discussing caching and accelerating distance based scoring will be tomorrow at 10ish.
I can't make it until a bit later (hopefully 10:10 or so). I'll email tomorrow if it is later. Sorry.
On Fri, Jun 8, 2012 at 7:13 AM, Dina Schneidman duhovka@gmail.com wrote:
> works for me. > > On Fri, Jun 8, 2012 at 7:08 AM, Daniel Russel drussel@gmail.com wrote: > > OK. Does 10 work for everyone? > > > > On Jun 8, 2012, at 12:40 AM, Yannick SPILL wrote: > > > > if it were a little earlier (like 10-10:30) I could skype in > > > > Y > > > > On 06/07/2012 09:22 PM, Daniel Russel wrote: > > > > Sounds like a good idea. How about next Wednesday at 11 (PST)? Can > everyone > > who is interested make it or VC in then? > > > > On Thu, Jun 7, 2012 at 11:06 AM, Dina Schneidman duhovka@gmail.com > wrote: > >> > >> maybe we should have an IMP "high society" meeting and think how to > >> improve both software design and performance of scoring functions. I > >> have been looking into atomic resolution functions recently and have > >> some suggestions there, and Daniel and Barak know what we need for low > >> resolution. So we can come up with something that will cover all > >> resolutions efficiently. > >> > >> On Wed, Jun 6, 2012 at 9:29 PM, Yannick Spill yannick@salilab.org > wrote: > >> > just my 2 cents: > >> > I const_cast things. Don't know if it's a good thing, people were > >> > telling me > >> > to avoid mutable. > >> > I'm ok with dina that we need something more standardized. > >> > > >> > Y > >> > > >> > > >> > Le 07/06/12 00:19, Daniel Russel a écrit : > >> > > >> > It might make sense to introduce something a DistancePairScore base. > It > >> > could have an evaluate that takes the distance between the two > particles > >> > and > >> > the difference vector (and maybe the distance to avoid dup sqrts). One > >> > could > >> > then have a variant of PairsRestraint that takes a list of such pair > >> > scores > >> > and caches things for each pair passed in. > >> > > >> > It would also have the nice advantage of making it clear that certain > >> > scores > >> > are invariant to rigid transforms and so provide a more principled > basis > >> > for > >> > ignoring, eg, terms that are within a rigid body or not recomputing > >> > things > >> > when rigid mc moves are performed. > >> > > >> > Doing this would involve forking: > >> > IMP::PairScore (and corresponding macros) > >> > IMP::core::PairRestraint > >> > IMP::container::PairsRestraint > >> > IMP::internal::TupleRestraint > >> > IMP::internal::ContainerRestraint > >> > > >> > On Wed, Jun 6, 2012 at 2:40 PM, Dina Schneidman duhovka@gmail.com > >> > wrote: > >> >> > >> >> I think we need more general caching mechanism. For example, if my > >> >> score includes LennardJones and Coulombic terms, currently each one > >> >> will compute the same distance, in addition there is external > >> >> calculation that decides if we should score the pair of particles > >> >> based on the distance between them. so instead of one distance > >> >> calculation there are three. It would be great just to be able to > pass > >> >> the distance to evaluate() to avoid additional calculations. > >> >> > >> >> On Wed, Jun 6, 2012 at 2:19 PM, Daniel Russel drussel@gmail.com > >> >> wrote: > >> >> > You can mark member variables "mutable" to mean they aren't const > >> >> > when > >> >> > the > >> >> > class is. This is generally used for caches and stuff like that. In > >> >> > general, > >> >> > declaring a method const is used to imply logical constness instead > >> >> > of > >> >> > physical constness. That is, it means that doing it 2x with the > same > >> >> > arguments should give the same answer, rather than that none of the > >> >> > bits > >> >> > should change. > >> >> > > >> >> > > >> >> > On Wed, Jun 6, 2012 at 2:14 PM, Barak Raveh <barak.raveh@gmail.com > > > >> >> > wrote: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> Let me consult with the high IMP society about some IMP scoring > and > >> >> >> caching design issues, don't wanna mess things up. > >> >> >> > >> >> >> I've been profiling code, and consequently wanted to cache some > >> >> >> intermediate computations that are made during pair score > >> >> >> evaluations > >> >> >> (e.g., > >> >> >> the distance between particles). I just need the last intermediate > >> >> >> from > >> >> >> each > >> >> >> computation, so I thought of simply adding a [cache_] variable to > my > >> >> >> scoring > >> >> >> class, and store the intermediate computations there. BUT, > >> >> >> ::evaluate() > >> >> >> and > >> >> >> ::evaluate_index() are const functions, so I can't do that. > Another > >> >> >> option > >> >> >> is to add an output parameter to ::evaluate(), but that's also not > >> >> >> very > >> >> >> clean. Is it absolutely necessary that these functions are const? > Or > >> >> >> any > >> >> >> other suggestions so that I can cache intermediate calculations > >> >> >> during > >> >> >> ::evaluate()? This can speed some things up considerably. > >> >> >> > >> >> >> Barak > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > IMP-dev mailing list > >> >> > IMP-dev@salilab.org > >> >> > https://salilab.org/mailman/listinfo/imp-dev > >> >> > > >> >> _______________________________________________ > >> >> IMP-dev mailing list > >> >> IMP-dev@salilab.org > >> >> https://salilab.org/mailman/listinfo/imp-dev > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > IMP-dev mailing list > >> > IMP-dev@salilab.org > >> > https://salilab.org/mailman/listinfo/imp-dev > >> > > >> > > >> > > >> > _______________________________________________ > >> > IMP-dev mailing list > >> > IMP-dev@salilab.org > >> > https://salilab.org/mailman/listinfo/imp-dev > >> > > >> > >> _______________________________________________ > >> IMP-dev mailing list > >> IMP-dev@salilab.org > >> https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > > > > > _______________________________________________ > > IMP-dev mailing list > > IMP-dev@salilab.org > > https://salilab.org/mailman/listinfo/imp-dev > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
-
Daniel Russel -
Dina Schneidman -
Yannick Spill