Answers.Body: <p>To answer the question in the title: In chess programming, <a href="https://www.chessprogramming.org/Perft" rel="nofollow noreferrer">perft</a> is used for debugging move generators and testing their performance: the goal is simply to calculate the number of possible ways the game could continue until a mate or a stalemate for the next N moves. Modern engines give around 10-100 million nodes per second using one core of a modern processor. <a href="http://www.talkchess.com/forum/viewtopic.php?t=48387" rel="nofollow noreferrer">This program</a> apparently searches 20 billion nodes per second using a modern GPU instead of a CPU.</p>
  <hr />
  <p>However, as I said in the comments, searching for a mate in N moves is very different than searching all possible moves until that depth. The following observation is the heart of <a href="http://en.wikipedia.org/wiki/Alpha%E2%80%93beta_pruning" rel="nofollow noreferrer">alpha-beta pruning</a>: for example, if you have found that after 6.Nc3 Qxb4 7.Nd3 white can mate, there's no need to see what happens after 6.Nc3 Qxb4 7.a4.</p>
  <p>Another, perhaps more likely example: You have found that the position after 5.e3 is drawn, and then find out that 5.e4 Qc7 gives a draw, too. Now we already know that the position before 5.e4 is at least a draw for white, and find out that the position after 5.e4 cannot be a win for white. Because it does not matter whether white draws or loses after 5.e4, we don't have to see what happens after 5.e4 Qb6.</p>
  <p>As you probably can see, move ordering is critical here: it is beneficial to search best moves first. In fact, with perfect move-ordering, alpha-beta can reduce the number of searched nodes to approximately square root of the original value. So with perfect move-ordering, the number of positions needed to search for mate in 10 plies would be 35^5, not 35^10. But to get a good move ordering, one needs to do something else than just generate moves: perhaps evaluate the intermediate positions to get a good hint of the values of the moves. Of course, for the search of mate in, say, 20 plies, the best evaluator function would probably be different than what is used in engines designed to play a full game of chess.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-17T05:31:47.470Z
Answers.Text: I think the statement that alpha-beta related to forced mate is wrong. You DO have to continue search once you've found the mate. I don't have space here to elaborate as a comment, but please read http://talkchess.com/forum/viewtopic.php?start=0&t=20804&topic_view=flat , in particular what Hyatt wrote.
Answers.UserDisplayName: SmallChess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-17T07:03:27.760Z
Answers.Text: @StudentT That occurs when using hash tables and other extensions which cause the actual search depth of different branches of the tree to vary; we are not doing them here.
Answers.UserDisplayName: JiK
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2014-12-16T19:11:35.370Z
Answers.LastActivityDate: 2021-05-17T16:21:26.400Z
Answers.LastEditDate: 2021-05-17T16:21:26.400Z
Answers.UserDisplayName: JiK
Answers.Body: <p>This depends heavily on how complicated your evaluation function is. The more complicated it is, the more time is necessary to &quot;calculate&quot; (more accurate word here is evaluate) one position. That's why the current neural network engines calculate three orders of magnitude fewer positions per second than traditional engines. In the same way, engine speeds are usually slower during the early-middle game when there are more pieces on the board, and therefore more functions in the evaluation need to be calculated (e.g. if all the knights are gone then the <em>knight</em> function in the evaluation can be ignored).</p>
  <p>Since you're only after an order of magnitude estimate, we can make these assumptions:</p>
  <ul>
  <li>The engine playing is Stockfish with NNUE enabled, currently the strongest engine available. <a href="https://en.wikipedia.org/wiki/Efficiently_updatable_neural_network" rel="nofollow noreferrer">NNUE</a> is a version of neural network evaluation that can run quickly on CPU. It is slower than the traditional handcrafted eval (by about a factor of 2), but not by much.</li>
  <li>If you look at the latest TCEC Superfinal, <a href="https://tcec-chess.com/#div=sf&amp;game=1&amp;season=20" rel="nofollow noreferrer">game 1</a>, you can see that Stockfish evaluated about 120 million positions per second. TCEC's CPU engines run on 88 physical cores.</li>
  <li>The <a href="https://en.wikipedia.org/wiki/Fugaku_(supercomputer)" rel="nofollow noreferrer">world's fastest supercomputer</a> right now has, if I am not mistaken, about 8 million cores. Therefore it is about 100,000 times faster than the TCEC computer.</li>
  </ul>
  <p><strong>Conclusion</strong>: about 12,000,000 million positions a second - or about 12 trillion positions per second.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-17T22:26:54.950Z
