Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching for pathfinding #1569

Closed
kostmo opened this issue Oct 4, 2023 · 6 comments · Fixed by #1595
Closed

Caching for pathfinding #1569

kostmo opened this issue Oct 4, 2023 · 6 comments · Fixed by #1595
Assignees
Labels
C-Moderate Effort Should take a moderate amount of time to address. Z-Feature A new feature to be added to the game. Z-Performance This issue concerns memory or time efficiency of the Swarm game.

Comments

@kostmo
Copy link
Member

kostmo commented Oct 4, 2023

To improve the performance of #836, a caching mechanism could be designed that optimizes for the common case: a robot repeatedly invokes path with identical arguments and follows the yielded directions precisely.

  1. If the robot takes a step off of the optimal path, the computed path shall be invalidated.
  2. If the robot invokes the path command again with different arguments, the previous computed path shall be discarded.
  3. If the list of entities that are unwalkable for the invoking robot changes, invalidate the cache.
  4. Map modifications
    1. If an entity is added or removed at a Manhattan distance farther from the robot than the computed path length, the cache is unaffected.
    2. "unwalkable" entities (an entity is placed or removed that is "unwalkable" with respect to the invoking robot)
      1. If an "unwalkable" entity is added to the map, the computed path shall only be invalidated if the new entity lies on the path.
      2. If an "unwalkable" entity is removed from the map, the computed path shall be invalidated.
    3. "target" entities (if the path command had been invoked with the modified entity as a target)
      1. Adding
        1. If a target entity is added that lies on the computed path, the computed path is truncated to that entity's location
        2. If a target entity is added that does not lie on the computed path, invalidate the cache
      2. Removing
        1. If a target entity is removed that is the destination of the computed path, invalidate the cache
        2. If a target entity is removed that is not the destination of the computed path, the cache is unaffected
@kostmo kostmo added Z-Feature A new feature to be added to the game. Z-Performance This issue concerns memory or time efficiency of the Swarm game. C-Moderate Effort Should take a moderate amount of time to address. labels Oct 4, 2023
@byorgey
Copy link
Member

byorgey commented Oct 4, 2023

This sounds nice in theory but it seems like it might be premature optimization. I am worried that the logic to invalidate the cache would be more expensive than just recomputing a path every time.

  • Would there be just a single global cached path? Or one per robot?
  • One per robot would make the most logical sense (after all, two robots could be simultaneously following different paths), but I worry about keeping those updated. If the map is modified, do you then have to scan through every robot to see whether any of them have a cached path that needs to be invalidated? That would obviously be disastrous for performance.
  • Alternatively, instead of invalidating cached paths directly, we could simply keep a log of world changes, and have the path command itself be responsible for checking whether the cached path needs to be invalidated. But that sounds complicated, especially since we'd have to make sure the "world changes log" is somehow windowed so it doesn't grow without bound.

@xsebek
Copy link
Member

xsebek commented Oct 4, 2023

Well, how would we determine if the optimisations are premature? I am not sure we are using the path enough yet to make a good decision. But once we do, could we use the new counters to count path queries/etc. @kostmo?

I am also interested in the simple alternatives, like keeping the original path and letting robots recalculate if they need to.

@xsebek
Copy link
Member

xsebek commented Oct 4, 2023

It would be cool if we could update the shortest distance cache of A* directly and let it recompute the result.

My hope is that the path metric of the algorithm would itself determine if the update is relevant. Most of your points still apply @kostmo, but I was considering if we could avoid throwing out all the work.

@kostmo
Copy link
Member Author

kostmo commented Oct 20, 2023

Well, how would we determine if the optimisations are premature? I am not sure we are using the path enough yet to make a good decision.

I've created a demo in #1594 where I think the kind of caching I describe here would help a lot.
When the robot clears a patch of flowers such that the next one is far away, the game stutters heavily as the lengthy path is recalculated upon every tick.

Other than the stuttering issue, the emergent roaming/grazing behavior is quite fun to observe and could feature in various scenarios.

@kostmo kostmo self-assigned this Oct 21, 2023
@kostmo kostmo mentioned this issue Oct 21, 2023
@kostmo
Copy link
Member Author

kostmo commented Oct 22, 2023

#1595 implements caching and demonstrates a dramatic improvement to the roaming/grazing performance.

@xsebek
Copy link
Member

xsebek commented Oct 22, 2023

@kostmo great, but isn't that measured against turning off an on navigation for each turn? 🤔

Also how is everything else affected? 😅

@mergify mergify bot closed this as completed in #1595 Nov 14, 2023
mergify bot pushed a commit that referenced this issue Nov 14, 2023
Closes #1569

## Performance

Path cache invalidation upon world modifications (i.e. entities inserted or removed) entails iterating over all of the previously-cached paths [here](https://github.com/swarm-game/swarm/pull/1595/files#r1390158411).  For efficiency's sake, we avoid iterating over "all existing robots".

Any scenario that does not use the `path` command is entirely unaffected by this change.

## Demo

Previously, this demo was virtually unplayable, since when moving between widely-spaced "clusters" of flowers, an expensive A-star search was invoked at almost every tick.  Now, the vast majority of moves utilize the cache, and the demo exhibits minimal stuttering (e.g. when a single A-star search is performed when moving between distant clusters).

    scripts/play.sh -i scenarios/Fun/horton.yaml --autoplay --speed 7

### Event log

An event log specific to the path cache is maintained with its own ring buffer:

    scripts/play.sh -i scenarios/Testing/1569-pathfinding-cache/1569-harvest-batch.yaml --autoplay

 and view http://localhost:5357/paths/log
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Moderate Effort Should take a moderate amount of time to address. Z-Feature A new feature to be added to the game. Z-Performance This issue concerns memory or time efficiency of the Swarm game.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants