← Back to team overview

yade-dev team mailing list archive

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

 

Bruno Chareyre said:     (by the date of Thu, 21 Feb 2008 19:53:09 +0100)

> Hi guys
> 
> After a carefull inspection of valgrind outputs, I came to the 
> conclusion that
> 
> (1) this line :
> 
> for(InteractionContainer::iterator I=interactions->begin(); 
> I!=interactions->end(); ++I)

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 suppose this is how you fixed it?


> (2) Even worse, in this code from PhysicalActionVectorVector.cpp :
> 
> shared_ptr<PhysicalAction>& PhysicalActionVectorVector::find(unsigned 
> int id , int actionIndex )
> {
>     if( physicalActions.size() <= id ) // this is very rarely executed, 
> only at beginning.
>     // somebody is accesing out of bounds, make sure he will find, what 
> he needs - a resetted PhysicalAction of his type
>     { ....
> 
> 
> the size of physicalActions WILL BE COMPUTED each time somebody type 
> physicalActions.find(i,j) !!! As a result, size() is executed around 
> 4500 times per timestep in a TriaxialTest with 400 spheres, which 
> represents around 20% of the cost of a function like 
> ElasticContactLaw.action().


so you have added member data called "size" to physicalActions ?
Did you check carefully to increment and decrement it everytime when
new data is added/removed? You know - if it gets out of sync with the
"real size" we will get many crashes, and it will be difficult to
find out why.
 
 
> (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?

Remember that too much optimization results in fast code, which
becomes very difficult to keep without bugs. Donald Knuth in his book
"The Art of Computer Programming", had written "Premature optimization is
the root of all evil". Just be careful.


But anyway, with switching to boost::serialization (real soon now,
like before th eend of March), I will have to reconsider ClassIndex
stuff, becasue boost::serialization also provides this mechanism, so
it may be better to switch to using that one. But I'll have to
investigate it beforehand.



> (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'


> 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...


> 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.

would be kind of you if you answer to my concerns I mentioned above
before you commit ;-)

I you want to check on other computers - you can use mine. I'll only need
to create an account for you, do you want to?


best regards
-- 
Janek Kozicki                                                         |
_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev



Follow ups

References