9thFinger's ThreadingMod

[Deathawaits4]

Hei, i was trying to pick up on something like this. My approach on this would be to put pathfinding and unused objects on different threads. I dont really think there is anything else that would profit from multithreading. Pathfinding is eating up most of your cpu late game, while i am still fairly unexperienced, a friend who is a game dev is giving me alot of insight in his multithreading work(he is a network developer for online games). He also played rimworld alot, and this was his answer when i asked him:

Multithreading is not just throwing stuff onto a different Core, it has to be used in a effective and clever way. Most things will get slowed down but one thing that will profit most of the time is the pathfinding. This is really hard to implement but not impossible if you are dedicated enough. It might take 2 years and can break compatibility, there is no way around it. Some mod authors will have to make their mod compatible with yours, it is not possible on your end.

Sadly he is working with c++ and can not really help me with my task except telling me what steps to take. I have now 1 year of experience in working with unity and i do want to create my own game at some point. This would be a good task to increase my skills. Like the OP i cant promise too much, but i am really dedicated since i want to play rimworld lag free myself. I havent started anything yet.. i am still planing, propably releasing some other mods first in order to get used to everything. But i am confident.

[Kiame]

Pathfinding should be doable as initially just the claim system would have to be analyzed for thread safety. Might be able to use something like the thing if as the lock (concurency might be possible by adding a new component to things)

I've been curious to try my hand at multithreading rimworld but my other mods keep me busy enough =P

[RawCode]

you can't implement MT by dropping random "component" into random place.

start small, implement (yourself) collection (do not take blocking queue or any other stock implementation and do not ever try copyonwrite collections, they are fine but not applicable in case of RW) that support add,remove,read from multiple threads at same time.

to check is write collide, start 10 threads that will add fixed amount of objects into collection at same time, measure result in performance.
best case if you can measure spinlock await time of each thread to estimate real loss of cycles on write sync.

then predict case, where two or more threads calculate path for multiple pawns and end in  pathing into same cell, first thread will be okay, two remaining will be forced to recalculate path, and they may end again in pathing into same cell.
As result, your super MT logic will result in 4x more calculation for no reason.

this will explain you, why trying to implement MT without any reason is bad.

as long as you do not know exact bottleneck, trying to fix it is waste of time, going MT unconditionally also waste of time, as solution may be more simple and effective then MT.

[MostNimbus]

Rest in pepperoni