High execution time for update

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
nug700
Posts: 9
Joined: Sat Dec 03, 2016 2:34 am

High execution time for update

Post by nug700 »

For some reason the space.update function is taking 500 ms to execute with the ParallelLooper, and 800-1400ms without ParallelLooper with 220 dynamic convex hulls and 40 nondynamic Boxes.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: High execution time for update

Post by Norbo »

If that's on a mainstream gaming desktop, then those numbers are about a factor of several hundred off the expected ranges. Those numbers would be about right for a phone from a decade ago. It's hard to say what exactly is happening with so little information, but a few things to check for starters:

1) Are the convex hulls extremely complicated? If they have a few hundred thousand vertices each, things will slow down quite a bit. The cost of a convex hull in collision detection is linear with the number of vertices in the ConvexHullShape.
2) Is the simulation actually running on some kind of corrupted state, like NaNs? Those can cause all kinds of explosive problems, including massive performance cliffs. BEPUphysics has an optional CHECKMATH compilation symbol that can catch this sort of thing by inserting a ton of validation logic all over the place.
3) Are there any environmental sources of interference, like other heavy compute threads?
4) Is Space.Update() called with or without a parameter? If a dt value is supplied to the update, it will try to simulate enough timesteps to match the accumulated time. A common problem is passing in milliseconds rather than seconds into Space.Update(dt), essentially asking the engine to simulate at 1000x rate. This is clamped by the Space.TimeStepSettings.MaximumTimeStepsPerFrame, but it can still hurt performance. By default, it can be responsible for up to around a factor of 3 performance loss.
nug700
Posts: 9
Joined: Sat Dec 03, 2016 2:34 am

Re: High execution time for update

Post by nug700 »

To give a little more information about my situation, I'm running this on an i7-4970k processor, with my internet browser and an irc client running. The convex hulls only have 226 vertices. I have enabled the CHECKMATH symbol, and am not seeing any exceptions being thrown from the library. I am running the library inside a console application with a networking thread that makes it thread wait until a client connects (not clients are connecting during this test so no addition threads are being spawned from it at the moment), and another main thread that waits 1ms at the end of every iteration (making this thread wait longer, like 16ms. has no affect on the performance of the physics library). I am supplying Update() a dt perameter, and have verified that it is in seconds (what's being entered in the Update method is 0.016, for example, when the delta time in ms is 16).

EDIT: These objects are in an area of 120x60 and all moving/colliding with each other (they are the tanks in my previous thread, driving in circles). They were supposed to be separated in groups of 22, with each group on a different y positions 10 units apart (had something commented out that wasn't supposed to be, having them all spawn on the same level). When I fixed this and have the groups spawn on different levels, the execution time went down to 6-8ms.
Last edited by nug700 on Tue Dec 06, 2016 11:23 pm, edited 2 times in total.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: High execution time for update

Post by Norbo »

Nothing described sounds like a reasonable culprit. Are the time measurements definitely accurate? Is there anything that could be blocking the update thread? Are there cores visibly busy in the task manager for the duration?

Trying to replicate the slowdown in the BEPUphysicsDemos or other highly isolated application would probably help narrow it down.

(As a side note, 226 vertices is still on the high side for convex hulls; I generally recommend staying below 30 vertices whenever convenient. It doesn't explain a 1000x slowdown, though.)

Edit:
Glad you found something- though I should note that getting to 500+ms with those kinds of shapes would imply all of them were right on top of each other, creating ~30000 collision pairs. If you were seeing 500+ms with a small fraction of that number of pairs, there might still be something else going on.
nug700
Posts: 9
Joined: Sat Dec 03, 2016 2:34 am

Re: High execution time for update

Post by nug700 »

Something I've noticed is that with one tank running, when it collides with another object (in this case a non-dynamic box), the execution time goes from ~0.04ms to ~0.15ms, to spikes of almost 0.3ms. And at about 300 tanks, it starts spiking dramatically. At 660 tanks,I'm at about 130ms execution time (with them not moving). It does drop as time goes on. As I was writing this it went down to 50ms.

Also, The demos that come with the library are not compatible with my version of visual studio (VS 14).
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: High execution time for update

Post by Norbo »

For reference, if I create 660 dynamic convex hulls with 250 points each, drop them all onto a big box, and disable sleeping, the simulation takes about 7-8ms on my 3770K. That's with 800+ collision pairs updating every frame. (Side note: 660 dynamic convex hulls with only 30 points each in the same setup results in about 3.5ms per frame despite having 1250+ collision pairs.)

Given that your tanks can presumably go to sleep when they're not moving and your processor is a bit newer, you should probably see numbers better than mine- certainly not 50-130ms. So there is probably something odd still going on.

Regarding the demos- there are some XNA installers for newer versions, but I understand that it's a hassle (future versions of BEPUphysics won't rely on it). Even a simple copypaste of a minimal simulation setup that reproduces the performance issue would be valuable.
nug700
Posts: 9
Joined: Sat Dec 03, 2016 2:34 am

Re: High execution time for update

Post by nug700 »

I figured out what seems to be the issue, and it's that I was building the project in Debug configuration (I added the library source code directly to the project). Changing to the Release configuration brought the execution time down to the 7-8ms you were getting.
Post Reply