A Question about Crafty

[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.

[jefk]

Can you post your crafty.rc or .craftyrc file? Options have certainly changed...

ok, i think i solved it, in the code was also a 'noise' statement,
and apparently this now is in seconds instead of (m)nodes..
(and the previous value of noise was *way* to high,
so only thing displayed was 'feature'

jef
PS and the time divided by 100 i simply commented out..

[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.

Yes, but the branch is already there a few lines below:
if (depth <= draft) {

[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.

Yes, but the branch is already there a few lines below:
if (depth <= draft) {

Here's the issue. That block at the top (update age) is independent of anything else in the following code. Putting it up there lets it be interleaved with the other instructions that follow, making its cost pretty near zero. If you move it down to just before the return, it serializes and delays the return, with nothing to really interleave with. You can always test it. I did it both ways and found that on the machine I was testing on (newer xeon machine) this was very slightly faster when measuring with vTune...

[bob]

Can you post your crafty.rc or .craftyrc file? Options have certainly changed...

ok, i think i solved it, in the code was also a 'noise' statement,
and apparently this now is in seconds instead of (m)nodes..
(and the previous value of noise was *way* to high,
so only thing displayed was 'feature'

jef
PS and the time divided by 100 i simply commented out..

Not sure what you mean by "time divided by 100..." was commented out? That sounds like it would break things.

[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.

Yes, but the branch is already there a few lines below:
if (depth <= draft) {

Here's the issue. That block at the top (update age) is independent of anything else in the following code. Putting it up there lets it be interleaved with the other instructions that follow, making its cost pretty near zero. If you move it down to just before the return, it serializes and delays the return, with nothing to really interleave with. You can always test it. I did it both ways and found that on the machine I was testing on (newer xeon machine) this was very slightly faster when measuring with vTune...

OK. I used to know how to optimize code, but now it seems you need vTune or an equivalent.

[jefk]

Not sure what you mean by "time divided by 100..." was commented out? That sounds like it would break things.

well it's simply a line in this 'pipe' coding see excerpt below;
above the ------------------------------------------

[ Move = "";
sscanf(p, "%s %lf %lf %s %s", s1, &s2, &s3, s4,s5);
Depth = s1; ]
!!!!!!!?!?! Time = AnsiString(s3/100);
------------------------------------------------------
[ Score = (frmMain->Bord->MoveColor == 1) ? AnsiString(s2/100) : AnsiString(-s2/100);
etc ]

And it's only for output in the time field on the Bb Gui.
So no big deal.
btw Crafty 25.01 eval seems indeed a bit better, but
still quite different than Komodo or Stockfish (which
both also sometimes are different again..). But i did
see some option 'autotuning' for the 25.0 version,
but haven't looked into that (the 25.01crafty.ja
compile had some documentation with it); is it
worthwile to use this (ie is it working properly for users
like me ? or maybe it would require excessive comptime)?

jef

PS as next step i consider to go for a real winboard
interface, but have no hurry in this.) At the moment
it's still more of toy, but i have some ideas to make it better in
opening practice (book training) features, for beginners/intermediate.
The existing Chess Position Trainer program has good reviews
but is a bit (too?) advanced i think, especially for beginners.
And beginners shouldn't study too much opening theory
anyway, it's just a matter of having some confidence in
coming through the openings stage without any damage.

[bob]

Not sure what you mean by "time divided by 100..." was commented out? That sounds like it would break things.

well it's simply a line in this 'pipe' coding see excerpt below;
above the ------------------------------------------

[ Move = "";
sscanf(p, "%s %lf %lf %s %s", s1, &s2, &s3, s4,s5);
Depth = s1; ]
!!!!!!!?!?! Time = AnsiString(s3/100);
------------------------------------------------------
[ Score = (frmMain->Bord->MoveColor == 1) ? AnsiString(s2/100) : AnsiString(-s2/100);
etc ]

And it's only for output in the time field on the Bb Gui.
So no big deal.
btw Crafty 25.01 eval seems indeed a bit better, but
still quite different than Komodo or Stockfish (which
both also sometimes are different again..). But i did
see some option 'autotuning' for the 25.0 version,
but haven't looked into that (the 25.01crafty.ja
compile had some documentation with it); is it
worthwile to use this (ie is it working properly for users
like me ? or maybe it would require excessive comptime)?

jef

PS as next step i consider to go for a real winboard
interface, but have no hurry in this.) At the moment
it's still more of toy, but i have some ideas to make it better in
opening practice (book training) features, for beginners/intermediate.
The existing Chess Position Trainer program has good reviews
but is a bit (too?) advanced i think, especially for beginners.
And beginners shouldn't study too much opening theory
anyway, it's just a matter of having some confidence in
coming through the openings stage without any damage.

That's not my coding so I don't know what it does. Crafty displays times in various ways, such as 1.2 for 1.2 seconds, or 1:30 for 1 minute and 30 seconds. The normal time resolution is 1/100th of a second, however, to match up with the winboard protocol...

[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.

Yes, but the branch is already there a few lines below:
if (depth <= draft) {

Here's the issue. That block at the top (update age) is independent of anything else in the following code. Putting it up there lets it be interleaved with the other instructions that follow, making its cost pretty near zero. If you move it down to just before the return, it serializes and delays the return, with nothing to really interleave with. You can always test it. I did it both ways and found that on the machine I was testing on (newer xeon machine) this was very slightly faster when measuring with vTune...

OK. I used to know how to optimize code, but now it seems you need vTune or an equivalent.

With modern super-scalar processors with multiple-issue, multiple pipes, and out-of-order execution, I find it quite surprising at times as to what is fastest.

[bob]

I had forgotten to respond to the autotuning part. That is solely related to parallel search, and it simply tunes the various options reasonably close to optimal for a specific processor. The default values work pretty well, but autotune will improve the parallel search performance a bit. On machines with many cores, it might help more than a bit.