yade-dev team mailing list archive

[Václav S(milauer <eudoxos@xxxxxxxx>]

>
> The damping dispatcher takes 89% of cpu time to do 
> something else, namely :
> - LocateMultivirtualFunctor : 50%
Good to know. If Janek listens: wouldn't it be much faster to have an 1D
or 2D array, sized maxClassIndex (× maxClassIndex), that would be used
for lookup? Just pointer arithmetics. This array could even be shared
for different dispatchers, since no pair of classes can (probably) be
used in different dispatchers, right?

Another way would be to have boost::ublas::compressed_matrix for the 2D
case, if 2D array of some 10000 elements is too much (OK, if we have
1000 classes once, that would mean 1e6 which is not nice). Should be
reasonably fast as well. No 3D functors, though ;-).

Will play with that if I find some time. That would sound like big speed
improvement (there is quite a few dispatchers in the simulation, if they
take 30% of time, that means 15% for dispatching... wow.

I thought originally this stuff was part of Loki and was well optimized.

> A simple example :
>
> shared_ptr<PhysicalAction>& PhysicalActionVectorVector::find(unsigned 
> int id , int actionIndex )
> {
>     if( current_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
>     {
>         ....
>     }
>     usedIds[id] = true;
>     return physicalActions[id][actionIndex];
> }
>
> 1. There is this test at the begining, that is useless all the time 
> except at iteration 1.
> 2. there is this usedIds[id] affectation (same remark again, only 
> modified at iteration 1).
> 3. Then return a reference to a shared pointer (while shared_ptr 
> operations are slower than normal).
>   
You're right, I thought that 1. and 2. was the business of ::prepare,
which is called from PhysicalActionContainerInitializer. It should be
the user's responsibility to use valid indices, right?

UsedIds, that's a different story; it says what index contains a
non-null action so that we can iterate over non-null actions. But this
flag could be put into the action instance itself. Then
physicalActions[id][actionIndex] could be used directly.
> Of course, this function "find" is used many many times. Result 3.81% of 
> total CPU time just for it, while we could just use 
> physicalActions[id][actionIndex] instead of find(), and reduce that time 
> a lot. But of course physicalActions is private...
>   
Just change that in the header and make it public, no problem. If the
"user" screws stuff, it it his problem, not mine. I think Olivier liked
having lot of stuff private, but then we have overheads for for
accessors. Sadly, c++ has no way to say: this member is public for
reading and private for writing, which could help in many cases.
> Janek : I know that containers will be changed anyway, and that is why I 
> think this is the right moment to cry about speed. :)
> Users don't care about Godwin's law, they need SPEED!!!
>   
Cosurgi, should I fiddle with PhysicalActionContainer or is it going to
be changed anyway?
> Yes, I thought to that too, but I was not expert enough to be sure. 
> Can't the compiler check that nothing will be affected in some situations?
>   
It can in some, but I don't know in which ones. Putting const everywhere
also checks that there are no side-effects of the method on its
instance, for example.

Another thing is that many methods should be inlined, but grepping
through headers reveals that only very small subset is: for the most
part, the openGl wrapper. Inlining functions is turned on by the -O3
flag to g++, so we don't gain nothing here probably. But gcc manpage
says for -finline-limit: " This option is particularly useful for
programs that use inlining heavily such as those based on recursive
templates with C++." which is just our case.

And by the way, I just found out that assert(...) is not compiled-out in
optimized builds of scons, since we don't define NDEBUG. Will be fixed
in next commit. No big deal ;-)
_______________________________________________
yade-dev mailing list
yade-dev@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/yade-dev