Null move: minimum depth

[Joost Buijs]

So depth 6 is 334k nodes in 2112ms, so 158k nodes per second (on an "Intel(R) Celeron(R) CPU 1037U @ 1.80GHz").

It seems a bit slow.
I don't know the performance of this processor, I guess it's an Ivy-Bridge.
Most engines I know run about 1 mnps on a processor like this.

I think because I'm not using bitboards etc.

It looks as if you don't use any pruning at all, 334k nodes is al lot for a 6 ply search.
My engine (which has not a very good BF either) does about 8k nodes on a 6 ply search from the initial position.

What is the low hanging fruit for pruning?

I do have a +/- 20 elo points gain from the version I combatted with at the csvn tournament. Not too bad!

My engine is very basic, it uses a transposition table, a history table for move ordering, 2 killers, futility, null-move and LMR.
So nothing fancy at all.
Your branching factor looks very bad, maybe your quiescence search is exploding.

[flok]

My engine is very basic, it uses a transposition table, a history table for move ordering, 2 killers, futility, null-move and LMR.
So nothing fancy at all.
Your branching factor looks very bad, maybe your quiescence search is exploding.

I found at least one bug yesterday evening. Well, not really a bug but more of a deficiency: when I found a hit in my "prevent repetition"-position-list, I would check if the number of possible moves in that node was 1. If so, I would keep searching and only if number of moves was > 1 I would use score 0 and continue.
Now I have a total of 242951 nodes for depth 6 with 134704 for quiescence.

My q-s:
- has its own tt
- also checks the regular search tt
- checks if the material gain is x where x is calculated before the move-iteration and is alpha - eval_of_the_current_node
- ...or if the move is a promotion to queen/knight