Les GPU sont meilleurs pour certains types de calculs, par exemple pour générer des bitcoins et effectuer des simulations climatiques.
Les moteurs d'échecs bénéficieraient-ils s'ils calculaient avec des GPU au lieu de CPU?
Peut-être qu'une personne bien informée peut mettre en évidence les différences entre les deux et nous éclairer sur le fait que les GPU conviennent ou non au type de calculs que les moteurs d'échecs exécutent.
Réponses:
ÉDITER:
Peu d'autres points soulevés dans http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=32317 .
Original :
@ Maxwell86 a déjà fourni d'excellents liens et ressources. Faites attention au moteur d'échecs zeta. C'est un moteur d'échecs GPU. Malheureusement, le GPU n'a pas prouvé son utilité dans la programmation des échecs. En fait, le projet de moteur d'échecs zeta est allé absolument nulle part.
Le GPU fonctionne très bien sur les calculs flottants et les algorithmes qui peuvent être mis en parallèle. Cela nécessite l'indépendance. Mais si nous regardons un arbre min-max (ou alpha-bêta) typique (utilisé par chaque moteur d'échecs)
La branche droite dépend de la branche gauche. En particulier, si nous pouvons obtenir une coupure (échec), nous n'aurions même pas besoin de rechercher les nœuds restants. Malheureusement, ce n'est pas quelque chose qu'un GPU peut faire efficacement. Il est possible d'écrire un programme GPU pour l'alpha-bêta, mais les threads GPU (appelés noyaux) devront être mis en pause pour attendre. Contrairement à un processeur, un chenil GPU ne peut pas simplement passer à autre chose (un processus appelé thread-switch ou même process-switch).
Nos connaissances existantes sur les algorithmes et les moteurs ont été dérivées pour le monde du CPU. L'ensemble de l'algorithme devrait être réexaminé pour le GPU. Malheureusement, il n'y a pas beaucoup d'intérêt et de recherche à ce sujet.
Je n'ai aucune expérience de la programmation GPU, mais, généralement, les GPU sont très efficaces pour exécuter des commandes simples de manière parallèle. Apparemment, ce n'est pas le cas pour l'arborescence de recherche utilisée pour les moteurs d'échecs. Par conséquent, le GPU perd son avantage de calcul par rapport à un processeur.
Bien sûr, c'est l'état actuel de la programmation GPU pour les moteurs d'échecs, mais la programmation GPU est relativement nouvelle, alors peut-être qu'ils trouveront des solutions aux problèmes actuels à l'avenir.
Voici quelques liens intéressants, en particulier le blog sur la mise en œuvre d'un moteur d'échecs pour GPU est assez perspicace.
Le projet LC0 (Leela Chess Zero), une adaptation open source d'AlphaZero pour les échecs, montre les avantages du gpus, des performances en virgule flottante et de la bande passante mémoire utilisée dans les grands réseaux de neurones.
J'ai terminé ma course actuelle sur Zeta v099a, mon moteur d'échecs expérimental gpu.
https://github.com/smatovic/Zeta
La conclusion réelle de l'itération actuelle est qu'un moteur simple, avec des techniques de programmation d'échecs standard, peut être porté sur OpenCL pour fonctionner sur un processeur graphique, mais il faudrait plus d'efforts pour rendre le moteur compétitif en termes de nœuds calculés par seconde ( vitesse), l'heuristique (connaissances expertes) et la mise à l'échelle (algorithme de recherche parallèle).
Computer Chess, en tant que sujet informatique, a évolué au fil des décennies, à partir des années 40 et 50, et a atteint un pic en 1997 avec le match Deep Blue vs Kapsarow. De nos jours, les moteurs d'échecs sont réglés en jouant des milliers et des milliers de jeux, donc obtenir un moteur de jeu d'échecs fonctionnant sur le GPU et obtenir un moteur de jeu d'échecs compétitif fonctionnant sur le GPU sont deux tâches différentes.
J'ai une certaine expérience avec CUDA et la programmation d'échecs (pas la programmation de moteur). Cette question m'est également venue plusieurs fois à l'esprit. Voici mon avis, je n'ai jamais étudié ça.
Eh bien, tout d'abord, il est pratiquement certain qu'avec la conception actuelle des moteurs d'échecs, c'est impossible. Sinon, quelqu'un le ferait simplement.
Que vous puissiez l'utiliser dans un tout nouveau design, c'est une plus grande question. Il n'y a pas de problème avec les opérations entières, mais il est clair que vous devez exécuter du code primitif sans branchement sérieux sur de nombreuses entités.
À mon avis, tous les calculs d'arbre devraient fonctionner sur le processeur.
Mais je peux imaginer (je ne dis pas que c'est possible) des fonctions d'évaluation partielles qui font juste autant d'évaluations sur les positions que possible, pour donner plus de temps au CPU, pour l'aider à construire l'arborescence d'une meilleure façon, disons une de ces fonctions pourrait calculer la gravité du calcul à effectuer pour chaque position.
Vous pouvez calculer le nombre de carrés attaqués, les morceaux attaqués, la puissance de feu autour des rois et dans certaines sous-régions à bord, les choses liées à la structure des pions, vous pourriez probablement créer du code optimisé pour le GPU pour ceux-ci. Vous pouvez probablement obtenir gratuitement de nombreuses informations utiles (pas de temps CPU, pas d'attente CPU), mais vous devrez être un vrai génie pour utiliser toute la puissance des GPU modernes pour de si petites choses.
Ce n'est probablement pas très intéressant de faire pour créer une conception complètement nouvelle des moteurs pour obtenir disons 30% de vitesse supplémentaire. Et pour obtenir, disons, une accélération de 20 fois sur les GPU de pointe, vous devez rendre les fonctions d'évaluation vraiment étrangères.
Et dernière chose sur ce que je vois être un problème. Vous pouvez exécuter un code sur le CPU avec peu de réflexion, mais dans le scénario CPU + GPU, vous devrez faire face à des ratios vraiment différents de CPU et de GPU. vitesses et nombre de carottes. Vous auriez besoin d'un code différent pour un cluster à 16 cœurs avec un GPU faible que sur un processeur lent avec un GPU super rapide pour utiliser toutes les capacités du matériel. Il serait souhaitable de comparer le CPU et le GPU, puis d'exécuter plus de code sur la machine la plus rapide. Mais encore, je pense que vous ne serez pas du tout près de nourrir 3000 bêtes avec seulement des fonctions d'évaluation.
Edit: Juste pour que les choses soient claires, le CPU envoie régulièrement des tableaux GPU de positions pour effectuer des évaluations partielles. Peut-être que ce n'était pas clair d'après ce que j'ai écrit.
Beaucoup de problèmes pour que cela fonctionne.
Je ne vois que des avantages à utiliser un moteur d'échecs basé sur GPU et je ne vois aucun problème sérieux à le faire. Peut-être avez-vous des problèmes à essayer d'utiliser un programme d'échecs standard, je ne sais pas grand-chose des autres. Je commence juste à écrire un programme d'échecs à partir de la première ligne, comme deuxième programme basé sur CUDA après avoir fait quelques premiers tests de programmation sur CUDA sans sens spécifique. Bientôt, je pourrai faire quelques premiers tests de performances et tester des jeux contre d'autres moteurs. Peut-être la semaine prochaine. Je commence juste à le créer mais je suis déjà proche de le terminer et la plupart des fonctions sont déjà terminées.