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 >