feat: Multithreading

[L3tum]

Hallo!

I like to build base and have big map. I noticed a while back that Celsius didn't seem to scale all that well with larger map sizes and got curious how it did its thing. From that this change was created, which I've been using successfully in both "standalone" and a larger (~200 mods) modpack.

Changes

• Explicit Array.Clear rather than creating a new array for thermalProps. Afaik this works out to the same code once the compiler ran over it, but I personally dislike these rather hidden and unexpected optimizations. I also don't know how Mono plays into it
• The #if DEBUG conditional compilation was removed to be able to actually activate debug logging at runtime without recompiling
• TicksPerSlice, SliceCount, slice and so on were removed and instead the whole map is updated all at once
• The whole-map update uses a worksetTemperature array to prevent a single temperature change to propagate across the whole map in a single tick
• The whole-map update takes place once every TicksPerUpdate, rather than 4 times and every TicksPerSlice (which was 1/4th of TicksPerUpdate)
• TicksPerUpdate can now be upped to 1000 ticks, since I like to play on speed 4, which aims at 900 TPS. Default wasn't adjusted
• The rare update stuff (like colour and thermal properties) were moved to be changed on every iteration, which works out to the same timing as previously, just without the slice stuff
• The temperature update calculation was moved into a background thread which is synchronized to the ticking on the main thread
• The temperature update was parallelized (pretty naively with a Parallel.ForEach)
• Some comments were added (half of which so I could make sense of what was happening when)

Results

• Before (on a 600x600 cell map): Average per-tick timing was 1,2ms, however the tick the computation happened on took ~10ms, and the rare update took 150ms -> Some stuttering when the update happens and higher speeds or larger maps are pretty bad. Max speed was 400 TPS
• After: Average per-tick timing is 0ms, and the background thread computing the whole map takes ~8ms (albeit on my 5950X, so less powerful CPUs will likely take longer) -> No impact on the game simulation, max speed is 900 TPS (maximum)

Questions

I'm new to Rimworld modding and know Rimworld and its creators don't really like Multithreading. I tested these changes extensively though, but:

• I haven't caught any errors regarding synchronization. From my understanding all the code does is read from Rimworld structures, then (asynchronously) update its own temperature array, then provide that array to Rimworld (on the main thread again). This should be fine and should not cause race conditions, but in particular the snow melting/freezing seems to work but I'm not sure about.
• I've tried continuing to play on an older save with a large modpack (~200 mods) and the game crashed after loading the save. I couldn't find any errors except the game process literally froze. I tested some more and while I couldn't find any reason for it to be happening, and the save was kinda skuffed already, I do want to mention it
• The default update interval (120 ticks) is pretty hard on the CPU when you play at speed 4 (since it's essentially 900 / 120 = ~7.3 updates a second). That's a lot, even parallelized. I would propose upping it, or maybe changing it to be an updates per second/seconds per update setting rather than per ticks. We could still use ticks internally
• I tried to test a lot but obviously couldn't test everything. I'm not sure what happens when you raid another settlement or what happens on Anomaly-specific maps (I don't have that DLC)

Further work

• Periodically clearing the thermal properties and room temperatures isn't optimal. It would be better to either only clear part of it, and not delete the dictionary completely and instead reset the values to a default value (like float.MinValue)
• I think some of the stuff from Rimworld can be cached and used to optimize the data structures, like cells and cell indices. It's not like we're suffering for memory usually, but I'm not sure how they are handled internally by Rimworld, and how it could affect some things (like embarking) or how much performance it would improve

I'm happy to discuss this change with you and I'd be fine if you would want to make it a setting or fork or something like that. I haven't published it to the Workshop, just forked for the code commit.

[L3tum]

I just noticed that I think from the change to the worksetTemperature there's now an issue with essentially "infinite energy" being pulled, since the calculation takes temperatures rather than worksetTemperatures into account. I need to think a second on how it could be mitigated without impacting the multithreading too much, so I converted it into a draft. My first instinct would be to, instead of having a worksetTemperature, save the temperatureChange and then cumulatively applying it. It would reduce performance a bit but not by much. I'm not all that well versed in energy simulation. If you have any input or any sources I could read I'd appreciate it. Most of what I can find is highly scientific and less about the nitty gritty of performantly simulating it.

The few things I've found, i.e. 1 and 2 seem to simply accept the error as is from what I could tell. That feels a bit weird although is probably acceptable for a game.

[L3tum]

lol, disregard the above. I thought of it as a discrete energy transfer rather than simultanously solving the same function on multiple inputs. I got spooked by the temperature on a testmap steadily rising, but it reached an equilibirum after ~2 ingame hours. I'm gonna add another comment to the code to explain this as well just to make sure. At least this also means we could get another significant speed-up with some SIMD acceleration, especially around the terrain code I guess.

That mentioned, I did also try to have the different components (terrain, cell, ambient) in different functions so that they could be throttled individually as well, but I found it made the code a whole lot more unreadable. At least the melting code could be separated, but I'll let you look over this first to see what you think of it.

[GarwelGarwel]

Hey, this is a great effort, and something I wanted but never had the heart to do. I have almost no experience with multi-thread programming. All I know about it is that it may be a hell to debug. But if the code works well, it's a huge improvement.

Don't forget to mark the PR as ready when it is, so that I could test it and see how best to integrate it.

[L3tum]

Hey @GarwelGarwel , thank you! I had a few issues with a borked Rimworld installation, but after reinstalling I could test the ice/snow melting and it works for both terrain and cell and replaces an ice sheet with water. That was the major thing that I didn't know if it would work accurately in multithreading, but it does, so the PR for me is gtg and I'll undraft it in a sec. Regarding SIMD I noticed Unity is still using Mono, which doesn't support the newer SIMD stuff that .NET Core 3 and later put out. Honestly thought it had already moved over at least for desktop, since they published plans for that a few years ago. So that's unfortunately a no-go for now, afaik