yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

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


>
>
>
> 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.
>  
>   
It should be synchronized. Data is never removed at the moment (we can't 
remove bodies), and only one function can add new data : find(), so this 
function now set "current_size". clear() also set size, just to be sure...


>  
>   
>> (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?
>
>   
So perhaps the speedup is only due to the first 2 points.



> 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.
>
>
>   
Tell Luc Scholtes, who is finishing is PhD and wait days to get results, 
that this is "premature" ;-)


> 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.
>
>
>   
I think speed should be kept in mind with high priority when 
implementing new serialization and new container.

> 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...
>
>
>   
Hehe, I think you can't develop in a really approriate way if you are 
not a user at the same time. Guess why Vaçlav is implementing command 
line interface with Python... :)
Real 100% developers usualy create beautiful concepts and codes, but 
nobody use their code because it is not designed for a end-users. I know 
dozens of examples like this.
Speed, for instance, is one of the major issue for most users.

>> 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.
>>     
>
>
> 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?
>
>
>   
Yes, we can try that before I commit.


Bruno

-- 
 
_______________
Chareyre Bruno
Maitre de conference

Institut National Polytechnique de Grenoble
Laboratoire 3S (Soils Solids Structures) - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________

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