any tips for glaurung

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Uri Blass
Posts: 10282
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: any tips for glaurung

Post by Uri Blass »

kaustubh wrote:I have glaurung source , can anyone give me any tips for making changes in the source.
I do not know if this tip works but I noticed that glaurung has the following code:

Code: Select all

if(moveCount == 1) 
        value = -search_pv(pos, ss, -beta, -alpha, newDepth, ply+1, threadID);
      else {
        if(UseLMR && depth >= 2*OnePly && !isCheck && ext == Depth(0)
           && moveCount >= 7 && !moveIsCapture && !move_promotion(move)
           && !moveIsPassedPawnPush && !move_is_castle(move)
           && H.ok_to_reduce(pos.piece_at(move_to(move)), move)) {
          ss[ply].reduction = OnePly;
          value = -search(pos, ss, -alpha, newDepth-OnePly, ply+1, true, 
                          threadID);
        }
        else value = alpha + 1;
        if(value > alpha) {
          ss[ply].reduction = Depth(0);
          value = -search(pos, ss, -alpha, newDepth, ply+1, true, threadID);
          if&#40;value > alpha && value < beta&#41;
            value = -search_pv&#40;pos, ss, -beta, -alpha, newDepth, ply+1, 
                               threadID&#41;;
        &#125;
      &#125;
I have 2 questions about it.

1)Is it a good idea to have 2 similiar functions and writing the code twice
Namely search_pv and search?
2)In case that reduced move fail high glaurung does not research with alpha beta but with alpha and alpha+1 and only if the second search fail high again it researches with alpha and beta.

I wonder if it is a good idea to do it.
After fail high with alpha+1 you can expect another fail high so the question is if there is a reason to spend time on 2 researches instead of one research.

Uri
Tord Romstad
Posts: 1808
Joined: Wed Mar 08, 2006 9:19 pm
Location: Oslo, Norway

Re: any tips for glaurung

Post by Tord Romstad »

Uri Blass wrote: I do not know if this tip works but I noticed that glaurung has the following code:

Code: Select all

if&#40;moveCount == 1&#41; 
        value = -search_pv&#40;pos, ss, -beta, -alpha, newDepth, ply+1, threadID&#41;;
      else &#123;
        if&#40;UseLMR && depth >= 2*OnePly && !isCheck && ext == Depth&#40;0&#41;
           && moveCount >= 7 && !moveIsCapture && !move_promotion&#40;move&#41;
           && !moveIsPassedPawnPush && !move_is_castle&#40;move&#41;
           && H.ok_to_reduce&#40;pos.piece_at&#40;move_to&#40;move&#41;), move&#41;) &#123;
          ss&#91;ply&#93;.reduction = OnePly;
          value = -search&#40;pos, ss, -alpha, newDepth-OnePly, ply+1, true, 
                          threadID&#41;;
        &#125;
        else value = alpha + 1;
        if&#40;value > alpha&#41; &#123;
          ss&#91;ply&#93;.reduction = Depth&#40;0&#41;;
          value = -search&#40;pos, ss, -alpha, newDepth, ply+1, true, threadID&#41;;
          if&#40;value > alpha && value < beta&#41;
            value = -search_pv&#40;pos, ss, -beta, -alpha, newDepth, ply+1, 
                               threadID&#41;;
        &#125;
      &#125;
I have 2 questions about it.

1)Is it a good idea to have 2 similiar functions and writing the code twice
Namely search_pv and search?
At the moment, it probably doesn't matter at all. Having a separate search function for PV nodes increases the code size slightly, but may also make the program 0.01% faster, because I don't have to scatter "if(pvNode) ..." statements around in my search. Not very important, of course.

The reason I separated my search into two functions is that I expect that the difference between what I do at PV and non-PV nodes will get considerably bigger when my program grows more mature. For instance, I plan to experiment with very different move ordering schemes at PV nodes, and to make time managment decisions based on fail highs at internal PV nodes (I have a simple special case of this already in my current development version; I extend the thinking time when failing high at PV nodes at ply 1). Eventually the search_pv function may end up looking similar to the root_search function (but without code for writing search output and MultiPV mode). Internal PV nodes resemble the root node, and it makes sense to use similar techniques both places.
2)In case that reduced move fail high glaurung does not research with alpha beta but with alpha and alpha+1 and only if the second search fail high again it researches with alpha and beta.

I wonder if it is a good idea to do it.
After fail high with alpha+1 you can expect another fail high so the question is if there is a reason to spend time on 2 researches instead of one research.
Thanks for the suggestion! Intuitively, I don't expect it to work: The zero-window search is cheap, and even though it is unnecessary work in most cases, it saves a lot of nodes in the less usual case where a move is good at depth N-1 but not at depth N. I would guess that the difference is tiny, but that using the zero-window search is slightly better.

But my intuition is frequently wrong, and your suggestion certainly deserves to be tested. I'll add it to the list of things I should try.

Tord