Answers.LastActivityDate: 2021-05-17T22:50:08.010Z
Answers.LastEditDate: 2021-05-17T22:50:08.010Z
Answers.UserDisplayName: Allure
Answers.Body: <p>Since another user already commented on alpha-beta and the importance of good heuristics for move ordering, I will focus on a different aspect of your question.</p>
  
  <p>You specifically asked about forced mates rather than general board position evaluation, which makes the question somewhat easier to answer because it does not depend on the strength and cost of some evaluation function heuristic. </p>
  
  <p>There is a family of related tree search algorithms collectively known as PN or proof number search (distant cousins of the general alpha-beta pruned search) which are particularly efficient at solving binary subproblems in computer games, such as whether or not there is a forced mate in &lt;=N moves in chess (rather than the more abstract question of which board position is "better").
  The algorithm proceeds by visiting each node and trying to either prove or disprove the initial query by checking which conditions must be satisfied for that branch to contain a solution (or a countersolution) and evaluating them in a "good" order such that proof failures can be detected early. The search quits as soon as it finds the first solution to the query (unlike ab- search, which keeps going until it finds the optimal minimax sequence).</p>
  
  <p><a href="https://en.wikipedia.org/wiki/Proof-number_search" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Proof-number_search</a></p>
  
  <p>In general, the "deepest" searching algorithms based on PN combine two searches, the "top" half running some PN variant sped up by transposition tables, and after some critical depth which depends on the amount of memory available for the tables, a second search algorithm without TT is launched, for some maximum depth of plies. It is the case that large enough searches will far exceed in number of nodes any reasonable amount of memory, so the TT can only help skip redundant branches at the lowest depths.</p>
  
  <p>If we assume we can build a TT in memory with something like 10^9 positions (for a memory in the order of several Gb), we will in theory fill it with the surviving search candidates from a search in theory twice as deep (10^18 positions), the vast majority of which will have been ruled out by the algorithm without further analysis. Stockfish can run in the order of 70 million plies per second on a high-end computer, which means a "regular" computer can fill the top half of the search in the order of 10s of seconds to a few minutes. This top part of the search roughly corresponds to 11.6 plies already.</p>
  
  <p>The expensive work however is to launch a search at each one of the leaves, which can fortunately be done in parallel using as much hardware as you can throw at it. The point here is not so much how many "computations" can be done per second but whether or not you want to check the table (memory accesses are costly, but narrow the search), build a local TT of just a few Mb to speed up purely the local search, or just use CPU power as means of tree exploration.</p>
  
  <p>Tianhe-2 has something like 10^7 cores, so we are talking about assigning ~100 subproblems to each for maximum parallelism. So two minutes of thinking time will roughly translate into 1 second of unbounded exploration for each of the 10^9 leafs. Now assume each core visits 5 million (pruned) positions in this second and we get in theory an extra 8.7 plies of depth for a total of 20.3 plies of depth.</p>
  
  <p>HOWEVER, the true number will be much higher because we ignored the effect of transpositions. Since we are considering ALL legal moves each turn, we can approximate the number of transpositions as roughly (M!^2) with M=2P the number of moves. This is because most moves outside of a strategy do not interfere with other legal moves elsewhere on the board.</p>
  
  <p>So visiting 10^9 nodes in the first half actually implies solving  30 ^ P = (10^9)^2 (P/2)!^2, which gives a (possibly too optimistic) bound of P~24, and similarly the bottom half gives P~14 for a total depth of 38 plies.</p>
  
  <p>Now of course in reality moves will end up not commuting, and the children nodes are not always visited in optimal order, but on the other hand we are using all legal moves as branching factor, which is a very pessimistic selection choice .</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-03-27T20:33:07.850Z
Answers.LastActivityDate: 2019-03-27T20:33:07.850Z
Answers.UserDisplayName: paperclip optimizer
Answers.Body: <p>I am unable to comment so im commenting here. Do you assume the computer starts calculating from the very beginning of the game or from a middle-endgame position? From the very beginning it would be impossible to find a forced mate because if both sides were to play their best lines it would be a draw. Lets say for example that out of the infinite chess mate positions possible it comes up with the fools mate first. If your computer were to calculate to find the first available mate it would find that. The question would be better asked if you have a move min or max to help centralize the math.</p>
  
  <p>Potentially super computer in the future will have unimaginable processing rates and they will progress in their ability until infinity would we conclude then computers could calculate infinite amount of moves in a second? It was good you defined your parameters in the beginning by keeping the processing power limited to today's limits.</p>
  
  <p>As refered to in the first comment the question should be how many positions a comp can generate in a second. To analyse a move and its infinite amount of possible positions would take infinitely long.</p>
  
  <p>I might be rambling on at this point but i just wanted to ask a few questions to help refine your questions.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-16T18:22:47.647Z
