Echecs : Les tables de finales - Echecs et informatique sur PC-Windows

Echecs : les tables de finales

Voici un point assez délicat - et souvent négligé par les joueurs d'échecs pourtant habitués aux joutes contre des adversaires informatiques : les programmes d'échecs ont une certaine difficulté à faire face aux fins de parties. Le phénomène est bien connu : les moteurs s'affaiblissent en finale, en partie à cause de l'effet "horizon". Pour simplifier, en caricaturant, les moteurs ne voient pas au delà de leur profondeur d'analyse maximale et peuvent ignorer un petit pion ordinaire qui va passer et se transformer en une redoutable dame.
Enfin, ça c'était surtout le cas il y a 20 ans. Le problème est beaucoup moins sérieux aujourd'hui mais cette perte d'efficacité en finale existe toujours, surtout pour les moteurs tactiques.

Certains moteurs recourent à des algorithmes spécifiques, qui explorent les branches de l'arbre à grande profondeur, en tache de fond, afin de limiter l'effet horizon. Ce choix à une conséquence : il consomme de 15 à 20% du temps de réflexion - et donc ralenti sensiblement le moteur.  Les plus récents intègrent la "connaissance" des configurations de finales les plus courantes. Il n'en reste pas moins que sans ces bases de finales même les meilleurs moteurs verront leurs performances baisser en fin de partie. C'est sans doute pourquoi les plus forts d'aujourd'hui continuent à s'appuyer sur ces fameuses tables.

A quoi ça sert ?

Le role des tables de finales est de rassembler l'ensemble des configurations possibles lorsqu'il ne reste plus que 3 à 6 pièces sur l'échiquier.  Elles existent depuis longtemps et pourtant elles ne sont pas très populaires. Elle présentent en effet plusieurs inconvénients qui ont freiné leur diffusion - du moins dans le grand public:
1/ La taille des fichiers (7 Go pour les tables à 5 pièces Nalimov compressée)
2/ La nécessité d'accéder sans cesse au disque dur pour lire les données
3/ L'obligation pour le moteur de décompresser les fichiers à la volée.

Ces deux derniers processus occassionnent un ralentissement qui peut-être tel que, en pratique, la force du moteur baisse au lieu d'augmenter.
Ces inconvénients existent toujours mais ont moins d'influence aujourd'hui. Les ordinateurs sont plus puissants, les disques durs de grande capacité sont monnaie courante et ils sont beaucoup plus rapides ; les meilleurs étant en la matière les disques durs SSD, de 4 à 8 fois plus rapides que les disques mécaniques.
Enfin, les moteurs sont beaucoup plus performants et incorporent généralement des "connaissances" qui leur permettent de limiter l'accès aux EGTB. Ce qui suppose cependant de connaitre certains réglages pour optimer leur utilisation.

Pour finir, il ne faut pas oublier qu'elles seront une aide précieuse lorsqu'on utilise un moteur pour l'analyse d'une partie. Ou lorsque on étudie simplement les fins de parties. Dans le premier cas, le facteur "temps de traitement" n'est plus aussi déterminant ; dans le second, il devient négligeable.


Arena et Scid vs PC en première ligne

En matière d'interface de jeu, j'utilise principalement Lucas Chess et Arena. Mais Scid vs PC, gestionnaire de bases de données, est aussi une bonne interface.  
    
Lucas Chess, très moderne, très ludique, exceptionnel outil d'études doté d'une module d'analyse de parties extra… a carrément fait l'impasse sur les bases de finales ! La dernière version contient 50 moteurs et n'offre en guise de database de fin de parties que les fichiers à 3 pièces au format Syzygy; le plus moderne mais le moins courant et dont ne se servent que les versions récentes de quelques moteurs ultra-puissants. Surtout,rien, depuis l'interface, n'est prévu pour valoriser le contenu de ces databases, pas plus les Syzygy que les autres.

Arena, plus ancien, plus austère que Lucas Chess, reste incontournable car il offre des possibilités ignorée de Lucas Chess ou d'autres interfaces. En matière de gestion des bases de fin de parties, tout a bien été prévu. Cette interface sera donc naturellement le support de notre expérimentation de ces fameuses endgame database.

Pour l'étude des finales, il ne faudra pas faire l'impasse sur Scid versus PC, Le gestionnaire de bases de parties est également une interface d'échecs assez polyvalente, qui sait utiliser les tables Nalimov, les plus courantes. Dans les phases finales d'une partie il présente les données des tables de façon originale et utile.

