9thFinger's ThreadingMod

[FrodoOf9Fingers]

Oh, and don't worry, this will release for B18. If B19 comes out during that time, then I'll see how much work it is to update it to that. Already merged my work to work with B18.

[FrodoOf9Fingers]

Definitely watching. I have an i7 3930k waiting to eat Rimworld alive...

Just a request, B18 please. You'll have less work to bring it to Rimworld's 1.0, then having to migrate from A17 to 1.0. That, and B18 is getting more mods daily, which means modders are learning to update their code to be more efficient and subject to less errors.

Oh, and I should nip this in the bud:

I am making no guarantee whatsoever that the game will run better when multithreaded. Multithreaded can actually make the game slower. While it is typically expected to be the case, sometimes multithreading doesn't work. Again, no guarantee, though I am trying for it. Don't get your expectations too high now

[Harry_Dicks]

Oh, and I should nip this in the bud:

You heard it here first, fellas! FrodoOf9Fingers is promising 200+ fps on a late game, 50 colonist, decked out colony, running 300 mods, with only my Core II Duo!

I'm so grateful we have multi-threading GODS like Mr. 9Fingers here promising better performance for everyone!

[Nightinggale]

I am making no guarantee whatsoever that the game will run better when multithreaded. Multithreaded can actually make the game slower.

I'm currently working on making the main update loop of the game multi-threaded. Currently, every "thing" does it's "tick" on the same thread, I'm working on splitting the work into separate threads.

I think it would be best to make categories of "thing"s and add the ability to turn each category on/off. It doesn't really matter if it requires a recompile or not to turn one category on/off. The benefits would be:

• Allows only using the speed boosting code
• Helps identify slowdowns, which might be fixable
• Allows documenting the impact of each change
• Allows documenting the impact of multiple approaches to the same code

While 1-2 will help players when the mod is finally released, all list items should be able to help writing a better report. Your grade will not depend on how well your code works, it will come (partially) from how well you can document your code, the impact of your changes and how you use your documented facts to write a report.

Also while we would like to get a working result ASAP, you better talk with your advisor about when you can release anything. We don't want you to get problems because some report checking bot has detected that you handed in code, which can be found online. They do in fact use such automated report checking code and possibly for the code as well since it has become way too easy to copy from online sources. You can include code you didn't write (like Harmony), but then you have do explicitly write that you didn't write it and precisely what you didn't write (like everything in this sub folder) to avoid issues of them claiming you claim credits for writing it. The same goes for writing quotes in the report. It's ok if you explicitly write where you copied the text from.

[FrodoOf9Fingers]

I won't have to worry about someone accusing me of copying someone else's code. I won't go into reasons, but this is for a bachelor's degree and I'm on good terms with most of the teaching staff.

I guess you could at things via categories, plants don't need a mutli threaded pathfinding system, for instance. It's more work though and is beyond the requirements I've set. So it'd be a stretch goal. It might be worthwhile later.

I've only got 2 known bugs atm. Once I get them fixed, it may be time for public testing... So if things go well, you guys should be able to play with a (probably, very broken and buggy) version within a week!

[FrodoOf9Fingers]

Fix one bug, a million others pop up O.o

Still working, working on a strange bug, something to the effect of:

if (thisQueue.length <= 0)
{
    return;
}
obj = thisQueue.pop();          <---- throws an "Arguement out of bounds" error.

Tis fun .

[Kiame]

Haven't been following this thread but the last post has piqued my interest.

Is the queue shared in any way? Are you able to specify the type of queue? ConcurrentQueue.TryDequeue would be advisable if so. Or (slower) ThreadLocal<Queue<?>> might also work.

Otherwise that may need to be surrounded by a try/catch. Maybe in the catch check if the length is 0 with a log error printing the length. 

[FrodoOf9Fingers]

The code Tynan's, and I'm trying to change as little of it as possible (as using reflection/Harmony will slow the program down). In order to debug it, however, I detach his code and replace it with a copy of my own using harmony.

The probable cause is that a thread is coming in after the conditional portion of the if statement and altering the state of the queue. This shouldn't be happening (in most of the cases), as only one thread even has pointers to the said object. Unless somehow multiple threads are trying to use the same pathfinder object (in this case) at the same time, but I review my code controlling how threads get matched up to pathfinder instances and it doesn't seem possible. It happens in a few other cases. The root cause is unknown O.o, but once I find I'll probably say "Oh duh!"

The interesting thing is, if it happens once, it'll happen thousands of times. Otherwise it doesn't happen at all.

In other news...
There's a crash bug inside the code, though I know the fix (mostly). And there's a bug that makes so you have to restart rimworld before you can load a 2nd game.


EDIT: Multiple threads on the pathfinder object wouldn't cause the issue either. Something is just modifying the queue while what I except to run is working.

EDIT EDIT: The answer, in one case, is that I didn't realize that there was a PawnPathPool.

[FrodoOf9Fingers]

To be specific, the queue is the handmade FastPriorityQueue class made by Tynan.

[Kiame]

i've done some looking at the pathfinding and iirc it assumes single threaded and shares the same pathfinding object/s - don't remember if it was a shared instance or static class off the top of my head, i think it was static though.

[FrodoOf9Fingers]

i've done some looking at the pathfinding and iirc it assumes single threaded and shares the same pathfinding object/s - don't remember if it was a shared instance or static class off the top of my head, i think it was static though.

It's non static, theres one instance per map.The bypass involves creating multiple instances of the Pathfinder object (a copy actually, to avoid patch looping) in a pool and patching the findPath function of the original pathfinder object to a function that grabs an available copy of pathfinder and running its findPath.

This wouldn't be required if pathfinder didn't store algorithm state data as object members O.o.

[FrodoOf9Fingers]

Checking in, things are progressing. Knocking bugs out one at a time, so fast and some very, very slow (curent bug has taken about 10 hours so far).

[Jagerius]

Any news on this one?

[HexCube]

Just curious, is this still being worked on? How's it going, if so? No rush, just interested

[FrodoOf9Fingers]

Well, I got it to a decent point with not that many errors, but the non-intrusive approach I was taking produced minimal results in actual speed. There's just too many parts moving on a global scale.

I still graduated though, so my interest in this has died down. The work was really rough to gain little progress due to lack of good debugging tools. I've moved on to a different hobby project too that maybe someday will be fun for others to play.