1 00:00:00,050 --> 00:00:02,500 The following content is provided under a Creative 2 00:00:02,500 --> 00:00:04,010 Commons license. 3 00:00:04,010 --> 00:00:06,350 Your support will help MIT OpenCourseWare 4 00:00:06,350 --> 00:00:10,720 continue to offer high quality educational resources for free. 5 00:00:10,720 --> 00:00:13,330 To make a donation or view additional materials 6 00:00:13,330 --> 00:00:17,205 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,205 --> 00:00:17,830 at ocw.mit.edu. 8 00:00:21,900 --> 00:00:23,400 EDDIE SCHOLTZ: So, I'm Eddie Scholtz 9 00:00:23,400 --> 00:00:25,120 and this is Mike Fitzgerald and we 10 00:00:25,120 --> 00:00:28,100 worked on a backgammon tutor. 11 00:00:28,100 --> 00:00:30,310 And to start off, let's see a show of hands. 12 00:00:30,310 --> 00:00:33,690 Who here knows how to play backgammon? 13 00:00:33,690 --> 00:00:34,830 OK, a few. 14 00:00:34,830 --> 00:00:37,830 So to give you an idea of how it works, 15 00:00:37,830 --> 00:00:41,790 it involves both skill and luck. 16 00:00:41,790 --> 00:00:43,400 And it's a two player game. 17 00:00:43,400 --> 00:00:45,930 And the object is to move all your pieces 18 00:00:45,930 --> 00:00:48,680 past your opponent's pieces and off the board. 19 00:00:48,680 --> 00:00:51,510 So white's trying to move his pieces this way, 20 00:00:51,510 --> 00:00:53,080 down and across. 21 00:00:53,080 --> 00:00:55,960 And brown's trying to move his pieces the other way. 22 00:00:55,960 --> 00:00:58,520 And you move by rolling the dice. 23 00:00:58,520 --> 00:01:01,350 Some important rules are that you can not 24 00:01:01,350 --> 00:01:04,410 land on a point on which your opponent has 25 00:01:04,410 --> 00:01:05,940 two or more pieces. 26 00:01:05,940 --> 00:01:09,300 And if your opponent only has a single piece there, 27 00:01:09,300 --> 00:01:11,705 you can land on it and send it back to the beginning. 28 00:01:14,780 --> 00:01:16,780 So the goals of this project when we started off 29 00:01:16,780 --> 00:01:19,071 were, first of all to implement the rules of backgammon 30 00:01:19,071 --> 00:01:23,200 and get the game going, and that took a good amount of work. 31 00:01:23,200 --> 00:01:25,690 Next we wanted to create or find the function that 32 00:01:25,690 --> 00:01:29,890 evaluates or says how good a given board is. 33 00:01:29,890 --> 00:01:35,390 And then we wanted to be able to look into the future, 34 00:01:35,390 --> 00:01:38,540 in order to better determine what move to choose now. 35 00:01:38,540 --> 00:01:43,650 And this is the part of the program that we parallelized. 36 00:01:43,650 --> 00:01:45,650 And finally our last goal was to try 37 00:01:45,650 --> 00:01:50,370 to teach the player how to improve 38 00:01:50,370 --> 00:01:53,470 by suggesting why one move might be better than another 39 00:01:53,470 --> 00:01:53,980 in English. 40 00:01:57,810 --> 00:02:01,540 So to start with, the two basic kinds of board evaluation 41 00:02:01,540 --> 00:02:05,750 are just a static evaluator and a neural net. 42 00:02:05,750 --> 00:02:09,449 And the static evaluator works by looking 43 00:02:09,449 --> 00:02:14,050 at features of the board and creating a score based 44 00:02:14,050 --> 00:02:16,520 on that feature, and then multiplying it 45 00:02:16,520 --> 00:02:19,600 by weight based on how important that feature is, 46 00:02:19,600 --> 00:02:20,970 and summing them up. 47 00:02:20,970 --> 00:02:24,790 So a program like this was created by Hans Berliner at CMU 48 00:02:24,790 --> 00:02:27,770 in 1979, and it was actually the first program 49 00:02:27,770 --> 00:02:30,710 to beat a ruling world champion. 50 00:02:30,710 --> 00:02:33,636 And they said the program got a little lucky but it did win. 51 00:02:33,636 --> 00:02:35,010 And one of the important features 52 00:02:35,010 --> 00:02:37,189 was it adjusted the weights as the game went on, 53 00:02:37,189 --> 00:02:39,105 because certain features became less important 54 00:02:39,105 --> 00:02:44,040 as the game progressed and other features became more important. 55 00:02:44,040 --> 00:02:45,790 So the next approach that people have used 56 00:02:45,790 --> 00:02:50,810 is framing neural nets to determine how good a board is. 57 00:02:50,810 --> 00:02:52,940 And these have been really successful. 58 00:02:52,940 --> 00:02:57,050 They work by basically playing hundreds of thousands, 59 00:02:57,050 --> 00:03:00,790 if not millions of games against itself. 60 00:03:00,790 --> 00:03:05,080 And so it improves this way. 61 00:03:05,080 --> 00:03:07,930 And after about a million and half games 62 00:03:07,930 --> 00:03:13,430 it reaches its maximum performance. 63 00:03:13,430 --> 00:03:16,990 And one such board evaluator is Pubeval 64 00:03:16,990 --> 00:03:20,680 which was released by Gerry Tesauro in 1993. 65 00:03:20,680 --> 00:03:23,060 And this is the evaluation function 66 00:03:23,060 --> 00:03:26,677 that we used for our program. 67 00:03:26,677 --> 00:03:28,260 Looks like we lost network connection. 68 00:03:28,260 --> 00:03:31,510 This is the evaluation function that we used for our program. 69 00:03:31,510 --> 00:03:34,150 And he sort of released this as a benchmark evaluator 70 00:03:34,150 --> 00:03:36,870 so that other people in the development community 71 00:03:36,870 --> 00:03:40,130 could have something to compare their evaluators against. 72 00:03:40,130 --> 00:03:41,994 And it plays an intermediate level if not 73 00:03:41,994 --> 00:03:42,910 a pretty strong level. 74 00:03:46,210 --> 00:03:48,900 So our next goal was to implement the search 75 00:03:48,900 --> 00:03:50,570 the looks into the future in order 76 00:03:50,570 --> 00:03:53,640 to help choose the best move now. 77 00:03:53,640 --> 00:03:56,770 One of the challenges of this is that the branching factor 78 00:03:56,770 --> 00:03:59,550 is so large because you don't know what the dice rolls are 79 00:03:59,550 --> 00:04:02,350 going to be in the future. 80 00:04:02,350 --> 00:04:05,630 And like in checkers, the branching factor is 10. 81 00:04:05,630 --> 00:04:07,290 In chess it's 35 to 40. 82 00:04:07,290 --> 00:04:12,540 But in backgammon, for a turn it's around 400. 83 00:04:12,540 --> 00:04:15,140 Another challenge that we faced in the search was 84 00:04:15,140 --> 00:04:19,660 that the Pubeval function that we used is not zero sum. 85 00:04:19,660 --> 00:04:23,990 So that produced some challenges that you'll see. 86 00:04:23,990 --> 00:04:27,360 And also there's the question of whether searching deeper 87 00:04:27,360 --> 00:04:30,160 actually does produce better play. 88 00:04:30,160 --> 00:04:34,220 And most papers say that the board evaluator 89 00:04:34,220 --> 00:04:36,790 is more important than searching deeper. 90 00:04:36,790 --> 00:04:41,990 But they do say that searching into the future 91 00:04:41,990 --> 00:04:44,380 does improve play, and especially when you're already 92 00:04:44,380 --> 00:04:47,925 at a pretty high level of play where everyone's near the same 93 00:04:47,925 --> 00:04:50,499 and playing really well. 94 00:04:50,499 --> 00:04:53,040 A slight increase in performance could make a big difference. 95 00:04:56,460 --> 00:05:00,190 So here's an illustration of the search tree 96 00:05:00,190 --> 00:05:02,540 to give you a better idea of how it works. 97 00:05:02,540 --> 00:05:04,480 So say it's X's turn. 98 00:05:04,480 --> 00:05:08,420 There might be 20 or so moves that he can commit. 99 00:05:08,420 --> 00:05:10,710 Now these are a series of moves. 100 00:05:10,710 --> 00:05:14,520 So you roll the two dice, and if they're 101 00:05:14,520 --> 00:05:16,650 doubles you get four moves. 102 00:05:16,650 --> 00:05:19,150 Certain turns you may not be able to move at all so you 103 00:05:19,150 --> 00:05:20,570 might not have any moves. 104 00:05:20,570 --> 00:05:23,050 So that really varies. 105 00:05:23,050 --> 00:05:26,500 So after those 20 moves the other player, 106 00:05:26,500 --> 00:05:28,090 O is going to roll. 107 00:05:28,090 --> 00:05:31,480 And there's 21 different dice combinations he can have. 108 00:05:31,480 --> 00:05:35,440 And then for each of those there's about 20 moves. 109 00:05:35,440 --> 00:05:37,800 And then it's X's roll. 110 00:05:37,800 --> 00:05:41,050 And once again he has 21 dice combinations. 111 00:05:41,050 --> 00:05:42,910 And then X's move. 112 00:05:42,910 --> 00:05:47,580 So this is looking two moves into the future. 113 00:05:47,580 --> 00:05:50,410 So the idea is to build this search tree, 114 00:05:50,410 --> 00:05:52,810 and then at this point we're already 115 00:05:52,810 --> 00:05:54,275 up to 3.5 million boards. 116 00:05:56,860 --> 00:05:59,830 So you have all these leaf nodes that represent your boards, 117 00:05:59,830 --> 00:06:01,260 and you're going to evaluate them 118 00:06:01,260 --> 00:06:04,160 with your evaluation function to determine how good they are. 119 00:06:04,160 --> 00:06:06,290 Since it's not zero sum, you have 120 00:06:06,290 --> 00:06:10,970 to evaluate it for both player and both of these values 121 00:06:10,970 --> 00:06:14,380 need to get passed up as you're going to move back up the tree 122 00:06:14,380 --> 00:06:15,730 to determine the best move. 123 00:06:18,850 --> 00:06:22,130 So you start at the bottom and you 124 00:06:22,130 --> 00:06:23,630 say that since it's X's move he's 125 00:06:23,630 --> 00:06:29,300 going to choose the best possible move given that roll. 126 00:06:29,300 --> 00:06:33,400 And then in order to move up further and calculate 127 00:06:33,400 --> 00:06:36,120 the value for the parent node, you 128 00:06:36,120 --> 00:06:39,800 say it's equal to the probability of the dice 129 00:06:39,800 --> 00:06:43,007 roll for the child node times the value that's 130 00:06:43,007 --> 00:06:44,090 stored in that child node. 131 00:06:47,870 --> 00:06:51,710 And then you keep doing this and repeating this. 132 00:06:51,710 --> 00:06:56,850 O picks his best move and sort of sums the expected value. 133 00:06:56,850 --> 00:07:01,214 And then get back up the top and X picks his best move. 134 00:07:01,214 --> 00:07:02,880 So now I'm going to hand it over to Mike 135 00:07:02,880 --> 00:07:04,920 who's going to talk about the part of the code 136 00:07:04,920 --> 00:07:05,794 that we parallelized. 137 00:07:07,830 --> 00:07:09,330 MIKE FITZGERALD: There's a question. 138 00:07:09,330 --> 00:07:10,390 AUDIENCE: Quick question. 139 00:07:10,390 --> 00:07:12,210 Can you use alpha beta pruning? 140 00:07:12,210 --> 00:07:13,970 You know about alpha beta pruning? 141 00:07:13,970 --> 00:07:14,803 EDDIE SCHOLTZ: Yeah. 142 00:07:14,803 --> 00:07:18,236 People have used that and just like a [INAUDIBLE] 143 00:07:18,236 --> 00:07:20,060 search of narrowing it down. 144 00:07:20,060 --> 00:07:22,590 AUDIENCE: Typically by down to the square root of n. 145 00:07:22,590 --> 00:07:25,904 So you would have a 20 branch effect rather than a 400. 146 00:07:25,904 --> 00:07:28,362 It seems like a real payoff if you could make it work here. 147 00:07:28,362 --> 00:07:30,653 I don't know if there's some reason on the back end why 148 00:07:30,653 --> 00:07:31,784 it's hard. 149 00:07:31,784 --> 00:07:34,200 EDDIE SCHOLTZ: Well, we actually didn't get to that point. 150 00:07:34,200 --> 00:07:37,395 We just spent a lot of time just implementing rules of the game. 151 00:07:45,100 --> 00:07:47,510 MIKE FITZGERALD: All right, so the first thing 152 00:07:47,510 --> 00:07:51,880 we looked at and said this would be perfect for parallelizing 153 00:07:51,880 --> 00:07:56,040 is just the brute force evaluation of those million 154 00:07:56,040 --> 00:07:58,570 boards that you get down to at the end. 155 00:07:58,570 --> 00:08:01,530 Which if you run through on one processor just takes a while. 156 00:08:05,780 --> 00:08:08,261 Generally an evaluation of a board, regardless of its state 157 00:08:08,261 --> 00:08:09,510 takes the same amount of time. 158 00:08:09,510 --> 00:08:14,979 So we just had to split the number evenly between SPUs. 159 00:08:14,979 --> 00:08:16,770 We had to keep it around a multiple of four 160 00:08:16,770 --> 00:08:21,310 just to get the DMA calls to line up nicely with the floats 161 00:08:21,310 --> 00:08:24,070 that we were returning and things like that. 162 00:08:24,070 --> 00:08:27,260 So if you're evaluating a million boards which 163 00:08:27,260 --> 00:08:31,680 was our number for our benchmarks that we did, 164 00:08:31,680 --> 00:08:35,059 each SPU has about 170,000 to handle, 165 00:08:35,059 --> 00:08:38,730 and it clearly can't take all those over at once. 166 00:08:38,730 --> 00:08:41,900 So each SPU knows where it's supposed to start 167 00:08:41,900 --> 00:08:43,280 and how many it's supposed to do. 168 00:08:43,280 --> 00:08:44,905 And it knows how much it can pull over. 169 00:08:44,905 --> 00:08:49,026 So it does a DMA call to pull in as much as it can process. 170 00:08:49,026 --> 00:08:53,810 It processes those, evaluates them, returns them, 171 00:08:53,810 --> 00:08:55,050 and gets to the next bunch. 172 00:08:55,050 --> 00:08:59,600 So that is what we were able to implement. 173 00:08:59,600 --> 00:09:02,990 There's also a good opportunity for double buffering there 174 00:09:02,990 --> 00:09:05,220 for pulling them in as it's actually 175 00:09:05,220 --> 00:09:06,520 evaluating the previous ones. 176 00:09:06,520 --> 00:09:10,930 So that would be actually a pretty easy step to do next. 177 00:09:10,930 --> 00:09:12,310 But each of those six are roughly 178 00:09:12,310 --> 00:09:16,840 finished at the same time and then get back to the PPU 179 00:09:16,840 --> 00:09:21,430 to evaluate, to run up that tree. 180 00:09:21,430 --> 00:09:23,750 And another opportunity to make it a bit quicker, 181 00:09:23,750 --> 00:09:25,166 which we didn't quite get to would 182 00:09:25,166 --> 00:09:27,460 be SIMDizing the evaluation function 183 00:09:27,460 --> 00:09:28,950 so we could do four boards at once 184 00:09:28,950 --> 00:09:33,380 with vector engines instead of just one. 185 00:09:33,380 --> 00:09:35,770 So the performance that we got when 186 00:09:35,770 --> 00:09:39,490 looking at the number of SPUs we were using 187 00:09:39,490 --> 00:09:43,070 was actually roughly in proportional 188 00:09:43,070 --> 00:09:44,880 to the number of SPUs we were using. 189 00:09:44,880 --> 00:09:48,570 It's actually 18.18 at the top there. 190 00:09:48,570 --> 00:09:51,090 So when using two instead of one we got just about half. 191 00:09:51,090 --> 00:09:55,240 When using three instead of one we got just about a third. 192 00:09:55,240 --> 00:09:58,410 If you just look at this speedup graph it's pretty much one 193 00:09:58,410 --> 00:10:02,025 to one from the number of SPUs we 194 00:10:02,025 --> 00:10:04,810 were using to the amount of time it took. 195 00:10:04,810 --> 00:10:06,991 So it was a pretty efficient algorithm 196 00:10:06,991 --> 00:10:09,240 for splitting those up and evaluating them and pulling 197 00:10:09,240 --> 00:10:11,325 them back together. 198 00:10:11,325 --> 00:10:12,450 I'll give you a brief demo. 199 00:10:12,450 --> 00:10:14,400 I'll show you quickly how it looks. 200 00:10:14,400 --> 00:10:18,023 We might have to fudge our network connection a little bit 201 00:10:18,023 --> 00:10:18,523 here. 202 00:10:45,490 --> 00:10:48,070 So we used just an [INAUDIBLE] Windows 203 00:10:48,070 --> 00:10:55,430 setup to display our [INAUDIBLE] we were using. 204 00:10:59,720 --> 00:11:05,190 So I'm just going play a couple rounds of the display, 205 00:11:05,190 --> 00:11:07,191 let's say against the computer. 206 00:11:16,397 --> 00:11:18,980 So you can see the computer just took a couple of moves there. 207 00:11:18,980 --> 00:11:21,130 But basically what we get here is 208 00:11:21,130 --> 00:11:25,340 a print out of a text representation of the board. 209 00:11:25,340 --> 00:11:28,030 And then it's my turn. 210 00:11:28,030 --> 00:11:29,195 I rolled a six and a two. 211 00:11:31,932 --> 00:11:33,390 It does its own evaluation and says 212 00:11:33,390 --> 00:11:36,090 this is what the best move combo would be for me at this point. 213 00:11:38,960 --> 00:11:40,761 In the ideal tutoring situation we 214 00:11:40,761 --> 00:11:43,010 don't let the user pick what they thought was the best 215 00:11:43,010 --> 00:11:45,380 and then tell them why not, but right now, 216 00:11:45,380 --> 00:11:47,360 with the time we had this is how we did it. 217 00:11:47,360 --> 00:11:51,060 And then it lists all the legal possible moves you can make. 218 00:11:51,060 --> 00:11:54,770 Let's say I want to move from 0.6 to 0.4. 219 00:11:54,770 --> 00:11:59,145 It moves my piece up there, and from 8 to 2 for example. 220 00:11:59,145 --> 00:12:02,180 And the computer makes its couple of moves. 221 00:12:02,180 --> 00:12:03,400 That's the general idea. 222 00:12:03,400 --> 00:12:06,630 You can run the computer against itself as many times, 223 00:12:06,630 --> 00:12:09,150 just to test different evaluation functions 224 00:12:09,150 --> 00:12:09,950 against each other. 225 00:12:09,950 --> 00:12:13,410 You can also do it without the animation on the GUI 226 00:12:13,410 --> 00:12:16,310 so that it runs a lot quicker. 227 00:12:16,310 --> 00:12:18,725 But that's the general idea. 228 00:12:22,210 --> 00:12:26,241 Just to wrap up, four more slides. 229 00:12:26,241 --> 00:12:27,740 The way we went about this basically 230 00:12:27,740 --> 00:12:32,370 was, we just got sequential code working on just the PPU, got 231 00:12:32,370 --> 00:12:34,500 the rules of the game worked out, 232 00:12:34,500 --> 00:12:36,970 all the weird conditionals and things 233 00:12:36,970 --> 00:12:40,330 that can happen in backgammon and we fixed out our bugs 234 00:12:40,330 --> 00:12:42,640 and our memory leaks and things like that. 235 00:12:42,640 --> 00:12:45,540 We just shelled out the parallel code 236 00:12:45,540 --> 00:12:50,310 and got that working on the PPU, then on one SPU, 237 00:12:50,310 --> 00:12:51,630 and then on six. 238 00:12:51,630 --> 00:12:56,760 So it was a pretty clean process of doing it. 239 00:12:56,760 --> 00:12:59,660 And we ran into a few walls. 240 00:12:59,660 --> 00:13:02,124 We aren't really backgammon experts or even 241 00:13:02,124 --> 00:13:04,540 intermediate players, so it was kind of a new thing for us 242 00:13:04,540 --> 00:13:06,190 to make sure we had the rules right, 243 00:13:06,190 --> 00:13:10,619 and we weren't doing stupid things here and there. 244 00:13:10,619 --> 00:13:12,660 But also managing the search tree was a big deal. 245 00:13:12,660 --> 00:13:15,730 And looking at what the program has 246 00:13:15,730 --> 00:13:17,890 to do in running the game, that's 247 00:13:17,890 --> 00:13:23,450 the next thing we want to tackle as far as paralyzing goes. 248 00:13:23,450 --> 00:13:27,932 It takes a while, and it's pretty tough. 249 00:13:27,932 --> 00:13:29,640 We ran into some memory management issues 250 00:13:29,640 --> 00:13:32,826 with how we were representing our boards. 251 00:13:32,826 --> 00:13:35,480 We were able to pack them down into, 252 00:13:35,480 --> 00:13:41,410 I think 24 byte structure, 20 byte structure 253 00:13:41,410 --> 00:13:43,750 to be able to pass more to the SPUs at one time. 254 00:13:50,204 --> 00:13:53,585 PROFESSOR: [INAUDIBLE] What's the general idea 255 00:13:53,585 --> 00:13:54,280 for [INAUDIBLE]? 256 00:13:54,280 --> 00:13:55,780 MIKE FITZGERALD: I'm sorry, I missed 257 00:13:55,780 --> 00:13:57,488 the beginning of your question because it 258 00:13:57,488 --> 00:13:58,730 wasn't on speakerphone. 259 00:13:58,730 --> 00:13:59,688 PROFESSOR: [INAUDIBLE]. 260 00:14:23,560 --> 00:14:26,060 EDDIE SCHOLTZ: Are you talking about moving into the future? 261 00:14:26,060 --> 00:14:27,160 Are you talking about looking into the future? 262 00:14:27,160 --> 00:14:27,659 Yeah. 263 00:14:27,659 --> 00:14:31,490 So we built the code for creating that tree 264 00:14:31,490 --> 00:14:33,620 and evaluating the leaf nodes. 265 00:14:33,620 --> 00:14:35,875 We didn't quite have time to finish up-- 266 00:14:35,875 --> 00:14:37,500 PROFESSOR: [INAUDIBLE] I can't hear you 267 00:14:37,500 --> 00:14:39,200 through this [INAUDIBLE]. 268 00:14:39,200 --> 00:14:39,950 EDDIE SCHOLTZ: OK. 269 00:14:39,950 --> 00:14:42,910 We created the code for constructing the tree 270 00:14:42,910 --> 00:14:44,650 and evaluating the leaf nodes. 271 00:14:44,650 --> 00:14:46,660 We haven't quite has time to finish up 272 00:14:46,660 --> 00:14:48,250 moving back up the tree. 273 00:14:48,250 --> 00:14:50,620 So at this point we're now looking ahead more 274 00:14:50,620 --> 00:14:56,457 than just the moves for now, for like one move. 275 00:14:56,457 --> 00:14:57,040 PROFESSOR: OK. 276 00:14:57,040 --> 00:14:58,034 OK. 277 00:14:58,034 --> 00:14:59,825 EDDIE SCHOLTZ: But we got the parallel code 278 00:14:59,825 --> 00:15:01,616 working for actually evaluating the boards. 279 00:15:01,616 --> 00:15:04,250 It shouldn't be too hard to-- 280 00:15:04,250 --> 00:15:06,450 MIKE FITZGERALD: Just extend that tree. 281 00:15:06,450 --> 00:15:07,360 EDDIE SCHOLTZ: To move back up the tree 282 00:15:07,360 --> 00:15:08,776 and see what the best move is now. 283 00:15:12,862 --> 00:15:14,820 EDDIE SCHOLTZ: Yeah, so that's basically as far 284 00:15:14,820 --> 00:15:18,406 as the road blocks we hit were. 285 00:15:18,406 --> 00:15:19,894 EDDIE SCHOLTZ: Any other questions? 286 00:15:24,360 --> 00:15:28,140 Yeah, just some future ideas. 287 00:15:28,140 --> 00:15:32,740 One of the big ones is for training, the evaluation 288 00:15:32,740 --> 00:15:34,540 functions using neural nets. 289 00:15:34,540 --> 00:15:39,270 That takes a lot of time to play hundreds of thousands, 290 00:15:39,270 --> 00:15:40,680 millions of games. 291 00:15:40,680 --> 00:15:43,470 So one of the ideas is to parallelize 292 00:15:43,470 --> 00:15:48,240 that to help speed that up. 293 00:15:48,240 --> 00:15:50,911 And I think we're about out of time, so that concludes it. 294 00:15:50,911 --> 00:15:51,910 Are there any questions? 295 00:15:55,101 --> 00:15:56,600 AUDIENCE: I'm just curious, you said 296 00:15:56,600 --> 00:15:58,558 looking far into the future doesn't necessarily 297 00:15:58,558 --> 00:16:00,510 help as much as the evaluation function. 298 00:16:00,510 --> 00:16:03,110 Does that mean that AI backgammon 299 00:16:03,110 --> 00:16:05,820 is-- I mean how computationally intensive is a good player? 300 00:16:05,820 --> 00:16:10,927 I mean, is it a computationally problem? 301 00:16:10,927 --> 00:16:12,510 Would you benefit from the parallelism 302 00:16:12,510 --> 00:16:13,770 in a practical setting? 303 00:16:13,770 --> 00:16:15,300 MIKE FITZGERALD: Well, just looking 304 00:16:15,300 --> 00:16:17,762 at how long it takes to go through those million boards, 305 00:16:17,762 --> 00:16:19,176 if you're playing a computer you don't 306 00:16:19,176 --> 00:16:21,759 want to wait 18 seconds for them to make their move as opposed 307 00:16:21,759 --> 00:16:22,330 to-- 308 00:16:22,330 --> 00:16:24,000 AUDIENCE: Oh, so that's time scale of the absolute? 309 00:16:24,000 --> 00:16:26,041 If you just ran on a uni-processor for 20 seconds 310 00:16:26,041 --> 00:16:27,016 kind of a thing? 311 00:16:27,016 --> 00:16:29,944 MIKE FITZGERALD: Yeah, once you're doing a million boards. 312 00:16:29,944 --> 00:16:33,263 And also, if you're on the level of competing 313 00:16:33,263 --> 00:16:37,312 against really good competitors, just having a deep search tree 314 00:16:37,312 --> 00:16:39,120 to get that much more of an edge would make 315 00:16:39,120 --> 00:16:41,260 a difference in that situation. 316 00:16:45,160 --> 00:16:45,760 Anyone else? 317 00:16:45,760 --> 00:16:47,285 No? 318 00:16:47,285 --> 00:16:48,160 EDDIE SCHOLTZ: Great. 319 00:16:48,160 --> 00:16:49,660 Thanks. 320 00:16:49,660 --> 00:16:51,210 [APPLAUSE]