High Performance CUDA Accelerated Local Optimization in Traveling Salesman Problem

Size: px

Start display at page:

Download "High Performance CUDA Accelerated Local Optimization in Traveling Salesman Problem"

Peregrine Horn
5 years ago
Views:

1 High Performance CUDA Accelerated Local Optimization in Traveling Salesman Problem Kamil Rocki, PhD Department of Computer Science Graduate School of Information Science and Technology The University of Tokyo

2 Why TSP? It s hard (NP-hard to be exact) Especially to parallelize But easy to understand A basic problem in CS TSPLIB - a set of standard problems Allows comparisons of algorithms It s simple to adjust the problem size Platform for the study of general methods that can be applied to a wide range of discrete optimization problems

3 Not only salesmen s headache Computer wiring Vehicle routing Crystallography Robot control pla85900.tsp It took 15 years to solve this problem (solved in 2006)

5 Local/Global Optimization Usually the space is huge There are many valleys and local minima Local search might terminate in one of the local minima Global search should find the best solution

6 Iterated Global Search - Global Optimization (Approximate algorithm) Local search is followed by some sort of tour randomization and it s repeated (until there s time left) perturbation Most of the time is spent in the Local Search part cost s % % % % % % % % % % % % % % s* s* % % solution space S % % % % % kroe100 ch130 ch150 kroa200 ts225 pr299 pr439 rat783 vm1084 pr2392 Thomas Stützle, Iterated Local Search & Variable Neighborhood Search MN Summerschool, Tenerife, 2003 p.9

7 Iterated Global Search - Global Optimization (Approximate algorithm) 1: procedure I TERATED L OCAL S EARCH 2: s 0 := GenerateInitialSolution() 3: s * := 2optLocalSearch (s 0 ) GPU 4: while (termination condition not met) 5: s := P erturbation (s * ) 6: s * := 2optLocalSearch (s ) GPU 7: s * := AcceptanceCriterion (s *, s * ) 8: end while 9: end procedure

8 TSP - Big valley theory (Why does ILS work?) Local minima form clusters The better the solution, the closer it is to the global optimum x Cost Cost Global minimum is somewhere in the middle x Mean distance to other solutions (a) Distance to optimal (b) ILS worsens the tour only slightly Local Search is repeated close to the previous minimum S. Baluja, A.G. Barto, K. D. Boese, J. Boyan, W. Buntine, T. Carson, R. Caruana, D. J. Cook, S. Davies, T. Dean, T. G. Dietterich, P. J. Gmytrasiewicz, S. Hazlehurst, R. Impagliazzo, A.K. Jagota, K. E. Kim, A. Mcgovern, R. Moll, A. W. Moore, L. Sanchis, L. Su, C. Tseng, K. Tumer, X. Wang, D. H. Wolpert, Justin Boyan, Wray Buntine, Arun Jagota: Statistical Machine Learning for Large-Scale Optimization, 2000

9 2-opt local optimization Exchange a pair of edges to obtain a better solution if the following condition is true distance(b,f) + distance(g,d) > distance(b,d) + distance(g,f) A B A B C C D D E E F F G G

10 2-opt local optimization In order to find such a pair need to perform: n 2 for (int i = 1; i < points - 2; i++) for (int j = i + 1; j < points - 1; j++) 2 =(n 2) (n 3)/2 checks { if (distance(i, i-1) + distance(j+1, j) > There are some pruning techniques in more complex algorithms I analyze all possible pairs distance(i, j+1) + distance(i-1, j)) update best i and j; city problem -> 49.9 Million pairs city problem -> 5 Billion pairs } remove edges (best i, best i-1) and (best j+1, best j) add edges (best i,best j+1) and (best i-1, best j)

11 Obtaining a distance Naive approach - calculate it each time it s needed Smart way - reuse the results For a 100-city problem it is approximately 5 times faster (CPU) Problem Number Memory Memory (TSPLIB) of cities needed needed (points) for LUT for coordinates (MB) (kb) kroe ch ch kroa ts pr pr rat vm pr pcb fl fnl n 2 n

