Threading Framework & Threaded Collisions#6814
Conversation
|
This is great! I do wonder how this compares to using collision groups for optimisation’s sake: Can we go without them in the future without too much trouble or is collission checking still a heavy-but-now-more-managable concern? |
|
Overall collision groups just help with ship to ship collisions, while this kind of threading helps with all collisions including weapon to ship collisions. Ultimately to get the most performance it would be good to still use collisional groups when possible. |
|
With really collision-heavy missions, you gain at most a factor of two in terms of performance currently, so if you'd add more than twice the collisions with collision groups, you lose all the speedup this gives you. |
wookieejedi
left a comment
There was a problem hiding this comment.
Works in all my tests thus far, and is especially invaluable in speeding up heavy missions with lots of lasers/weapons.
This PR adds a somewhat generic system to manage helper threads for FSO.
For now, it is gated behind the CLI flag
-threads <n>, where n has to be 2 or larger to activate threading. Note that due to this being heterogeneous multithreading with a main thread and n-1 helper threads, only 2 threads will likely not see much improvement at all.To achieve that, FSO will manage an arbitrarily large helper thread pool that can be spun up for specific tasks, such as collision. In the future, AI turret behaviour or model load could be parallelized as well, but that's out of scope for this for now.
Performance-wise, a 4-thread FSO can achieve almost 1.8 times speedup compared to singlethreaded FSO in CPU-heavy but still reasonable missions:


In missions that are not CPU-bound (i.e. they have only very few collisions, in this case the performance cost is almost entirely GPU-latency based), like Icarus, the PR at least doesn't reduce performance, and can cause small uplifts in heavy sections:
For collisions specifically, the flow diagram looks approximately like this:
