user3237: 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.  

user18777: 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 .

user15223: 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 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, 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 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.

user1761: To answer the question in the title: In chess programming, 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 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: 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.

3237: <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>
 18777: <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>
 15223: <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>
 1761: <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>