Answers.Text: The math could be affected by what positions it considers first. It may find the fastest mate 1st or it might not find it until later
Answers.UserDisplayName: theeppright
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-17T00:08:05.830Z
Answers.Text: Just a couple of observations: (1) "From the very beginning it would be impossible to find a forced mate because if both sides were to play their best lines it would be a draw." We don't know that. (2) "... out of the infinite chess mate positions ..." There are only finitely many chess positions period, as there are only finitely many pieces and finitely many places to put them.
Answers.UserDisplayName: ETD
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-16T18:09:15.780Z
Answers.LastActivityDate: 2014-12-16T18:09:15.780Z
Answers.UserDisplayName: theeppright
Body: <p>If we created a very powerful supercomputer (as powerful as the current most powerful supercomputers) which was only designed to find forced mates, how many positions could it calculate per second?  </p>
  
  <p>I only need an approximation. And remember, the computer doesn't waste time evaluating every single positions (like normal engines do); it just calculates as far as he can until he finds a forced mate (if there is any).</p>
  
  <p>I tried to find the answer to the question myself, but I'm not sure at all if my conclusion is correct. So what follows may be wrong.</p>
  
  <ul>
  <li>I found that the supercomputer Deep Blue "was capable of evaluating 200 million positions per second" (from Wikipedia).  </li>
  <li>But Deep Blue was old, supercomputers have became much more powerful since 1997, and Deep Blue wasted time evaluating every positions.  </li>
  <li>Therefore 200 million is only a lower bound for the answer to this question.  </li>
  </ul>
  
  <p>Since Deep Blue had a performance of 11.38 GFLOPS, and the current most powerful supercomputer (Tianhe-2) has a performance of 33.86 PFLOPS = 33 860 000 GFLOPS, we could estimate that the answer would be closer to 200 000 000 * 33 900 000 / 11.38 = 6 * 10^14 = 600 trillion positions per second. That seems like a lot, but taking into account that in average a position has around 35 legal moves, given 3 minutes such a computer would only be able to calculate every single positions up to a depth of 11 plies. Since Deep Blue wasted time evaluating every single of those 200 million positions per second, I believe Deep Blue should have been able to calculate approximately a billion positions per second if it didn't have to evaluate them.  </p>
  
  <p>So the true answer to the question is probably closer to 3 * 10^15 = 3 quadrillion positions per second. That's still not much: given 30 seconds it would just be able to calculate everything up to a depth of 11 plies. Even given an entire year it would only be able to calculate every positions up to a depth of 15 plies.  </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-12-16T17:59:14.487Z
