Needed Starmade Performance Optimization: MultiThreading

[BDLS]

le bump for Schine response to op

 

[PizzaPress]

From what I've heard, multi-threading ain't easy.
The problem is that some of these things have to be done sequentially, making certain things hard, if not impossible, to multithread.
Now if there are independent interactions occurring(two collisions are occurring in different sectors), that might just be multithreadable?
The game should be using multiple threads, but not every part can be multithreaded.

 

[Knack]

The sector system same as the systems and galaxies are perfect for multi threading.
There is no real reason why a lagging sector on the other side of the galaxy is affecting me.

 

[Parameter]

Agreed that it would seem the sectoring of the world would allow for a lot of multithreading optimization, since you can find lots of common cases where events happening are completely independent.

However, if your application isn't architected to support multi-threading, it can be a pain to refactor all of your code to be thread-safe. In addition, debugging becomes significantly harder when you're dealing with threads and their interactions. Don't ask me how I know .

It would be nice if that "Read by Schine" tag got used a bit more...I know of several suggestion threads with Schine interaction that don't have that tag. Just cause its read doesn't mean there has to be a response - it's just nice to know the developers are listening to our noisy echo chamber.

 

[Knack]

However, if your application isn't architected to support multi-threading, it can be a pain to refactor all of your code to be thread-safe. In addition, debugging becomes significantly harder when you're dealing with threads and their interactions.

I've done this multiple times now, it's nothing impossible.
We have also seen that schema is able to refactor the code and replace big parts with new algorithms. (Universe Update/ Turret-Rail Update)

Only make sure the database is not the next bottleneck. Passing entities between the threads should also be not that problem, especially not in comparison to the already existing glitches when passing sectors.
When multi threaded sectors are done, the collision detection could be outsourced to the client if only one player is in a sector. (I know, exploitable by cheaters but random plausibility check can face this problem)

 

[Parameter]

I've done this multiple times now, it's nothing impossible.
We have also seen that schema is able to refactor the code and replace big parts with new algorithms. (Universe Update/ Turret-Rail Update)

Only make sure the database is not the next bottleneck. Passing entities between the threads should also be not that problem, especially not in comparison to the already existing glitches when passing sectors.
When multi threaded sectors are done, the collision detection could be outsourced to the client if only one player is in a sector. (I know, exploitable by cheaters but random plausibility check can face this problem)

I agree, not an unsurmountable problem at all, just one that may take some time. I don't know how Schine racks and stacks their development tasks - they may prefer to get more alpha features in for testing than optimize servers for better high-player count performance. It would be nice to hear from Schine if this is anywhere in their pipeline, though. Not sure who would be in a position to respond to this. schema, of course. Calbiri perhaps?