Stockfish version with hash saving capability

[zullil]

BTW, I just tested AsmFishW save and load hashes: it doesn't work at all, even if no move is made.

I just tested the Linux version. TTSave worked. TTLoad did not---until I discovered that the file created by TTSave had permissions 000. Once I made the file readable, TTLoad worked.

Then, a more interesting test you could run could be, with little hash size:

a) let AsmfishW analyze a position until a consistant fail high/low happens.
b) save hash
c) close and restart GUI
d) load hashes and chech if AsmFishW hits the fail high/low immediately.

Here, it didn't work. I'm curious if it works under linux.

Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...

[Rodolfo Leoni]

Is the saving-hash engine capable of doing this? And if not, why is it then useful in connection with persistent hash?

What the "saving-hash engine" is?

In my PC, AsmFishW cannot do it. Stockfish "savehash" version by Daniel can.

About PHs, you use them to run analysis, trying different moves and variations. At analysis end, all key positions are kept in the hashes, but you have to turn your PC off sooner or later. If you need to resume your analysis later, you need a save/load option. That's why I asked Daniel to include them, few time ago...

[Rodolfo Leoni]

Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...

Komodo has the save/load hashes feature too, but I didn't test it as well. It's lunch time now.. See later.

[zullil]

BTW, I just tested AsmFishW save and load hashes: it doesn't work at all, even if no move is made.

I just tested the Linux version. TTSave worked. TTLoad did not---until I discovered that the file created by TTSave had permissions 000. Once I made the file readable, TTLoad worked.

Then, a more interesting test you could run could be, with little hash size:

a) let AsmfishW analyze a position until a consistant fail high/low happens.
b) save hash
c) close and restart GUI
d) load hashes and chech if AsmFishW hits the fail high/low immediately.

Here, it didn't work. I'm curious if it works under linux.

Actually, I'm beginning to have some doubts too. So far not seeing any indication that the loaded hash is resulting in a faster search. Guess I need to test more...

Definitely seems like there are issues here. Using a saved hash seems to hinder the search rather than help it. Load followed by immediate save produces a file different from what was loaded, which seems odd ...

[Rodolfo Leoni]

I found HGM post with the idea he found for having hashes persistent:

http://www.talkchess.com/forum/viewtopi ... 847#721847

And this is the exact paragraph:

The solution is quite simple: engines should realize that an interactive analysis session is in fact a single search, where the low plies are governed by the user, and the root positions of the various analysis searches are not root positions at all, but just internal nodes of the tree the user is constructing. As such, they should not increment the search number during analysis. They are just not different searches, but part of the larger one.

In my engines incrementing the search number only before searches intended to play in a game ('thinking'), and leaving it as it was in an analysis search, did solve the problem.

Then, Daniel adopted that idea and he encoded it, both in Andscacs and in a Stockfish version.

Besides, engines needed their hashes free for better performance when playing against an opponent. This option makes a sense only when in infinite analysis, as the player could need to keep track of good and bad variations. The clues for keeping track of them are propagated scores.

[peter]

Hi!

I tested 1 GB hash size and 128 MB size, by making moves and trying different variations. Both sizes keep entries fine enough.

D'accord.
But more then 2G isn't possible here with me at Win7x64Pro. From 4G upwards stored file doesn't show in Win Explorer neither (name appears but with 0 Kb).
Tried Fritz14 and Shredder13 GUI

[peter]

Hi Rodolfo!

Here you're not quite right, I guess. Making a move doesn't normally delete the hash, it "ages", some entries are overwritten, others are kept of course.

The aging of hash is one of the most difficult and from engine to engine different point in engine- programming, e.g. Mark Lefler once wrote in an email to me, he wouldn't want a "Keep Hash"- feature for komodo at all, but even as for engines where you have that feature, e.g. Shredder, if not activated (Shredder has that UCI- Option to chose) the hash isn't "deleted" by making moves ony neither.

But I'm rather sure too, asmFish has a problem as for communication with some GUIs and for it's Save Hash- command.

