Moves per depth in search engines

Question

I have been implementing a chess engine myself and it is playing pretty good but it seems to calculate way too many nodes.

I was looking at this post: Stockfish nodes

And tested it with my engine.

Nc3[48.0]:     depth: 01(+0)    time[m:s:ms]: 00:00:059 total:        64    terminal :        21    fullNodes:        22    qNodes:        21
d3[-5.0]:      depth: 02(+0)    time[m:s:ms]: 00:00:006 total:       157    terminal :        48    fullNodes:        61    qNodes:        48
Nc3[43.0]:     depth: 03(+0)    time[m:s:ms]: 00:00:010 total:       771    terminal :       224    fullNodes:       323    qNodes:       224
Nc3[-5.0]:     depth: 04(+0)    time[m:s:ms]: 00:00:010 total:      1494    terminal :       415    fullNodes:       664    qNodes:       415
Nc3[15.0]:     depth: 05(+0)    time[m:s:ms]: 00:00:010 total:      2827    terminal :       787    fullNodes:      1253    qNodes:       787
Nc3[-10.0]:    depth: 06(+0)    time[m:s:ms]: 00:00:029 total:     11695    terminal :      3128    fullNodes:      5439    qNodes:      3128
Nf3[15.0]:     depth: 07(+0)    time[m:s:ms]: 00:00:163 total:    100382    terminal :     28074    fullNodes:     44234    qNodes:     28074
Nf3[-1.0]:     depth: 08(+0)    time[m:s:ms]: 00:00:205 total:    152551    terminal :     42087    fullNodes:     68377    qNodes:     42087
Nf3[6.0]:      depth: 09(+0)    time[m:s:ms]: 00:01:267 total:   1594238    terminal :    451868    fullNodes:    690326    qNodes:    451956
Nf3[-5.0]:     depth: 10(+0)    time[m:s:ms]: 00:00:982 total:   2470195    terminal :    690833    fullNodes:   1087889    qNodes:    691153

(These are results for a search to depth 10 using iterative deepening and no quiescence search.)

Basically at depth 10, the amount of nodes I am searching is almost 100 times the amount of nodes stockfish has searched.

Enabling transpositions brings this number down to 1.5 million which is still way more.

---

Maybe some information about my search:

- PVSearch
- LMR: if node is one of the first 4 or a capture, no reduction is done.
       if depth > 4, I reduce by depthLeft/3
       else I reduce by 1.
- Move ordering:
       I sort the moves in the following order:
       pv moves > good captures > killers > bad captures > no captures
- Null moves

One problem is that I do not use bitboards for move generation so I do not know if a move puts the king into check or not. (legal moves are only used for the first 2 plys)

I do not know how I could further decrease the amount of nodes.

Is this only the effect of a hyper-aggressive LMR? What else should I try?

---

UPDATE:

So I just tested some things and realised that I sort the pv move first every time I sort the moves. So I implemented that the pv move should only be sorted first if and only if it is the first node (like the left most node in the tree). I went down to 150000 nodes.

Answer 1

There’s no reason for you to scale down your engine doors if it’s fast. Why would you do that?

I am sure Talkchess used to have a post about how chess engines report searched nodes differently. I can’t find it now it was a few years ago. Read it before... their search function is not good.

If you are interested in the difference you will need to read the SF source make sure how they increment the node counter is consistent to yours. Also you may want to test SF on your own machine.

Answer 2

Too many nodes? As long as the response time is fast enough then more nodes is better.