Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Trensicourt]

I play with a lot of mods. When I load the game, even with my SSD, I find that the issue is that the game is using one core to load. The application process I see is Java(TM) SE Binary. This is fine. But when I am in the game with about ~30 mods, Java(TM) SE Binary hits 90%+ core usage. This causes stuttering after a half hour session. This forces me to close the app, letting my single core cool from turbo boosting for so long. I am wondering Starsector doesn't use more cores, especially these days where many CPUs have around four cores per CPU.

My processor is a i7-9750h and my graphics card is a GTX1650. I can tell for sure that the limiting factor is the single core usage from my six cores.

[Nick XR]

This causes stuttering after a half hour session.

Sounds like something (probably a mod) has a memory leak and the GC is "thrashing"

You could up your allocated memory and it'll take longer before the system gets in that state.

Regarding using multiple cores, it's hard-sh to do generally and especially hard to do in games.


To quote someone on Reddit who did a decent job of explaining why it's hard (from https://www.reddit.com/r/Games/comments/nj7tc/why_dont_pc_games_take_advantage_of_multicore/)

here is the deal. Games. are not a stream of data that can be encoded and decoded to 100% take advantage of multiple cores. the game depends on your decision. so you're not doing the same thing over and over like decoding a video or running a benchmark. when if you know what textures you have and you know what image you need. your PC assigns this Core to do this and this core to do that.

well when it comes to games. a thing is thrown at instance at the CPU when you move you mouse left or right or any other action. there is no repeated action or a part of code that is already pre-defined. its not a video thats static. it really depends. so thats why single core > multi core. now multiple cores do help some things but they cannot help as much as single core clock and IPC because video game instruction are hard to parallelize. your CPU tries to process the data it gets as fast as possible. if you have slower but less cores well. its still gonna take you longer to process the information you need for that frame instantaneously because you can't assign the Other core to process the next frame because the computer doesn't know what the next frame is unless you decide. its about timing and IPC now how wide the information Bus is. multiple cores basically make sure you won't get bottlenecked by other things but they will not do much for you really.

So you could then ask "Why can't AI/RangeCalculations/SomeCpuIntensiveCalc be on the another core, that'll make it faster!", well often the cost of dispatching the calculation to be computed to a different core, solving that calculation,  then synchronizing the memory states to do a xfer back tothe main thread is MORE work than just doing it on the main thread. So you're generally going to be unable to parallelize any per-frame action (or that's my guess anyhow). From what I understand, games that do utilize a lot of threads are doing streaming or decoding or network stuff in the background. But maybe I'm wrong on this; and I'd love to hear about what parts of a game engine are parallelizable!

[Thaago]

I don't know about game engines in particular, but I know from high performance code that if I don't design the tool from the beginning to be able to be run on multiple cores, it can take a total redesign to make it do so efficiently. In that case its mainly an issue of synchronization and data parceling/transfers, and you have to know the memory architecture of the machine its going to be running on for best results.

I suspect that there are probably lots of things in SS that could be offloaded onto other cores, but that doing so would take a lot of coding time and thought to make sure everything is still happening correctly. And this is probably code that hasn't been touched in years, so remembering how everything works might itself be a decent time sink. Given that the game runs well enough in most use cases, its just not worth the effort.

[bobucles]

Threaded code does not imply concurrent code. Loading up dozens of threads will definitely burden your computer with the extra work needed to juggle dozens of threads, but not necessarily result in any benefit. If the job is very simple or highly interdependent on other threads to do its job, the thread load will cost more CPU time than the thread benefit gives.

Concurrent code makes more sense when you have very difficult tasks that provide simple solutions. Pathing algorithms are a huge example. Calculating a path starts with a large unchanging data set, can take a huge amount time to complete, and there's no real interaction with the game sim until the task is complete. When complete it spits out a sequence of waypoints, which is little more than a data sequence. It also makes more sense in codecs and video cards, because the job of "what color belongs on this pixel" multiplies very well when you have millions of independent pixels doing the exact same thing.

[Zeeheld]

To quote someone on Reddit [...]

Looks like you just broke the golden rule of the internet: Reddit is ALWAYS wrong.
Multi-core programming is certainly a damn sight more difficult to program than single core, but there is no conceptual barrier preventing multiple cores from ever being viable as that redditor put it. That redditor was tipping his fedora a bit too hard.
And while it's true that it's the software that is bottlenecking the hardware, it has been that way for quite some time and progress is being made, if ever so slowly. However, since Java is only below php in awfulness as a programming language, I don't think we'll live to see Starsector running multi-cored.

[AgentFransis]

However, since Java is only below php in awfulness as a programming language, I don't think we'll live to see Starsector running multi-cored.

wat.jpg
What has Java's fugliness as a language have anything to do with adding concurrency to Starsector? The core library has all the concurrency primitives you need easily accessible and the JVM is perfectly happy to run lot's of threads. Unlike, for instance, horrible hackjobs like Python where the interpreter just chokes on them, forcing the entire ecosystem to use subprocesses like it's 1979.

Like Thaago said, it's mainly a question of examining the code to find independent sections that can be parallelized and wrapping it all in the correct sync primitives to maintain correctness. And then spend a year debugging it.

[Yunru]

I imagine things like fighters (where they only occasionally interact with other systems) would be easiest to multithread, although I
A- say easiest, but not easy
and
B- know about as much as John Snow.

[Alex]

And then spend a year debugging it.

That's really the crux of it, except it's more like "a year, and then something like half your time going forward". Multithreading for *this* sort of thing makes the code way more complicated and bug-prone, and also makes the bugs much harder to reproduce, diagnose, and fix. Starsector does do multithreading for a few things where it's a good fit - namely, music streaming, and some tasks while loading the game - iirc sound decoding is done on another thread, as is the compilation of loose scripts by Janino.

Plus, using multiple cores helps more on the high end than it does on the low end (which is where more help is needed), so if I was going to put a lot of additional time into optimizing, I'd probably utilize it in other ways...

This causes stuttering after a half hour session.

Sounds like something (probably a mod) has a memory leak and the GC is "thrashing"

You could up your allocated memory and it'll take longer before the system gets in that state.

Yeah, that seems pretty likely! Some common kinds of mod-memory-leaks only ever double the required memory and don't keep growing beyond that, so increasing the allocated memory could actually resolve the issue entirely.