← Back to team overview

yade-dev team mailing list archive

Re: Note on optimized compilation / optimized coding / profiling results

 

OK,  a few ideas for low-hanging optimizations. Tell me if you thing
they will not work.

1. LocateMultivirtualFunctor can cache last arguments as well as the
return value at successful lookup. Since it typically does the same
lookup over and over (takes 50% of Cundall damping), it could be reduced
to almost zero (I think):

 if(index1==cachedIndex1 && index2==cachedIndex2) return cachedResult;
/* at the beginning of LocateMultivirtualFunctor */

Given c++ short-circuits conditions, it will add one integer comparison
if we have a "cache miss", no big deal.

(BTW, Janek, couldn't we use some template and virtual functions magic
to have the compiler do the dispatching code? There is plenty of stuff
like that in boost, have a look at extending boost::range with new
classes. Don't know how it works internally, though. We also probably
would have to know all candidates at compile-time.)

2. I will create a new class CundallForceAndMomentumDamping, which will
act on RigidBodyParameters and will be inside the same dispatcher as
CundallnonViscousForceDamping (for ParticleParameters). This way, one
loop over bodies will be gotten rid of. I know the force damping code
will be duplicated at 2 places, but it is just a few lines of code.

3. Physical action appliers could reset those physical actions that have
been applied. This way, we save yet another loop, in
PhysicalActionContainerResetter. LeapFrogPositionIntegrator will apply
force and set it to 0 etc. Is that OK?

Bruno, what do you use to measure time of execution? Small.xyz and
TriaxialTest or something else?

Vaclav

_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev



Follow ups

References