![MONTE CARLO SIMULATION
(defn inside-circle? [x y]
(>= 1 (+ (* x x) (* y y))))
(defn sample []
(inside-circle? (rand) (rand)))
1
(0,0)](https://image.slidesharecdn.com/go-121116092921-phpapp01/85/Playing-Go-with-Clojure-32-320.jpg)
![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)](https://image.slidesharecdn.com/go-121116092921-phpapp01/85/Playing-Go-with-Clojure-33-320.jpg)
![MUTABLE STATE
(deftype Mutable
[^:unsynchronized-mutable ^long counter]
IMutable
(get-counter [_]
counter)
(set-counter [_ val]
(set! counter val)))](https://image.slidesharecdn.com/go-121116092921-phpapp01/85/Playing-Go-with-Clojure-58-320.jpg)
![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)))](https://image.slidesharecdn.com/go-121116092921-phpapp01/85/Playing-Go-with-Clojure-59-320.jpg)
![MUTABLE STATE
(deftype Mutable
[^:unsynchronized-mutable ^long counter]
IMutable
(get-counter [_]
counter)
(set-counter [_ val]
(set! counter val))
(add [_ val]
(set! counter (+ counter val))))](https://image.slidesharecdn.com/go-121116092921-phpapp01/85/Playing-Go-with-Clojure-60-320.jpg)
Playing Go with Clojure
- 1. PLAYING GO WITH CLOJURE Zach Tellman @ztellman
- 2. RULES OF GO
- 3. RULES OF GO
- 4. RULES OF GO
- 5. RULES OF GO
- 6. RULES OF GO
- 7. RULES OF GO
- 8. RULES OF GO
- 9. RULES OF GO
- 10. RULES OF GO
- 11. RULES OF GO
- 12. RULES OF GO
- 13. RULES OF GO
- 14. RULES OF GO
- 15. RULES OF GO
- 16. RULES OF GO
- 17. RULES OF GO
- 18. RULES OF GO
- 19. RULES OF GO
- 20. SHALL WE PLAY A GAME?
- 21. MY QUALIFICATIONS • I’m a mediocre Go player •I think this stuff is pretty cool • I’ve written performance-oriented Clojure before
- 22. THE GAME TREE X X X … X O X O X O …
- 23. THE GAME TREE X X X … X O X O X O …
- 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. 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. MINIMAX • plays a perfect game • requires traversing the entire tree • there are ~9! possible tic-tac-toe games
- 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. THE TROUBLE WITH HEURISTICS • difficult to quantify • depth vs. quality • understanding a function vs. understanding its repeated, recursive application
- 29. THE TROUBLE WITH GO • lots of breadth • lots of depth
- 30. HISTORICAL APPROACHES • programmers who are professional-level players • shallow and narrow searches, heavy evaluation functions
- 32. MONTE CARLO SIMULATION (defn inside-circle? [x y] (>= 1 (+ (* x x) (* y y)))) (defn sample [] (inside-circle? (rand) (rand))) 1 (0,0)
- 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)
- 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
- 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. MONTE CARLO TREE SEARCH
- 39. SIMULATING GO WITH CLOJURE • select a move • check for suicide • make move • check for capture • repeat
- 40. SIMULATING GO WITH CLOJURE • select a move • check for suicide • make move • check for capture • repeat
- 42. INCREMENTAL STATE 4
- 43. INCREMENTAL STATE 6
- 44. INCREMENTAL STATE 8
- 45. INCREMENTAL STATE 6 2
- 46. 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
- 47. A LITTLE ARITHMETIC • select a move 1 second / 10,000 games per second • check for suicide • make move • check for capture • repeat
- 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
- 49. 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
- 50. A MILLION TIMES A SECOND (assoc {} :a 1, :b 2, :c 3, :d 4, :e 5) (reduce + (range 10)) (set (range 5))
- 51. execute typical instruction 1 ns fetch from L1 cache memory 0.5 ns branch misprediction 5 ns fetch from L2 cache memory 7 ns mutex lock/unlock 25 ns fetch from main memory 100 ns “Teach Yourself Programming in Ten Years” Peter Norvig, 2001
- 52. execute typical instruction 1 ns fetch from L1 cache memory 0.5 ns branch misprediction 5 ns fetch from L2 cache memory 7 ns mutex lock/unlock 25 ns fetch from main memory 100 ns “Teach Yourself Programming in Ten Years” Peter Norvig, 2001
- 53. A QUICK DESCENT INTO INSANITY PERFORMANCE
- 54. NOT YOUR DAY JOB • not latency bound • faster is smarter • diminishing returns not within reach
- 55. 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
- 56. MUTABLE STATE
- 57. 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
- 58. MUTABLE STATE (deftype Mutable [^:unsynchronized-mutable ^long counter] IMutable (get-counter [_] counter) (set-counter [_ val] (set! counter val)))
- 59. 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)))
- 60. MUTABLE STATE (deftype Mutable [^:unsynchronized-mutable ^long counter] IMutable (get-counter [_] counter) (set-counter [_ val] (set! counter val)) (add [_ val] (set! counter (+ counter val))))
- 61. MEASURE TWICE, CODE ONCE user> (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 %
- 62. 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
- 63. 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
- 64. INDIRECTION “Any performance problem can be solved by removing a layer of indirection.” Unattributed
- 65. INDIRECTION = count == identical? Array/getLength
- 66. INDIRECTION
- 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. 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 %
- 69. 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
- 70. Exploitation Strong AIs Pushkin Exploration Possible Plausible http://github.com/ztellman/pushkin
- 72. QUESTIONS?
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: \n
- #49: \n
- #50: \n
- #51: \n
- #52: \n
- #53: \n
- #54: \n
- #55: \n
- #56: \n
- #57: \n
- #58: \n
- #59: \n
- #60: \n
- #61: \n
- #62: \n
- #63: \n
- #64: \n
- #65: \n
- #66: \n
- #67: \n
- #68: \n
- #69: \n
- #70: \n
- #71: \n
- #72: \n
- #73: \n