> ok, this one is easy - just declare another variable before the loop,
>
> InteractionContainer::iterator e=interactions->end();
> for(InteractionContainer::iterator I=interactions->begin(); I!=e; ++I)
>
I was trying to adapt Yade containers to boost::range recently so that
BOOST_FOREACH would work with them. It does exactly this optimization
(it is called "hoisting", they say) and is much nicer:
foreach(interactions,I){...}. Will retry.
It can't be optimized by the compiler, since the container may change
during the loop body execution... (perhaps I did say once it would...
sorry).
>> (3) actionStiffness->getClassIndex() is always executed too. It is
>> better to add a member data stiffnessIndex to the engine, then define it
>> only once as stiffnessIndex=actionStiffness->getClassIndex() in the
>> constructor, and finally use stiffnessIndex for internal tests instead
>> of getClassIndex().
>>
>
> getClassIndex() returns only a member static variable of a class.
> I can't belive that it will be faster more than 0.5% if you create
> another variable and access this one instead of that original static
> one. Is that really the case?
>
getClassIndex is still a virtual function which has some dispatch
overhead, and there is a function call (getClassIndexStatic) inside.
There will be some cost of that.
> "Premature optimization is the root of all evil".
>
Last time I had flu and headache it was not because of premature
optimization. If that is not "evil", consider 2nd world was, which was
not caused by premature optimization either.
>
>> (what is the optimization level whith scons flag "optimization=True", is it
>> equivalent to -O3?).
>>
>
> if you look into SConscript, you will see that it's '-O3 -ffast-math'
>
Or if you run scons pretty=0, which will show all commands.
>> Afer fixing things here and there concerning those 3 points above (e.g.
>> I added a member data called "size" to the container to avoid computing
>> it all the time),
>>
>
> in fact you can do whatever you want with the containers, because we
> are switching boost::multi_index as soon as I ... do all my non-yade
> development work. Uh, I wish I've been paid to work on yade, not some
> other unrelated stuff, this is killing me. I want to develop yade
> itself but I can't. But everyone is using yade and they need it better.
> But now I have to do snow, concrete and that stuff...
>
Janek, is multi_index random-access in O(1)? That is important if we try
to use openMP, which can parallelize some loops by itself.
>> I could run the triaxial test around 25% faster.
>> I can commit those changes soon, I'm curious to know the results on
>> other computers.
>>
Great improvement, Bruno. I will run kcallgrind also, it seems very useful.
V.
_______________________________________________
yade-dev mailing list
yade-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/yade-dev
