- User Since
- Dec 18 2018, 5:32 PM (120 w, 5 d)
Nov 16 2020
I think I have an idea how we could implement global thread pool so it would be easy to migrate current pathfinder code, and also easy to use in future.
I'll publish the code for some minimal working version as soon as I finish coding it (should be tomorrow).
However, thread pool itself has little to do with pathfinder, so there is probably better place than this diff for discussing it.
Nov 14 2020
Aren't we already using a thread pool?
We create a few threads during initialization of pathfinder component and they stay running until component is destroyed.
Isn't that what thread pool is?
Apr 30 2020
Unfortunately, it's an issue with pathfinder.
Apr 28 2020
I've done a multiplayer game as you suggested.
There was not problems during the game and also playing replays works (tried different numbers of threads and disabled threading too).
There was however a problem with late game rejoin, because I got a segfault on instance that was rejoining.
I'm going to take a closer look at this issue now.
Apr 22 2020
Was the replay that you chose one that contained the hash, i.e. was a multiplayer replay? (One started in multiplayer mode, not necessarily with other human players)
No, this replay was only for performance testing purposes.
I tested it in multiplayer games already several months ago.
That was old version of the patch tough, so we need to make another test I guess.
Apr 21 2020
Minor changes once again.
Bumped years, and named threads.
Just few minor changes
Only lock obstruction manager when using threading.
Compatibile with latest source.
Patch currently fails to merge with latest source.
It's very easy to fix it tough.
Jul 24 2019
Tested on Jebel Barkal, Mainland, Lake, Snowflake, with AI and multiplayer.
Everything seems to work.
Jul 13 2019
Jul 6 2019
May 19 2019
Jan 5 2019
Using 255 threads was not the reason. I still get segfault. I will have to take a closer look at this bug...
Ok, I've figured it out. I got stack overflow because I've once set 255 threads and forgot to set it back to 6.
It was linux. I always use linux. And I've never had problems with RAM, and it is not what caused crash.
This is what callgrind told me about the crash:
Well, it's not ready. I get segmentation fault on Jebel Barkal. It's unclear why. It happened after 4 minutes of playing and wasn't caused directly by any of my actions. It happened while my units were fighting against gaia.
In that case, you should use "Commandeer Revision", which will mark you as author and will automatically put @wraitii as reviewer. ?
Maybe fixed issue with tests.
Well, button said "resign as reviewer". I've only intended to cancel my old review that is not correct anymore.
I'm still working on this.
Jan 4 2019
Changed thread number limit from 64 to 255
Jan 3 2019
Some changes according to comments.
Dec 30 2018
Thank you for response, I've already fixed all of issues you mentioned in inline comments except the one in test_Pathfinder.h
Added myself to programming.json
Some small changes. Updated years to 2018 in copyright headers.
I think it's ready or almost ready to commit.
Dec 29 2018
Patch now does pass unit tests.
Updated to be compatibile with lates commit.
Dec 28 2018
Sorry for whitespace differences again... This has to be an issue with my editor... :(
Fixed (some of) reported memory leaks. Merged with D53.
I've fixed reperted memory leaks (maybe not all of them but memory usage is significantly lower).
Some time ago I merged this with D53 on my computer and uploaded patch to forum. I'm not sure if it's ok to upload merged version here, but I only have merged version on my computer.
Uploading non-merged version would mean downloading latest version and applying all of my changes again, manually.
D53 is also about upgrading pathfinder and probably would be commited anyway so I think it's not bad to upload merged version.
Dec 26 2018
I am working on some bugfixes (see topic in forum). I had no time during christmas but now I will start working again.
Dec 23 2018
I guess playing a game fluent is more important than a replay being nice and smooth on all machines...
So I think, and that is why I suggested choosing optimal game parameters for players. Saving it in replay is only necessary for other players to play the replay correctly.
I think choosing optimal value of MaxSaneTurnMoves is important because it has large influence on gameplay quality. It's optimal value is different for different players so we can't just hardcode it like it is currently.
I will start working on this now.
Dec 22 2018
One could also run a match (set it to multiplayer, so that it records the simulation hash to the replay) and then replay that match. The replay mode tests the hashes and complains with an out-of-sync error if the simulation state differs somewhere.
I've already done that before submitting this patch :)
Dec 21 2018
In multiplayer matches, the 7 players with quadcores will always wait for the 1 player with a single core laptop. This can lead to the exclusion of players with less than average CPUs from multiplayer matches.
Players with slower hardware will always slow down players with faster hardware. This issue also exists without multithreaded pathfinder.
The CPU will heat up more. The cores are not available to other processes anymore. pyrogenesis will even consume more CPU power if players increase the population limits.
That's why I've added option to manually choose number of worker threads. If player experiences such problems he can set number of threads to smaller one.
Dec 18 2018
Debugger launch failed: No such file or directory