OpenChess

petevine wrote:Yeah, but is it equivalent to PH off in a completely new position NPS-wise?

Except for any time spent reading in positions from the hash DB, more or less. There will be a tiny hit for iterating the PH TT and determining that there's nothing which needs to be written. This time should be negligible, but not zero.

But I'll add that if you are exclusively concerned about NPS, this is probably the wrong fork of Stockfish for you.

I'll consider a true read-only mode for the next release, though (whichever SF build gets to the highest stage of season 6 of TCEC gets a new build). It never occurred to me that anyone would need that.

jb

Thanks for the in-depth reply!
I have probably found an issue so let's move to the really important stuff.
On linux, upon engine startup if the PH file is a symlink to a file on a usb device (fat filesystem) the symlink gets replaced with the actual file. If the full path to the external filesystem is given, nothing gets written to that file but a new empty one is created next to it with a tmpkch suffix.
I don't think it's a permissions problem as critter's sf file works fine on the same fs but then what else could it be?

petevine wrote:Thanks for the in-depth reply!
I have probably found an issue so let's move to the really important stuff.
On linux, upon engine startup if the PH file is a symlink to a file on a usb device (fat filesystem) the symlink gets replaced with the actual file. If the full path to the external filesystem is given, nothing gets written to that file but a new empty one is created next to it with a tmpkch suffix.
I don't think it's a permissions problem as critter's sf file works fine on the same fs but then what else could it be?

Hmmmm, that's pretty crazy. I'll have to do some tests and get back to you.

Clearly, the issue must be related to the fact FAT is not a real unix fs and stockfish might be trying to do sth unix specific on the file or if you can't replicate the problem, maybe certain mount flags of that fs forbid it.

petevine wrote:Clearly, the issue must be related to the fact FAT is not a real unix fs and stockfish might be trying to do sth unix specific on the file or if you can't replicate the problem, maybe certain mount flags of that fs forbid it.

I am pretty sure the Kyoto Cabinet (the DB used by the PH) is 100% responsible for the creation of that file (I haven't had a chance to look and refresh my memory). I might need to do some surgery on KC if I can't find some way to make it work using flags. I don't have a Linux ready-to-go, but I downloaded Mint last night and will get it up and running in a VM today, and hopefully will have time to take a closer look in the course of this week.

jb

OK, after some minor wrangling on Linux, I have it building and running, but I'm not actually getting any response from the engine (like when I type 'uci'). Did you have to make any source-level changes to make it work on Linux, before I start spending time on figuring it out myself?

Thanks -
jb

I don't think so - I remember compiling qdbm and kyoto though.
I'm attaching an strace of the symlink scenario.

petevine wrote:I don't think so - I remember compiling qdbm and kyoto though.
I'm attaching an strace of the symlink scenario.

Thanks. I got it running after doing a 64bit-modern build, which maybe points to some other problem.... *sigh*

jb

Hi,
Correct if I'm wrong but shouldn't both formats lead to the same stored position in the PH file? Right now if you analyse a 960 chess position given in X-fen there's nothing available if you go back to it in Shredder format.
With both castling rights available (and 2 rooks present) or 1&1 there shouldn't be any difference anyway.
Thx

More precisely it looks like the standard Shredder format PH entries get overwritten by X-fen whereas the latter don't leave a trace altogether in subsequent analysis (even though the PH file seems to grow).
I've encountered this scenario in scidb application which seems to store/import c960 games in X-fen.