Seperate root search

[laurietunnicliffe]

Hey,
What is the advantage of a seperate root search function rather than just treating the root as any other node.
I know you can do some sorting at the root, but is there always a measurable advantage/improvement in the
total search.

Thanks in advance.

[Mike Sherwin]

The advantage of a root search is simplicity meaning that some test in a regular search need not be considered. However, some engines call different search routines from the root like PVS or regular or some other flavor. I think it is just a good idea to have a root search.

[laurietunnicliffe]

Wouldn't just doing the normal search at the root be simpler ? Rather than writing a seperate function and a different move sorting.
What extra tests need to be done ? If you just run the search as normal it doesn't treat any node differently.
Are you thinking of: IF Root THEN DO this that and the other.

> I think it is just a good idea to have a root search........... I need a more technical reason than just a hunch.

[lithander]

A separate root search only makes sense if you plan to do something different in the root than in the main search. If you don't then there's no advantage. I started without one and only split the root search off the main search when needed. It's an implementation detail.

[JoAnnP38]

Hey,
What is the advantage of a seperate root search function rather than just treating the root as any other node.
I know you can do some sorting at the root, but is there always a measurable advantage/improvement in the
total search.

Thanks in advance.

One possible advantage is that you don't need to regenerate moves at the root when implementing iterative deepening. Instead generate them one time and pass the move list in. You can also update the move scores as each move is examined with the actual AB scores so that it can be sorted more "accurately" on the next iteration. This would be impractical to do at any other node than the root.

[Mike Sherwin]

Wouldn't just doing the normal search at the root be simpler ? Rather than writing a seperate function and a different move sorting.
What extra tests need to be done ? If you just run the search as normal it doesn't treat any node differently.
Are you thinking of: IF Root THEN DO this that and the other.

> I think it is just a good idea to have a root search........... I need a more technical reason than just a hunch.

It is more than a hunch. But if in your engine you have no need for a root search then don't worry about it. You can also ask if a seperate Qsearch is really needed and the answer is also no as it can also be incorporated into Search. And do you really need a seperate Search function or an initial iterate function? No just put everything in main().

[hgm]

None of my engines has a separate root search. Or a separate QS, for that matter. But there are programs that use different search routines for all kinds of different nodes, such as cut-nodes, all-nodes and PV nodes, and even for the different colors. This is mostly a micro-optimalization; the basic idea of all the nodes is the same, and the differences could easily be handled by putting the code for it in a conditional statement. E.g. when depth > 0 I suppress the stand-pat test, and when depth <= 0 I return from the node after the captures have been served, and the node would continue generating and searching non-captures. I theory you could eliminate these branches by making separate search functions, but since most nodes are QS nodes they are predicted quite well, and thus not very expensive. And you would need a branch to decide which of the dedicated functions to call anyway. And having many functions for the same task causes more pressure on the instruction cache, which can also cause a slowdown.

The root node is not really different from other PV nodes as far as search strategies go. There is one practicle difference, though: you never leave the root search function before the entire search is completed. This makes it easy to use the root move list from one iteration to the next, in particular the move ordering that was optimized from the results of the previous iterations. PV nodes deeper in the tree will return to the root before they are called in the next iteration, and would have to re-discover the optimal sorting over and over again. Of course the TT tries to make this easier, by providing a hash move that you can put in front. But this is really a very minimal attempt at sorting, for all other moves it will make the same mistakes over and over again, if the hash move fails low.

So there can be some advantage in retaining the move ordering from the previous iteration in PV nodes. (Which occurs automatically in the root.) E.g. by having a special TT for PV nodes, where the entries do not store just one hash move but the entire, sorted move list. This is affordable since there are so few PV nodes in the tree.