12 Obtaining a distance Naive approach - calculate it each time it s needed Smart way - reuse the results For a 100-city problem it is approximately 5 times faster (CPU) For a city problem it can be slower Cache Problem Number Memory Memory (TSPLIB) of cities needed needed (points) for LUT for coordinates (MB) (kb) kroe ch ch kroa ts pr pr rat vm pr pcb fl fnl n 2 n

13 Obtaining a distance Naive approach - calculate it each time it s needed Smart way - reuse the results For a 100-city problem it is approximately 5 times faster (CPU) For a city problem it can be slower Cache With multiple cores, it becomes slower Cache/memory Problem Number Memory Memory (TSPLIB) of cities needed needed (points) for LUT for coordinates (MB) (kb) kroe ch ch kroa ts pr pr rat vm pr pcb fl fnl n 2 n

14 LUT (Look Up Table) vs recalculation Not-so-clever algorithm Time Clever algorithm Number of cores

15 A change in algorithm design - sequential Memory is free, reuse computed results Use sophisticated algorithms, prune the search space

16 A change in algorithm design - parallel Memory is free, reuse computed results Limited memory (size, throughput), computing is free (almost) Use sophisticated algorithms, prune the search space Sometimes brute-force search might be faster (especially on GPUs) Avoiding divergence Same amount of time to process 10, 100 even elements in parallel But -> empty flops

