Endgame Tablebases by Eugene Nalimov.
No longer downloadable here due to web space restrictions.
With permission by Eugene Nalimov (USA) & Andrew Kadatch (USA).
For an engine, endgame is tough. More so than for a human, because an engine is hard to teach how to form long-term plans. Tablebases are a useful asset for simplifying the engine's job. What are tablebases? They are tables including precise solutions for certain endings. If, during the search, an engine reaches a position for which the endgame tablebase is present, it can stop the search, because the tablebase will tell it the exact evaluation of the position. This evaluation is as if you, for example, would tell the engine: "In this position white can checkmate black in 12 moves, even if black defends in the best possible way." Or: "The position is draw, with best play of both opponents."
There have been several methods translating endgame positions into tablebases. The most state-of-the-art method has been invented by Eugene Nalimov. Modern engines almost exclusively use tablebases of the Nalimov type. It must be noted that endgame tablebases (often referred to as EGTBs) are not a wonder weapon. This is because the size of EGTBs increases rapidly with the numper of pieces on the board. Even endgames with only 4 pieces (including kings) occupy 30 MB space, and 5-men EGTBs require more than 7 gigabytes. Generating 6-men EGTBs required several month's time even on most up-to-date computers. And you need about 1.2 TB disk space. They are downloadable on Tablebases Online and on tablebases.sesse.net. Creating the first 7-men tablebases is currently ongoing process. Since endgames often include more pieces than that, you can imagine that the use of EGTBs is rather limited.
Because of the size of EGTBs, it is common practice to use only subsets of, say, 5-men tablebases. You can install e.g. only EGTBs including rooks, since these are the most important ones. However, this can create problems for certain engines. Why? Consider that the engine has reached a position with 2 kings, one rook for each side, and a pawn. You expect that it is about to promote that pawn into queen. But it doesn't. Why? EGTBs tell him that the position is mate in, say, 14 moves. But after queening that pawn, he does not find the corresponding EGTB. Its limited-depth search returns a value of 10 or so (it can't see tha mate yet), which is worse than mate. So it decides it will be better not to promote the pawn. It makes useless moves with its rook and king, and the game is drawn by the 50-move or repetition rule. Some engines can overcome this problem, some can't. You should always check what the case is (for example, by setting up an appropriate position and see if the engine can promote the pawn). If your engine can't work properly with incomplete tablebases, you'd better set it to use only EGTBs with smaller number of pieces. Also, note that for an engine to use EGTBs, additional operative RAM space is required, in which it processes the EGTBs. Additional RAM may be reserved for storing parts of the EGTBs in use (this will increase search speed, because fewer disk accesses are required).