OpenChess

If you do not have Probeonlyat root checked you will have time losses. I unchecked it on Gran2d and the first game in a new tour was a time loss.

keoki010 wrote:If you do not have Probeonlyat root checked you will have time losses. I unchecked it on Gran2d and the first game in a new tour was a time loss.

Thanks, that's a good hint. Will investigate.

Jeremy

Frankly I believe ProbeOnlyAtRoot should always be checked, except perhaps in analysis in certain endgames. Tablebases just aren't worth enough to compensate for the speed hit. Of course this all changes if you have your tablebases on an SSD.

Peter

keoki010 wrote:If you do not have Probeonlyat root checked you will have time losses. I unchecked it on Gran2d and the first game in a new tour was a time loss.

Can you please try the attached and let me know if it's better in this regard? Leave ProbeOnlyAtRoot _unchecked_. 64-bit build only attached until I'm confident that this change is useful.

Thanks
Jeremy

And here's another one with a slightly different strategy. I'd be interested if you see time losses with it, as well (also with ProbeOnlyAtRoot disabled).

Thanks so much,
Jeremy

Using Toga with bitbases under Chessbase could be problematic. I think it had something to do with the dll that was used to read the bitbases, and Chessbase also using dll to interface with propietary Chessbase engines? Anyway that is what I suspected at the time and if the Gaviota bases are also read with a dll, there possibly could be similar problems, not related to time managment at all. Somebody should try ERT, ChessGUI or Cutechess to check Stockfish's timemanagement. Until then I don't think this is related to time management at all Could be wrong though

Regards, Eelco

Ancalagon wrote:Using Toga with bitbases under Chessbase could be problematic. I think it had something to do with the dll that was used to read the bitbases, and Chessbase also using dll to interface with propietary Chessbase engines? Anyway that is what I suspected at the time and if the Gaviota bases are also read with a dll, there possibly could be similar problems, not related to time managment at all. Somebody should try ERT, ChessGUI or Cutechess to check Stockfish's timemanagement. Until then I don't think this is related to time management at all Could be wrong though

Regards, Eelco

I'm actually pretty sure that it's the result of overly lengthy tablebase probes when Stockfish is under time pressure. The new builds explore two different strategies for restricting those probes when time management is in play.

Tablebase probing code is compiled directly into these builds, btw -- no .dlls or even statically linked libraries are being used.

Jeremy

Some bullet matches in endgame positions using Gran2c, Gran2d, Gran2e, Gran2f, Gran2g and JA seem to demonstrate that, despite the occasional time loss, the information gained from probing tablebases in non-root searching makes the engine stronger overall.

After 540 games,

e  100.5/180
c  97.5/180
d  97/180
g  90/180
f  86/180
ja 69/180

I'll do some longer time testing with full games after this RR is finished, but this may really be a non-issue. Again, it's worth noting that these builds are intended for analysis and not for bullet games, so I consider the time losses to be a curiosity that would be nice to eliminate, rather than a serious problem.

jb

Jeremy Bernstein wrote:And here's another one with a slightly different strategy. I'd be interested if you see time losses with it, as well (also with ProbeOnlyAtRoot disabled).

Thanks so much,
Jeremy

Jeremy here are the 60 games from last night. Only 1 time loss and it was for 2d. Surprise black won more games. Ponder=off sleeping threads on for all. 2d ran with ProbeOnlyAtRoot enabled the other 2 with it off. Time Management using above params for 2d the other 2 defaults. games 3/3 on i7-980x. if you think it's worthwhile I can run some more tonight.
-----------------------------Rating.dat:-----------------------------

3/3/2011 7:44:06 AM :

Program Elo + - Games Score Av.Op. Draws

1 Stockfish_201_PA_GTB_Gran2g_x64 : 2417 58 55 40 53.8 % 2391 72.5 %
2 Stockfish_201_PA_GTB_Gran2f_x64 : 2394 62 62 40 48.8 % 2403 67.5 %
3 Stockfish_201_PA_GTB_Gran2d_x64 : 2388 53 55 40 47.5 % 2406 75.0 %


