Lazy move generation and move ordering

[tsoj]

I have staged move generation in my program and it doesn't change anything performance wise, maybe it is even a little worse than generating all moves at once (probably because it's quite a lazy implementation by me but anyway).

[Joost Buijs]

I have staged move generation in my program and it doesn't change anything performance wise, maybe it is even a little worse than generating all moves at once (probably because it's quite a lazy implementation by me but anyway).

I have exactly the same experience. Staged move generation helps a little bit at nodes with an early beta cutoff, but on other nodes it counteracts, the net result being nil.

At an SMP split-node it also has the drawback that the delayed move generation effectively blocks all the threads working on that node until the move generation is finished, this effect is small but noticeable. It probably depends upon the way my SMP search works, usually I get somewhat better results when I generate all the moves at-once before splitting. Maybe I should distinguish between PV, CUT and ALL nodes, but in my current engine I don't look at that at all.

[Michael Sherwin]

In RomiChess which is a bitboard engine I do a hybrid staged move generation. First a pseudo move generator creates all the move and attack bitboards. At anytime if the opposing king is captured it exits immediately. Then in the staged part it starts with the hashtable move checks to see if that move/capture bit is set for that piece which is a quick move verification, negates the bit and makes the move. Bits are turned into moves and negated as needed. Very simple. Very efficient.