How to use the multi-thread K-Mod path-finding in my Mod?

[mediv01]

I found there are multi-thread K-Mod path-finding in WTP mod based on TPP. But I do not know how to copy it to my own mod.
Should I move the KmodPathFinder.h and KmodPathFinder.CPP
and used it in CvUnit::generatePath()?
Should I change the makefile and ompiler option? Thanks a lot

 

[Nightinggale]

@devolution wrote this, so maybe he has something useful to contribute.

I will say that there are WTP specific code, like GLOBAL_DEFINE_MOVE_DENOMINATOR. I think it's called GC.getMOVE_DENOMINATOR() in vanilla BTS. The loop with RouteTypes relies on WTP code, which adds FIRST_ROUTE, NUM_ROUTE_TYPES and the ++ operator to enum types.

for (int iRoute = 0; i < GC.getNumRouteInfos(); ++iRoute)

That should do the same, through it's not type safe like in WTP.

 

[devolution]

@mediv01
Now that is a novel idea, back-porting the multithreaded K-Mod pathfinder to BTS

But on a more serious note, which mod serves as the foundation for your own mod? I also advise caution, as WTP features significantly more complex 'canMoveInto*' functions and lacks essential caches, particularly for danger checks. This complexity could enhance the effectiveness of multithreading. However, both K-Mod and AdvCiv, especially the latter, are likely more efficient. As a result, multithreading in its current state might not be advantageous. This concern is why I've limited the iteration space, restricting maximum concurrency to just 2 threads. My apprehension stems from the possibility that there may not be sufficient work per thread, considering the overhead associated with TBB's operation (such as work-stealing). If we didn't limit the iteration space (which currently has a maximum of effectively 7), we could face a scenario where tasks are allocated too little work relative to the scheduling overhead.

 

[mediv01]

@mediv01
Now that is a novel idea, back-porting the multithreaded K-Mod pathfinder to BTS

But on a more serious note, which mod serves as the foundation for your own mod? I also advise caution, as WTP features significantly more complex 'canMoveInto*' functions and lacks essential caches, particularly for danger checks. This complexity could enhance the effectiveness of multithreading. However, both K-Mod and AdvCiv, especially the latter, are likely more efficient. As a result, multithreading in its current state might not be advantageous. This concern is why I've limited the iteration space, restricting maximum concurrency to just 2 threads. My apprehension stems from the possibility that there may not be sufficient work per thread, considering the overhead associated with TBB's operation (such as work-stealing). If we didn't limit the iteration space (which currently has a maximum of effectively 7), we could face a scenario where tasks are allocated too little work relative to the scheduling overhead. I

My base mod is Dawn of Civilization, and it is a mod mod from Rhye's and Fall of Civilization. It contains BUG Mod but it does not contain K-Mod

 

[mediv01]

@mediv01
Now that is a novel idea, back-porting the multithreaded K-Mod pathfinder to BTS

But on a more serious note, which mod serves as the foundation for your own mod? I also advise caution, as WTP features significantly more complex 'canMoveInto*' functions and lacks essential caches, particularly for danger checks. This complexity could enhance the effectiveness of multithreading. However, both K-Mod and AdvCiv, especially the latter, are likely more efficient. As a result, multithreading in its current state might not be advantageous. This concern is why I've limited the iteration space, restricting maximum concurrency to just 2 threads. My apprehension stems from the possibility that there may not be sufficient work per thread, considering the overhead associated with TBB's operation (such as work-stealing). If we didn't limit the iteration space (which currently has a maximum of effectively 7), we could face a scenario where tasks are allocated too little work relative to the scheduling overhead.

Why multi-thread in path-finding for WTP does not improve the speed. I have read a thread that it claims that the TBB improves 50% of the speed of WTP. Mostly improve in path-finding. Is it that true?

[IMPORTANT] Multi-threading in WTP mod - [required to run the mod]

Hi guys, please note that the DLL you can currently build from "New Hope" already uses multi-threading now, since it was merged with "develop2". (It is supposed to dramatically increase performance to values currently unknown by any other Civ4BTS and Civ4Col mod.) This branch uses Intel...

forums.civfanatics.com

 

[Nightinggale]

I have read a thread that it claims that the TBB improves 50% of the speed of WTP. Mostly improve in path-finding. Is it that true?

Most likely not. None of the WTP team members announced 50% or any other number for that matter.

i.e. if it's really a 50% improvement, that leaves a lot of room to use part of the gains to include features previously discarded.

This doesn't say that it is 50%. Instead it says that if it is, then the speedup can be used to spend more CPU time on features, which have been discarded for being too slow. It's not a team member making this statement and I'm not entirely sure I agree. I would rather just have the AI working faster.

I also advise caution, as WTP features significantly more complex 'canMoveInto*' functions and lacks essential caches, particularly for danger checks.

For this reason I plan to do a complete rewrite of CvUnit::canMoveInto. However I'm not sure how interesting that would be for BTS mods. After all it will be designed to handle WTP specific issues and WTP has a bloated function to begin with.