----------------------------Programs.dat:----------------------------
Individual statistics:

1 Stockfish_201_PA_GTB_Gran2g_x64: 2417 40 (+ 7,= 29,- 4), 53.8 %

Stockfish_201_PA_GTB_Gran2d_x64: 20 (+ 1,= 16,- 3), 45.0 %
Stockfish_201_PA_GTB_Gran2f_x64: 20 (+ 6,= 13,- 1), 62.5 %

2 Stockfish_201_PA_GTB_Gran2f_x64: 2394 40 (+ 6,= 27,- 7), 48.8 %

Stockfish_201_PA_GTB_Gran2d_x64: 20 (+ 5,= 14,- 1), 60.0 %
Stockfish_201_PA_GTB_Gran2g_x64: 20 (+ 1,= 13,- 6), 37.5 %

3 Stockfish_201_PA_GTB_Gran2d_x64: 2388 40 (+ 4,= 30,- 6), 47.5 %

Stockfish_201_PA_GTB_Gran2f_x64: 20 (+ 1,= 14,- 5), 40.0 %
Stockfish_201_PA_GTB_Gran2g_x64: 20 (+ 3,= 16,- 1), 55.0 %


----------------------------General.dat:-----------------------------

Games : 60 (finished)

White Wins : 6 (10.0 %)
Black Wins : 11 (18.3 %)
Draws : 43 (71.7 %)
Unfinished : 0

White Perf. : 45.8 %
Black Perf. : 54.2 %

ECO A = 9 Games (15.0 %)
ECO B = 18 Games (30.0 %)
ECO C = 24 Games (40.0 %)
ECO D = 3 Games ( 5.0 %)
ECO E = 6 Games (10.0 %)


----------------------------Cluster.dat:-----------------------------
Cluster No. 1:

Stockfish_201_PA_GTB_Gran2d_x64 (2)
Stockfish_201_PA_GTB_Gran2f_x64 (2)
Stockfish_201_PA_GTB_Gran2g_x64 (2)

3 programs, 60 games

itoffset = 0.010905

Jeremy Bernstein wrote:

Ancalagon wrote:Using Toga with bitbases under Chessbase could be problematic. I think it had something to do with the dll that was used to read the bitbases, and Chessbase also using dll to interface with propietary Chessbase engines? Anyway that is what I suspected at the time and if the Gaviota bases are also read with a dll, there possibly could be similar problems, not related to time managment at all. Somebody should try ERT, ChessGUI or Cutechess to check Stockfish's timemanagement. Until then I don't think this is related to time management at all Could be wrong though

Regards, Eelco

I'm actually pretty sure that it's the result of overly lengthy tablebase probes when Stockfish is under time pressure. The new builds explore two different strategies for restricting those probes when time management is in play.

Tablebase probing code is compiled directly into these builds, btw -- no .dlls or even statically linked libraries are being used.

Jeremy

You are right Jeremy, if the tablebase probing is not done with a dll then my theory does not fly. I have not looked at the Gaviota or your code yet, because I don't have the Gaviota bases installed either yet and I decided I had no time to really study any of it anyway. But the latest results are much better even if you are considering only the vulnerability to overstepping timecontrols! It seems your strategy is working! I see there is also a 32 bit version in every package, thanks for that Jeremy, I don't have a 64 bit OS yet. Maybe I will try to download the Gaviota bases then and see if I can find some room for it. I already have Nalimov 5 piece bases, Scorpio bitbases, Shredder bitbases so one more set does not really make much difference then I was just wondering,if there were some types of positions that are really frequent with say no more than 7 pieces, and if you had some sort of position learning in combination with tablebases, then you could build the equivalent of opening books for the endgame, working backwards as it where. It would probably of limited usefulness because there are so many positions possible, but it could be a fun project! But this strategy worked better with something like checkers because there just werent that many possibilities involved. Wasn't that more or less how the game was solved?

Regards, Eelco