Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2]

Author Topic: Suggestion to split DF's pathfinding into asynchronous 2nd thread (2 cores use).  (Read 4808 times)

Shonai_Dweller

  • Bay Watcher
    • View Profile

Last time I got crazy stuttering and lag it turned out to be people being born at vast rates in the outside world (was fixed). So, what looks like pathfinding bug, might be something completely different.

You may be right and it was something i already considered that there's a chance of it being something that nobody could expect. That's how it usually goes with bugs.
Still, of the things we know to cause lag, pathfinding is at the top of the list
And the most difficult to improve to any notable degree, even by rewriting the whole game to be multi-threaded, so we're kind of stuck for the moment. Hopefully the map rewrite will help optimize the way sites work and reduce the bugs somewhat.
Logged

PatrikLundell

  • Bay Watcher
    • View Profile

Note that pathfinding BUGS will not be solved by performing the same flawed implementation faster, but by identifying and fixing the bugs. Lockups and extreme slowdowns are typically not caused by pathfinding being performed in a slow and sub optimal manner, but by pathfinding being performed an excessive number of times (for the cases where pathfinding IS the thing using the CPU/memory), and the correct action is to change the logic so the useless pathfinding calls aren't made at all.

That doesn't mean the current logic is perfect or that it definitely doesn't benefit from being farmed off to another thread, only that bugs should be separated from implementation and logic improvements.
Logged

Atarlost

  • Bay Watcher
    • View Profile

The bridge activation slowdown is pretty well linked to pathfinding as everything recalculates.  The slowdown during sieges is pathfinding related.  Pet population slowdowns are pathfinding related. 
Logged

PatrikLundell

  • Bay Watcher
    • View Profile

Large number of units in the fortress (be they invaders, inhabitants, animals, visitors, or reanimated critters in the caverns) cause slowdowns due to their volume, true. However, I'm not sure there has been any stringent analysis that has shown that path finding in particular is the cause of the volume slowdown (as opposed to e.g. the task of moving all those critters along the paths previously calculated by path finding, collision detection [which may result in the need to calculate paths to move around the obstacles, although those path modifications are typically rather small in themselves], or other issues caused by the number of critters moving around).

Although I haven't seen it myself (no noticeable slowdown as I close/open the last entrance to my fortress in the face of invaders, but on the other hand I give those orders while paused), cutting off the only access through a heavily traveled path ought to logically result in a need to recalculate a large number of paths, and if your setup toggles that access on and off regularly you're probably going to suffer (including from cancellation spam when hauling tasks have to be dropped, and the subsequent bump in job allocation as all those dorfs have to be given new tasks (with their attendant path finding, as well as job selection based on distance, of course)).
Logged

Sarmatian123

  • Bay Watcher
    • View Profile

Lets also not forget, the mass pitting unfixed issue. You still need to pasture a blinking and chained dog and re-chaining it back, to fix mass pitting in most cases. I bet this is an issue alike the pathing through closed doors, but it has other "FUN!" effects rather then hit on fps.

Can we agree, that there is an awful lot of invisible errors, which current coding of path-finding algorithm causes?

Path-finding refactoring seems to me like a common sense with maintenance, upgrading and error tracing in mind.
Logged
Pages: 1 [2]