Parallelization in Computer Board Games Ian Princivalli

Introduction  “Solved” Game  Ultra-weak  Weak  Strong  Current Efforts  Chess  Shogi  Reversi (Othello)  Go

Computer Go  General Overview  19 x 19 board with intersections  Objective: Have the most territory  Black and white stones surround and capture  Programming Challenges  3 N possible board positions where N = size of board (19 x 19 board has 361)  Evaluating function  Endgame

How Parallel Computation fits in  Most popular design philosophies  Tree searching  Application of Monte Carlo methods  Pattern matching and knowledge based systems  Machine learning

Example: MoGo  MCTS (UCT)  UCT (Upper Conditional bounds for Trees)  Balance out exploration and exploitation

Example: MoGo continued  Utilizes both multicore parallelization for shared memory and cluster parallelization with message passing

Example: MoGo final  In a 2008 Taiwan Go tournament MoGo was able to defeat professional Go player Myungwan Kim (8p) 2 out of 4 matches with a 9 stone handicap.  Professionals gave MoGo an approximate ranking of 2d and Kim himself noted that with more time MoGo would have fared better

Limitations of Improvement via Parallelization  Increased computation seems to have diminishing returns  In a 2009 Computer Olympiad, Zen, a program running on a single four-core machine took first place over second place Fuego, running on ten, eight-core machines and third place MoGo, running on twenty, thirty-two core machines  In general MCTS cannot reliably solve certain situations, e.g. cases involving visual elements or other human sophisticated techniques and therefore parallelization of said MCTS does nothing for these cases  Improvement algorithmically seems to proceed improvement via parallelization  e.g. some later iterations of MCTS (UCT) based Computer Go programs have accommodated expert heuristics when these edge cases arise

Questions?