mlcp solver performance

[gdlk]

Hi!

I have a scene with only many boxes. When I use the SI solver, all works fine ( less than 1ms processing time ). However, if I use the mlcp solver (with Dantzig), the processing time go up to 130 ms or more.... Is this ok?, I know that the mlcp solver is more expensive than SI solver, but 130ms is too much I think D=

The profiling tell that "processIsland" is consuming all the processing time, is this ok?

Some tip or advice is welcome ( I need the mlcp solver because I need to work with large mass ratios ).

Thanks!

Regards!

PS: Part of profiling

Code: Select all

Profiling: Root (total running time: 137.437 ms) ---
0 -- debugDrawWorld (0.00 %) :: 0.001 ms / frame (1 calls)
1 -- stepSimulation (100.00 %) :: 137.434 ms / frame (1 calls)
Unaccounted: (0.001 %) :: 0.002 ms
...----------------------------------
...Profiling: stepSimulation (total running time: 137.434 ms) ---
...0 -- synchronizeMotionStates (0.12 %) :: 0.171 ms / frame (4 calls)
...1 -- internalSingleStepSimulation (99.87 %) :: 137.259 ms / frame (4 calls)
...Unaccounted: (0.003 %) :: 0.004 ms
......----------------------------------
......Profiling: internalSingleStepSimulation (total running time: 137.259 ms) ---
......0 -- updateActivationState (0.01 %) :: 0.010 ms / frame (4 calls)
......1 -- updateActions (0.00 %) :: 0.000 ms / frame (4 calls)
......2 -- integrateTransforms (0.06 %) :: 0.083 ms / frame (4 calls)
......3 -- solveConstraints (98.12 %) :: 134.684 ms / frame (4 calls)
......4 -- calculateSimulationIslands (0.01 %) :: 0.018 ms / frame (4 calls)
......5 -- performDiscreteCollisionDetection (1.53 %) :: 2.094 ms / frame (4 calls)
......6 -- createPredictiveContacts (0.03 %) :: 0.039 ms / frame (4 calls)
......7 -- predictUnconstraintMotion (0.07 %) :: 0.097 ms / frame (4 calls)
......Unaccounted: (0.170 %) :: 0.234 ms
.........----------------------------------
.........Profiling: solveConstraints (total running time: 134.684 ms) ---
.........0 -- solveGroup (1.65 %) :: 2.229 ms / frame (4 calls)
.........1 -- processIslands (98.32 %) :: 132.417 ms / frame (4 calls)
.........2 -- islandUnionFindAndQuickSort (0.02 %) :: 0.030 ms / frame (4 calls)
.........Unaccounted: (0.006 %) :: 0.008 ms
............----------------------------------

[Basroil]

That certainly is strange. How many objects do you have in the world?

[gdlk]

I have about 90 boxes (all active)

[Basroil]

I have about 90 boxes (all active)

I assume you made the minimum batch size 1 as in the demo, so it might have to do with island processing gobbling up cycles somewhere. There is a section of code that could fall apart if it somehow processes 90 islands that fit a very narrow selection of criteria, but I've never seen that happen in my own testing. I suggest you add a few profiler entries (like BT_PROFILE("processIslands"); but with a different name) and try to narrow down exactly where the processing is heaviest

[gdlk]

I have about 90 boxes (all active)

I assume you made the minimum batch size 1 as in the demo, so it might have to do with island processing gobbling up cycles somewhere. There is a section of code that could fall apart if it somehow processes 90 islands that fit a very narrow selection of criteria, but I've never seen that happen in my own testing. I suggest you add a few profiler entries (like BT_PROFILE("processIslands"); but with a different name) and try to narrow down exactly where the processing is heaviest

yes, I had the minimum batch size in 1. I will try to find the exactly point, thanks!!.

By the way, do you have an estimation how much process time would be a "normal increase" respect to the SI solver? (would be nice have a reference =P )

[Basroil]

By the way, do you have an estimation how much process time would be a "normal increase" respect to the SI solver? (would be nice have a reference =P )

Depends on at lot of things! In fact, some MLCP solvers are faster than SI for the same result (one simulation of mine is a bit funky until about 150-200 iterations per joint) for very small islands. A (incredibly) rough estimate would be number of iterations*sum of constraints (SI) vs sum of the square number of constraints per island (for MLCP), but it's really had to tell what your average and worst case performance will be. The above is pretty much what I have seen in my own trials, with a tiny simulation of 3 hinge joints being about 7x faster with Dantzig than 200 iteration SI (with occasional spikes down to just equal).

If you're looking at very large simulations, there's some papers on multithreaded Dantzig solvers which scale well up to about a dozen cores, though I can't say if they actually work well with bullet.

[gdlk]

By the way, do you have an estimation how much process time would be a "normal increase" respect to the SI solver? (would be nice have a reference =P )

Depends on at lot of things! In fact, some MLCP solvers are faster than SI for the same result (one simulation of mine is a bit funky until about 150-200 iterations per joint) for very small islands. A (incredibly) rough estimate would be number of iterations*sum of constraints (SI) vs sum of the square number of constraints per island (for MLCP), but it's really had to tell what your average and worst case performance will be. The above is pretty much what I have seen in my own trials, with a tiny simulation of 3 hinge joints being about 7x faster with Dantzig than 200 iteration SI (with occasional spikes down to just equal).

If you're looking at very large simulations, there's some papers on multithreaded Dantzig solvers which scale well up to about a dozen cores, though I can't say if they actually work well with bullet.

Thanks!!, with that I have a better idea what to expect in performance =D ( I was really blind in that sense ).

[gdlk]

I did more profiles and found that all the processing time is been consuming by the solveMLCP function D=

I will look now on the multithreaded Dantzig way