17 GPU implementation GPU uses this simple function for EUC_2D problems device int calculatedistance2d (unsigned int i, unsigned int j, city_coords* coords) { //registers + shared memory register float dx, dy; dx = coords[i].x - coords[j].x; dy = coords[i].y - coords[j].y; } return (int)(sqrtf(dx * dx + dy * dy) + 0.5f); //6 FLOPs + sqrt

18 GPU implementation dist(i,j) = dist (j,i), dist (i,i) = 0 Example for 32 threads Matrix of city pairs to be checked for a possible swap, each pair corresponds to one GPU job N 0,1 0 0,2 1 1,2 2 0,3 3 1,3 4 2,3 5 0,4 6 1,4 7 2,4 8 3,4 9 0,5 10 1,5 11 2,5 12 3,5 13 4,5 14 0,6 15 1,6 16 2,6 17 3,6 18 4,6 19 5,6 20 0,7 21 1,7 22 2,7 23 3,7 24 4,7 25 5,7 26 6,7 27 Iteration 1 Iteration 2 0,8 28 1,8 29 2,8 30 3,8 31 4,8 32 5,8 33 6,8 34 7,8 35 0,9 37 1,9 38 2,9 39 3,9 40 4,9 41 5,9 42 6,9 43 7,9 44 8,9 45 Iteration 3 N N Iteration 4 Each thread has to check: Iteration 5 if (distance(i, i-1) + distance(j+1, j) > Iteration 6 distance(i, j+1) + distance(i-1, j)) update best i and j; N Iteration 7

19 Optimizations Preorder the coordinates in the route s order on CPU The reads from the global memory are no longer scattered - much faster 8B needed instead of 10B per city Route Array of coordinates Get coordinates of point at position n x = coordinates[route[n]].x y = coordinates[route[n]].y Total size: n * sizeof(route data type) + 2 * n * sizeof(coordinate data type) No unnecessary address calculations The problem can be split if it s too big for the shared memory s size Route + coordinates = Array of ordered coordinates Get coordinates of point at position n x = ordered_coordinates[n].x y = ordered_coordinates[n].y Total size: 2 * n * sizeof(coordinate data type)

20 GPU implementation An overview of the algorithm: 1. Copy the ordered coordinates to the GPU global memory (CPU) 2. Execute the kernel 3. Copy the ordered coordinates to the shared memory 4. Calculate swap effect of one pair 5. Find the best value and store it in the global memory 6. Read the result (CPU)

21 What if coordinates size exceeds the size of shared memory? This part requires 2*m float2 elements to be calculated Let s assume a big problem N too big for the shared memory This part requires 2*m float2 elements to be calculated This part requires 2*m float2 elements to be calculated N coordinates range (N-2m+1,N-m) coordinates range (N-m+1,N) N coordinates range (0,m) coordinates range (m+1,2m)

22 What if coordinates size exceeds the size of shared memory? Problem of size N Assuming local memory of limited size m coordinates Needed data: two arrays coordinates range (m/2+1,m) 0 N coordinates range (N-m/2+1,N) 0 N coordinates range (N-m/2+1,N) Total size: 2 * 2 * n * sizeof(coordinate data type) coordinates range (m/2+1,m) It is possible to calculate distances in arbitrary segments

23 What if coordinates size exceeds the size of shared memory? Arbitrarily big problems can be solved 2 sets of coordinates needed Work can be split and run on multiple devices device int calculatedistance2d( unsigned int i, unsigned int j, city_coords* coordsa, city_coords* coordsb) { register float dx, dy; dx = coordsa[i].x - coordsb[j].x; dy = coordsa[i].y - coordsb[j].y; } return (int)(sqrtf(dx * dx + dy * dy) + 0.5f);

24 Results 2-opt step processing time 10,000s Approximately 22 billion comparisons/s 1,000s (3960X) A distance(b,f) + distance(g,d) > distance(b,d) + distance(g,f) B A B 100s C C D D 10s E E F F 1s G G 0.1s 0.01s For a city problem 0.001s s pair need to be checked s kroe100 kroa200 pr439 pr2392 fnl4461 d15112 pla85900 ara tsp

25 Results Time needed for a single local optimization run GTX 680 Compared to Intel i7-3960x CPU Up to 300x speedup (single core, no SSE) Up to 40x speedup (Intel OpenCL) Table II 2-OPT - TIME NEEDED FOR A SINGLE RUN, CUDA, GPU: GTX680, CPU: I NTEL I X Problem GPU Host to Device GPU 2-opt Time to Initial Optimized (TSPLIB) kernel device to host total checks/s first Length Length time copy copy time (Millions) minimum full 2-opt time time 2-opt from MF berlin52 20 µs 50 µs 11 µs 81 µs µs kroe µs 50 µs 11 µs 82 µs µs ch µs 50 µs 11 µs 82 µs µs ch µs 50 µs 11 µs 84 µs µs kroa µs 50 µs 11 µs 85 µs ms ts µs 50 µs 11 µs 85µs ms pr µs 50 µs 11 µs 87 µs ms pr µs 50 µs 11 µs 93 µs ms rat µs 51 µs 11 µs 115 µs ms vm µs 51 µs 11 µs 142 µs ms pr µs 53 µs 11 µs 363 µs ms pcb µs 55 µs 11 µs 547 µs ms fl µs 54 µs 11 µs 788 µs ms fnl µs 58 µs 11 µs 815 µs ms rl µs 59 µs 11 µs 1079 µs ms pla µs 58 µs 11 µs 1616 µs ms usa µs 66 µs 11 µs 4805 µs s d µs 69 µs 11 µs 6043 µs s d µs 75 µs 11 µs 9014 µs s sw ms 85 µs 11 µs ms s pla ms 96 µs 11 µs ms s pla ms 205 µs 11 µs ms s sra ms 249 µs 11 µs ms s usa ms 287 µs 11 µs ms s ara s 740 µs 11 µs s s lra s 1774 µs 11 µs s m lrb s 2833 µs 11 µs s h

26 Results 1 Kepler GPUs 2 Kepler GPUs 4 Kepler GPUs 8 Kepler GPUs

27 I have implemented and published LOGO TSP Solver LOGO - LOcal GPU Optimization CUDA + OpenCL Linux/Mac: Source code, Windows: Binary with GUI GPL License + More resources about LOGO (slides, papers)

28 Summary Big TSP problems can be solved very quickly on GPU! (The fastest GPU TSP Solver?) Sometimes naive algorithms might run faster overall in parallel Large and very large problems typically can be decomposed into smaller ones and fit fast memory Avoid memory accesses (true for both CPUs and GPUs now) Memory is a scarce resource, FLOPs are abundant Exploit locality by manually reordering data (additional 0.1s of preprocessing may save 1s somewhere else)

High Performance GPU Accelerated Local Optimization in TSP

2013 IEEE 27th International Symposium on Parallel & Distributed Processing Workshops and PhD Forum High Performance GPU Accelerated Local Optimization in TSP Kamil Rocki, Reiji Suda The University of