|
| Hash Tables, Houdini 2.0 et Ivanhoe 999947 par Re***ar*12579 le
[Aller à la fin] |
| Informatique | |
Bonjour
Dans Fritz quand on lance un module, on peut voir la taille des hash tables en % de ce qui leur est alloué. Ce qui n'est pas le cas dans ChessBase.
Une solution à la vitesse de calcul des processeurs, ce serait d'éviter que le module recalcule des positions. Les Hash-Tables servent à cela.
Avec un module courant, on avance d'un coup, et on peut constater que les hash tables sont réinitialisées.
Aquarium propose une solution à cela, on a la possibilité d'enregistrer les HT sur le disque dur, et il y a aussi cette possibilité dans Rybka.
Je trouve qu'au niveau manipulation c'est un peu lourd, surtout si on analyse plein de position, à chaque fois enregistrer un fichier.
J'ai regardé les spécifications d'Houdini 2.0, il a une fonction qui permet de retenir les HT.
En fait cette fonction existe aussi dans Ivanhoe, il y a certaines options UCI à cocher, et dans Fritz quand on avance d'un coup, la taille des HT continue à croitre, et se stabilise autour de 87%.
Parfois quand on joue une variante de quelques coups, et que l'on reviens à la racine, très rapidement on est a une profondeur de 21, voir plus si on avait laissé le module calucler longtemps sur cette position.
J'ai un core i36 avec 4G de ram, et je fais tourner Ivanhoe sur 2 processeur en allouant 2048 Mo aux HT, cela va assez vite, en 5mn 75% de la mémoire des Hash Tables est consommée.
Donc je me demandais si en allouant 4gigas au Hash Tables, j'aurais un gain de temps, le truc c'est qu'une fois que la mémoire des HT est pleine, le module recalcule des positions, et là on perd du temps.
Etant donné l'investissement non négligeable en barrette de mémoire, à votre avis est-ce que ça vaut le coup ???
|
|
|
Je suis surpris de voir un i36 avec 4 Go de RAM
Le mien est en triple channel, mais peut-être que c'est une question de carte mère, et la RAM doit donc être un multiple de 3, par exemple 6 Go
|
|
|
Une faute de frappe, un core i3, pour info mon PC est un Toshiba Satellite.
Core i3 = 3 processeurs physiques et 4 flux de données.
Il n'y a pas de rapport entre le nombre de processeurs et la ram de l'ordinateur.
Concrètement ce qui nous intéresse c'est le nombre de processeurs physiques, pas les flux.
Donc avec un core i3 on peut faire travailler un module en bi processing ou 2 modules en mono processing. Si on utilise un troisième module en mono, on constate qu'il empiète légèrement sur les performances de deux autres modules. Dans Fritz 13, l'usage intelligent des processeurs, limite à 2 processeurs pour un core i3. ; n = nombre de processeurs physique - 1.
Je viens de chronométrer exactement le temps mit pour atteindre 90% de la mémoire allouée aux Hash Tables (2048Mo), 2mn30 en bi-processing et on atteins une profondeur de 22-23.
Si on essaie de rentabiliser le temps d'usage des processeurs, formellement pour une analyse complète dans Fritz, pas besoin de laisser le module calculer plus de 2mn30 (avec les paramètres indiqués).
|
|
|
Bonjour Redbear, le calcul des hashtables ne semble pas simple. Quelques utilitaires trainent sur la toile mais ceux-ci sont trop simplistes et ne prennent pas en compte la puissance nominale de la machine. Un calcul effectué sur la fréquence seule est... dérisoire. J'utilise tout simplement les temps de réactivité de ma machine en consultant les Ko/neuds/s produits par le module. Dans la mesure où il y a un ralentissement dans le calcul cela semble indiquer un temps de balayage des hashtables qui peut avoir des conséquences drastiques sur les performances. D'où, en conséquence, le rapport temps/performance optimal à trouver... oui mais comment ? telle est la question... Pour l'analyse je règle les hashtables juste avant le ralentissement et, en effet, les temps de calculs tactique ne sont pas affectés tout en bénéficiant d'une meilleur qualité de jeu apportée par les quelques kilos de base de hashtables obtenus.
|
|
|
Salut Midi
Disons que tout dépend comment on utilise le module.
a) en lançant une analyse complète dans Fritz
b) en analysant manuellement, c'est à dire en allant d'avant en arrière dans la partie en laissant calculer le module
Concernant le cas a) actuellement je procède ainsi, la question étant bien le rapport temps / performance optimal à trouver...
Je rêgle le seuil à 0.30 (valeur par defaut) voir 0.20; j'alloue 2048 Mo de Hash Tables, je règle mon module en mono-processing, comme cela je peux utiliser mon ordinateur pendant l'analyse, de toute façon le bi-processing ne multiplie pas par 2 les performances, et je donne 150 secondes de reflexion par coup.
Fritz ne reste pas 150 secondes pil poil sur un coup, parfois plus, parfois moins, le programme "semble intelligent" et comprendre qu'il faut faire calculer le module plus longtemps sur certaines positions. Avec ces valeurs 60 à 80% des 2048 Mo sont consommées pour les Hash Tables.
Pourquoi 150 secondes, j'ai fais des ensembles de test, et sur ma machine, il n'y a aucun programme qui trouve le bon coup après 150 secondes de calcul, soit le programme trouve avant, soit il ne trouve pas. Et très très rarement après 120 secondes.
L'autre option serait d'allouer 1024 Mo au HT, mais alors je devrais réduire le temps de calcul pour éviter de saturer la mémoire.
Sur les ensemble de test, mettons que l'on a 80% de réussite à 150 secondes et 2048 de hash, on aura 75% de réussite à 75 secondes et 1024 de hash.
Sinon l'interprétation de tests que j'ai fais (http://www.volny.cz/evcomp/elotesty.htm) c'est que pour 1 position il est inutile d'allouer plus de 2048Mo de Hash, puisque quand le module aura consommé toute cette mémoire, il aura soit trouvé la solution du test, soit il ne l'aura pas trouvé, mais de toute façon il ne la trouvera pas si on le laisse calculer plus longtemps et consommer plus de Hash, il est passé à coté de la solution et l'a écarté, et à ce moment il est en train de calculer en profondeur.
Mas je suis quasi sur que l'on pourrait appliquer ce raisonnement pour 1024 Mo de Hash, il faut être réaliste, on est loin de jouer les parties de Fischer ou Kasparov, et si il y a un coup impossible à trouver dans une de nos parties, la cause en sera le hasard, pas le talent, donc est-ce grave si on passe à coté ?
|
|
|
Sur les machines que j'utilise, qui ne sont volontairement pas très puissantes afin de pouvoir utiliser les modules d'un niveau de joueur de club moyen, les hashtables ne sont pas très utiles. Elles le deviennent en analyse automatique en partant du dernier coup vers le premier. Effectivement en ce cas on exploite pleinement la capacité des hastables à mémoriser des variantes qui ne seront pas recalculées par la suite. Si j'ai bien compris, les hashtables semblent utiles pour faire grimper le ELO des modules dans les matchs entre modules...
|
|
|