There aren't any valuable entries stored by "Save" nor reloaded by "Reload", even if the file is stored and shown in Win Explorer in chosen bigness, and Shredder13- GUI even does count down the amount of stored and reloaded data.

Yet time to solution for tactical positions with difficult to find solution is nowhat better after Save and Reload.

That problem is well- known as for komodo since a long time too, you can't store hash in Fritz- GUI e.g., Mark Lefler knows about the issue, he too says it's the GUI's problem not the engine ones.

You can store hash with komodo in Arena or Shredder, this one file you can reload then in Fritz too, (don't forget to "Delete Hash" before reloading the stored one or restarting the engine ((changing it or srarting the GUI newly works as well as "Delete Hash", maybe "Save" or "Reload" does so too as for the engine- communication with the GUI ) than time to solution of an already "found" hidden one is practically zero (as well as not changing the engine nor delete the hash by command) after reload and that's how it's meant to be, everybody can try out easily.

AsmFish doesn't store valuable hash- entries by save and reload, not in Fritz14 nor in Shredder13, about command- line- engine I can't tell , didn't try that neither

[Rodolfo Leoni]

Hi Rodolfo!

Here you're not quite right, I guess. Making a move doesn't normally delete the hash, it "ages", some entries are overwritten, others are kept of course.

The aging of hash is one of the most difficult and from engine to engine different point in engine- programming, e.g. Mark Lefler once wrote in an email to me, he wouldn't want a "Keep Hash"- feature for komodo at all, but even as for engines where you have that feature, e.g. Shredder, if not activated (Shredder has that UCI- Option to chose) the hash isn't "deleted" by making moves ony neither.

But I'm rather sure too, asmFish has a problem as for communication with some GUIs and for it's Save Hash- command.

There aren't any valuable entries stored by "Save" nor reloaded by "Reload", even if the file is stored and shown in Win Explorer in chosen bigness, and Shredder13- GUI even does count down the amount of stored and reloaded data.

Yet time to solution for tactical positions with difficult to find solution is nowhat better after Save and Reload.

That problem is well- known as for komodo since a long time too, you can't store hash in Fritz- GUI e.g., Mark Lefler knows about the issue, he too says it's the GUI's problem not the engine ones.

You can store hash with komodo in Arena or Shredder, this one file you can reload then in Fritz too, (don't forget to "Delete Hash" before reloading the stored one or restarting the engine ((changing it or srarting the GUI newly works as well as "Delete Hash", maybe "Save" or "Reload" does so too as for the engine- communication with the GUI ) than time to solution of an already "found" hidden one is practically zero (as well as not changing the engine nor delete the hash by command) after reload and that's how it's meant to be, everybody can try out easily.

AsmFish doesn't store valuable hash- entries by save and reload, not in Fritz14 nor in Shredder13, about command- line- engine I can't tell , didn't try that neither

Hi Peter.

The advantage when dealing with people much more expert than me is that I learn something new daily. I have to study hash behavior better, I guess.

Thanks!

[Rodolfo Leoni]

..............................
The aging of hash is one of the most difficult and from engine to engine different point in engine- programming, e.g. Mark Lefler once wrote in an email to me, he wouldn't want a "Keep Hash"- feature for komodo at all, but even as for engines where you have that feature, e.g. Shredder, if not activated (Shredder has that UCI- Option to chose) the hash isn't "deleted" by making moves ony neither.

.................................

I gave a look at TT.cpp SF8 source. I understand 0% of code, but, at least, I got an idea about how it works on SF.

Code: Select all

/// TranspositionTable::probe() looks up the current position in the transposition
/// table. It returns true and a pointer to the TTEntry if the position is found.
/// Otherwise, it returns false and a pointer to an empty or least valuable TTEntry
/// to be replaced later. The replace value of an entry is calculated as its depth
/// minus 8 times its relative age. TTEntry t1 is considered more valuable than
/// TTEntry t2 if its replace value is greater than that of t2.

It seems clear enough.

[peter]

Thanks!

You're welcome.
Of course programmers could explain much better than me what I meant to say about aging of hash in game- playing and in analysis- mode