Les différents formats de bases de données de finales

Comme toujours, pour compliquer les choses, il y a 5 ou 6 formats de database de fin de parties et les moteurs utilisent les uns et pas les autres. Trois sont tout de même plus courants : le formats Nalimov, le format Gaviota - et le format Syzygy.

Le format Nalimov est assez ancien et à l'inconvénient de générer de gros fichiers, difficiles à stocker et manipuler. Mais beaucoup de moteurs l'utilisent encore, à commencer par les moteurs Winboard (du moins ceux qui sont capables d'exploiter de telles bases). Parmi les moteurs UCI, nombreux sont ceux qui utilisent encore les bases Nalimov ; y compris de très forts moteurs comme Fritz, Junior, Hiarcs, Nimzo, Chess tiger, Shredder, Patzer, Crafty…

Le format Gaviota peut être considéré comme une évolution du format Nalimov, dont il est  proche. Il se différencie essentiellement par un encombrement inférieur de 10%. Son handicap est qu'il est moins standard que le Nalimov.

Le format Syzygy est beaucoup plus récent. Il n'est pas considéré comme vraiment meilleur, en terme d'efficacité (les avis sont partagés, preuve que la distance est faible), mais il a l'énorme avantage sur Nalimov de prendre 7 fois moins de place. Ce qui laisse envisager la possibilité d'utiliser une base à 7 pièces, laquelle ne prendra "que" 150 Go au format Syzygy contre plus de 1000 Go pour les vieux formats. Syzygy reste marginal quantitativement mais quelques uns des plus importants moteurs d'aujourd'hui s'y sont convertis : Deep Fritz depuis la version 14, et le tiercé gagnant des moteurs du jour : Stockfish depuis la version 7. Komodo à compter la v8 et Houdini à partir de la v4.

Avec Arena

Arena propose en standard dans son dossier "TB" les finales à trois pièces des databases Gaviota. Il est judicieux d'y ajouter au moins les fichiers à 4 pièces. Et à 5 pièces si c'est possible. Le problème est qu'elles ne sont pas facile à trouver.
La croissance du volume des données de ces tables est géométrique. Les tables à 5 pièces Gaviota ou Nalimov pèsent déjà 7 Go compressées ! Quant aux fichier à 7 pièces, c'est 1000 Go. Donc n'en parlons plus !

Si vous avez de la place sur votre disque et un peu de temps à perdre, vous pouvez compléter la TB Gaviota d'Arena. Vous trouverez ici les fichiers à 4 et 5 pièces :
https://chess.cygnitec.com/tablebases/gaviota/
Arena a déjà dans le répertoire "TB"\Gtb.cp4" les dossiers rêts à accueillir les fichiers Gaviota : "gtb4" et "gtb5".
Le fichier à 4 pièces est une unique archive appelée "4.7z". Téléchargez-là, ouvrez l'archive, elle contient un dossier "4". Videz-le dans le répertoire "gtb4" d'Arena.

La base à 5 pièces, beaucoup plus grosse, est scindée en 53 parties au format de 7zip. Ca va prendre du temps ! La décompression est aussi plus compliquée. Il faut coller tous les morceaux dans un dossier, y compris le fichier "md5sum" (qui sert à vérifier que des fichiers ne sont pas altérés). Ensuite venir sur le fichier "5.7z.001" et le décompresser avec 7-zip. Il va alors vous sortir automatiquement de l'archive tous les autres fichiers. Si vous n'avez pas cet archiveur, vous devrez le télécharger et l'installer. Vous le trouverez ici : https://7zip.fr/ Par chance c'est un gratuit.
Ensuite copiez tous les fichiers décompressés dans le dossier "gtb5" d'Arena.

Notez qu'on trouve également les fichiers à 4 pièces à cette adresse : https://github.com/michiguel/Gaviota-Tablebases/tree/master/gtb

En cas de problème d'indisponibilité ou de disparition, voici une source alternative
de téléchargement pour les fichiers à 4 et 5 pièces :
https://tablebase.lichess.ovh/tables/standard/Gaviota/


Finales Nalimov

C'est le format le plus courant, utilisé par de nombreux moteurs et en particulier par une majorité de moteurs Winboard. Il y a donc un intérêt à installer aussi les TB Nalimov sur votre ordinateur.
Vous trouverez les bases à 3 et 4 pièces Nalimov ici :
http://horizonchess.com/FAQ/Winboard/egtb.html#%5BA.7%5D
Cherchez sur la page "Alternatively, Frank Quisinsky offers all the 3 and 4 men tablebase for download in one 30 meg file." Presque tous les autres liens sont morts.
Si vous voulez les 5 pièces, vous les trouverez ici :
http://tablebase.sesse.net/3-4-5/
C'est galère ! 7 Go de données répartis en près de 300 fichiers, à télécharger un par un ! On en bave, quand même !
Une fois que vous les aurez, créez un répertoire "Nalimov" dans le dossier "TB" d'Arena et copiez-y vos fichiers.

Comment les moteurs utilisent-ils les databases de finales ?

Par défaut, Arena conduit les moteurs UCI vers le dossier "TB". Si vous voulez le vérifier :
menu "Modules" > "Gérer", onglet "Détails", puis onglet  "UCI". Assurez-vous que "Chemin des tablebases communes (Nalimov)" est coché et que le chemin vers le dossier "TB" est bon.
Notez que vous pouvez d'ici imposer à tous vos moteurs UCI le nombre de coeurs physiques que votre ordinateur pourra utiliser. Il suffit de cocher aussi "Configuration du nombre max. de coeur CPU en commun" et d'indiquer le nombre de coeurs.

Remarques :
Si vous avez installé les tables Gaviota et les tables Nalimov, vous n'avez pas à choisir entre les deux. L'adresse du répertoire "TB" suffit.  
Vous pouvez cocher aussi "Cache des tablebases communes (Nalimov)" et choisir une valeur - par exemple 64 mo. Mais dans ce cas, cette valeur sera commune à tous les moteurs utilisant les EGTB Nalimov. Or, vous pourriez avoir ponctuellement besoin de valeurs différentes, en fonction du moteur ou de l'usage que vous souhaitez en faire.



Pour les moteurs Winboard, le principe est le même. Ouvrez l'onglet "Winboard" : il y a trois chemins par défaut : vers Gaviota, vers Scorpio et vers Nalinov. Là, par contre, vous devez être très précis dans l'adressage.



L'ensemble de ces paramètres sont communs à tous les moteurs d'Arena. Autrement dit, si vous avez copié vos fichiers dans les bons répertoires et si tout est bien coché et renseigné, vous n'avez en principe pas à y revenir chaque fois que vous installez un nouveau moteur. Celui-ci devrait être capable d'aller chercher de lui-même ce dont il a besoin.
Cependant ces réglages ne sont valables que pour ceux qui utilisent les tables Nalimov ou Gaviota.

Ce n'est pas encore tout à fait fini. Pour tous les moteurs n'utilisant pas de tables de finales, vous devez indiquer à Arena s'il doit lancer la consultation de ses tables Gaviota : menu "Options" > "Configuration tablebases". Cochez la case  "Utilise tablebases des finales" et assurez-vous que le nombre de pièces que vous avez installé est bien reconnue par Arena, comme sur l'illustration ci-dessous.

Vous devrez aussi indiquer ici à Arena le chemin vers les répertoires à 3, 4 et 5 pièces.

Remarque : ne perdez pas de vu que le processus de consultation des tables consomme des ressources-machine, surtout les fichiers à 5 pièces. Vous devez donc vous demander si les tables ne devraient pas être désactivées par défaut. Ou, alternative, si Arena ne pourrait pas se contenter de consulter les tables à trois pièces - ou à trois et quatre pièces...


Les databases Syzygy

Plus récemment un nouveau format de tablebases est apparu, le format Syzygy. Principal avantage: les tables occupent 7 fois moins d'espace, soit environ 1 Go pour les fichiers de 3 à 5 pièces. Elles sont particulièrement recommandées pour le moteur Houdini, dont la version 4 a été spécialement optimisée pour elles. Autres moteurs célèbres les utilisant : Rybka, Fritz, Deep Fritz, Junior.
Les bases Syzygy se composent de deux ensembles de fichiers, les fichiers WDL stockant les informations de gain et pertes en fonction des positions, afin de déterminer lesquelles sont gagnantes.  Et les fichiers DTZ avec des informations de distance à zéro indiquant au moteur comment terminer la phase finale.   


Téléchargement

Les tables Syzygy sont sous licence libre, donc librement téléchargeables. Le plus pratique est de télécharger les fichiers Syzygy pour 3, 4 et 5 pièces sur le OneDrive de l'excellent site  chess.massimilianogoi.com/. Ils sont rassemblés dans une unique archive de près d'un Go.

Sur le même site on peut télécharger les fichiers Syzygy à 6 pièces. Ici vous obtenez deux fichiers torrent, l'un pour les fichiers dtz et l'autre pour les wdl. Pour les utiliser vous devez avoir un client BitTorrent. Je vous conseille µTorrent, facile à utiliser et gratuit. Rappel : ça pèse lourd : 150 Go !

Alternative pour les 3,4,5 pièces: https://tablebase.lichess.ovh/tables/standard/3-4-5/
Pour les six pièces :
https://tablebase.lichess.ovh/tables/standard/6-dtz/
https://tablebase.lichess.ovh/tables/standard/6-wdl/

Ou encore :

Pour les 3,4 et 5 pièces :
http://tablebase.sesse.net/syzygy/3-4-5/

Pour les six pièces :
http://tablebase.sesse.net/syzygy/6-DTZ/
http://tablebase.sesse.net/syzygy/6-WDL/

On trouve même ici les fichiers à 7 pièces :
http://tablebase.sesse.net/syzygy/7-DTZ/
http://tablebase.sesse.net/syzygy/7-WDL/
Mais alors là bon courage ! Des centaines de fichiers et plus de 16 térabits de données, vous n'avez pas encore fini !

Comment forcer les moteurs à utiliser Syzygy ?

Arena n'a intégré dans son fonctionnement que l'usage des tables Gaviota, Nalimov et Scorpio.  Pour les moteurs utilisant  les tables Syzygy, rien n'est prévu. Mais ils ont toujours un module de configuration - ou à défaut un fichier d'initialisation - à modifier pour indiquer au moteur le chemin vers les tables. Voyons ça sur un exemple, avec une version récente de Stockfish :
1/ D'abord faire de Stockfish le moteur 1 d'Arena (Menu "Modules", "Gérer" et choisissez Stockfish).
2/ Ensuite menu "Modules", "module1" et "configurer", pour ouvrir le menu de configuration. Dans le champ "Syzygy path", allez chercher le chemin de la base Syzygy.

Visionner le travail des tables de finales

Si Arena est configuré pour utiliser les tables de finales, il pourra afficher le résultat des consulations dès qu'il n'y aura plus que trois, quatre ou cinq pièce sur l'échiquier de la partie en cours. Deux cas peuvent de présenter :

Le moteur en fonctionnement n'accède à aucune table de finales : dans ce cas, Arena consulte lui-même les tables Gaviota. Vous pouvez bien sûr afficher le résultat des consultations sur l'interface : sous les boutons de déplacement vous avez quatre discrets petits onglets qui ont pour nom "Liste de coups", "Biblio./Tb", "Mix 1" et "Temp". Si vous sélectionnez "Biblio./Tb" puis "Mix 1" l'espace se partagera entre la liste des coups à gauche et les données des tables à droite, comme sur l'exemple ci-dessous.

Ici AnMon joue contre lui-même une partie où il ne reste que cinq pièces sur l'échiquier. Dans cette position, les tables de finales indiquent que si au prochain coup la tour noire prend la tour blanche c6, les noirs peuvent encore faire partie nulle. Tous les autres coups prédisent la défaite des noirs en un nombre de coups variables.


J'ai mis un certain temps à déterminer si Arena pouvait indiquer au moteur le meilleur coup résultant de son exploration. Très souvent en effet, les coups du moteur et les résultats des tables étaient identiques. Mais la réponse est non. L'interface ne pourra donc pas suppléer à une déficience du moteur en la matière.

Le moteur accède lui-même à des tables de finales : dans ce cas, c'est le retour de la consultation du moteur que vous pourrez observer, de la façon que vu ci-dessus, même si ce moteur utilise les tables Syzygy. Il aurait été dommage et techniquement peu efficace qu'il y ait une double consultation ! Arena fait ici la démonstration de l'excellente intégration des tables de finales dans son fonctionnement global.


Avec Scid

L'intégration des tables de finales dans l'interface Scid est moins poussée que dans Arena. Le gestionnaires de bases de parties s'appuie sur les tables Nalimov et ne pourra pas en exploiter d'autres - même par moteur interposé.
Comme pour Arena, la fenêtre "tables de finales" de Scid commence  à afficher des données dès que le nombre de pièces limite est atteint (3, 4 ou 5 pièces restantes). Si une partie est en cours, la fenêtre s'actualise à chaque nouveau 1/2 coup. Mais le moteur en fonctionnement peut bien utiliser les tables Syzygy, ce sont toujours les résultats des requêtes de Scid dans les tables Nalimov qui s'afficheront.  


Pour les blancs, si la partie est parfaitement menée jusqu'à la fin, les perspectives de victoire sont fortes (21 coups y mènent) et les risques de perte nuls, dans cette situation.


L'interface sera donc plus adaptée à l'étude post-mortem des parties. La présentation des données de consultation est claire et agréable : dans la section "résultats" de la fenêtre dédiée sont indiquées d'abord les perspectives de gain (Won), de perte (Loss) ou de nul (Draw) pour la couleur au trait. Viennent ensuite dans l'ordre : les coups gagnants, s'il y en a, les coups menant à la nullité, s'il y en a,  et enfin les coups perdants.
Autre petit plus par rapport à Arena : la présentation de données statistiques tirées d'une grosse base de données dont Scid dispose. Ce sont toutefois des données très générales, sans lien directe avec la finale en cours. Pour en savoir plus, voir : Scid - Tables de finales

Et pour Lucas Chess ?

Lucas Chess ne propose aucun moyen de consultation des résultats des tables de fin de parties. Pire : sur les 51 moteurs qu'il met en batterie, beaucoup sont capables d'utiliser un format de table ou un autre, mais rien ne permet de leur indiquer où sont vos tables, si vous en disposez. L'interface, comme vous le savez peut-être, ne propose aucun accès à un éventuel fichier de configuration pour les moteurs internes. Seuls les moteurs utilisant les tables Syzygy pourront lire les fichiers à trois pièces, présents dans la distribution de Lucas Chess.

En revanche, tout moteur "externe", que vous auriez installé vous-même dans Lucas Chess, pourra être éventuellement paramétré depuis son propre menu de configuration (ou par modification d'un fichier d'initialisation), s'il est disponible. Pour  les 23 moteurs que j'ai sélectionné pour vous, ce sera le cas pour : Leela Chess Zero, Komodo, Stockfish, Smarthink (utilisent les tables Syzygy), Fruit, AnMon et Mustang (utilisent les tables Nalimov) et Houdini 1.5a (tables Gaviota).

Remarque : Komodo et Stockfish sont des moteurs internes d'Arena. Si vous voulez accéder à leur module de configuration, il faut les réinstaller comme moteurs externes. Cela étant dit, si vous les utilisez pour jouer, ce sont des moteurs si forts que même sans recours aux tables de fins de partie, ils resteront plus forts que vous. Par contre, lorsqu'ils sont utilisés comme moteurs de conseil ou d'analyse, l'accès aux tables est plus utile.

Deux moteurs utilisent leurs propres (petites) tables externes : Chessterfield et Chenard. Rybka et Rhetoric utilisent les tables Nalimov mais je n'ai trouvé aucune solution pour eux, leur menu de configuration ne permettant pas d'établir un lien vers un dossier contenant les TB.
A priori, mes autres moteurs n'utilisent pas de tables de finales externes.

Réglage pour limiter l'accès aux EGTB

Les moteurs les plus modernes et les plus puissants, tels que Stockfish, Komodo ou Houdini, sont déjà très performants, sans accès aux tables de finales. Il est même probable que s'ils y accédaient sans restriction, ils perdraient de la force au lieu d'en gagner, surtout avec les EGTB stockées sur un disque dur mécanique. C'est pourquoi ces moteurs puissants proposent un paramètre de type "Probe Depth", qui va déterminer la profondeur de recherche la plus basse à partir de laquelle le moteur accèdera aux tables de finales, plutôt que de se contenter de son évaluation interne. Par exemple "Hard_Pro_Depth" (Houdini), SyzygyProbeDepth (Stockfish, Komodo)...
Le principe : plus votre disque dur est lent, moins votre processeur est puissant et moins vous avez de coeurs, plus vous avez intérêt à augmenter cette valeur.

Comme pour l'évaluation interne avec les tables de hachage, les données déjà obtenues par les accès EGTB peuvent être stockées dans une mémoire cache spécifique, dont la taille peut varier. Cette table porte un nom comme "NalimovCache" (Fruit, AnMon), GaviotaTBCache (anciennes versions d'Houdini) TBCacheSize (Mustang)...
Si vous avez 4 Go de mémoire porter cette valeur à 64 Mo me parait judicieux. Si vous ne manquez pas de mémoire, 128 Mo sera bien sûr encore mieux.

Rob Rob, mai 2019