crafty cleanup

[jwes]

Bob mentioned that he was doing a cleanup of crafty code, so I thought I'd list the odd things I have found in crafty.

In iterate.c
line 342 is
if (!(shared->root_moves[0].status & 0x38)) {
as best as I can see this causes a fail low after a fail high to skip to the next iteration. Why would you want to do this ?
lines 353 and 357 are both
shared->root_value = shared->root_alpha;
Could be a copy-paste problem.
More generally, wouldn't it make more sense to handle fail-highs and fail-lows in SearchRoot rather than in Iterate ? Then you wouldn't need that hack in NextRootMove to have fail-lows return to Iterate.

in hash.c
lines 80-82 are
htable->prefer.word1 =
(htable->prefer.word1 & 0x1fffffffffffffffULL) | ((BITBOARD) shared->
transposition_id << 61);
If I read this correctly, this sets the age to the current age to keep good entries from previous moves from being overwritten. This could be moved afteh line 93 since if the draft is not large enough, the entry will be overwritten very soon anyway. Almost the same code is at lines 143-146, but I don't see how this will help as these entries are always replaced anyway. Also the code for lockless hashing seems to be gone. Did you decide it was not necessary ?

The EVTest test is pretty much broken, as the score printed out is sometimes a cumulative score, and not the score for a prarticular term.

I also am observing more fail-highs and fail-lows taking a very long time to resolve, sometimes more than 100 times as much time as had been used up to then.

[bob]

Bob mentioned that he was doing a cleanup of crafty code, so I thought I'd list the odd things I have found in crafty.

In iterate.c
line 342 is
if (!(shared->root_moves[0].status & 0x38)) {
as best as I can see this causes a fail low after a fail high to skip to the next iteration. Why would you want to do this ?
lines 353 and 357 are both
shared->root_value = shared->root_alpha;
Could be a copy-paste problem.
More generally, wouldn't it make more sense to handle fail-highs and fail-lows in SearchRoot rather than in Iterate ? Then you wouldn't need that hack in NextRootMove to have fail-lows return to Iterate.

in hash.c
lines 80-82 are
htable->prefer.word1 =
(htable->prefer.word1 & 0x1fffffffffffffffULL) | ((BITBOARD) shared->
transposition_id << 61);
If I read this correctly, this sets the age to the current age to keep good entries from previous moves from being overwritten. This could be moved afteh line 93 since if the draft is not large enough, the entry will be overwritten very soon anyway. Almost the same code is at lines 143-146, but I don't see how this will help as these entries are always replaced anyway. Also the code for lockless hashing seems to be gone. Did you decide it was not necessary ?

The EVTest test is pretty much broken, as the score printed out is sometimes a cumulative score, and not the score for a prarticular term.

I also am observing more fail-highs and fail-lows taking a very long time to resolve, sometimes more than 100 times as much time as had been used up to then.

I will keep these handy, as everything is subject to cleanup at the moment. And yes, that part of iterate.c is impossibly complicated. As far as whether to handle fail highs in the root or in iterate, it is probably related to splitting at the root, which Crafty does (I think it is probably the only program doing so as that adds some complexity most want to avoid).

The lockless stuff has been removed, yes. It has a cost, and with very large hash tables, and the fact that I can easily and quickly verify that the hash move is legal on the current board, I decided to get rid of the cost and accept that every now and then (maybe 10-20 times per game) I will get a broken hash entry, and about 1/2 of those (fail-low nodes) will probably have a bad score that I will trust. But after the hash collisions research last year, this has essentially no chance of affecting anything.

If you notice anything else, let me know. The move generators are done, as are make/unmake, and about 75% of evaluate.c. So far, over 2,500 lines of code have been removed as the black/white duplication is eliminated.

BTW the fail-high/fail-low is an issue, but it is greatly aggravated by the search reductions, since moves that fail high probably have a ton of reductions in the search, and the re-search suddenly can't use them which blows the tree up. It just comes with the selectiveness...

[afterthought]

What version are you looking at? Your line counts didn't exactly match 21.6...