A Question about Crafty

[jefk]

but autotune will improve the parallel search performance a bit. On machines with many cores, it might help more than a bit.

ah ok, on my main machine (8 threads) i've set mt 7, so i might
have a try on this later; if i can find some explanation with
that .ja compile how to do it; the crafty.hlp doesnt show in my
win7 but i might be able to fix that as well as budding&old 'hacker'.

As for the 'time 'option in the crafty output in
my Gui (*) , i've removed the commenting again,
and to my surprise it works again so it was the noise
feature indeed which was the (only) culprit..
The used time is displayed in hundreds of a second
which is a real cool feature for those favoring
bullet or lightning; maybe i should increase the
fonts-ize a couple of times eg ten bigger (and
then let the time decrease from eg. one second per
human (opening) move to zero..; would be cool training
feature and besides the pipe there's anyway already some
rudimentary xboard functionality; sofar only using max
depth/crafty move i think and not time; ah well -> todo..

www.bookbuilder.nl

jef

PS as for this (strange pipe) coding, it also isn't *my* code..
in fact i 'had' some four programmers or so; with varying
clarity; (and (lack of) documentation ); with 3 Dutch
done it (almost) free; for which i'm still grateful one a certain
Langeveld maybe brother of the more known ICCF guy who
cleaned up some standards and try to improve clarity;
whereby the original Hamstra code (and board component
inclusive lack of any commenting or documentation) is about
as transparent as ancient Egypt (or alien?) hieroglyphs.
At least the old version still is able to do a 'full minimax'
now for some thirty million positions on one thread
and then still only within half an hour or so (although
some ten million might be loose nodes; todo as well);
chessok software should be able to clean up loose
nodes in an Epd file; unfortunately in my tests sofar
it also cleaned up most of the most important nodes..

[jefk]

but autotune will improve the parallel search performance a bit. On machines with many cores, it might help more than a bit.

have a try on this later; if i can find some explanation with
that .ja compile how to do it; the crafty.hlp doesnt show

ah, no problem, in one crafty2501.ja download there's a crafty.hlp
already translated into a .txt file; so running autotune now..
Stage II will take some 4 hrs (with input 20 12) no
problem, as i'm curious about the results.

[jwes]

I was looking at the code and saw that you update the age if you get a hit and the age is different. You only need to update the age if it causes a cutoff as otherwise the entry will be overwritten when the search of this node returns.

Right, but it is faster to just do it every time. It gives more work to do that can be interleaved with the branch prediction stuff and it doesn't add additional branches that also have to be predicted.

But is it faster to check the age, and not just overwrite on every hash hit?

[bob]

I was looking at the code and saw that you update the age if you get a hit and the age is different. You only need to update the age if it causes a cutoff as otherwise the entry will be overwritten when the search of this node returns.

Right, but it is faster to just do it every time. It gives more work to do that can be interleaved with the branch prediction stuff and it doesn't add additional branches that also have to be predicted.

But is it faster to check the age, and not just overwrite on every hash hit?

It wasn't when I tested. I can't guarantee that right this instant without testing again. Probably something like fine #70 would be the best test, a position where there are LOTS of signature matches...

I just tested and didn't see any speed difference I could measure, on my macbook i7. However, for fine 70 this DOES change the node counts dramatically, because it affects replacement since my first pass is to replace entries with exact signature match, then replace an entry with the oldest "age" (from previous search) and then finally replace entry with lowest draft. Not updating the age unless it is a useful EXACT, LOWER or UPPER entry changes the node counts on fine 70 significantly. Not so much on more normal positions.

[bob]

I actually think I like your idea a bit better, I just moved that down to the three places where a hash causes a return with no further searching, and then did the age update in those three places, which skips the case where there is a sig match but no cutoff...

It makes minor node count changes if you take fine 70 and use old and new approach, and search to something pretty quick (depth=50 takes 5 secs on my macbook). Then play the predicted move which will cause the age updates to happen, and the node counts will change a bit.

You've earned a comment in main.c

[jwes]

I'm honored.

[bob]

I'm honored.