Comments.Text: So the question is "how many positions can a supercomputer *generate* per second"? What about transpositions; do those count? Even without doing any evaluation, it's likely somewhat dependent on how many pieces are on the "starting" board: does it start from the beginning position, or something else? I think this question would benefit from some rewording; I'm not totally sure what it is that you're asking.
Comments.UserDisplayName: Henry Keiter
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-12-16T18:19:34.163Z
Comments.Text: @Henry Keiter: I don't think the answer really depends on the "starting board". But we could say that the starting board is some position in the middlegame around move 20. As for transpositions, yes they do count obviously (remember that the supercomputer in the question doesn't evaluate the positions, so no time is lost evaluating positions which are just transpositions of some other positions already previously evaluated).
Comments.UserDisplayName: Fate
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-12-16T18:34:39.417Z
Comments.Text: @Petrosian If the goal is to find a forced mate, then every position does not have to be searched - you can use alpha-beta to reduce the tree. Transpositions are not only about evaluating single positions: if you are searching 10 plies deep starting from the initial position, and you have searched the position after 1.a3 a6 2.b3 seven plies deep, then searching the position after 1.b3 a6 2.a3 7 plies deep would repeat previously done work.
Comments.UserDisplayName: JiK
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-12-16T18:36:06.483Z
Comments.Text: Also, when using alpha-beta, evaluating positions might improve move-ordering when depth is high enough, and thus _decrease_ the time needed for finding a mate in N moves from a given position.
Comments.UserDisplayName: JiK
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-12-16T19:46:20.397Z
Comments.Text: Chess programs do _not_ use floating point operations, so any comparison based on FLOPS (floating point operations) is meaningless.
Comments.UserDisplayName: RemcoGerlich
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-04-05T09:46:27.800Z
Comments.Text: It really depends on what "computnig" a position is. You can make it compute almost as many as you want, the problem is whether for example by assigning a random evaluation to every of them. So there's a trade-off with precision there
Comments.UserDisplayName: David
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-05-17T19:25:21.840Z
Comments.Text: In [this talkchess post](http://www.talkchess.com/forum3/viewtopic.php?t=64983) someone shows the results for perft(15)
Comments.UserDisplayName: emdio
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-05-17T19:44:52.650Z
Comments.Text: Even for scientific computing, which is almost entirely floating point, FLOPS are mostly useless. The sooner that measure dies a death the better
Comments.UserDisplayName: Ian Bush
Tags: <engines><software><computer-chess>
Title: How many positions per second can a modern supercomputer calculate?
ThreadText: # How many positions per second can a modern supercomputer calculate?
  
  (Asked by: username_0 on 2014-12-16)
  
  If we created a very powerful supercomputer (as powerful as the current most powerful supercomputers) which was only designed to find forced mates, how many positions could it calculate per second?
  
  I only need an approximation. And remember, the computer doesn't waste time evaluating every single positions (like normal engines do); it just calculates as far as he can until he finds a forced mate (if there is any).
  
  I tried to find the answer to the question myself, but I'm not sure at all if my conclusion is correct. So what follows may be wrong.
  
  * I found that the supercomputer Deep Blue "was capable of evaluating 200 million positions per second" (from Wikipedia).
  * But Deep Blue was old, supercomputers have became much more powerful since 1997, and Deep Blue wasted time evaluating every positions.
  * Therefore 200 million is only a lower bound for the answer to this question.
  
  Since Deep Blue had a performance of 11.38 GFLOPS, and the current most powerful supercomputer (Tianhe-2) has a performance of 33.86 PFLOPS = 33 860 000 GFLOPS, we could estimate that the answer would be closer to 200 000 000 \* 33 900 000 / 11.38 = 6 \* 10^14 = 600 trillion positions per second. That seems like a lot, but taking into account that in average a position has around 35 legal moves, given 3 minutes such a computer would only be able to calculate every single positions up to a depth of 11 plies. Since Deep Blue wasted time evaluating every single of those 200 million positions per second, I believe Deep Blue should have been able to calculate approximately a billion positions per second if it didn't have to evaluate them.
  
  So the true answer to the question is probably closer to 3 \* 10^15 = 3 quadrillion positions per second. That's still not much: given 30 seconds it would just be able to calculate everything up to a depth of 11 plies. Even given an entire year it would only be able to calculate every positions up to a depth of 15 plies.
  
  **Tags:** engines, software, computer-chess
  
  > **Comments:**
  > **username_1**: So the question is "how many positions can a supercomputer *generate* per second"? What about transpositions; do those count? Even without doing any evaluation, it's likely somewhat dependent on how many pieces are on the "starting" board: does it start from the beginning position, or something else? I think this question would benefit from some rewording; I'm not totally sure what it is that you're asking.  
  > **username_0**: @username_1: I don't think the answer really depends on the "starting board". But we could say that the starting board is some position in the middlegame around move 20. As for transpositions, yes they do count obviously (remember that the supercomputer in the question doesn't evaluate the positions, so no time is lost evaluating positions which are just transpositions of some other positions already previously evaluated).  
  > **username_2**: @Petrosian If the goal is to find a forced mate, then every position does not have to be searched - you can use alpha-beta to reduce the tree. Transpositions are not only about evaluating single positions: if you are searching 10 plies deep starting from the initial position, and you have searched the position after 1.a3 a6 2.b3 seven plies deep, then searching the position after 1.b3 a6 2.a3 7 plies deep would repeat previously done work.  
  > **username_2**: Also, when using alpha-beta, evaluating positions might improve move-ordering when depth is high enough, and thus _decrease_ the time needed for finding a mate in N moves from a given position.  
  > **username_3**: Chess programs do _not_ use floating point operations, so any comparison based on FLOPS (floating point operations) is meaningless.  
  > **username_4**: It really depends on what "computnig" a position is. You can make it compute almost as many as you want, the problem is whether for example by assigning a random evaluation to every of them. So there's a trade-off with precision there  
  > **username_5**: In [this talkchess post](http://www.talkchess.com/forum3/viewtopic.php?t=64983) someone shows the results for perft(15)  
  > **username_6**: Even for scientific computing, which is almost entirely floating point, FLOPS are mostly useless. The sooner that measure dies a death the better  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_2 on 2014-12-16. Score: 7
  
  To answer the question in the title: In chess programming, [perft](https://www.chessprogramming.org/Perft) is used for debugging move generators and testing their performance: the goal is simply to calculate the number of possible ways the game could continue until a mate or a stalemate for the next N moves. Modern engines give around 10-100 million nodes per second using one core of a modern processor. [This program](http://www.talkchess.com/forum/viewtopic.php?t=48387) apparently searches 20 billion nodes per second using a modern GPU instead of a CPU.
  
  ---
  
  However, as I said in the comments, searching for a mate in N moves is very different than searching all possible moves until that depth. The following observation is the heart of [alpha-beta pruning](http://en.wikipedia.org/wiki/Alpha%E2%80%93beta_pruning): for example, if you have found that after 6.Nc3 Qxb4 7.Nd3 white can mate, there's no need to see what happens after 6.Nc3 Qxb4 7.a4.
  
  Another, perhaps more likely example: You have found that the position after 5.e3 is drawn, and then find out that 5.e4 Qc7 gives a draw, too. Now we already know that the position before 5.e4 is at least a draw for white, and find out that the position after 5.e4 cannot be a win for white. Because it does not matter whether white draws or loses after 5.e4, we don't have to see what happens after 5.e4 Qb6.
  
  As you probably can see, move ordering is critical here: it is beneficial to search best moves first. In fact, with perfect move-ordering, alpha-beta can reduce the number of searched nodes to approximately square root of the original value. So with perfect move-ordering, the number of positions needed to search for mate in 10 plies would be 35^5, not 35^10. But to get a good move ordering, one needs to do something else than just generate moves: perhaps evaluate the intermediate positions to get a good hint of the values of the moves. Of course, for the search of mate in, say, 20 plies, the best evaluator function would probably be different than what is used in engines designed to play a full game of chess.
  
  > **Comments:**
  > **username_7**: I think the statement that alpha-beta related to forced mate is wrong. You DO have to continue search once you've found the mate. I don't have space here to elaborate as a comment, but please read http://talkchess.com/forum/viewtopic.php?start=0&t=20804&topic_view=flat , in particular what Hyatt wrote.  
  > **username_2**: @StudentT That occurs when using hash tables and other extensions which cause the actual search depth of different branches of the tree to vary; we are not doing them here.  
  
  ---
  
  ### Answer by username_8 on 2021-05-17. Score: 3
  
  This depends heavily on how complicated your evaluation function is. The more complicated it is, the more time is necessary to "calculate" (more accurate word here is evaluate) one position. That's why the current neural network engines calculate three orders of magnitude fewer positions per second than traditional engines. In the same way, engine speeds are usually slower during the early-middle game when there are more pieces on the board, and therefore more functions in the evaluation need to be calculated (e.g. if all the knights are gone then the *knight* function in the evaluation can be ignored).
  
  Since you're only after an order of magnitude estimate, we can make these assumptions:
  
  * The engine playing is Stockfish with NNUE enabled, currently the strongest engine available. [NNUE](https://en.wikipedia.org/wiki/Efficiently_updatable_neural_network) is a version of neural network evaluation that can run quickly on CPU. It is slower than the traditional handcrafted eval (by about a factor of 2), but not by much.
  * If you look at the latest TCEC Superfinal, [game 1](https://tcec-chess.com/#div=sf&game=1&season=20), you can see that Stockfish evaluated about 120 million positions per second. TCEC's CPU engines run on 88 physical cores.
  * The [world's fastest supercomputer](https://en.wikipedia.org/wiki/Fugaku_(supercomputer)) right now has, if I am not mistaken, about 8 million cores. Therefore it is about 100,000 times faster than the TCEC computer.
  
  **Conclusion**: about 12,000,000 million positions a second - or about 12 trillion positions per second.
  
  
  ---
  
  ### Answer by username_9 on 2019-03-27. Score: 1
  
  Since another user already commented on alpha-beta and the importance of good heuristics for move ordering, I will focus on a different aspect of your question.
  
  You specifically asked about forced mates rather than general board position evaluation, which makes the question somewhat easier to answer because it does not depend on the strength and cost of some evaluation function heuristic.
  
  There is a family of related tree search algorithms collectively known as PN or proof number search (distant cousins of the general alpha-beta pruned search) which are particularly efficient at solving binary subproblems in computer games, such as whether or not there is a forced mate in <=N moves in chess (rather than the more abstract question of which board position is "better").
  The algorithm proceeds by visiting each node and trying to either prove or disprove the initial query by checking which conditions must be satisfied for that branch to contain a solution (or a countersolution) and evaluating them in a "good" order such that proof failures can be detected early. The search quits as soon as it finds the first solution to the query (unlike ab- search, which keeps going until it finds the optimal minimax sequence).
  
  <https://en.wikipedia.org/wiki/Proof-number_search>
  
  In general, the "deepest" searching algorithms based on PN combine two searches, the "top" half running some PN variant sped up by transposition tables, and after some critical depth which depends on the amount of memory available for the tables, a second search algorithm without TT is launched, for some maximum depth of plies. It is the case that large enough searches will far exceed in number of nodes any reasonable amount of memory, so the TT can only help skip redundant branches at the lowest depths.
  
  If we assume we can build a TT in memory with something like 10^9 positions (for a memory in the order of several Gb), we will in theory fill it with the surviving search candidates from a search in theory twice as deep (10^18 positions), the vast majority of which will have been ruled out by the algorithm without further analysis. Stockfish can run in the order of 70 million plies per second on a high-end computer, which means a "regular" computer can fill the top half of the search in the order of 10s of seconds to a few minutes. This top part of the search roughly corresponds to 11.6 plies already.
  
  The expensive work however is to launch a search at each one of the leaves, which can fortunately be done in parallel using as much hardware as you can throw at it. The point here is not so much how many "computations" can be done per second but whether or not you want to check the table (memory accesses are costly, but narrow the search), build a local TT of just a few Mb to speed up purely the local search, or just use CPU power as means of tree exploration.
  
  Tianhe-2 has something like 10^7 cores, so we are talking about assigning ~100 subproblems to each for maximum parallelism. So two minutes of thinking time will roughly translate into 1 second of unbounded exploration for each of the 10^9 leafs. Now assume each core visits 5 million (pruned) positions in this second and we get in theory an extra 8.7 plies of depth for a total of 20.3 plies of depth.
  
  HOWEVER, the true number will be much higher because we ignored the effect of transpositions. Since we are considering ALL legal moves each turn, we can approximate the number of transpositions as roughly (M!^2) with M=2P the number of moves. This is because most moves outside of a strategy do not interfere with other legal moves elsewhere on the board.
  
  So visiting 10^9 nodes in the first half actually implies solving 30 ^ P = (10^9)^2 (P/2)!^2, which gives a (possibly too optimistic) bound of P~24, and similarly the bottom half gives P~14 for a total depth of 38 plies.
  
  Now of course in reality moves will end up not commuting, and the children nodes are not always visited in optimal order, but on the other hand we are using all legal moves as branching factor, which is a very pessimistic selection choice .
  
  
  ---
  
  ### Answer by username_10 on 2014-12-16. Score: -1
  
  I am unable to comment so im commenting here. Do you assume the computer starts calculating from the very beginning of the game or from a middle-endgame position? From the very beginning it would be impossible to find a forced mate because if both sides were to play their best lines it would be a draw. Lets say for example that out of the infinite chess mate positions possible it comes up with the fools mate first. If your computer were to calculate to find the first available mate it would find that. The question would be better asked if you have a move min or max to help centralize the math.
  
  Potentially super computer in the future will have unimaginable processing rates and they will progress in their ability until infinity would we conclude then computers could calculate infinite amount of moves in a second? It was good you defined your parameters in the beginning by keeping the processing power limited to today's limits.
  
  As refered to in the first comment the question should be how many positions a comp can generate in a second. To analyse a move and its infinite amount of possible positions would take infinitely long.
  
  I might be rambling on at this point but i just wanted to ask a few questions to help refine your questions.
  
  > **Comments:**
  > **username_10**: The math could be affected by what positions it considers first. It may find the fastest mate 1st or it might not find it until later  
  > **username_11**: Just a couple of observations: (1) "From the very beginning it would be impossible to find a forced mate because if both sides were to play their best lines it would be a draw." We don't know that. (2) "... out of the infinite chess mate positions ..." There are only finitely many chess positions period, as there are only finitely many pieces and finitely many places to put them.  
  
  ---
  
  