Bipedal-locomotion-framework: The ContinousContactModelUnitTests lasts weirdly long when compiled in debug

[S-Dafarra]

It took 10.5 minutes (!) on my PC on Ubuntu 20.04. Even without memcheck.

cc @GiulioRomualdi

[GiulioRomualdi]

Yes I noticed this. I think it's due to the Montecarlo integration used to test the code

[S-Dafarra]

Yes I noticed this. I think it's due to the Montecarlo integration used to test the code

Is there a way to speed it up?

[GiulioRomualdi]

I'm running callgrind to find the bottleneck

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes ./bin/ContinousContactModelUnitTests

but it's taking ages. I'll update this issue as soon as it finishes

[traversaro]

I'm running callgrind to find the bottleneck

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes ./bin/ContinousContactModelUnitTests

but it's taking ages. I'll update this issue as soon as it finishes

For faster collection of profilation data, you could also try perf/hotspot (see https://github.com/KDAB/hotspot#using), I heard good things about it (but I never used it).

[GiulioRomualdi]

I run callgrind only on one portion of the code. Please check here to understand how.

This is the result.

I reduced the number of samples used in Monte-Carlo from 1e7 to 1e4. Consequentially the tolerance is now increased from 1e-4 to 1e-2. Thanks to this solution now the test is much faster. Indeed when it's compiled in debug the following command:

time ./bin/ContinousContactModelUnitTests

returns

real    0m0,776s
user    0m0,736s
sys 0m0,040s

Since getTorqueAtPoint() calls getForceAtPoint(), another way to improve the performances is fuse the getForceAtPoint() and getTorqueAtPoint() into getWrenchAtPoint().

[S-Dafarra]

Cool @GiulioRomualdi, thanks a lot.

Since getTorqueAtPoint() calls getForceAtPoint(), another way to improve the performances is fuse the getForceAtPoint() and getTorqueAtPoint() into getWrenchAtPoint().

I may have misunderstood, but then probably getWrenchAtPoint() would take a time equal to the sum of getTorqueAtPoint() plus getForceAtPoint(), unless they both require to compute the whole wrench. In any case, getWrenchAtPoint() seems cleaner if you need both parts at the same time.

[GiulioRomualdi]

getTorqueAtPoint() actually cals getForceAtPoint(). So the getWrenchAtPoint() is not simply

getWrenchAtPoint(....)
{
    getForceAtPoint(...);
    getTorqueAtPoint(....);
   ....
}

The idea is in fact to copy the content of the two functions inside getWrenchAtPoint().

By the way, I think that for the time being, we can simply reduce the number of samples used in the Monte-Carlo integration since it solves the issue

[S-Dafarra]

getTorqueAtPoint() actually cals getForceAtPoint(). So the getWrenchAtPoint() is not simply

getWrenchAtPoint(....)
{
    getForceAtPoint(...);
    getTorqueAtPoint(....);
   ....
}

The idea is in fact to copy the content of the two functions inside getWrenchAtPoint().

By the way, I think that for the time being, we can simply reduce the number of samples used in the Monte-Carlo integration since it solves the issue

Yes, I think it is enough to reduce the samples, but the other improvement is also interesting. It may be worth bearing in mind if we are going to have other performance issues in the future.