counting nodes vs counting evaluations

[Rebel]

When I run mine I typically get:

Code: Select all

Nodes Searched       : 65.426.495  (0:24) average  2.732M  p/s
Evaluation called    : 14.009.203         average  0.583M  p/s

Does your engine behave in a similar way?

[bob]

When I run mine I typically get:

Code: Select all

Nodes Searched       : 65.426.495  (0:24) average  2.732M  p/s
Evaluation called    : 14.009.203         average  0.583M  p/s

Does your engine behave in a similar way?

Are you doing endpoint / q-search evaluations or do you call it internally also? I do only q-search evaluations..

Here's my numbers (I don't count evals so had to add a quick fix):

nodes=8753973650(8.8B)
evals=3373776750(3.4B)
time=1:33.6 (93.6s)
nps=93.5M

[Joost Buijs]

When I run mine I typically get:

Code: Select all

Nodes Searched       : 65.426.495  (0:24) average  2.732M  p/s
Evaluation called    : 14.009.203         average  0.583M  p/s

Does your engine behave in a similar way?

My engine behaves differently.

In my engine each make(move); counts as a new node, and at every node the evaluation function is called.
This is not necessary when the king of the side to move is in check, but out of laziness I have never fixed this.
I don't do lazy evaluation because that introduces too much inaccuracies.
The evaluation function is needed at every non check node for pruning decisions.
In older versions of my engine I had a cache with results from past evaluations to speed thing up a little, but the current version doesn't have that, which is an omission.
Normally you don't need to call the evaluation function when you can prune on a past result from the transposition table, also in this case I'm wasting time.
I want to fix all these shortcomings in a new version of the engine which I'm still working on.

[Joost Buijs]

Like Bob I also added an evaluation counter and this is the result from a 22 ply search at the start position.

Code: Select all

info depth 22 score cp 31 time 48038 nodes 613958104 nps 12780675 tbhits 0 evaluations 588208482

What surprises me is that there is a difference between the number of nodes and the number of evaluations, this is something I don't understand.
It can be a bug, certainly something to look at.

Edit: When I do a null-move I don't call the evaluation function, but I just negate the value from the previous node, this is probably the reason.

[Rebel]

When I run mine I typically get:

Code: Select all

Nodes Searched       : 65.426.495  (0:24) average  2.732M  p/s
Evaluation called    : 14.009.203         average  0.583M  p/s

Does your engine behave in a similar way?

Are you doing endpoint / q-search evaluations or do you call it internally also? I do only q-search evaluations..

Internally also.

Here's my numbers (I don't count evals so had to add a quick fix):

nodes=8753973650(8.8B)
evals=3373776750(3.4B)
time=1:33.6 (93.6s)
nps=93.5M

So your ratio is 888/348 = 2.5
Mine 654/140 = 4.6

My way of counting: a node is every evaluation whether full or fast. Fast includes (succeeded) lazy eval and (succeeded) futility pruning where there is no need to do a full (expensive) eval.

[Joost Buijs]

My way of counting: a node is every evaluation whether full or fast. Fast includes (succeeded) lazy eval and (succeeded) futility pruning where there is no need to do a full (expensive) eval.

So you are only counting full evaluations as an evaluation and not the lazy ones?

I'm aware of the fact that I can speed up my engine considerably by not calling the evaluation function at nodes that are pruned by the transposition table and at nodes when side to move is in check.
This is something I still have to change, past versions of my engine were behaving normally in this respect, somehow the 'easy' fixes are always done the last.

Edit: Maybe a good reason to fix it right away.

[Joost Buijs]

I fixed the wasted evaluation calls, but it didn't improve much.
N/s went up from 12,8 to 13,5 million.

Code: Select all

info depth 22 score cp 37 time 32426 nodes 437913161 nps 13505000 tbhits 0 evaluations 389881831

This is probably due to the fact that I have disabled hashing in the quiescence search, which I found not to be very helpful in the old situation.
I have to experiment with it a little bit more, maybe adding an evaluation cache will help.

[cdani]

Andscacs:

nodes: 21,094,297
evaluations: 13,203,642

A node is every make move (also nulls).
I do evaluation for every node unless the king is in check or the evaluation is in the hash. In quiescence is equal.

[Karlo Bala]

Like Bob I also added an evaluation counter and this is the result from a 22 ply search at the start position.

Code: Select all

info depth 22 score cp 31 time 48038 nodes 613958104 nps 12780675 tbhits 0 evaluations 588208482

What surprises me is that there is a difference between the number of nodes and the number of evaluations, this is something I don't understand.
It can be a bug, certainly something to look at.

Edit: When I do a null-move I don't call the evaluation function, but I just negate the value from the previous node, this is probably the reason.

Hash hits ?!

[Joost Buijs]

Hash hits ?!

The point is that out of laziness I called the evaluation function directly from the make move, so I expected the number of make moves (nodes) and evaluations to be the same.

When doing a null move I don't call the evaluation function, since my evaluation function is symmetrical I negate the evaluation from the underlying node, this explains the difference I saw.
It is better not to count the null move as a node at all.

This morning I made some changes, I don't call the evaluation function anymore in case of a hash hit or when the king is in check.
This increased the N/S by ~5.5% which is not very much.