KSP CPU utilization? Any ideas on whether KSP2 will handle math-intensive processes more efficiently / take advantage of modern archetectures?

[JoeSchmuckatelli]

This is more of a computer-nerd question than something particular to either KSP or KSP2.

I'm hoping to hear from folks who've previously looked into the hardware limitations that affected some users when they built high part-count craft.  My understanding is that these became CPU bound (given that the graphics demands of a 10 year old game should be slight) and as such dramatically reduced frames on some machines.

While I haven't delved effectively into KSP's issues to know what the issues were - in other games I've heard the problem is inefficient use of multi-core processors or threading of processes.

Anyone already done a deep dive into this and can comment?

 

 

(Bonus points if you can explain the problems observed with KSP's design and how you hope KSP2 will handle similar requirements).

TIA!

[kerbiloid]

All KSP resources are loaded at once, instead of loading/unloading on demand.

Originally very ineffective texture graphics formats were being used, later replaced with dds. They took a lot of RAM.

Edited November 1, 2022 by kerbiloid

[Ryaja]

On 11/1/2022 at 12:19 PM, kerbiloid said:

All KSP resources are loaded at once, instead of loading/unloading on demand.

Originally very ineffective texture graphics formats were being used, later replaced with dds. They took a lot of RAM.

All games preload everything, it makes them run faster because they don't have to pause to fully load things

[kerbiloid]

7 hours ago, Ryaja said:

All games preload everything

No. Usually they load what's needed and unload what's not currently used. That's how you run a 30 GB game on 8 GB RAM.

[Ryaja]

10 hours ago, kerbiloid said:

No. Usually they load what's needed and unload what's not currently used. That's how you run a 30 GB game on 8 GB RAM.

Preload not load games that do not preload are much slower

[Nuke]

On 11/1/2022 at 10:19 AM, kerbiloid said:

All KSP resources are loaded at once, instead of loading/unloading on demand.

Originally very ineffective texture graphics formats were being used, later replaced with dds. They took a lot of RAM.

dds is still pretty antique. they were introduced on s3 graphics cards way back in the voodoo era (voodoo cards also supported the format as well as its own inferior fxtc). there are newer formats like astc and etc that seem to see very little use on the pc (though are used heavily on smart phones and portable devices, possibly game consoles).

ive always advocated storing textures in a lossless format like png. at first launch the game can query the hardware for texture capabilities then transcode and cache the textures in the best available formats, and scale them for best performance. while some games do this, i suspect the lack of uptake may be due to the fact that its better to use the most compatible format to save space as the bulk of game data is textures. also perhaps game studios don't want to leak their production quality textures.

[JadeOfMaar]

Years ago, I read somewhere that while it's relatively very easy to make the hardware (and its firmware) that provide for multi-threading and hyperthreading, it's very hard to produce the software (mainly games) to truly take advantage of the same. Unless I'm mistaken, my understanding is that you can create all the parallel processing you want, but the end of these processes all come back to a singular one, the master thread that relies on all their outputs, and the idea of multi-threading is self-defeating to whatever degree depending on what the game is trying to do. Or it's (still) beyond the game dev's imagination to write, or the popular game engines/program languages to execute truly multi-threaded code.

It may still not be common knowledge yet but Squad used KSP to learn to use the Unity engine, so a lot of KSP's faults are due to literally "beginner mistakes and the band-aids for the boo-boos" ...and also that the Unity engine and its ecosystem were still very young back then so there would be a certain lack of docs, features and assets to borrow from.

KSP2 will handle large part count crafts much better:

• Intercept Games promised it, even naming a feature "Stateful Physics."
• Intercept Games is an experienced game studio before KSP2 existed, unlike Squad who got experience because they made KSP.
• The Unity engine is 10+ years older than when KSP1 first started.
• Increased use of procedural parts (of more kinds than just wings) means less parts to do math on for a given ship, especially on huge ships (interstellar transports or not).

[Nuke]

minecraft is one of those games which i think would benefit from strong parallelization. it doesnt of course, not stock, and not in either java or bedrock as far as im aware (i think optifine does as well as some server side stuff). mostly by doing chunk updates in parallel. spatial partitioning is already built in to the game. i figure do not simultaneously update two directly adjacent chunks simultaneously. logically define groups of chunks (say 4, 9 or any square array of them), lets call them hunks. each thread would process a hunk, one chunk at a time (each thread would process the same chunk in their respective hunks at the same time), such that no two adjacent chunks are simultaneously updated. if you have 16 threads, you could simultaneously update a 4x4 grid of hunks. which means your ginormous redstone powered base wont lag your machine anymore. you may encounter a race condition where some chunks process faster than others, leaving a lot of cores to sit idle waiting for the signal to work on the next one. while i think this is suboptimal. but remember you are doing 16 or how many ever threds you have, minus one or two to handle things like rendering and i/o  (rendering will also be sped up since you aren't handling chunks on that thread). i believe something like this is actually done in some servers, though it would be nice if it would also work in single player. still, big lost opportunity there. 

ksp2 will probibly have to use moving partitions to handle single craft or groups of craft interacting. a ship at jool likely has little impact in the kerbin moon system. problem is the same, as you are going to have densly populated areas with a lot of interaction as well as a bunch of loners in simple ships doing basic things. so the thread disparity is going to be a lot bigger than it is in minecraft. physics is usually a big n^2 problem, so finding some way to partition out interactions that can then be handled on other threads just dont matter to the current situation. radius checks and dot products of velocity in some agreed upon frame of reference is good enough to tell if ships have a chance of interacting at all. of course that only really applies to multiplayer. threading inter-part interactions on a ship is going to be a bigger problem and proximity will likely require it all be done on one thread. 

Edited November 3, 2022 by Nuke

[JoeSchmuckatelli]

On 11/3/2022 at 4:13 PM, Nuke said:

proximity will likely require it all be done on one thread. 

That's interesting - and makes sense.  Guessing that even large processes like that, which might have bound on a single core of yesteryear - even if still residing on a single core of today - would be less likely to be similarly bound? 

On 11/3/2022 at 4:13 PM, Nuke said:

finding some way to partition out interactions that can then be handled on other threads just dont matter to the current situation. radius checks and dot products of velocity in some agreed upon frame of reference is good enough to tell if ships have a chance of interacting at all. of course that only really applies to multiplayer

Why only multiplayer?  I would think that if the player had a satellite swarm and various things active in Kerbin and moons region when the player is at Jool that some process has to maintain what is going on (ISRU, science, etc).  Would they be likely to offload such processes to a separate core - or does that create a program complexity that outweighs the simplicity of running the whole KSP2 app on a single core? 

[JoeSchmuckatelli]

That last question comes from a dredged up memory that most games used to be written for 1 or two cores at most - likely because of Console limitations.  I really have no idea how programming has adapted to the new hardware 

[Nuke]

i think the problem is you cant work on two things that interact with eachother at the same time. this is bad in situations where you need to test every object against every other object, like physics and collision detection. thats why my minecraft example skipped adjacent chunks. if you need to propagate a redstone signal from one chunk to another, you need to be able to modify the edge of the adjacent chunk. then that signal is propagated to the other blocks when that chunk is processed. the 2x2 chunk would require the chunks be organized in a way where you can modify the edge blocks on both sides without them interacting with the same memory regions (say using quadrants within the chunk). otherwise you would need to do 3x3 hunks to keep the memory areas isolated. having two threads write to the same thing at the same time, especially something that is going to change the size of the structures. you have to process nine chunks instead of four, but other threads are doing the same in adjacent chunks.  you normally use semiphores and locks for this so you dont write to the same thing at the same time, but i think its possible to partition your world in a way you can multithread it without a whole lot of inter-thread communication.

need not be a multiplayer only thing i suppose. even ksp1 has rendezvous. it would be nice if it could handle multiple rendezvous simultaneously, but im not sure how you would accomplish that with only one player. ksp actually runs 2 different physics simulations simultaneously. the parts within a craft, and different craft. ksp 2 might also do physics siumlation on the other craft's parts. really if you are doing something to get both those ships shaking to the point where the inter-part interactions matter, you are probibly about to have a visit from the kraken very soon. 

i dont think languages often used for games and game engines, namely c and c++, ever added native multithreading features. so everything needed to be handled by the programmer or 3rd party libraries. lisp on the other hand is a language for supercomputers and is built around the idea of doing the same operations on multiple data. though i doubt you will find many games written in it (freespace did have a form of lisp for its mission editor). newer languages (read: ones i dont know about, but probibly c# is a good example) will no doubt have these features built in. lua had co routines but i dont think it threads them. 

Edited November 5, 2022 by Nuke

[kerbiloid]

And btw, KSP is written in C#, the language and platform (.Net) with memory garbage collection, which means it overloads the memory with unused chunks of obsolete data, periodically flushing them.

Edited November 5, 2022 by kerbiloid

[Nuke]

10 hours ago, kerbiloid said:

And btw, KSP is written in C#, the language and platform (.Net) with memory garbage collection, which means it overloads the memory with unused chunks of obsolete data, periodically flushing them.

the core unity engine itself is c++. c# is just the scrpiting api. its correct to say that ksp is written in c# because you can stay out of the (what modern coders call dangerous) c++ code and get the engine to do what you want. but you really want to be close to the metal at the low level where it matters. 

Edited November 5, 2022 by Nuke

[magnemoe]

On 11/3/2022 at 4:41 PM, Ryaja said:

Preload not load games that do not preload are much slower

Loading assets in games is an science. Preloading is loading stuff before its needed as game know it might need it soon, if you play KSP and set up an intercept with an space station, well you can start loading it as you will need it soon so you preload it. An open world game will preload map cells around you as you move so they are ready before you reach them. 
If you have an slow drive or cpu and an very fast plane in an flight sim you might move faster than the game can load. 
Memory is also important, PS3 and 360 had little memory PS3 had 256 MB of system and 256 MB video memory who was not much on release, so they had problems preloading unless they knew that they that would need next. Well that is hard in open world games. 
On an pc with lots of memory and an fast ssd, its brilliant if the game use it, also with lots of memory you keep old stuff as you might need it again. 

One thing KSP 1 did not do was render the model in physic before showing it. Benefit of this that you saw the base blow up rater than seen it blown up because landing legs freaked out 20 seconds ago. 

[magnemoe]

21 hours ago, JoeSchmuckatelli said:

That last question comes from a dredged up memory that most games used to be written for 1 or two cores at most - likely because of Console limitations.  I really have no idea how programming has adapted to the new hardware 

PS 4 and One has 8 cores and uses the same AMD x86 cpu, PS 5 and Xbox uses an upgraded version of this cpu. 
More an issue that multi core is hard to write for complex programs, its very easy if you have lots of small calls like on an web server, much harder then code has to do lots of calculations after each other. 
Then running code in parallel you also need keep track of the treads and have receiver wait for them is both is needed going on. 


 

[Nuke]

the rule of thumb is that arithmetic is free, memory is expensive, and communication is prohibitively expensive. if you can at all avoid moving the data over the pcie bus and instead use every bit of memory possible in the gpu, it will improve performance. procedural generation could stand to be even faster as you can just generate whatever data you need in the shader program. so long as generating the data every frame is faster than moving it from ram, you could save a lot of throughput for other uses. problem with procedural generation now is that most of it takes place on the cpu and thus incrus the transfer penalty, and you want to cashe it locally on the gpu to avoid that so it eats memory too. as a result you are starting to see geometry shaders that can generate geometry and textures on the fly. games run best when there is little or no bus traffic and thats why gpus have 8+ gigs of ram. where you have big open world games, keeping the bus idle frees it up for streaming in new textures and geometry for new areas as you progress. gpus are also starting to have direct access to storage to stream assets without bugging the cpu (sort of like dma for shared bus systems of olde). 

unfortionately i dont think gpu manufacturers are going in that direction, it seems like they are all in for ray tracing even though it is impractical at a consumer friendly price points and costs a lot of heat and power consumption. 

Edited November 6, 2022 by Nuke