* 22.9 More eval tuning producing another +10 Elo gain. Curmv[n] was *
* "overloaded" in that it was used to obtain the next move for a *
* parallel thread and was also used to pass back a "fail high" move *
* to store in a "LOWER" hash table entry. This led to some error *
* messages internal to Crafty that could possibly cause problems. *
* There is now a second variable "cutmove" used to pass the move *
* back to eliminate race conditions. Hash.c modified extensively *
* to improve readability as well as to eliminate duplicated code. *
* Internal iterative deepening code removed. No measurable benefit *
* in real game testing led to removal since it is simpler without *
* the code. EvaluateMaterialDynamic() also removed. This was code *
* that implemented ideas suggested by IM Larry Kaufman, but careful *
* testing showed absolutely no effect on game results. Again, we *
* chose "simpler is better" and removed it, as no tuning attempts *
* helped for this code. Nasty pawn hashing bug fix, something that *
* has been around for years. This was essentially the same sort of *
* bug that the "lockless hashing algorithm" addressed for the main *
* hash table, where out-of-order memory writes could produce a hash *
* signature and the 64 bit word with score and best move which did *
* not "go together". The same thing happens in pawn hashing, *
* except that an entry is 32 bytes rather than 16, giving even *
* higher probability of an entry that contains mismatched pieces. *
* In the best case, we just got a bad score. In the worst case, *
* this could cause a program crash since some of the data might be *
* invalid, yet it can be used in ways that produce impossible array *
* subscripts that would cause (very rarely) a segmentation fault. *
* The solution was to do the same lockless hashing algorithm where *
* the key is XORed with the other three 64 bit words when the entry *
* is stored, then XORed with them again when we try to match. If *
* the entry is mismatched, the signature will not match anything *
* and we simply will not use the bad data and do a normal pawn *
* evaluation to compute valid values. *
* *
Is anyone else seeing something like the problem below with 22.9 ?
I compiled it with -DSKILL so I can set the skill to some low integer (so I can win sometimes).
With 22.8, everything compiles fine and works well. Time controls are obeyed for a fast game, etc.
With 22.9, things seem to compile fine. However when I start a game with skill=10, the first move out of book causes crafty to think forever without moving.
I've learned a bit more about this. It appears to be an issue with the new Crafty and eboard. Xboard and Crafty 22.9 with skill level set works just fine as does command line Crafty 22.9.
Denis P. Mendoza wrote:I've added all-purpose (epd-skill-hashstats on) compiles - for old pc/OS.
A couple of notes. The pawn hash bug was serious. I actually first saw it when making some test runs on a dual I7 box and saw a couple of crashes, but they were _impossible_ to reproduce. The Intel IDB debugger installed was not much help either, in that when this segfault happened, it would say "normal exit" and I could not see anything since it said "no program running..."
Finally saw a game on ICC on the normal 8-core box I use all the time that kept logging off and on. Turns out a position was triggering this bug and it was reproducible after a fashion and I tracked it down.
There are a few other speed tweaks and another 10+ Elo in eval tunings also. Still more to work on however...
!)