PLAYING GOWITH CLOJURE   Zach Tellman    @ztellman
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
RULES OF GO
SHALL WE PLAY A GAME?
MY QUALIFICATIONS• I’m    a mediocre Go player•I   think this stuff is pretty cool• I’ve   written performance-oriented Cl...
THE GAME TREE          X           X       X                                  …X O   X       O   X                  O     ...
THE GAME TREE          X           X       X                                  …X O   X       O   X                  O     ...
THE GAME TREE   a cooperative or single-player game, we only need to• in search for victory• in   a competitive game, we n...
MINIMAX• assign   a value to each leaf node       the parent the maximal child value if it’s our turn,• assign or the mini...
MINIMAX• plays   a perfect game• requires   traversing the entire tree• there   are ~9! possible tic-tac-toe games
EVALUATION FUNCTIONS• construct    a shallow game tree       each leaf node a value based on our best guess at• assign the...
THE TROUBLE             WITH HEURISTICS• difficult   to quantify• depth   vs. quality• understanding a function vs. underst...
THE TROUBLE                     WITH GO• lots   of breadth• lots   of depth
HISTORICAL APPROACHES• programmers     who are professional-level players• shallow   and narrow searches, heavy evaluation...
MONTE CARLO SIMULATION
MONTE CARLO SIMULATION             (defn inside-circle? [x y]               (>= 1 (+ (* x x) (* y y))))             (defn ...
MONTE CARLO SIMULATION             (defn inside-circle? [x y]               (>= 1 (+ (* x x) (* y y))))             (defn ...
MONTE CARLO SIMULATION
MONTE CARLO EVALUATION• thestrength of a position is how often one side wins, given repeated, naive playouts by both sides...
MULTI-ARMED BANDIT
MULTI-ARMED BANDIT• multiple   levers to pull, each with an unknown expected  reward• exploitation   vs exploration• if   ...
MONTE CARLO TREE SEARCH
SIMULATING GO                WITH CLOJURE• select   a move• check    for suicide• make     move• check    for capture• rep...
SIMULATING GO               WITH CLOJURE• select   a move•   check for suicide• make     move•   check for capture• repeat
INCREMENTAL STATE           4
INCREMENTAL STATE           6
INCREMENTAL STATE        8
INCREMENTAL STATE        6        2
INCREMENTAL STATE• we  keep track of the pseudo-liberties, but also the  neighbor sum and sum-of-squares• ifsum × sum = ps...
A LITTLE ARITHMETIC• select   a move        1 second                         / 10,000 games per second• check    for suici...
A LITTLE ARITHMETIC• select   a move        1 second                         / 10,000 games per second• check    for suici...
A LITTLE ARITHMETIC• select   a move        1 second                         / 10,000 games per second• check    for suici...
A MILLION TIMES         A SECOND(assoc {} :a 1, :b 2, :c 3, :d 4, :e 5)(reduce + (range 10))(set (range 5))
execute typical instruction           1 nsfetch from L1 cache memory          0.5 nsbranch misprediction                  ...
execute typical instruction           1 nsfetch from L1 cache memory          0.5 nsbranch misprediction                  ...
A QUICK DESCENT      INTO   INSANITY PERFORMANCE
NOT YOUR DAY JOB• not   latency bound• faster   is smarter• diminishing   returns not within reach
MUTABLE STATE“They are for experts only - if the semantics and implications of :volatile-mutable or :unsynchronized- mutab...
MUTABLE STATE
MUTABLE STATE• if   a value is only used on a single thread, it can be  unsynchronized• for   everything else, use volatil...
MUTABLE STATE(deftype Mutable  [^:unsynchronized-mutable ^long counter]  IMutable  (get-counter [_]    counter)  (set-coun...
MUTABLE STATE(deftype Mutable  [^:unsynchronized-mutable ^long counter]  IMutable  (get-counter [_]    counter)  (set-coun...
MUTABLE STATE(deftype Mutable  [^:unsynchronized-mutable ^long counter]  IMutable  (get-counter [_]    counter)  (set-coun...
MEASURE TWICE,            CODE ONCEuser> (bench (assoc {} :a 1, :b 2, :c 3, :d 4, :e 5))Evaluation count : 46619100 in 60 ...
CRITERIUM• one   of the many great libraries from Hugo Duncan• use   it at the REPL, and in your tests• tends   to exagger...
BOTTOM-UP PERFORMANCE• measure   each piece of your code• measure   them when used together• buildan intuition for how lon...
INDIRECTION“Any performance problem can be solved by removing a layer of indirection.”                            Unattrib...
INDIRECTION     =                    count==       identical?   Array/getLength
INDIRECTION
PUT IT ALL TOGETHER> lein test pushkin.test.simulator :benchmark----- random 9x9 playout-----Evaluation count : 501120 in ...
PUT IT ALL TOGETHER> lein test pushkin.test.simulator :benchmark----- random 9x9 playout-----Evaluation count : 501120 in ...
PLUMBING THE DEPTHS      OF PERFORMANCE          INSANITY• simulating   C-style structs with ByteBuffers• mimicking    C c...
Exploitation             Strong AIs               PushkinExploration           Possible          Plausible    http://githu...
QUESTIONS?
Playing Go with Clojure
Playing Go with Clojure
Upcoming SlideShare
Loading in …5
×

Playing Go with Clojure

1,331 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,331
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Playing Go with Clojure

    1. 1. PLAYING GOWITH CLOJURE Zach Tellman @ztellman
    2. 2. RULES OF GO
    3. 3. RULES OF GO
    4. 4. RULES OF GO
    5. 5. RULES OF GO
    6. 6. RULES OF GO
    7. 7. RULES OF GO
    8. 8. RULES OF GO
    9. 9. RULES OF GO
    10. 10. RULES OF GO
    11. 11. RULES OF GO
    12. 12. RULES OF GO
    13. 13. RULES OF GO
    14. 14. RULES OF GO
    15. 15. RULES OF GO
    16. 16. RULES OF GO
    17. 17. RULES OF GO
    18. 18. RULES OF GO
    19. 19. RULES OF GO
    20. 20. SHALL WE PLAY A GAME?
    21. 21. MY QUALIFICATIONS• I’m a mediocre Go player•I think this stuff is pretty cool• I’ve written performance-oriented Clojure before
    22. 22. THE GAME TREE X X X …X O X O X O …
    23. 23. THE GAME TREE X X X …X O X O X O …
    24. 24. THE GAME TREE a cooperative or single-player game, we only need to• in search for victory• in a competitive game, we need to optimize for victory
    25. 25. MINIMAX• assign a value to each leaf node the parent the maximal child value if it’s our turn,• assign or the minimal child value if it’s our opponent’s turn• ascend one level, and repeat
    26. 26. MINIMAX• plays a perfect game• requires traversing the entire tree• there are ~9! possible tic-tac-toe games
    27. 27. EVALUATION FUNCTIONS• construct a shallow game tree each leaf node a value based on our best guess at• assign the outcome• apply minimax to these values
    28. 28. THE TROUBLE WITH HEURISTICS• difficult to quantify• depth vs. quality• understanding a function vs. understanding its repeated, recursive application
    29. 29. THE TROUBLE WITH GO• lots of breadth• lots of depth
    30. 30. HISTORICAL APPROACHES• programmers who are professional-level players• shallow and narrow searches, heavy evaluation functions
    31. 31. MONTE CARLO SIMULATION
    32. 32. MONTE CARLO SIMULATION (defn inside-circle? [x y] (>= 1 (+ (* x x) (* y y)))) (defn sample [] (inside-circle? (rand) (rand)))1 (0,0)
    33. 33. MONTE CARLO SIMULATION (defn inside-circle? [x y] (>= 1 (+ (* x x) (* y y)))) (defn sample [] (inside-circle? (rand) (rand)))1 (repeatedly 1e6 sample) (0,0)
    34. 34. MONTE CARLO SIMULATION
    35. 35. MONTE CARLO EVALUATION• thestrength of a position is how often one side wins, given repeated, naive playouts by both sides• possible playouts vs plausible playouts• eachnew playout gives us additional information about what is plausible
    36. 36. MULTI-ARMED BANDIT
    37. 37. MULTI-ARMED BANDIT• multiple levers to pull, each with an unknown expected reward• exploitation vs exploration• if the search space is stable over time, we expect to converge on a solution
    38. 38. MONTE CARLO TREE SEARCH
    39. 39. SIMULATING GO WITH CLOJURE• select a move• check for suicide• make move• check for capture• repeat
    40. 40. SIMULATING GO WITH CLOJURE• select a move• check for suicide• make move• check for capture• repeat
    41. 41. INCREMENTAL STATE 4
    42. 42. INCREMENTAL STATE 6
    43. 43. INCREMENTAL STATE 8
    44. 44. INCREMENTAL STATE 6 2
    45. 45. INCREMENTAL STATE• we keep track of the pseudo-liberties, but also the neighbor sum and sum-of-squares• ifsum × sum = psudeo-liberties × sum-of-squares, there’s only one real liberty• proof is left as an exercise for the reader
    46. 46. A LITTLE ARITHMETIC• select a move 1 second / 10,000 games per second• check for suicide• make move• check for capture• repeat
    47. 47. A LITTLE ARITHMETIC• select a move 1 second / 10,000 games per second• check for suicide / 100 moves per game• make move• check for capture• repeat
    48. 48. A LITTLE ARITHMETIC• select a move 1 second / 10,000 games per second• check for suicide / 100 moves per game• make move• check for capture• repeat = 1μs per move
    49. 49. A MILLION TIMES A SECOND(assoc {} :a 1, :b 2, :c 3, :d 4, :e 5)(reduce + (range 10))(set (range 5))
    50. 50. execute typical instruction 1 nsfetch from L1 cache memory 0.5 nsbranch misprediction 5 nsfetch from L2 cache memory 7 nsmutex lock/unlock 25 nsfetch from main memory 100 ns “Teach Yourself Programming in Ten Years” Peter Norvig, 2001
    51. 51. execute typical instruction 1 nsfetch from L1 cache memory 0.5 nsbranch misprediction 5 nsfetch from L2 cache memory 7 nsmutex lock/unlock 25 nsfetch from main memory 100 ns “Teach Yourself Programming in Ten Years” Peter Norvig, 2001
    52. 52. A QUICK DESCENT INTO INSANITY PERFORMANCE
    53. 53. NOT YOUR DAY JOB• not latency bound• faster is smarter• diminishing returns not within reach
    54. 54. MUTABLE STATE“They are for experts only - if the semantics and implications of :volatile-mutable or :unsynchronized- mutable are not immediately apparent to you, you should not be using them.” Rich Hickey, the docstring for deftype
    55. 55. MUTABLE STATE
    56. 56. MUTABLE STATE• if a value is only used on a single thread, it can be unsynchronized• for everything else, use volatile• unsynchronized is roughly 2x faster
    57. 57. MUTABLE STATE(deftype Mutable [^:unsynchronized-mutable ^long counter] IMutable (get-counter [_] counter) (set-counter [_ val] (set! counter val)))
    58. 58. MUTABLE STATE(deftype Mutable [^:unsynchronized-mutable ^long counter] IMutable (get-counter [_] counter) (set-counter [_ val] (set! counter val)))(defn add [^Mutable m ^long val] (set-counter m (+ (get-counter m) val)))
    59. 59. MUTABLE STATE(deftype Mutable [^:unsynchronized-mutable ^long counter] IMutable (get-counter [_] counter) (set-counter [_ val] (set! counter val)) (add [_ val] (set! counter (+ counter val))))
    60. 60. MEASURE TWICE, CODE ONCEuser> (bench (assoc {} :a 1, :b 2, :c 3, :d 4, :e 5))Evaluation count : 46619100 in 60 samples of 776985 calls. Execution time mean : 1.286463 us Execution time std-deviation : 4.220920 ns Execution time lower quantile : 1.280215 us ( 2.5%) Execution time upper quantile : 1.295557 us (97.5%)Found 4 outliers in 60 samples (6.6667 %) low-severe 1 (1.6667 %) low-mild 2 (3.3333 %) high-mild 1 (1.6667 %) Variance from outliers : 1.6389 %
    61. 61. CRITERIUM• one of the many great libraries from Hugo Duncan• use it at the REPL, and in your tests• tends to exaggerate cache coherency• minimum resolution appears to be ~15ns
    62. 62. BOTTOM-UP PERFORMANCE• measure each piece of your code• measure them when used together• buildan intuition for how long something should take, and investigate when you’re wrong
    63. 63. INDIRECTION“Any performance problem can be solved by removing a layer of indirection.” Unattributed
    64. 64. INDIRECTION = count== identical? Array/getLength
    65. 65. INDIRECTION
    66. 66. PUT IT ALL TOGETHER> lein test pushkin.test.simulator :benchmark----- random 9x9 playout-----Evaluation count : 501120 in 60 samples of 8352 calls. Execution time mean : 121.293385 us Execution time std-deviation : 2.534460 us Execution time lower quantile : 119.685345 us ( 2.5%) Execution time upper quantile : 128.150772 us (97.5%)Found 8 outliers in 60 samples (13.3333 %) low-severe 3 (5.0000 %) low-mild 5 (8.3333 %) Variance from outliers : 9.4036 %
    67. 67. PUT IT ALL TOGETHER> lein test pushkin.test.simulator :benchmark----- random 9x9 playout-----Evaluation count : 501120 in 60 samples of 8352 calls. Execution time mean : 121.293385 us Execution time std-deviation : 2.534460 us Execution time lower quantile : 119.685345 us ( 2.5%) Execution time upper quantile : 128.150772 us (97.5%)Found 8 outliers in 60 samples (13.3333 %) low-severe 3 (5.0000 %) low-mild 5 (8.3333 %) Variance from outliers : 9.4036 %
    68. 68. PLUMBING THE DEPTHS OF PERFORMANCE INSANITY• simulating C-style structs with ByteBuffers• mimicking C compiler offset calculation with local analysis• creating a bridge to heterogeneous computing
    69. 69. Exploitation Strong AIs PushkinExploration Possible Plausible http://github.com/ztellman/pushkin
    70. 70. QUESTIONS?

    ×