rvida wrote:
I wont bother you with numbers, just a few observations:
- difference between B and C (the worst case) was _much_ smaller with LMR off than with LMR enabled
This is very intuitive. In root node, being an all node, you need to search all the moves and if LMR is disabled there is little difference if you search one move before another.
But with LMR everything changes ! the order in which you search the moves becomes of paramount importance.
This is a concept apparentely not difficult to grasp but there is people that _still_ keep saying that he doesn't bother to sort the non-captures above a certain point.
IMHO if you want to go along the super-aggressive LMR path, then you MUST properly order every move that you want to try because move ordering makes the difference between a working LMR and a crap.
In SF 1.8 I am now testing a slightly modified ordering of non-captures, to my surpirse this slightly change seems to introduce an interesting gain (around 10 ELO). I am sure that in case we had a traditional LMR instead of the beast that is now, this gap would have been much much smaller because the change is really tiny.
I have found the same thing in Komodo, with aggressive LMR move ordering is very important.
At the root node LMR is not yet helpful for Komodo but I will be revisiting that soon. We get some speedup for doing it at the root but we pay too much in quality - and I'm sure it's probably related to move ordering.
So far I have not been real fussy about root move order - basically I sort by the result of a 1 ply search initially and then after each iteration I push the best move to the front of the list, while maintaining the ordering of the other moves. I don't believe that formula by itself is very workable for LMR.
mcostalba wrote:
In SF 1.8 I am now testing a slightly modified ordering of non-captures, to my surpirse this slightly change seems to introduce an interesting gain (around 10 ELO). I am sure that in case we had a traditional LMR instead of the beast that is now, this gap would have been much much smaller because the change is really tiny.
Inspired by your good news I have tried to change from
void MovePicker::score_noncaptures() {
// First score by history, when no history is available then use
// piece/square tables values. This seems to be better then a
// random choice when we don't have an history for any move.
Move m;
Piece piece;
Square from, to;
int hs;
for (MoveStack* cur = moves; cur != lastMove; cur++)
{
m = cur->move;
from = move_from(m);
to = move_to(m);
piece = pos.piece_on(from);
hs = H.move_ordering_score(piece, to);
// Ensure history has always highest priority
if (hs >= 0)
hs += 10000;
// Gain table based scoring
cur->score = hs + 16 * H.gain(piece, to);
}
}
Not sure but at least it is a tiny change and it seems to work in ultra fast games...
BTW, meanwhile I have found myself that very fast games are too often not reliable. On my machine it seems I need at least 15sec per game for a reasonable reliable test result.
Ralph Stoesser wrote:
BTW, meanwhile I have found myself that very fast games are too often not reliable. On my machine it seems I need at least 15sec per game for a reasonable reliable test result.
We have done some test at 5"+0 but we have now moved to 10"+0.1 and is still not clear if is enough.
Regarding your change, well it is interesting, our is tiny, but not so tiny
Ralph Stoesser wrote:
BTW, meanwhile I have found myself that very fast games are too often not reliable. On my machine it seems I need at least 15sec per game for a reasonable reliable test result.
We have done some test at 5"+0 but we have now moved to 10"+0.1 and is still not clear if is enough.
Regarding your change, well it is interesting, our is tiny, but not so tiny
We often test at 6 +0.1 and 12 + 0.2 but as the program evolves it seems like a lot of things need a lot of depth to "prove."
There are obvious things also that do not show up at such fast time controls such as search related things that don't kick in unless the depth is more substantial.
The singluar hash table move idea is a huge improvement but appears to very minor or not even useful at low depths or really fast time controls because it needs some depth to really strut it's stuff.
Ralph Stoesser wrote:
BTW, meanwhile I have found myself that very fast games are too often not reliable. On my machine it seems I need at least 15sec per game for a reasonable reliable test result.
We have done some test at 5"+0 but we have now moved to 10"+0.1 and is still not clear if is enough.
Regarding your change, well it is interesting, our is tiny, but not so tiny
We often test at 6 +0.1 and 12 + 0.2 but as the program evolves it seems like a lot of things need a lot of depth to "prove."
There are obvious things also that do not show up at such fast time controls such as search related things that don't kick in unless the depth is more substantial.
The singluar hash table move idea is a huge improvement but appears to very minor or not even useful at low depths or really fast time controls because it needs some depth to really strut it's stuff.
I had a search, but couldn't find what I was looking for. Don - what's this singular hash table move thing?
Ralph Stoesser wrote:
BTW, meanwhile I have found myself that very fast games are too often not reliable. On my machine it seems I need at least 15sec per game for a reasonable reliable test result.
We have done some test at 5"+0 but we have now moved to 10"+0.1 and is still not clear if is enough.
Regarding your change, well it is interesting, our is tiny, but not so tiny
We often test at 6 +0.1 and 12 + 0.2 but as the program evolves it seems like a lot of things need a lot of depth to "prove."
There are obvious things also that do not show up at such fast time controls such as search related things that don't kick in unless the depth is more substantial.
The singluar hash table move idea is a huge improvement but appears to very minor or not even useful at low depths or really fast time controls because it needs some depth to really strut it's stuff.
I had a search, but couldn't find what I was looking for. Don - what's this singular hash table move thing?
I tried it a couple of days ago and it doesn't help a bit. May be I should test at longer time controls as Don suggested. I used 40/30sec for the test which allows to reach d=12 on average. I also tried to use singularity search not only for the hash move but by first doing IID to get moves at all nodes as I posted here http://talkchess.com/forum/viewtopic.ph ... 23&t=35302 . It did not help at all. It seems that it is the big deal for the super strong engines now though. Please discuss more
AlvaroBegue wrote:We also observed the program during games, and it was clear that the very last move searched turned out to be chosen surprisingly often.
Are you sure it wasn't just the last move to be *finished* searching, as opposed to the last move in the array?
I ask because I've been seeing that when splitting searches at the root only. One thread will be busy calculating by itself when all the other root moves are already searched, and then after a while this thread will announce a new best move.
In my case it didn't mean it was the last move in the array, it just meant that this move took quite long to search (which makes sense considering the "many nodes" = "hard to refute" = " good move" heuristic that many are discussing here).
