Stockfish 3 PA_GTB

[Jeremy Bernstein]

OK, I'm not too worried about a few hundred KB -- a few hundred MB would be demonstrating a potentially (very) problematic memory leak, but it doesn't seem like that's happening for you. Anyway, if anyone else notices unusual memory usage, especially with Persistent Hash enabled, please report it here. I don't think there's any real evidence that there is a problem at this point, but keep me posted...

[BorgKing]

By the way, I just saw that SF 4 is just out. Will you make a GTB version for that one too when you get the time?

[Jeremy Bernstein]

Sure, but also remember that v4 PA_GTB is nothing more than v008 PA_GTB plus a couple of extra commits -- we've been keeping pace with their updates on the road to v4.

[BorgKing]

Good to know!

Btw, if I've got it right SF 3 sets all cores by default and SF 4 is only 1 core by default. So, maybe that's why my computer has had troubles with 006 - 008!? Using only one core it seemed to use 10 times the memory...

Anyway, after setting threads to 2 there haven't been any more incidents (knock on wood).

[BorgKing]

When you get the time you may want to check up on the following bug I just noticed with the PH.

If say 43.Qh4-h5 has been deemed best by previously reaching the set ply depth for Persistent Hash, and black responds Ng8-f6 44.Qh5-h4 and then repeats the position with Nf6-g8 you get a quick draw by three folded repetition after some "best moves" even if the eval is saying that White should be winning, as SF never gets around to check for more promising alternatives.

This can also be observed in the lines it calculates, e.g. "43.Qh5 Nf6 44.Qh4 Ng8 45.Qh4 Ng8 46.Qh5 Nf6" - but usually the other engine tries to improve on that as Nf6-g8 isn't really a good move unless White keeps on repeating the position...

[Jeremy Bernstein]

viewtopic.php?f=7&t=2465