What is the purpose of running physics in a separate thread?

Question

I'm running some performance tests to understand the purpose of running physics in a separate thread. I have a benchmark scene that creates objects non-stop, in addition to that I have a system to measure frames per second.

One of the tests I've done is trying to create a Node where internally in GDScript I do some matrix multiplication to stress the CPU, all while still creating physical objects that collide with each other in 3D space. I have tried running this test with the option to run physics in a separate thread disabled, and then enabled. There is no performance difference between both options.

Another thing I have tried to do is try to stress the rendering process, to do this I have added multiple quite detailed 3D models (but not affected by physics) that move on the screen while I create the objects that do collide with each other. I have also done this test with both options and again the result is the same whether executing the physics in the main thread or in the separate thread.

In short, I would like to understand what the purpose of this option is, what would be the ideal use-case to execute physics in a separate thread? and how can I check it in my benchmark project?

Woermer

Answer 1

You can use Godot's built-in profiler or an external profiler to see what is eating the most CPU in your project. I wouldn't worry about stressing the rendering process, as that should mostly be handled by the GPU anyways.

Smite

Answer 2

Did you also try to stress the physics process? If you are only doing light physics I would not expect to see any benefits from running physics in a separate thread.

Escribe

Answer 3

Did you also try to stress the physics process? If you are only doing light physics I would not expect to see any benefits from running physics in a separate thread.

Yes, I'm stressing the physics system, that's the purpose of the benchmark. To the point of lowering the framerate to 2 or 3. And using a separate thread in that case is worse than not using it, that's why I ask about the purpose of this option.

Woermer

Answer 4

I dont think the reason has relation to performance. In the physical process you should handle physics related stuff, and in the normal process anything else. If you dont do that, you will have problems in the future. For example, I have a car game with authoritative multiplayer model, in the physics it handle the movement and in the process it handle particles, animations, etc, since the remotes dont use physics ( its handled by the host ) its disabled on they, but the normal process is normally enabled, only on the host all is enabled.

Demodulator

Answer 5

Try to eliminate object creation when benchmarking.

Maryrosemarys

Answer 6

Did you also try to stress the physics process? If you are only doing light physics I would not expect to see any benefits from running physics in a separate thread.

Yes, I'm stressing the physics system, that's the purpose of the benchmark.

I think Wines failed to put it into the right words. You should both have nodes with complex script logic and physics nodes stressing the physics system at the same time. Only then can you stress the main thread enough to see the benefit from moving the physics calculus to it's own thread.

edit: and even then you are left hoping the Operating System does the right thing and assigns the corresponding threads to separate physical cores. Which it should, but make sure to double check that while running your benchmarks.

Hermes

Answer 7

One of the tests I have done has been precisely that. In addition to the rigid bodies moving all the time and stressing the physics process, I have added another node that performs matrix multiplications to stress the logic side, the CPU. Moving the physics computation to a separate thread has made no difference in this case.

Woermer

Answer 8

Moving the physics computation to a separate thread has made no difference in this case.

Ah, but did you sanity check to make sure the OS does the right thing? Even if the process threads were assigned to different threads by the OS, they might still have been SMT threads on the same physical core.

Also possible the bottleneck is something like draw calls of the renderer instead. Maybe consider running the exported godot project through something like RenderDoc and have a peek.

Hermes

Answer 9

No, how can I ensure that each process is on a different core?

Woermer

Answer 10

Alas, far as I'm aware that is left entirely up to the OS. What a player can do is use something like Process Explorer to assign a process to a limited subset of cores, but the actual threads are assigned by the OS. Doing so is useful for an example on multi socket/cpu systems or the first gen Ryzen systems where there is a huge overhead to traversing across multiple core complexes(a latency hit).

https://superuser.com/questions/867127/determine-which-cpu-a-process-is-running-on/867452#867452
According to the above linked StackExchange answer if you are using Windows you can capture a XPerf trace and view it with Windows Performance Analyzer to follow the thread assignments with tho. See above links for more info.

Hermes

Answer 11

You generally can't affect core allocation for threads. It's the OS' responsibility.

Beware not to get caught up in premature optimization though, doing random "stress tests". If you have some actual requirement for your project, better to test specifically that. Hardware's parallelism doesn't behave "linearly" and it's often hard to predict its performance outcomes in a general way. Always better to benchmark as specific as possible, and on as many different hardware setups as you can.

Maryrosemarys

Answer 12

I'm not trying to optimize, just discover the meaning of the option to move physics to another thread. This benchmark project is only useful for that.

As for testing on different hardware, so far I have tested it on my laptop (with Linux) and on a Mac Mini. In both cases the result is the same.

Woermer

Answer 13

The benefit is to run it on a separate core. However, this is never guaranteed. Even when run on a separate core it is not guaranteed that you'll get a significant performance boost in every situation.

Maryrosemarys

Answer 14

I see. I understand that this option can be something significant for a large and complex project where you have to be careful which threads execute what things, I understand that my small benchmark is not the ideal scenario to check it.

In any case, thanks for your answers.

Woermer

Answer 15

Just keep in mind, that the physics is handle by a "different engine", so while a go godot was using bullet engine, nowadays its using an new engine, but keep in mind that almost every game engine, have an api that connects to an external physic engine that handles physics, you can for example, change the physic engine for your game, to use havok or something else. I know there are people here that uses bullet with godot 4. In the integration api of havok and I think also in bullet there are some advanced configuration to set the use of cpu, but I am not sure the current engine have this option.

Demodulator

Answer 16

Some info about godot4 + bullet engine : https://mcmap.net/q/14/godot-bullet-physics-in-godot-4

Demodulator