|
| Interfaces d'échecs par Ro***85***12614 le
[Aller à la fin] |
| Informatique | |
Bonjour à tous. Celà fait plusieurs années que je m'intéresse aux logiciels d'échecs, et je constate qu'il y a de plus en plus d'interfaces différentes
(Fritz, Chessbase, Arena, Shredder Classic, Aquarium, etc.).
Celles-ci proposent toutes des fonctions plus ou moins avancées en fonction de ce que recherche l'utilisateur. Par exemple, certaines d'entre elles seront mieux adaptées au tri de parties, d'autres seront plutôt destinées aux tests entre modules, etc.
En revanche, je n'ai vu aucun site évoquant l'influence de celles-ci sur la force de jeux des moteurs d'échecs. Selon vous, un même logiciel peut-il jouer plus ou moins bien en fonction de l'interface utilisée.
Veuillez noter que je parle de la force globale d'un module d'échecs sur une interface donnée, ce qui exclut les éventuels bugs constatés ici et là dans certaines situations particulières. Merci d'avance pour vos réponses.
|
|
|
Non.
|
|
|
Réponse concise mais exacte de Reyes.
J'ai fait des essais sur la question, il y a pas mal de temps. Tout ce que l'on peut en conclure est que la force de jeu n'est pas influencée par la GUI bien que le comportement puisse l'être à cause des échanges entre le module et l'interface. Mais cela relève de la section "bugs".
|
|
|
l'interface graphique est l'élément qui consomme un peu de mémoire pour le logiciel d'echecs ...
mais aujourd'hui avec les cartes video prévues pour des jeux videos, et des ram qui se comptent en Giga , on peut considerer que la quasi totalité des ressources disponibles du PC est utilisées pour le processeur qui calcule les coups selon le moteur d'echecs lui même ....
Plus que l'interface graphique, un " moteur " d'echecs risque d'etre sensible d'un part à la puissance de calcul du processeur intel multicore , et d'autre part à la ram disponible .
Bien sur les réglages effectués dans l'interface graphique par defaut , peuvent dans certain cas laisser croire qu'un moteur donné joue mal dans une interface et bien dans une autres, il convient bien sur que tous les reglages , comme le nombre de processeur core utilisé, comme les hash tables disponibles, comme l'utilsation ou pas des livres d'ouvertures, ou de tables de finales , soient reglées exactememnt de la meme maniere dans toutes les interfaces.
|
|
|
Bonjour,
En quoi le processeur se doit-il d'être un "Intel multicore" ? L'expression dans son contexte semble tout droit sortie d'une présentation markéting de la firme de Santa Clara. D'une part, car les mono-coeur existent encore, et d'autre part, car on pourrait évidemment avoir de l'AMD, entre autres. Sans parler des CPU de type ARM, qui commencent tout doucement à percer aux cotés des CPU x86 dit "classiques".
Un moteur -est- sensible à la puissance du CPU. C'est même l'élément limitant, et de loin, dans la majorité des cas. Dire qu'il risque seulement de l'être est donc un euphémisme qui peut-être trompeur. Quant à la RAM, un manque de cette dernière est généralement pénalisant. Un excès, par contre, n'aura plus d'influence sur les performances "normales".
Pour plus de précision, on dira que le moteur est non seulement sensible à la puissance du CPU, mais aussi et surtout au temps qui lui est alloué pour tourner sur ce dernier. C'est sur ce point que les multiples interfaces peuvent se différencier. Sans trop rentrer dans les détails, il s'agit d'une histoire de priorité des processus. C'est pourquoi une interface destinée aux tests entre modules, en plus d'avoir certaines options spécifiques, prendra soin de distribuer équitablement les ressources de la machine entre les processus des différents moteurs.
D'autre part, interviennent bien sûr tous les facteurs (ou réglages) cités par thierrycatalan en fin de message.
Enfin, juste un mot sur le "pondering": action de laisser le moteur "penser" pendant le coup de l'adversaire. Ce réglage peut avoir une influence non négligeable sur une partie entre deux moteurs, voire une partie homme-machine.
|
|
|
