Parallel A* path nding algorithm - ETH Z · Parallel A* path nding algorithm Goal Our Goals were I Implement a correct parallel A* algorithm I Make it faster than the serial version

Parallel A* pathfinding algorithm

Giuseppe AccaputoPascal Iselin

December 16, 2013


Overview

I Goal

I Literature Review

I Approaches

I Results


Goal

Our Goals were

I Implement a correct parallel A* algorithm

I Make it faster than the serial version


Goal

Our Goals were

I Implement a correct parallel A* algorithm X

I Make it faster than the serial version


Goal

Our Goals were

I Implement a correct parallel A* algorithm X

I Make it faster than the serial version X


A* Shortest Path

Best first heuristic search

f(n) = g(n)︸︷︷︸exact cost

+ h(n)︸︷︷︸estimated cost


Literature Review

Parallel A* in the literature

I Shared Priority Queue: Threads produce and consumesimultaneously. Does not perform well![Cohen et al., 2010]

I Bidirectional Search: Run two searches. Does not scale![Rios, Luis Henrique Oliveira, and Luiz Chaimowicz. PNBA*:A Parallel Bidirectional Heuristic Search Algorithm.]

I Sacrifice path quality for speed: Converge towards otheralgorithms[Sandy Brand, and Rafael Bidarra. Multicore scalable andefficient pathfinding with Parallel Ripple Search. Comp.Anim. Virtual Worlds 23.2 (2012)]

I Clustering: Too complicated[Rafia, Inam. A* Algorithm for Multicore Graphics Processors.(2010).]


Approaches

Ideas we implemented

I Concurrent Neighbor Expansion

I Shared Priority Queue

I Atomic ClosedFlags + Shared JobQueue

Same underlying datastructure for all the Implementations.SquareLattice filled with Objects of Type MapNode


Approaches

Concurrent Neighbor Expansion

Concurrent calculation of the neighbors in each step. This doesnot scale but it’s easy!


Approaches

Shared Priority Queue

I concurrent priority queue (CPQ) from Intel’s Thread BuildingBlocks (TBB)

I CPQ does not allow rebalancingI Recursive call of the search function with a counterI One lock per node


Approaches

Atomic ClosedFlags + Shared JobQueue

I Run serial A* until we have enough open nodesI Run a new A* in parallel on each of the open nodesI Each thread has its own priority queueI Threads communicate through a shared grid of closed flagsI Use atomic CAS to set the flags


Approaches

Atomic ClosedFlags + Shared JobQueue

I Run serial A* until we have enough open nodes

I Run a new A* in parallel on each of the open nodes

I Each thread has it’s own priority queue

I Threads communicate through a shared grid of closed flags

I Use atomic CAS to set the flags

I How to make sure threads don’t just terminate? → SharedJobQueue

I How to guarantee the shortest path?


Approaches

How to guarantee the shortest path?


Approaches



Approaches


Just take the green path... NO! That would be fringe search!


Results

Test setupI Tested on Kanifushi

(32 Cores Intel Xeon E7-4830 @ 2.13Ghz)I Compiled with GCC 4.7 and TBB 3.0I 10 runs per test caseI 90% of random map was walkable


Results

0

2

4

6

8

10

12

14

Size of square lattice

Serial A* vs. Boost A* run time (Random Map)E

xecution tim

e in s

econds

N=100 N=200 N=300 N=400 N=500 N=600 N=700 N=800 N=900 N=1000

Boost A*

Serial A*


Results

0

5

10

15

20

25


Serial A* vs. Boost A* run time (Wall map)E

xecution tim

e in s

econds

N=100 N=200 N=300 N=400 N=500 N=600 N=700 N=800 N=900 N=1000

Boost A*

Serial A*


Results

−1

−0.5

0

0.5

1

1.5

2

2.5

3


Serial A* vs. Parallel Neighbor Expanding A* run time (Random map)E

xe

cu

tio

n t

ime

in

se

co

nd

s

N=100 N=200 N=300 N=400 N=500 N=600 N=700 N=800 N=900 N=1000

Parallel Neighbor Expanding A*

Serial A*


Results

−1

0

1

2

3

4

5

6

7

8

9


Serial A* vs. Parallel Neighbor Expanding A* run time (Wall map)E

xecution tim

e in s

econds

N=100 N=200 N=300 N=400 N=500 N=600 N=700 N=800 N=900 N=1000


Serial A*


Results

−1

−0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

Number of threads

Serial A* vs. Parallel A* run time (Random map)E

xe

cu

tio

n t

ime

in

se

co

nd

s

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Parallel A*

Serial A*


Results

−1

−0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

Number of threads

Serial A* vs. Parallel A* run time (Wall map)E

xe

cu

tio

n t

ime

in

se

co

nd

s

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Parallel A*

Serial A*


Results

0

0.5

1

1.5

2

2.5

3

Number of threads

Parallel Neighbor Expanding A* vs. Parallel A* run time (Random map, N=1000)E

xecution tim

e in s

econds

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Parallel A*



Results

0

1

2

3

4

5

6

7

Number of threads

Parallel Neighbor Expanding A* vs. Parallel A* run time (Wall map, N=1000)E

xe

cu

tio

n t

ime

in

se

co

nd

s

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

Parallel A*



Results

Conclusions

I We comply with the literature!

I One must sacrifice path quality for speedI There are much better alternatives out there:

I Ripple Search [Brand et al., 2012 ]I Fringe Search

Documents

Parallel A* path nding algorithm - ETH Z · Parallel A* path nding algorithm Goal Our Goals were I Implement a correct parallel A* algorithm I Make it faster than the serial version